I am reposting this article I wrote here since it is no longer available at the original publication source! Enjoy!

GD

Disruptions are productivity killers. If you are reading this, perhaps you already know that. There are times when taking a break to chat with your peers and co-workers can actually help you get back on track.

had one such chat with Jeremy Woertink about team dynamics and communications for a talk I will be doing in Austin for this year’s SXSW Interactive Conference, and I needed to validate my thoughts with my peers. After about 3 breadsticks and half a salad (since we were chatting at Olive Garden), he told me about how important non-technical people are to a developer.

We were chatting about distractions, and I was stressing the importance of limiting distractions as a developer (a topic I care very much about), but he wanted to stress the importance of having those distractions, just at the right times. Downtime for a developer is needed, as with any vocation, to recharge and clear your head. This becomes even more important when you are really blocked by a task. This is why you see a Foosball table or Xbox in the common areas of many dev shops. It’s sometimes in these moments where a stuck developer can finally figure out how to solve a problem or architect a new feature.

He went on to say, “At the least, finding a good Rubber Duck can save a bad day.”

Confused? Let me give you an example:

“What’s up, Jeremy? You look stressed out.”

– Sales Dude

“I’m struggling with this weird bug! I’ve got all these employee objects that my code goes through and I want to update the employees that have more than … huh. Actually, I think I know what it is now. Thanks for your help.”

– Rockstar Developer Jeremy

blinking hard

– Sales Dude

Sales dude was Jeremy’s Rubber Duck.

A Rubber Duck is the concept of explaining a programming problem to someone else, possibly even to someone who knows nothing about programming, and then hitting upon the solution in the process of explaining the problem. The mere act of attempting to describe both 1) what the code is supposed to do and 2) what it actually does, can often make the actual problem clear.

The name Rubber Duck comes from an idea in The Pragmatic Programmer (1999), a non-technical book by Andrew Hunt and David Thomas, that explores software development as a craft. In one chapter, Debugging Strategies, the author suggests explaining the code line by line to an inanimate object, like a Rubber Duck, to accomplish this without an actual person.

Why would the author use a Rubber Duck as an example? David Thomas worked with a research assistant named Greg Pugh who would carry around a small yellow duck that he would place on his 3270 terminal while coding.

Work on a team with some developers? Don’t leave them pair programming with Rubber Ducks…offer your ear, don’t say a word, and let them do all the heavy lifting.

Rubber Duckie, you’re the one,
You make bathtime lots of fun,
Rubber Duckie, I’m awfully fond of you;

(woh woh, bee doh!)

Rubber Duckie, joy of joys,
When I squeeze you, you make noise!
Rubber Duckie, you’re my very best friend, it’s true.

Every day when I,
Make my way to the tubby,
I find a liddle fellah who’s,
Cute and yellah and chuu-by
(Rub-a-dub dubby!)

Rubber Duckie, you’re so fine,
And I’m lucky that you’re mine,
Rubber Duckie, I’m awfully fond of,
Rubber Duckie, I’d like a whole pond of-
Rubber Duckie, I’m awfully fond of you!

Back in the day, it was easier to tell what app it was! (Image from MacWorld.com)

I use Mission Control in OSX all the time. But I also have a dozen apps open most days. It’s hard to tell, the apps apart sometimes. Is that Chrome or FireFox? I always wanted Apple to bring back a little app icon to the tiny representation of the app. I did learn something recently that might be a useful if you suffer the same pain.

You can use quick view while in Mission Control. When the tiny window is highlighted, tap the space bar to make it bigger.

The repo can be found here.

You can see a working example here.

Get the right people communicating. You know that the founding team is so important; now really learn how to value what each member brings to the team. Learn how to create a culture of value between the sales and the dev team. Pick up on key factors that are driving your founding individuals so that you can truly learn how to communicate in their language.

This is a must-have conversation. Come watch it unfold live and take it back to your team with an immediate action plan.

Vote and comment here: http://panelpicker.sxsw.com/vote/38031

It started with a fun experiment on Facebook that turned into a brutal month of work. With the OpenFloor MVP released, I am looking forward to a few days of reflection and talking with some of our first set of users to find out what they like, what they don’t really like, and what they want to see next. Rinse. Repeat.

I am so thankful for the tools developers have at their disposal now. Getting what we have done in a month would have taken 3-6 months years ago.

Problems like this is why I prefer backend development. One browser crashing for what appears to be no good reason, and no real way to troubleshoot except commenting out code and running to try and find the culprit, just raises my blood pressure.

I have two routes specified in my header. New and Popular.

If I switch quickly between the two (progress bar never gets to right side of page before I click the alternate route) I can eventually create an error in Safari that says “a problem occurred with this webpage so it was reloaded.”

The other crazy thing to note was that the error never happened if we had the safari developer console open!

Even before I tried to find the needle in this haystack, I decided I might need to tighten up my routes and templates. Even after a 3 hour clean up sesh that started at 2am, and still getting nowhere (except code to clean you could eat of it) my co-founder and I had to get dirty commenting out small chunks of code until the app was stable.

What we discovered the issue was, and the workaround, still makes me shake my head…

We had a list of items being rendered into a template like this:

{{#each itemsWithRank}} 

    {{> itemItem }} 

{{/each}}

Super simple, but commenting this each block helper stabilized our crashes. Why would this be an issue? It’s really no different than many of the examples we have seen on the web or in other projects.

My co-founder decided to just wrap the the template inside the each block with a div, prevented our error. All we did was this:

{{#each itemsWithRank}} 

    <div> 

        {{> itemItem }} 

    </div> 

{{/each}}

Still not sure why this is needed, only for Safari, but it works! I hope this saves you some time, because it took us far too long to figure this out.

http://tech.co/george-diab-launches-openfloor-2014-08

Downtown Las Vegas just got a brand new platform from the minds of George Diab and Max Aceituno. OpenFloor, as they’re calling it, is a combined effort of their combined UX and programming skills to bring a Q&A platform into the spotlight.

OpenFloor was designed as a hyper-engaged question and answer platform that allows anybody the experience of being the authority on a topic. The unique UX of OpenFloor heightens the engagement and can be used for fun, educational purposes, or even brand promotion.

It feels very similar to Reddit’s popular Ask Me Anything (AMA) threads, and there are already a host of Downtown Vegas entrepreneurs who have opened the floor for questions. Frank Gruber and Jen Consalvo each did their own as well; their responses are awesome.

Pretty exciting to get written up in Tech Cocktail, and we are from launched, but if gmail can have the BETA flag for two years, I suppose we can hold on to it a bit longer too.

At OpenFloor, we decided to use Slack for team communication. We also had a use case for getting real time notifications into a specific channel or two for when users do a certain action. Also, I thought it would  just be easier to have users feedback submit right to a feedback channel for discussion with the team. When I checked the meteor package repo Atmosphere, I was surprised a package for slack didn’t exist. I had been raiding these packages for use in our MVP, so I thought I’d give back by writing and sharing the slack package I wanted for myself.

Well here it is: https://atmospherejs.com/package/slack-notify

I hope you will find it as useful as we do!

Max and I are in! We submitted our idea to The Mill two weeks ago, and today it is official!

It started with an experiment on Facebook. I just wanted to engage my audience on Facebook, so I typed up a simple status update and hit submit.

“The floor is open for questions.”

What happened next was a ton of fun, I had an incredible amount of engagement and conversations with many of my friends on Facebook. It was mostly playful and fun, but it was more engagement than I had with anything I had posted in the recent past.

A few days later I did it again. Same engagement, same experience, very satisfying.

Then over the next 7 days, I saw a few of my friends do the same thing on their walls! Ah…Validation! With some prodding from my now co-founder to make this experiment into an app, we decided to submit an application to our local Idea Accelerator, The Mill.

The Mill starts with a $5k investment, two months of office space at the downtown co-working space Work In Progress, and sprinkles in a few great mentor-ships and networking opportunities.

So here we go! I can’t wait to see my friends and peers open the floor in the near future!

A few months back I was given access to a local start-up teams Hackpad, and I was just blown away. I had heard of Hackpad before that, but I was comfortable with Google Docs, and couldn’t see a reason to swtich.

Seeing how this team used Hackpad to keep the ENTIRE team organized, I was sold. I couldn’t wait to implement it with my next team. This of course isn’t easy to do with an existing team. Most teams are resistent to changing tools, especially the non-technical team members. I understand the resistance.  Besides having to export all the current content, it can be a drain on a team lead or CTO to retrain and educate some of the other individuals on a team, so often the team continues to use “what we have used from the start.

A great tool is worth the effort and if you believe in it as a leader of a team, you need to work with your team to get all of them to buy in and commit to it’s use. Without exception. Consistency is important, and members of the team will often fall back on what they are used to. It’s to be expected, but be firm, and get everyone on the same page as quickly as possible.

I am researching the Meteor framework for a new project, and I was giddy to find the Meteor team using hackpad, and having it open to the public. That was exciting to find.

Check it out here:

https://meteor.hackpad.com/