I’ve been in the software industry for almost twenty years, working in both high pressure startups and big corporate machines. My career has been a set of fits and starts, great decisions, backwards movement, getting places due to luck and making my own luck with careful, considered judgement. A few days ago, an intern I was mentoring asked me to tell them how your software career develops, and I realised that nobody had told me this — and that I’ve had to pick it all up as I go along. So to give you a headstart in the software industry, here is what I’ve learned in the process:
If you’re following a developer career path, there are three phases to your career
Junior Developer (The more enlightened companies will drop the term ‘Junior’ and call Junior Developers ‘Developers’ or ‘Engineer 1’). This role is where you begin your career. You’re expected to know how to code, but you’re not expected to have learned how to code as part of a team yet. You don’t have the experience to know why some of the best practices exist, and it may turn out you are totally inexperienced with a tool which more senior developers have forgotten they ever had to learn.
In this role you’re generally going to start out by being given work to do, in order to train you up. Over time, you’ll begin to notice problems that underly the tasks you’re given, and you will start to suggest how to improve things — but rarely will you be able to make the decision to fix these things without discussion with a more senior engineer. The aim, at the start of your career should be to get ownership of some part of the codebase — become the go-to person when there are problems in a particular feature or area of code. This establishes you as someone who is unique and reliable.
As a Junior developer you have a few advantages over some of the people who have been around longer — you’ll know about new tools, languages and techniques which have passed more senior developers by. This is also the time in your career when you’ll get to do the most coding — as you’re not yet caught up in the world of meetings and process, and you’re still not heavily involved in system design and architecture
Senior Developer is the next role. As a junior developer your essential value is how much high quality code you can produce in a day. Over time, you stop becoming more efficient, because you’ve learned how everything works, and know all the productivity tricks which make you more effective. Once you’re not getting much more efficient, why would a company want to keep increasing your salary? The answer: You have to begin to make other people more efficient.
When you become a senior developer you take on a few new roles:
- Helping the junior developers: All that knowledge you picked up in the first few years of your career? Well, now its your turn to share that know how with the new developers the company has hired. The faster the new junior developers grow, the more valuable they become to the company — and you’re the person best placed to help.
- Communicating with management: By now you know what needs to be done, and where the problems are in the code base that the non-technical observer may not see. You’ll begin to make suggestions to management as to what they should be prioritising (and you’ll begin to run head first into the brick walls of corporate politics at the same time). You’re also going to be better at recognising what tasks are easy and what tasks are nearly impossible — and again you’ll be feeding that back in planning sessions.
- Design: You’ll begin to design larger and more critical parts of the code — perhaps entire features which will be implemented by several people. You’ll also begin to have to cope when your designs are criticised, and when their implementation introduces new and unexpected difficulties.
- Leadership: The junior developers will look up to you as someone who knows what they are doing. And you may be asked to run small teams of engineers working on a feature or tracking down a particularly gnarly problem. In the process, you’ll have to convince people to work with you, even though you have no significant authority. Generally speaking, your technical knowledge becomes the best lever you have in these situations.
Staff Engineer. Think of this as the ‘non-commissioned officer’ role in development. At this point, not only are you making your team more efficient (and by this point, you’re almost certainly leading a permanent or semi-permanent team of developers), you’re also making your managers more efficient by allowing them to not have to pay as much attention to the day to day development work. As a result, you’ll find yourself doing a lot more organisation of paperwork, and prioritisation of tickets. You may find yourself assigning work to people, and having to check up that its getting done. You’ll probably be left alone by your managers far more to get on with the things you need to do — but it won’t feel like it, because the things you need to do involve far more reporting and keeping everybody informed. You’ll still be coding — but quite possibly far less than you used to. You’ll be interrupted more frequently, and you’ll be spending more time reviewing other people’s code and designs, and working on breaking architectural designs down into work items that a team can manage. Frequently you’ll be your team’s dogsbody, filling in the roles that the less experienced developers don’t believe are important. You may also be handed parts of your managers job which your manager thinks you can do more effectively than they can.
Principle Engineer / Architect At this point, you’ve been promoted beyond the level of many engineering line managers, and you’re beginning to look at the big picture. You’re still going to be on the hook for ensuring software gets released, but you’re also going to be involved in determining what is best for the company on a strategic level. You’re still an individual contributor — but your work will be informing departmental and higher levels of the organisation’s future. If you’re an architect you may well find yourself writing documents and reviewing documents more than actually writing code. There is a good change any code you write will be a prototype and won’t actually make it into the product. At this point, the job description varies because it becomes based around what is unique about the individual. Probably the key thing which stays the same here is that you will be spending a lot of time learning about technologies which are not currently involved in the day to day work your company is doing. You are the person learning about the future from a technical perspective. In a well organised company, you will work hand in hand with product management at this point, trying to find ways to turn their insights into technical reality.
This is all very well — but how do you get promoted from one role to another?
There are a few things you need to know:
Your manager has his hands tied. She doesn’t get much freedom about how many promotions she can give out. Money is limited. And your manager may well simply be making recommendations for promotions to a more senior manager, who herself may be passing the list further up the chain. By the time promotions are announced the list will have been modified to keep everything in line with budgetary expectations, and your name may have fallen by the wayside. Ultimately this means that doing everything right might not get you the promotion in a particular year — but never fear, there are things you can do which increase the odds.
You don’t just get promoted by doing your job well. You get promoted because of everything you do outside of your job. The more you — and your projects are known about in other parts of the company, the more likely your name is to remain on the promotions list. So get involved with cross-company projects, or take on some of the work your manager would rather not do, if it gets you invited to some of their meetings. This doesn’t only include professional activities — take part in social events (even if you don’t want to). Join that work sports club or charity drive — especially if there are people involved you don’t currently know.
Show some leadership. Leadership takes many forms — it isn’t all about being the person who has been promoted above other people. Frequently it is about offering to take responsibility when the opportunity arises. So take on that team or feature lead position. Volunteer to be on the desk rearrangement sub-committee. but be warned: leadership also involves some more subtle aspects. Behave like a model employee — in order to set an example for the younger, more impressionable developers. You might notice your leaders already do that: Spending longer hours at the office, wearing smarter clothes, taking part in activities they might not particular want to, encouraging people to try new things, rather than resisting them, or being sarcastic about them. Don’t think this is an accident — they are doing it deliberately to let people see the message the company wants to be conveyed. If you join in, you’ll get seen as part of the solution to all of their problems!
Embrace change. Companies change. Startups keep needing to restructure as they grow bigger. Big companies rearrange deckchairs whenever there is a leadership change — or to embrace a new corporate fad. The thing about change is that most people resist it — and when changes happen, things become shaken up, and lots of new opportunities arise. So — if a company is introducing a change — whether or not it seems like it might be the solution to all of life’s problems, grab hold of it and run. Get excited, offer ideas (and take any other opportunity to get involved that you are offered). Most of your peers (and quite possibly several of your managers) will be avoiding this. So by putting your hand it, you’re literally giving people the chance to help pull you up to do the work they don’t want to. It doesn’t matter if the initiative fails… by getting involved, you’ll be seen as someone who isn’t afraid of getting involved in other projects in the future.
Ask your manager about what you need to do to be promoted. If your manager can give you a list of things you need to do — then you can show your manager that you’ve achieved them. Your manager is likely to want to get involved with you being promoted (when a managers reports are promoted, it makes the manager look good — and gives hime greater seniority) — so if you can make your manager part of the team to help you move up the ladder, you’ll have a cheerleader in the all important initial promotion meeting.
So what can go wrong? In this case I’ll offer some of my missteps:
Doing too much too soon. As a young and enthusiastic programmer, I was offered responsibilities before I was ready for them, and I jumped at the chance. This led to me working long hours, and seeing that some of the ideas I had implemented were actually less good in practice than they were in theory. I hadn’t built up the years of experience to know how to handle other people — or the experience to know what can go wrong in software development. Ultimately I burned out, unable to cope with the pressure.
Staying in a comfortable job for too long. Sometimes you notice that your company just isn’t changing — there really aren’t the promotion opportunities that you might find elsewhere… but the job is just so comfortable that there is no incentive to move. This hit me. I stayed in the same position with little to no upward momentum for five years — and it was only a redundancy happening during an economic downturn which got me out of the company. I left with the same job title as when I joined, but now with the (admittedly minor) stigma of having been made redundant, and far less self confidence.
Not spending enough time in a job: One job offered me lots of chances to get ahead — but I chose not to stay long enough for them to pay off. Overall, I’m glad I left the company (I didn’t think it was in a sound place for long lasting success), but it would have probably helped me move up the ladder faster if I had remained another year or two.
Not asking more about promotion: When I finally asked my manager about a move to management, he jumped at the chance of helping me. And the whole management team rallied round to assist. Presumably they knew I was ready for such a position before I did — but no-one ever said anything because they didn’t know it was the path I wanted to take.
None of these things got in the way of my eventual career success — but they each caused blips, and I could have got further, faster without them.
Now it’s your turn. As a software developer, you only have one career, so you should try to get to the place you want to be as soon as possible. I’ve offered my advice, but now you need to start acting like someone looking for a promotion and moving towards ever greater career success!