“Hey! I’m walking here!”
– Dustin Hoffman’s character in Midnight Cowboy*
* I don’t know the name of the character, I haven’t actually watched the film. My dad says it doesn’t have a happy ending. Most people might get annoyed and consider this to be a spoiler, but I’m glad I didn’t spend 2 hours watching something that would ultimately upset me. I probably shrugged and watched a film with The Muppets instead. I do like The Muppets.
How Programmers Work
We programmers are a fickle lot. When a programmer is writing code, they have a lot going on in their head. In psychology, this is known as ‘Flow’.
“In positive psychology, flow, also known as zone, is the mental state of operation in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity.” – Wikipedia.
In a documentary called Cybertopia – Dreams of Silicon Valley, Google Product Manager David E. Weekly was asked to describe what sort of state he feels like he’s in when he’s coding. His answer was something I could relate to.
“… most of the time there’ll be a lot of different components that all fit together… You might have some networking code over here, you might have a database that’s over here, you might have some functionality that’s over here and you might have some graphical output that’s over here and you’re thinking about how it all threads together.”
So, while on the outside it might look like they’re just staring at a computer screen, there’s a lot going on inside. David E. Weekly goes on to compare this thinking process to building lego with his mind.
So anyway, back to the Muppets.
So, What’s the Problem?
Interruptions are the problem.
When someone interrupts you, they’ve just broken the lego construction in your head. In the classic work environment, if the telephone rings or if someone approaches you while your in the middle of Work Flow, it can take time to put all of these components back together again.
I realise this must sound like hogwash to non-programmers, but it’s true.
There has been a recent rise in the number of in-house development teams being installed in more traditional workplaces. This means programmers are being ‘reintroduced to the wild’ so-to-speak.
You want to get the best out of your programmers and engineers. Here’s how “not to annoy them too much”.
How To ‘Not Annoy A Programmer… Too Much’
I once worked for a design agency where the project manager would verbally alert me to problems with the website as she noticed them. There are 2 issues with this –
1. it’s interrupting something else that I’m working on
2. there is nothing to document that this request was delivered.
The best way to do this is to put together a document with a list of changes. Include screenshots or any information required to repeat the issue you had. Schedule a QA session and go through each item individually. You need a list, and you need to talk them through the changes you want.
1. List the Changes
The great thing about having a list is that when you can physically cross off the items that are done. There is now a record of the changes and fixes that were requested. You can return to your daily grind, and the programmer can block out an appropriate amount of time to focus on the problems you have given them.
2. Arrange a Meeting
You need to set aside time to talk them through the changes because In some cases, meetings are the only way to make sure everyone’s on the same page. This can even happen over the phone. They work best when they’re scheduled, that way everyone can have a prepared list of questions ready in advance.
3. Let Them Work On It
When you’ve given a programmer a list of changes, let them do their thing without interruption. Let them block out time to fully focus on whatever it is you need them to look at. Try not to let people from other teams to interrupt them either.
And next time someone approaches a programmer and they seem unfriendly, it’s not because they don’t like you… it’s because in their heads, you just broke their lego castle.
