Software Development: Career Path
My last post was mainly about sharing my love of books, but my structure of organizing books into career tiers struck a nerve with some readers. As I am at the halfway point of my career, I’d like to offer my perspective on the career progression of a software engineer.
Software Engineer I
This is also called Programmer/Analyst at some companies. This will be your first job out of school. You’ll be mainly given bugs to fix and small, (hopefully) well-defined tasks. You’ll learn how to work in a team, follow processes, and meet deadlines. One of the things that struck me in my first “real” job was how much I didn’t learn in school. The foundations of data structures and algorithm analysis help you do your job, but they don’t tell you how to integrate with a buggy API or figure out some esoteric compiler error.
The work you do may not be challenging or even fun, but it is important. If there is a bug, someone has to fix it. When the year changes and the copyrights on web pages or emails need to be updated, someone has to do it. It’s part of your job to embrace the grind and take this small work off the plate of senior developers who need to focus on larger features and production issues. You’ll be in their shoes one day and will be thankful you’ll have someone to help with these tasks.
To excel and advance to the next level, you’ll need to focus on two things: ability and reliability. Throughout your career, you should work on the craft of software engineering. Always try to learn from books, conferences, and mentors. Study your company’s codebase and learn what’s good and what’s not. Learn how to write clean code with few defects. If simple bugs are found in your code, you’ll frequently have to go back and fix them or rework the solution. This prevents you from moving forward onto the next task.
You should also deliver on your promises. If your project manager needs something by a certain date, try to deliver it. If you don’t think you can, have that conversation earlier rather than miss the deadline. Managers appreciate knowing ahead of time rather than a last minute surprise. If you can deliver on time and with little rework, the managers and senior developers will have confidence that you can handle larger items.
Software Engineer II
At this point, you’ll have some wins under your belt and will be given more responsibility. You’ll get larger features to implement and maybe a small system to own under the guidance of a senior developer.
As always, keep sharpening your tech skills. Learn some design patterns and branch out into other areas like cloud operations or databases. Figure out what excites you and dive deep into that area. It’s always good to become recognized as the go-to person for a certain technology. It’ll also help you figure out in which direction you want your career to go.
You will also most likely start working across teams more frequently. If you’re developing an API that a front-end dev needs to call, work closely with that developer to determine exactly what they need and the best way to reach the goal together. When you get bugs from QA, work closely with them so you can understand the issue and help them if they don’t know the whole scope of the product.
Senior Software Engineer
Once you become a senior engineer, you’ll most likely be designing systems by yourself, but you’ll also be given more non-technical responsibilities. If your team doesn’t do whole team code reviews, you’ll be reviewing code. You may or may not be leading a team of junior developers. You’ll probably also be involved in meetings with product and project managers to scope out work and provide technical solutions for your company’s goals.
A word about code reviews: just because another developer didn’t write it the way you would have doesn’t make it wrong. Tailor your feedback toward simple design and easily understandable code. Point out problem areas (possible exceptions, null refs, etc) that you encountered yourself. Treat them partially as a teaching exercise so the other developers can level up their own skills.
In working with product managers, make sure you understand the end goal. Some managers have the habit of telling you the solution (“we should email the customer a CSV”) when they should be telling you what the customer wants (“they need to know how many widgets they sold today”). Sometimes the solution makes sense, but sometimes it doesn’t. Feel free to push back, but offer an alternative solution if you can. You’re on the same team with the goal of delivering value to your customer, so build a good working relationship with them.
You should also start looking around at the processes and systems that your company has in place. If a web service is receiving more traffic, point it out as a potential bottleneck and see if there are ways to refactor it. If every new product is launched with massive bugs and is a stressful event, invest in unit and integration testing. These things improve the quality of life for yourself and other developers.
Principal Software Engineer
A principal engineer often works as a de facto software architect. They are responsible for large systems and how systems interact with each other. They are often involved in transforming old systems into new systems. In my opinion, they should still be intimately involved in the codebase. You may not be able to do the most fun stuff anymore, but focus on the critical 20% and direct the rest of the team on how to do the remaining 80%.
I’m going to refer again to Gregor Hohpe’s The Software Architect Elevator. You’ll be in the unique position to have access to both the top level of the business and the folks in the boiler room who actually get stuff done. You’ll need to be able to speak both the language of technology and the language of business to make changes and communicate effectively to both audiences.
Parting Thoughts
One things I’ve noticed is that by the time you are promoted, you’ve often been operating at the next level before you get the official title bump. Don’t be discouraged. The work is more important than the title after your name.