What programmers want

I had a recent one on one with my boss and he was baffled about something. Multiple programmers, including me, had asked for larger monitors. Well it did not have to be a ton bigger but we wanted a better pixel count. The company standard is 20" monitor using a 1440x600 resolution. That is pitiful. Heck the 15" laptop has 1440x900. For him to order better monitors it was going to take some effort on his part and he really did not feel like doing it.

First off he said everyone in the building wants a bigger monitor. I am sure that is true. He did not want to start a trend. Boy have I run into this in the past. At a previous position I asked for a second monitor and that ended up in a big tussle. I final got one by submitting the fact clients had dual screens and we were not testing against them. In fact we knew we had dual screen issues that were not being resolved. When the big boss was out of town the next guy down was willing to sign off on me getting one. Of course other developers wanted one too. They got it in their head they had to order then all at once. I suggested they order a couple a month and hand them out by seniority. It took them a full year before they decide to do this. How much productivity was lost during that time?

You are much more productive when using multiple screens. I have two at home as do both my sons and my wife. I use the dual screen mode on Note II. We are constantly cutting and pasting between multiple apps. I have tons of apps on a screen when developing: Outlook, SmartGit, IM client, Chrome, Command line, File Explorer, IDE, Sublime 2 text editor, TFS, Paint.NET and other apps as needed. Running all that with not enough pixels is silly. My main screen at home is 1920x1080 and my second screen is 1680x1050. My previous job had dual 24" monitors at 1920x1080. As a programmer you use all the room. We don't live in Outlook + Word or Outlook + Excel all day long. Even using TFS on that little screen stunk. Not that TFS is UI to love, but man did I have to scroll around a lot to see anything. I want to have the email client running that I can quickly glance at to see if an incoming note is important or not. If it can be dealt with later or I am just on a big CC list then I easily ignore it and keep coding. If I have to ALT+TAB toggle windows to read it then I have been interrupted.

If you are a manager take a look at what your developers have open at any point during the day. If they don't have a dual screen set up by now then shame on you! If you have crappy little monitors then fix it! I bought my 23.6" main screen for $119 at Microcenter. That is a very tiny investment. Spread it out over time if you have a big pool of developers but take care of them or they will leave.

Leave is just what I am doing. I asked for a bigger monitor, promises were made but it never happened. I asked for a tablet to test our Android code against and that never happened either. One of the devs has an older MacBook and his compile times suffer and no upgrade in site. The other Android developer was promised a MacBook Pro on the day he started and 4 months in it never happened. Other developers have asked for larger monitors and have not gotten them.

They day after my one on one, first I had in my four months as a contractor, I was offered another job. They all have dual screen setups with large monitors. I have been in that sort of environment in the past and really missed it. When my home layout beats the pants off my work layout it is time to move on. During my resignation meeting I explained why I was leaving. There were a lot of other issues but I did reiterate that developers need bigger monitors and proper equipment. This was not news to my boss. Others have complained and left too.

The boss is very non-technical. He still did not get it but was willing to get people what they needed. I was one of three to resign in a few week time period and more are going to leave as they are looking hard right now. When people leave it is because little things add up. Sure big things play into it to but it is when you start to total up all the issues that you decide to move along. At the very least as a manager you have some control over the equipment your developers are using. Do yourself a big favor and make sure it is up to snuff.

During any interview I ask what type of equipment I will have. Now I know I need to ask about monitor size and pixel count. Of course they can easily lie during the interview just as they did to the other developer about getting a Mac. I generally want to walk back and see a typical developer setup so I can confirm things. Are they sitting on a folding table? Are they low, mid or high cube walls? Do they allow headphones? Does anyone over decorate their space or is it all super minimal decoration meaning they probably move around a lot. Funny cartoons on the wall or all business? Notes, screen shots, white boards with collaborations? If they don't have any white boards that is also a red flag to raise. You can tell a lot about the environment with a quick glance at a typical work space.

What do developers want and how should I manage them?

1) Proper equipment - dual screen setup, and yes one of the screens can be the laptop screen but if that laptop is 13" they you really need a docking station and two big monitors. Mac laptops tend to have really nice screens so I am talking more about a Windows system here. A Mac user still needs a second monitor. Try to have both monitors be digital is possible. VGA stinks at higher resolutions.

2) Monitors with high resolution. Don't go super cheap here, they stare at them all day long. Get a name brand and a matching set if possible.

3) White boards or some way to collaborate with others. A quick flow chart, screen mock up or drawing simple notes can go a long way towards solving issues that need visuals.

4) Access to a printer. I don't print often but there are times it is very handy to print out a document or series of screen shots to jot down notes or to compare for consistency issues.

5) Fairly open internet access. I don't care about using Facebook at work. I don't even have a Facebook account but if I keep getting blocked from finding answers to technical questions on the web because some blog with the perfect answer has a cuss word on it then I am blocked from doing my job. When I worked at a large telcom company it was hard to get to any website at all. Never, ever block stack overflow or you can just forget getting anything done.

6) Special equipment. If you are doing iOS you need an iPhone / iTouch and an iPad. Yes it can be a shared resource but not something you only can have for an hour. If you are doing Android you need a crappy small screen phone, a normal phone, a Note or Note II and a tablet of some sort. The emulator only gets you so far.

7) Uninterrupted time. If you have meetings all through the day a developer does not have time to get is train of thought out of the station. Programming is not something you start and stop on a dime. Once you are in the flow you want to just keep going. Morning stand ups are fine but meetings all through the day are silly.

8) Time to test. Sure we love to pound out code but if there is always another big feature on our plate we tend to just get what we have running and not hit it hard with testing. There needs to be down time between large projects. It gives us time to clean up the code, find our own bugs, fix graphical glitches have seen from time to time. Code lives forever it seems. Nothing is ever done, it just ships.

9) Some real desk space. Yes we need to spread things out when we have documents to scan and screen shots to look at and people to sit next to us to code review and work together.

10) Comfortable chair. I have been at too many places that roll old conference room chairs at the developers. Ratty torn up furniture. Yes, that chair may have cost big bucks when it was new but it is now better off in the trash than handed to someone who sits most of the day.

11) The sense that we matter. Sales and Marketing my have all the flash but in the end without the software there is nothing. The rest of the company generally depends on what the developers produce. The sales staff tends to run feast or famine but when they brag up the big sales bonus it really does not help developer morale unless they have a bonus system too. Little things add up here. A staff movie afternoon works wonders. Doughnuts on a Friday. Gift certificates. Action figures. Free sodas.

12) Ask about the little things that are not going well and try to fix them. Stand up for your team.

13) Don't shoot down cool ideas because the proper team / person did not think of them. This was another sore area and the job I am leaving. The Android team was last in line. Some one designed the product and the iOS team implemented it. That team was not much on the idea front. When it got to us we had some cool ideas to clean up the interface, eliminate taps and full screens. It would have worked just as well under iOS but since it was already done we were told STFU. It was going to be hard for them to adjust the user story, to admit it was wrong to start with and to do new screen shots. The iOS app is not shipping, things are not done in fact they had a 2 to 1 developer advantage. The iOS team even wanted to make the changes, no developer push back but instead management decided not to do the right thing because it was not their idea. Aim for that 2 star rating! They originally hired a code monkey off shore team to do this and it failed. They decided to bring in senior level developers to do the project but now don't want to listen to them.

14) Have one on one meetings. This is the only way you will hear about the little issues that are adding up. My first meeting was way too late. Yes, I brought up all the issues via email or hallway conversations. There were no surprises to anything I said during my resignation meeting but it felt like everything was so informal leading up to me leaving that nothing was ever resolved.

15) Don't treat different teams differently. The Android team always felt like a step child. They loved iOS and even Windows tablets but made us feel like dirt. The UI team was Apple fanatics and hated Android and let us know. All screen shots were iOS with total Android afterthoughts. Your clients don't care about your opinion here. If you ship an Android version it better be the best darn Android version you can produce. It better not be iOS UI on Android. It better not ignore the back button, the action bar and other Android givens. Same on the iOS side. Don't be so generic it could run on anything. Use the iOS UI and be as iOS friendly as possible. It is is new code run on the iPhone 5 full screen.

16) Do code reviews. Being an programming army of one is tough. A code review can bring up better ways of doing things, find areas where objects can be created or removed, find duplicate resources, strings that are not in tables, code not following naming conventions and many other issues. They don't have to be this massive formal setup. Two developers looking at their dual screen set up just talking over the code works. Do them often so this does not get out of hand.

17) Don't let one developer "own" something. Ever piece of code should be cross trained. Yes, you will have a developer that specializes in JSON parsing and one that does custom controls but they should each understand what the other is doing and be able to fix bugs in the code. I don't own any code I write. I type it up, comment it and check it in to source control. They company paid for it and it is theirs. If another team needs to take it over then have at it. To me if they never have need to ask me a single question about the code then I have done my job. There should not be anything magical about it, it should be standard easy to understand code. I should have commented any weirdness and things like "must call in this order to get around known bug in SDK" etc.

My next job will not be perfect but I know it solves a number of issues I have at the current one. I have learned how to interview the company I am applying at. I have reasons for asking for the things I do and I will continue to fight for the best, most productive environment I can have. We should all fight together so we don't have to fight anymore, all these things will just be a given.