Sunday, February 24, 2013

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.


  1. I really agree with your blog, about the way of developing apps for developer.To be successful in this new craze of app development, you require a unique and good idea that catches the fancy of people

  2. This is what I think:
    - if your position is a contract one, leave it if you can find a better rate position. If this position pays well, I don't see any reason you cannot spend $150 for a decent monitor and $200 for a nexus 7 to test your android apps.
    - if your position is permanent and you're happy with the salary, relax and enjoy your life.

    1. It was a contract position and I did bring in my own monitor and I did test with my own Xoom tablet.

      They bought iPads for the iOS team for testing. They bought iPads for QA too.

      QA had no way to test on Android tablets as they are perm employees and don't have personal tablets.

      Since I am sitting around basically doing nothing right now and they don't have new work lined up I am not happy. Sure, I could continue to bill hours until they found something for me to do but I am not that type of contractor. If I am not busy I am bored and feel very guilty about billing. It was an excellent time for me to move on. Maybe if they would have solved some of the smaller issues I would have hung out longer. Right now the mobile market it reasonably warm so I was able to quickly find a new gig.

      Thanks for reading and especially thanks for commenting.

  3. I like and agree with most of what you are saying here. Item 13 gives me some pause. This seems like a communication/respect issue. I think what I expect is that it is a discussion, not us vs them. So is the problem that Business designed the UI and wont hear any feedback from development? I have seen that. Or is it that the UI design is minimal, and dev wants to make it "more functional"? I have seen that too. In an open discussion all parties need to entertain the possibility that they are wrong.
    To me it is all about being treated with respect. Dev's are professionals too.

    1. mcmspark,

      I agree. While a developer is not necessarily paid to be a UI designer they have generally implemented plenty of UIs over the years. Plus the UI person in question was an Apple guy to the core and we were offering suggestions on the Android side of things.

  4. Great post! I have experienced so many of the same things you have. And I politely disagree with LG Optimus : even as a contractor, I don't think I should have to spend money on a monitor or a tablet. Yes, contractors are paid more - but that extra money is meant to compensate for the benefits permanent employess receive that contractors don't : pay holidays that are mandatory to take off, health insurance, sick time, etc. When those are factored in, I have not had that much extra money when contracting to just go and buy some monitor or tablet at will.

    I personally experienced #15 at a recent job, and it made it very unpleasant and demoralizing. I was on the .NET team, and the boss was gaga over the JavaScript/dojo team. It wasn't so bad that he made it so obvious how much he loved them, but what really got me is when he would make disparaging comments about the ".NET guys," as if we were second class citizens, hinting that anyone could do our job. It was not fun. I think until someone has been in that position, they can't really understand how demotivating it is. Thanks for bringing these points to light : )

    1. QK, it is sad you had to go through the same experience. Each team brings something to the table and should be treated with the same respect. When you are opening chided for being on the "wrong side of the tracks" it really stinks.

      I brought the point up because it has happened to me at more than one position. I was a Java developer at two different C++ shops. We were always treated as the "other team" at each place. At one place no Java employee was ever allowed to be employee of the month. The CEO made sure of it even though 1/2 the company revenue came from the Java product. My boss gave up trying to nominate me. I was never able to move up in that company so I moved on to greener pastures.

  5. I feel ya, Kevin. I've been a "corporate coder" at a financial sector for the past five years. Only thing keeping me here is the excellent benefits (sans the pay, which is substandard for the industry and area). And for anyone who says "It could be worse," my reply would be that of Han Solo's in the garbage compactor: "It's worse."

    Large development companies or companies focused on technology have learned their lessons about programmer needs, in general, but it seems like much of the rest of the corporate world hasn't caught up yet. I put up with a cube environment that's very hectic, surrounded by ringing phones and chatty Cathys. I have small monitors (at least I have two), and I have to take Help Desk calls 31 of my 40 hours per week (when I should really be on the other side of the house with the other IS programmers). I'm also the only developer specialized in the .NET platform, which gives me some autonomy, but it sucks having nobody to do code review with, get another perspective from, or just someone like me around with whom to "get my geek on."

    I've brought the issues to management many times but it seems to just continue falling on deaf ears. Any suggestions for what I might do to make my life better? And no, quitting right now isn't an option (although I'm looking, there are personal life things going on that force me to keep my medical insurance at the moment).

    1. Learning new things while on the current job is one way to help out. Yes, you are the .NET person right now but if you learn iOS / Android / Windows Mobile (.NET still applies there) then you have a leg up on new projects or a new position.

      Are you doing a lot of web work? All backend? Try some front end stuff. If doing all front end then learn SQL. Create a database you would use at home. Configure a web server if you have never done. Learn more features of you version control system (I hope you are using one).

      Is there some task the person sitting two cubes from you does every day, once a week, etc. Help automate it. Find out they are doing 3 types of file conversions to move from format A to format B and do it in one conversion.

      Learn another language - Java, Python, Ruby. Never know when that will come in handy for one off projects.

      I have other posts about being the "only" person who knows something and not being able to do code reviews. It bytes hard.

      Feel for ya on the insurance side. Been there before and it sucks. I hope that works out for you soon enough and you can move on or the current place and step it up and help you out.