Anyone that’s ever worked directly with me can tell you that I don’t like meetings. I consider most meetings to be a waste of time, and they’re incredibly distracting. As a programmer, I feel that my time should be spent actually programming things, or doing something that will help me to program. It’s the very, very rare meeting that actually fits that description in my opinion.
I know that there are plenty of people that disagree with me. Some people don’t mind meetings, some actually enjoy meetings as a means of getting out of their regular duties, and some people sit in meetings as a regular part of their job, (CEO’s and project managers come to mind…). I personally believe that programmers should not fit in to any of these three categories. Rather than just stand on my position and expect you to just agree with me, I thought I’d outline my position and hopefully save myself, (or other programmers), some time in the future.
Time Is Money
The old saying is true, time is money, and that is especially true in a professional environment. The next time you and your colleagues are gathered around the conference table, consider that every person in that room is being paid to be there. From a pure business perspective, it doesn’t make a lot of sense to spend money to have someone sit listening in a room if there isn’t some very good reason for that person to be there.
To put that into a more specific context, let’s consider programmers. Programmers are not generally hired to spend a lot of time in meetings. Programmers are hired to develop software, and they are usually paid a lot of money to do it. Even an entry-level programmer can comfortably expect to make $45-50k per year. Mid-to-senior level programmers easily double that figure. That means that it costs about $20-$25 per hour to have Mr. Junior Dev sitting in a meeting. For Mr. Guru Programmer, it’s $50 an hour.
If someone is going to be pulling down that kind of money in an hour, doesn’t it make more sense for them to do it while actually engaged in the duties they are uniquely qualified to perform?
Programmers are expensive, and they’re expensive no matter what they spend their time doing, so you want to minimize the amount of time they spend doing things that prevent them from doing what they do best.
There is a very good reason why documentation, technical manuals, programming books and programming blogs and forums make up the majority of a programmer’s body of reading. The written word is usually the most efficient means of conveying technical information. Written words can be quickly scanned for the purpose of picking out vital information and the rest is easily mentally discarded.
Contrast this method of extracting information with attempting to obtain information in a meeting. You can’t skim through a meeting. Each topic is talked through, one at a time, at whatever pace happens to prevail. Back and forth discussion of individual items slows the pace even more, and unforeseen tangents lengthen the time till valuable information is discussed. This is incredibly inefficient, and getting back to our previous point, it’s also expensive. Sitting through a half-hour meeting for the sake of the 5 minute segment that actually might matter to you means that you’ve still wasted 25 minutes. If you want to save money, and the programmer’s sanity, write up the things that might be relevant to them, then email it to them after the meeting.
Before you involve a programmer, (or really anyone), in a meeting, make sure that there isn’t some more efficient way to present them with the information you need to share. As often as not, _especially_for technical topics, (and why would you involve an expensive programmer in a non-technical meeting? A written summary will be more valuable and more efficient.
Concentration Is Key
Programming is not an easy job. It requires an immense level of concentration and attention to minute detail in addition to an ability to simultaneously keep track of a variety of separate and individual “thought processes” while never losing track of a much larger ‘big picture’. The mental energy required for this task is incredible, and the focus needed to achieve it is both extremely fragile and somewhat elusive. Some programmers refer to the mental state required to do their job as “the Zone”. Getting in to the Zone is hard, and once knocked out of it, it’s even harder to get back in to.
For that reason, while a “quick 5 minute sync-up” might not seem like a big deal when taken in context of an entire 8 hour day, the reality is that too many of these kinds of distractions, even minor ones like “Hey you got a minute?”, can blow hours of a programmer’s day as they try to find the Zone only to be pulled out of it every time someone feels the need to drag them in to communication with other people. This is why information efficiency is so important. The less time and energy a programmer needs to spend to obtain information, the better and easier they can get in to the Zone and do their actual job.
How To Communicate With Programmers
If you’ve read this far, you might be thinking, “So, I’m never allowed to talk to a programmer? I always have to write emails to them and keep them out of meetings, and let them listen to Trance on their headphones all day??? This is madness!!”
To answer that question I’d say…sorry, but yeah, that’s basically true. You should avoid bringing software developers in to meetings throughout the day, you’ll kill their groove and ruin their productivity. However, if you absolutely must have face-to-face time with a programmer, do it in the morning before they’ve really revved up. The Agile concept of a ‘stand-up meeting’ fits this description perfectly, and it’s one of the few meetings I have absolutely no objection to, provided it’s conducted properly. As an alternative, schedule it towards the end of the work day, but not so late as to risk over-running quitting time…you don’t want anyone checked out because they’re worried about traffic.
When you do have programmers in meetings, respect their time. If you can, bring the technical stuff up that you need them for early, then cut them loose once that part of the conversation is done. Do as much as possible to keep your meetings short and to the point, (that’s just good general advice).
If you do need to communicate with a developer while they’re working, try your best to do it in a non-intrusive way. Email is good, and a lot of businesses these days are using Skype or other chat programs to communicate. These are a great alternative for programmer communication because they allow the programmer to get to the message once their mental faculties are throttled back to a level sufficient to look at something else without coming completely off their task.
Involving programmers in meetings is expensive and distracting, so if you care about cost-savings and productivity, dramatically minimize the amount of meetings you involve software developers in. Err on the side of leaving a programmer out of a meeting and only bringing them in when you absolutely have to because no one else in the room is capable of answering or understanding a point. Let programmers program during the day rather than dealing with a barrage of meetings and questions. If you absolutely must meet face to face with developers, do it in the morning before they get off and running.
Comments, disagreements and discussion always welcome!