September 28, 2010

Nine non-development jobs professional developers would benefit from doing

Nine non-development jobs that professional software developers would benefit from doing once in their lives - not including the most obvious Software Engineer :P

  • Front line technical support - This will teach you that more often than not, business metrics [as flawed as they are from your developer point of view] drive the business, not your idealism towards your software. Your 'skewed' idealistic point of view has no weight in the call centre. This will give you an insight into just how much money large corporations waste on supporting each and every bug your software goes out with.
  • Second line technical support - Dealing with the simplest of problems that front line technical support can't figure out within the definition of their required metrics - i.e. their average call time, calls handled per shift etc.
  • Third line technical support - Dealing with calls from customers that neither front line or second line technical support can't figure out. Of the technical support jobs, this is the most fun. You only get the intriguing problems that nobody else can figure out.
  • Customer service in a call centre - Dealing with random calls regarding software, from "what does it do" to "I have no idea what I'm doing". You will have to find many ways of presenting the same information in different ways because not everyone 'gets it' the way you think they should. This will teach you patience... with a safety net, you can always put the customer on hold and freak out about how stupid they are.
  • Desk side support - Dealing with customers in person, sitting by the customer and fixing their problem for them or showing them how to fix it for themselves. The biggest lesson you will learn from this job is patience - without a safety net, you can't freak out because the customer is right there. Whether you consider the person an idiot or the smartest person you've met in your life, you have to keep an even temper and demonstrate compassion for their situation - even if underneath you're fuming.
  • Retail sales - The customer is important. This job will teach you many things: Personal interaction with unfamiliar people, body language, anticipation of customer needs and the value added upsell.
  • Integration specialist for someone else's software - Going to client sites and installing software into their production environments. This will teach you what happens in corporations once your software makes it into the wild. Just because it works on your test servers, with your test data doesn't mean it's going to work in the wild, on someone else's server, under someone else's control, with their data. It will also teach you the lengths you need to go to in order to integrate your software with other business applications.
  • Graphic Design - What's the point being able to make great software if it looks ugly?
  • Typesetting/Copy writing - What's the point in being able to make great software if nobody can read it?

If anyone's got any other non-development jobs that would be useful for rounding out a professional software developer, please comment! :)


  1. Interesting list, though you're not casting your net that wide, with the exception of retail sales. all the rest come from within the IT field.

    Even within IT there are a few other jobs that I think confer an advantage:

    Some experience over on the system administration side is useful. Developers need to know something about network infrastructure, server and desktop OS and hardware configuration. I've known good developers who've transitioned from DBA roles, too.

    A stint in QA is also a useful bit of background. Gives you a different appreciation for what 'finished' means.

    And from my personal experience (I've not done half of the jobs you recommend, nor have I been a sysadmin), I gained an enormous amount in my own career from experience as a technical writer. Software development is a communication business, and many of the best developers I've come across have a background in writing or - frequently - training.

  2. @James

    Great points! Someone else mentioned training on Twitter, and I concur. Another one I failed to mention, and perhaps should have is Toastmaster - which teaches you to communicate more effectively and would fit in nicely with this point.

    I think being a technical writer would be helped greatly from being in these positions too. It's been my observation that a technical writer is sort of an in between the people and the developers kind of role, neither more to one side or the other - kind of a bridge between two worlds, on the fence.

    This list is more inspired by spending time interfacing with users directly, learning to understand them and their thought processes rather than from a technical POV.

    Because of the nature of development, many of us tend to recede into our comfort zone surrounding ourselves with other technically minded people. We tend to spend as little time as we can bear on the user's side of the fence.

    I think understanding the people in your target audience is as important - if not more important than the technical aspects of the product or service you're developing.

    Of course, this depends greatly on what kind of software you're developing and who you're developing it for. If you're developing APIs for other developers, then that changes things fairly dramatically. If however, you have a much more general target audience then these would apply well.

  3. Ben, the first few bullet points of your post reminded me of a small company where I once worked and was the only employee whose last name started with Z.

    The company had a phone number with an IVR system where you could spell an employee's name by pressing phone keys. Once the match was unambiguous, the phone rang at the employee's desk.

    We had millions users worldwide at the peak and a well-publicized 1-800 number for tech support. But a tiny fraction of users called the corporate number instead and pressed "0" at some point to speak with an "operator." The IVR was set up such that 0 spelled Z.

  4. @Alexei - That's awesome. Perhaps 0 should automatically be wired to "The new guy" :D

  5. I have to agree with the retail point you made, I work in retail part-time and often find myself trying to determine the requirements for the customer (I sell computers/software). I don't want to give a student a full Sage accounting package if they just want to keep track of some basic expenses, Excel/Office would be a suitable and probably cheaper alternative.

    In a way it also ties into project management as making sure that the end product meets the customers needs/requirements means there's going to be less frustration, less problems and an overall positive experience for the user.