Discussion
What does it mean to be a junior developer, senior developer, software architect, and CTO?
Recently, Jace published an article, Do I Have What it Takes to be a Senior Engineer?, in our community. It really got us thinking. What is it that separates a senior developer from a junior developer? Or a CTO from a software architect?
Besides technical know-how, here are some of the things we think separate senior from junior developers:
- Analyzes and designs software architecture well
- Introduces better workflows to the team
- Shares knowledge and provides feedback
- Keeps calm when sh*t hits the fan
- Communicates respectfully
- Admits Mistakes
What do you think? Did we miss anything? What about software architects and CTOs?
Let us know in the comments below 👇 or in your own post!
Here's⬅️ a piece we wrote on how to be the engineering manager that your company needs. We'd love to hear your feedbacks!
As long as talking about the ranks I would rather separate social aspects and technical expertise (take Linus, for example). Often, great technical leadership comes with some cons on other areas. This kind of things are better addressed thru “career orientation” discussions. At the end of the day, value is the king so that everyone would find a good fit.
As for the ranking it’s rather straightforward - you split it based on “WHY/WHAT”, “HOW” and “WHEN” questions.
Junior and Senior developers are individual contributors that answers “WHEN” smth will be done where Senior has more experience and thus predicts better and more reliably in case of non-routine or non-standard tasks. Senior could mentor and lead Juniors. It’s good practice then each Junior has a settled Senior as a buddy from whom he can learn (especially, specifics of current team and technology).
Architects answers “HOW” and then distributes the answer as set of tasks to individual contributors. Seniors could provide input to Architects to align on costs and risks. Personal engagement in implementation (like 25-50%) is highly desirable.
CTO is about “WHY and WHAT” (i.e. strategy). Business acumen is a must. Delegation to Architects is a must (to assess different tactics). Leadership is a must.
it’s no longer about implementing of technology - it’s either about inventing technology for business scenario or vision on applying existing tech stack to the best possible business outcome.
The person should feel responsible for the product / project that they are working on and should not show a “not my job” attitude. For example, when I work on feature and I find a bug that is not related to what I am working on but can be fixed in less than a hour or something, I don’t report it to issue tracking and ask the author of the code to fix it. The same applies to performance optimisations, e.t.c
When a person shows this kind of attitude to set individual differences aside and work for the improvement of the product or tool, that is where they are differentiated from a junior developer
You can split things further, and it turns out a lot of companies do. A senior engineer is not actually a high-level position at most software companies, you can usually get to being a “senior engineer” by your late 20’s and early 30’s. The difference is usually described as this:
However there are more levels than that. Many tech companies have a “staff engineer” or a “principal engineer”. These non-managing engineers generally have impact far beyond themselves: they decide which problems among many are the important/impactful ones to solve, they set the development culture for the entire organization, they enable all the engineers to be more productive.
Here’s a great article that goes into a lot more detail on principal engineers: https://blog.dbsmasher.com/2019/01/28/on-being-a-principal-engineer.html