How to Work with Programmers

Sharing the Same Room with a Programmer

We need silence. Every time you speak loud next to a programmer, you may be planting a bug into his/her code. Every time you interrupt a concentrated programmer, you demolish a mental card castle which he/she must rebuild.

If a programmer is wearing headphones, it means that either he/she doesn’t want to be disturbed or you became a disturbance already. Either way, be mindful.

We need fresh air to keep our brain working. Let us keep the door / window / air conditioner open and don’t put on your mediocre perfume, it is a torture. We need free space as well and hate sitting like canned fish.

Just because a programmer is sitting next to you doesn’t mean that he/she will fix the Outlook problem you just had.

Working with a Programmer

When you have a technical request, be clear about your actual goal. Don’t show up with a muggle software design instead, we hate it. Tell us at least 50% more than you think we should know about the requirement, and be clear about your assumptions.

When submitting a bug, tell us exactly what you did, what you got, what you were expecting, and steps to reproduce the error. “It doesn’t work” doesn’t work.

We consider our apps our very children. Be kind when criticizing them.

We are immune to the term “urgent request”. Be more specific: a) Showstopper b) Workaround exists but we need it ASAP c) We need it within x weeks d) Nice to have

Don’t rush into the room expecting immediate involvement in whatever you got there. You might be breaking a difficult and sensitive development progress. Instead, send us an E-Mail or meeting request to ask for assistance.

Don’t even consider sitting in the development room and talking all day long, disturbing everyone else. Instead, kindly invite your programmer to another room if you need him/her.

When a programmer solves a critical problem within 10 minutes, he/she actually solved it in 30 years + 10 minutes (depending on the age). Don’t underestimate a quick fix, be grateful for it.

We are not interested in the story that you could be a great programmer if you wanted to. We don’t want to hear about the great app you wrote in Cobol or Visual Basic back at school.

Managing a Programmer

We are neither “project resources” nor “coding employees”. We are software artists. Some of us are eccentric, and most of us hate fixed shifts, dress codes, etc. If we show up in meetings and finish our tasks as expected, let us be.

We hate pressure of any kind; especially time. We need to work in a calm & positive mood to give our best – stress reduces code quality and is bad for our health. Your poor project plan or analysis is not our fault. Forced quick & poor coding will make things worse.

Limiting Internet access to “improve our productivity” is amusing because we all have smartphones and know a dozen methods to bypass your firewall without getting caught.

Consider our privacy before calling us to solve a problem remotely, or asking us to work overtime. Just because overtime is planned in advance doesn’t make it acceptable.

Don’t demonstrate our apps in development stage, and keep the sales team away before we say it is ready. They will sell an incomplete product to be delivered on an impossible date, and no one will benefit from that.

Don’t expect our apps to work perfectly. We are part of a long chain from requirement analysis to runtime environment. Human errors will happen, and not everything is our fault.

If you are a non-technical manager, don’t pretend to know and understand what we do. We are smarter than your superior and will laugh behind your back. You may be our manager, but our leader is the alpha-programmer.

Don’t involve us in your corporate politics. We are not as greedy as you and don’t want any mud on our cuffs.

Advertisement