What’s the difference between a junior and a senior engineer
I’ve always wondered, if it is possible to be a senior engineer with a junior engineer title? If so, what’s the difference between the two? There have been instances in my career where, although I was the most junior person on the team, I accomplished the most as measured by the number of tickets resolved (e.g. features, bugfixes). Did my manager see what a great job I was doing and promote me? No. The difference between a senior and junior engineer isn’t about the amount of lines written or tickets closed. It’s about the subtle nuances of software development (e.g. the best practices that come off as fluff to the less experienced). For the sake of simplicity, in this post, we’ll exclude soft skills and focus on technical aptitudes.
Development
Completeness
When a junior engineer is tasked with implementing a new feature, they will create a dedicated branch, make the required changes, validate that it works, and create a pull request. They may, however, forget to add (or intentionally neglect adding) unit tests and documentation. The senior engineer has been around long enough to know that one day someone is going to have to make changes to that part of code base. If the code is properly tested, any breaking changes will be caught before making their way into production.
Documentation is useful for someone who looks at the code for the very first time, and doesn’t have all the context as to why it was written that way. A well placed sentence can go a long way in ensuring that they do not leave out any business logic when modifying the code base. The problem with documentation is that some people overdo it which can lead to an aversion to writing it in the future. Your code should be self documenting. You should only document the parts that are absolutely critical for understanding. In addition, as espoused in the book Software Engineering at Google, documentation should live as close to the code as possible. If someone on your team asks you to go update some Wiki, you should raise a concern. Anyone who’s onboarded a team recently knows that the Wiki’s quickly fall out of date. If the documentation lives inside the repository, it’s more likely to be kept up to date as the code base evolves. Moreover, when documentation is written alongside code, you can enforce conventions (e.g. docstrings), which will encourage others to write documentation since they have something to work off. Furthermore, there exists tooling that is capable of rendering documentation in HTML format that could then be distributed to others who just want to use the exposed APIs.
A senior engineer shouldn’t approve any pull request that hasn’t been properly tested or documented first.
A given task can be expressed in terms of what and how. Most junior engineers can write code that will address the what. For example, when adding a REST endpoint for uploading images, they will confirm that they were able to upload an image themselves prior to considering the task ready for review. However, they won’t always account for the different edge cases (e.g. upload image with the same name, upload a corrupt file, etc). On the other hand, a senior engineer would pull out a pen and paper and think of all the different edge cases that might arise prior to implementing a feature.
Junior engineers will strive to address the how – ensuring that the code is sufficiently dynamic and modular. That being said, they will often fall short. A senior engineer has put in the hours necessary to apply the best practices.
Breaking down tasks
A junior engineer has a hard time working with ambiguity. They like having a well groomed backlog of tasks to pull from. When given responsibility for a larger feature or system, they will often stick to what they know best (i.e. writing code) and spend less time on organizing the work itself.
A senior engineer is able to break down tasks into quanta, and express the relationship between them. For instance, if tasks cannot be worked on concurrently, then they should be marked accordingly (e.g. A depends on B). They will come up with a list of pros and cons for each approach with the understanding that there is no right answer. For example, they may decide to use platform native functionality as opposed to open source technology since the latter would require more man hours to setup and maintain. They will include the tasks that produce the most value first in the upcoming sprint.
Refactoring
A junior engineer thinks in terms of technology whereas a senior engineer thinks in terms of business value. For example, a junior engineer might push for the adoption of a new technology (e.g. framework, language) simply because it’s cutting edge. On the other hand, a senior engineer will account for things like the current expertise on the team, the time needed to ramp up (i.e. learn the new syntax) and the advantages over what’s currently in use.
Operations
There’s a great book called the Effective Engineer by Edmond Lau. In it, the author talks about how the 10x engineer doesn’t necessarily need to put in 10x the time or effort. Rather, they need to be more selective about where they spend their time. For instance, a senior engineer might refuse to work on something that won’t be of value to the client. In other words, they spend as much time figuring out what the client wants as they do writing code.
They will also spend time on tasks that will improve their productivity and their team’s productivity down the line. For example, spending the time to setup your IDE properly is an investment that is often overlooked. However, if in setting up your IDE, you save a few seconds of iteration time, this could lead to days worth of savings throughout the remainder of the year.
A senior engineer does not need to have DevOps in their job title in order to be a big proponent of DevOps. They measure software delivery performance using the four key metrics as defined by the DORA research program:
1. Change Lead Time — Time taken for changes to end up in production
2. Deployment Frequency — How often they deploy to production
3. Mean Time To Restore (MTTR) — Average time taken to recover from failure
4. Change Fail Percentage — Percentage of deployments causing a failure in production requiring remediation
In order to make concrete improvements on these Key Performance Indicators (KPIs), a senior engineer will advocate for things like version control, continuous integration, continuous delivery, shifting left on security and code maintainability.
A novice programmer will go through the following sequence of steps for days on end:
- Move the ticket status to in progress
- Write the logic
- Write the unit test to verify the logic
- Verify the logic by running the application
- Write the documentation (e.g. docstring)
- Push the code to a feature branch
- Open a pull request
- Move the ticket status to in review (if not automated)
- Address any comments on the pull request
- Merge the pull request
- Move the ticket status to done (if not automated)
- Repeat
In contrast, a senior engineer won’t go to Jira right away and pick up their next ticket. They will spend some time thinking about how the process could be improved, if what is currently being worked on is providing the most value to the business.