Wixel Blog
Subscribe to our Feed Follow us on Twitter Back

How CEO’s Can Help Programmers Get into the Coding Zone

0 Comments
Developer Station

Developer Station at Wixel

If you are at the helm of a tech company, you should know that programmers need to be ‘in the coding zone’ to be productive. Most programmers agree that a coding zone is marked by isolation, uninterrupted blocks of time, music and good coffee/tea. For most developers these conditions only happen late at night or in the wee hours of the morning.

Working with a technical co-founder has taught me a lot about how developers work, what challenges they face, what makes them tick and what drives them mad. As the non-technical co-founder, much of my time is spent thinking about optimal business processes – working smartly and productively on things that matter. Wixel is my first tech company and I’ve spent a great deal of time thinking about, and creating an environment that programmers not only love working in, but thrive in.

I strongly believe that the CEO of a company can create an environment for programmers to flourish in and is obligated to do so. So what can you, as CEO do to help your team get into a coding zone? Here’s Wixel’s answer to that very question:

The Programmer Workspace

  • Create an isolated environment free of distraction and interruption – no movement, no noise. This is best achieved by allocating developers to rooms in the building that are secluded and quiet.
  • Create darker rooms. Dark rooms aren’t only for photographers – there is nothing as distracting or as uncomfortable as light reflecting on a screen. We make all the developer rooms darker by adding additional blinds behind the curtains. There’s a synergy between dark rooms and quietness.
  • Clear the clutter. As a rule we keep things minimal and clutter-free to minimize on distraction and disorganization. I personally and regularly do the rounds to clear coffee mugs and items that accumulate during the day.

Give Programmers the Best

Programmers sit all day – their backs, necks, hands and eyes take a hammering.

  • Buy the best orthopedic chairs your business can afford.
  • Buy the best screens you can afford.
  • Make sure that the developer machines are fast and on par with latest technology developments.
  • Buy software and applications that they prefer working on. We own everything from Coda to Textmate and everything in between. I don’t mind paying for different apps for different developers, as long as it makes their job easier.
  • Supply notebooks/sketchbooks and basic stationery. I think this is a terribly inexpensive thing to cater for and yet I’ve never worked with a company that supplied notebooks to their staff. Wixel supplies notebooks – you can find anything from A5 notebooks to A1 sketchpads in our office and I’m willing to pay for whatever notebook is needed.
  • See to good coffee, tea and some snacks. If you can serve meals at work, do so!

House Rules & Company Culture

  • Allocate blocks of time. At Wixel all discussions are done early in the morning, over lunch or just before the work day ends – anything in between is considered sacred time. No interruptions allowed. This will not be possible for many companies but you should allocate blocks of uninterrupted time for the programming team. A time where no other team member is allowed to bug them.
  • Minimize meetings. We haven’t had a single meeting since inception. Ideas and buy-in flow more freely during informal morning and lunch time discussions.
  • Remove abstract documents. Our team doesn’t deal with any specification documents, complex diagrams, mind-maps or reports. We simply don’t create anything that doesn’t serve a practical purpose. We focus on creating practical working documents – quick sketches of flows and screens, quick mockups in Balsamiq or quickly put together prototypes. 37 Signals refers to a similar concept in their book, Rework, which they call illusions of agreement. They explain the use of documents as abstractions – no two people view or interpret such documents in the same way and thus these documents create a sense of agreement that a concept is understood when in fact each individual creates his/her own understanding of it. Get your teams to ditch the pretty-looking strategies and get practical.
  • Shorten working hours. There’s a difference between 6 hours of plodding along and 6 hours of focussed working time. Six hours of productive time takes it out of you. Also, never forget Parkinson’s Law – work expands to fill the time available for its completion. I urge our team to work in a focussed manner for 6 hours and then to go home to do some living. Being a fan of the Pomodoro Technique, I also encourage the use of the Focus Booster app. There is immense value in encouraging team members to work and beat their own personal best times.
  • Recognise the importance and distinction of coding time and problem-solving time. Coding can only happen once the developer has done a lot of problem solving or headwork. Give them the time and freedom to do so.
  • Let developers set the deadlines. This helps establish responsibility and accountability from the bottom up. As an added benefit getting programmers in the habit of estimating timeframes for each task helps them become more accurate in estimations – this will be enormously valuable to your company in the long run.

Listen to Your Team

At the end of the day company cultures and priorities differ. The single best thing you can do is listen to your team. Listen carefully to what makes their jobs difficult, what causes delays and what causes frustration. It’s your job to figure out the pain points and your duty as the leader to remove those barriers. Only then can your developer team be the best team they can be.
Good luck!

Question: What have you done to enable your programming team that worked well?

Written by @bevmerriman
Blog comments powered by Disqus