Software Engineer Career in a Nutshell
Free Weekly Developer
Newsletter
Almost 12 years ago, I started my first job as a software engineer. Until today, I worked for various organizations from startups to large enterprises. I decided to summarize what differentiates stages of a software engineer’s career.
Junior Software Engineer
You are working your first or second job. Usually, developers remain at this stage for 2-5 years. How long it will take you to level up depends on your learning ability and environment. If you work for the company that gives you access to talented colleagues you are set for success. In this case, you will level up within the first 2 years of your career. If you are a lone wolf or lack access to mentors you will need to find the right way on your own. It takes time because you will follow many dead ends. Often you might get stuck there for weeks. That’s why you need mentors in your early days. They will point you into right direction and help to stay on the right path. It doesn’t mean you won’t fail. You will fail often but each failure leads towards something. That’s why in early days your career you must find good mentors.
As a junior developer, you must love to write code. You should be passionate about building projects. You must pursue each opportunity to build a project. Gather feedback from your mentors as often as you can but do it at least once weekly. Try to follow up with other colleagues and ask how to improve it your solution. They should point you into some reading materials. You need to do this otherwise you will make so many mistakes so you will need to rewrite the project all over again.
Software engineering is a team work and even solo projects are about other people. Either managers or end users. It’s essential to express yourself in a clear way. Technical jargon isn’t appreciated outside of the development team. Non-technical people don’t understand it. It means you should learn to express complex technical subject in a simple manner. It will make you likable and all people will be eager to work with you. Soft skills are as important as technical skills. That’s why you need to get involved in discussions about projects with managers as well.
You might feel afraid asking silly questions so nobody realizes your true incompetence. That’s wrong. You should always ask questions whenever you feel stuck. Software engineering is a broad subject and it is impossible to know everything. Also, everybody knows you are a beginner. So nobody will be harsh to you. Often senior engineers ask silly questions but they aren’t afraid of being judged. All questions might be relevant and save implementation time. If you are a beginner your time is less expensive for the company but still precious. Your time can be used to reduce workload on more senior engineers. It is a win-win situation for both parties - you and the company.
After a few months, you will complete your first own project. It will be deployed to the production system. Somebody will even start using it. You start to believe you are limitless. Now you are able to build everything. You are not a junior developer anymore, right? Arrogance is common for beginner engineers. It comes just after you achieve your first successful increments. Usually, it happens within the first 6-12 months. You fix bugs that bothered users or build important features for users. You get positive feedback from users, managers and fellow team members. You are feeling capable and you know how to code. You will start to work on code written by others and you will not understand why they wrote it that way. Sometimes this code was written by people who left the company long time ago. You will make harsh opinions on those engineers. “They must have been stupid to write something like that”, “Someone intelligent would never write anything like this”. Instead of trying to understand their context you will decide to fix it. You will refactor this module in the correct way. Meanwhile you will break some parts of the system and you will waste weeks on fixing bugs you introduced. Of course, you didn’t realize this simple refactoring will take so much time.
Junior developers are incapable of estimating project or even tasks. Rarely, they notice any difficulties that can be encounter during the implementation phase. They will provide estimation based on short summary without researching what’s the issue. Sometimes they have luck and their estimation is correct. But realistically speaking, they tend to underestimate tasks and projects by 10-15 times.
Junior developers have poor judgement to quality. Their thinking about quality is always limited code or development processes. They love to argue with each other about whitespaces, code style or linting rules. More experienced juniors try to set 80% unit test coverage threshold. High code coverage threshold might sound reasonable but works in limited cases only. I mean they rarely prove that increment fulfills functional requirements of sophisticated application.
Junior developers never document their code. They believe their code is self-explanatory and it doesn’t need any further explanation. Their comments are limited to todos and links on code. Links supposed to indicate from where they copied the snippet from. Nothing beyond that.
(Mid) Software Engineer
You have been working about 3 - 8 already. You might still be at your first job but likely you changed the company at least once. The border between you and junior developer is clear. You made some trouble and learned few lessons on your own skin. Probably, you made your senior colleagues to stay after hours to clean up the mess you made. You can say you learned the importance of backward compatibility the hard way. At this stage, you are no longer focusing on writing code but on processes. You are trying to improve the team workflow to improve velocity of delivery. Your main goal is the make your team reach excellence in software development. You are no longer self-oriented but you are focusing more on the team.
Your focus in terms of software quality changed. You realized the importance of integration and functional tests. You know how to build software that adheres to requirements and security. Speaking of code, your write clean code that is maintainable by others. Your main focus leans towards correct system design, consistency and development processes. Probably, you automated some those processes using continuous integration and delivery pipelines.
You still feel eager to refactor code written by others but you are more safeguarded. Before you even think of refactoring you check code’s dependencies and test coverage. If you believe the refactoring is doable you split the workload into smaller pieces. Usually limit yourself to a single class or module.
You document the project by writing readme files and comments on code. Your readme’s are short and limited to basic explanation how to run the application. The code comments are short and used to explain the strange parts of your code. Usually other developers need to ask questions after reading your comments.
Sometimes mid software engineers get opportunity to mentor others. If you have this opportunity you should follow it. It will help you questioning your knowledge. Don’t be arrogant, you can learn a lot from it. Also, explaining something to senior engineers doesn’t immediately make you a senior.
At this stage, you will realize that other departments have impact on your work. You might believe others are wasting your time or deadlines are too short. Common time wasters are time tracking from HR / finance or “features” from marketing. That’s why mid software engineers a judgmental towards employees from other departments. Often they might even believe that the management is harming the organization.
Senior Software Engineer
Unfortunately, Most software engineers never reach this level. Reaching this level depend on how many initiatives you taken in your entire career. You worked on various projects with people from many backgrounds. Probably, you have 6-15 years of work experience. This is the “why” stage of software engineer career and your focus is no longer on coding or your team. Senior developers believe that unwritten code is the best kind of code. That’s why junior and mid software engineers consider them as party poopers.
Senior developers are responsible for projects that impact many departments of the organization. Often, they spend most their time on things not related to coding. They are often dragged between project plannings, discussions with stakeholders and debugging. The debugging is the most related to coding part of their job. If you are interviewing candidates for senior positions ask them how they debug code. They should tell you how they are doing it. If you find their answer vague you can ask them to explain what is a call stack. If the candidate doesn’t know it they aren’t senior yet.
Senior engineers give accurate estimates but are reluctant to estimate large projects. They favor splitting them into milestones, and deliver small increments every few weeks. Projects led by senior engineers are clear for all parties. Everyone involved it well-informed and aligned with the company’s vision. It includes business, security, hiring new developers and fitting into the big picture.
Managers and other developers like to work with them because they are reliable. They never judge people rather try to understand their perspective. The communication skills are essential for them. They are able to express complex problems to people without technical background. They learn about subject matter even if it isn’t interesting. Understanding business is the precondition to tackling the right problem. They are good consultants.
Senior developers teach others and never feel intimidated when they lack knowledge. Software engineering is too complex to know everything. They are prepared to tackle problems and fix bugs.
Unfortunately, even if you worked as a software engineer for 15 years you might not be a senior yet. Probably, I am not a senior neither. I conducted interviews with many software engineers claiming they are senior. Often, they didn’t know a difference between decimal and float data types. These are basics! You might argue. Maybe not but that’s what differentiates mediocre software engineers from great ones.
Whatever you agree or disagree with me feel free to drop me a DM on Twitter . It would mean the world to me if you share this story with others. To be honest, writing this article took me longer than I expected.
Thanks for reading.
