Junior, senior, intermediate… What am I? Does it matter?
It doesn’t really matter, but it does impact how you think about yourself. It also goes hand-in-hand with your role and your salary expectations too. For the company, it’s helpful because having a good team composition on a project is important. Too many experienced people means a higher project cost. Too many junior people and the project may not come out as polished.
What you or your company calls you mostly comes down to how much guidance you will need from other members of your team and the variety of what you’ve been exposed to thus far in your professional career.
Junior programmer. You have limited experience as a professional developer. Your code may be great, but you still make simple errors like misaligned code blocks, bad class names or even have issues with language syntax. A junior programmer needs programming help.
Intermediate programmer. You’ve got programming down, but you have limited experience with the common pitfalls of design. Design patterns are your friend and you probably should review big tasks with someone else on your team before undertaking a larger task. An intermediate developer needs design help.
Senior programmer. You have a fair number of projects under your belt, but haven’t started too many. You’re a leader on the team, helping design and guide features to completion. You make sure that designs are kept consistent and there aren’t too many clever bits of code. You’re looking to a software architect role for guidance when starting a new project or refactoring something across the board.
Software architect. Another word for senior programmer, but you’re the person who draws the lines for other members of the team to fill in. You also make sure that the lines don’t move. You’re also accountable (meaning you have to fix it) when the project scope changes and the architecture can’t handle it. You may not need to stick around for the duration of a project, but if your company has multiple projects, it’s probably good that you check-in from time to time. You need to get buy-in from the CTO when proposing new software solutions.
There is a hierarchy of job titles, but conceptually these are roles to fill and come down to responsibilities and level of experience. The difficult part for people is that because they are organised hierarchically, it goes hand-in-hand with salary expectations and ego. Once someone gets to a certain level, they don’t want to go down, even though it may better represent their role on the team.
Leave a comment