A Traditional Approach to an IT Career

I have just read Career Development for Geeks [1] by Erik de Castro Lopo [2]. It makes some interesting points about a traditional approach to an IT career. The path I followed for most of my career (after I had a few years experience) was to work as a contractor and happily leave jobs without having anything else lined up.

Erik suggests getting Engineers rather than managers to give references, it’s an interesting idea. Engineers can give better references about quality of work, while managers can speak on behalf of their employer (in theory). In practice a sane manager won’t give a bad review for legal reasons so the value of a reference from a manager is probably limited. Of course one problem with reviews is that I have never heard of a recruiting agent or employer actually verifying the ID of a reference. I could be listed on a friend’s CV as a senior manager in a multi-national company (which doesn’t have a major Australian presence) and give a good review and it seems unlikely that the typical recruiter would work it out.

For someone with plenty of spare time and no significant assets (no risk of being sued) it could be entertaining to apply for a bunch of positions that they are not qualified for with friends using pre-paid mobile phones to give references. This could be done as a documentary on corporate hiring practices, or to simply try and get the highest paid job possible. Based on observing some former colleagues it seems that little skill is required to get a job and that when people do really badly they get paid for at least a few months. I am constantly amazed when reading reports about so-called “con artists” who commit crimes for what are often small amounts of money. Getting an income significantly greater than average without knowing anything about how to do the work is very common and is never treated as fraud (the classic example was a former colleague who wanted to write his own encryption algorithm but who didn’t even know about binary and therefore couldn’t use operations such as XOR).

Erik’s main suggestion for dealing with recruiting agents is to talk about project management issues (recruiters don’t understand technology). My way of dealing with them has been to assure them that I know it all and tell them to forward my CV to the client.

Another suggestion is to learn new skills and diversify your skills. I don’t support this because I believe that the majority of people who read my blog are significantly more skillful than the typical programmer. If an area of technology starts to go out of fashion then it’s the people with the least skills who suffer the most. If you are good at your work and enjoy it then it shouldn’t matter much if people around you are being laid off. Of course to rely on this you have to be working in a reasonably large field. For example if you develop software in a language which has hundreds of programmers then you may be at risk, but if there are tens of thousands of programmers using the language then you only need to be in the most skillful 10% to be assured of employment for the next decade or two.

That said there are benefits to moving around, meeting new people, and working on new contracts. One thing you don’t want is to have 10 years of experience which are the same year repeated 10 times!

Update: Here is a paper Erik submitted to OSDC on the same topic [3]. Mostly the advice is the same but with more detail and in a better format for reading.

4 comments to A Traditional Approach to an IT Career

  • Erik de Castro Lopo

    The first reference is just the slides from a SLUG talk. I presented a paper at OSDC on a similar topic and its available here:

  • Helen

    A new way to kick start a career in IT is through distance education. Thomson Education provides a range of IT and Design courses which can be completed faster, less expensive, more accessible, and more flexible than campus-based university programs.

  • etbe
    Helen: I don’t think that Thomson offers anything of use. The fact that almost half of their “IT & Design” section is comprised of Microsoft Office training really says it all. Please see the above URL for better ideas for training.

  • This is a good point: “measuring performance leads us to the issue of performance reviews. Before a performance review, a developer should read over their list of wins and losses. They should also look over how effective their project planning was and how close their time estimates were in comparison to how long the project actually took. During the performance review let management remember the failures but make sure to remind them of the successes. It can also be useful to ask management how performance is measured. If a developer knows how performance is measured they can tune the way they do their job to maximize their perceived performance.”