How to coach software engineers
In terms of the 3 jobs you juggle as an engineer, different experience, seniority levels come with different expectations. These 3 different jobs can also be used as a coaching framework to guide colleagues to expand their skills.
There are plenty of articles and books about coaching and mentoring, but they usually only offer an insight into the soft skills required to do it. The framework described below is an approaching for coaching as an individual contributor. This article is less suited for managers who are not programming themselves.
Seniority, experience and associated expectations
The junior engineer
Generally this category comprises engineers fresh off of school, or inflow from parallel tracks (like a manager wanting to get into programming). Developers in this category are mostly inexperienced on most fronts. Mostly relying on what they’ve learned in their formal education.
Expectations
A formal education in programming should have prepared them for being fairly proficient at using a programming language. You can expect them to usually write something that a computer will understand, but they will likely require some coaching when it comes to more complicated technical subjects like threading, performance optimisations, patterns or programming paradigms.
Expectations on the other 2 categories are fairly low. They should be able to pick up the gist of the business process relatively quickly, but the details will still be quite vague. This means there is no expectation that they can successfully finish a task when it is only explained in business language. In terms of writing human-readable code, the lack of detailed business and programming knowledge, will make that extremely challenging.
| Skill | Expected level |
|---|---|
| Write for a computer | Low - Medium |
| Understand the business | Low |
| Write for a human | Low |
Coaching a junior
The core of guiding a junior developer is slowly expanding their knowledge in all fronts. In first phases you want to give them low level tasks, at the most detailed level. A junior dev has fairly good knowledge about the programming language syntax, so working on or close to that syntax level is a good start.
The choice for this level is quite intentional: Their understanding of the business is still quite limited, so it’s hard or risky to only communicate in business language. Expecting them to then also translate that business language into human-readable code would be a monstrous task. The aim for this level is to eliminate those 2 factors from being an obstacle. Tasks at the very low level can be explained in terms of technical steps, in the programming language.
Any coaching should focus on expanding their skills/knowledge in a certain programming language, as well as teaching them about the business. And mostly focussed on low level, isolated tasks. Translating to human-readable code can be part of the mix but requires a bit more seniority as the complexity and cognitive loads go up quickly and require more experience.
The mid-level engineer
I’ve chosen these categories to be skill based, rather than time based. Time spent as a programmer has little predictive value when it comes to proper programming. Most of these skills are driven by being curious about how to improve as a person but perhaps most importantly, by the environments you’ve been in during your first few years as a programmer.
That means this category is quite wide and the edges are fuzzy (especially when it comes to progressing to senior engineer).
Expectations
It shouldn’t surprise you that the table below just says “medium” for all skills. It’s harder to describe the specific situation of a mid-level engineer as well: generally good but not exceptional. The expectations can better be expressed in what level of complexity they should be comfortable at instead of which skill is under- or overdeveloped.
They should be able to execute a task that:
- is explained to them only in business language
- requires a deeper knowledge of the programming language and general programming concepts
- is fairly good at making something a human can read
They should be able to do this in an existing codebase that has most of these items on point already. There is no expectation on a mid-level developer to be able to build this from the ground up. They should however be able to keep the quality high when the broad strokes have been put down: When the biggest abstractions are already made and align to the business.
| Skill | Expected level |
|---|---|
| Write for a computer | Medium |
| Understand the business | Medium |
| Write for a human | Medium |
Coach a mid-level engineer
Even though the expected levels are “medium”, there is still a huge range of skills levels to be found in mid-level engineers. As a coach it’s important to assess which skill is underdeveloped and needs focus.
Probably one of the best tools for this is pair programming. Where you are the navigator, not the driver. The process of pair programming as coaching, is perhaps a little more involved as you’ll be tested for your patience, quick reasoning and communications skills. Have a look at skills for coaching to get an idea of how do navigate and skyrocket the skills of your colleague.
To transition to senior you want to gradually focus on being able to handle tasks at a higher syntax level. As well as offering more about code design, architecture and communication.
The senior engineer
Expectations
The expectations for a senior go up significantly: they are expected to be good at each of the 3 jobs and probably excel in at least one of them.
Similar to a mid-level engineer, they should be able:
- understand the business process on all detail levels (either by having a lot of experience or being quick to learn)
- know all required programming concepts and have in-depth knowledge of the used programming language
- make it very easy for junior and mid-level engineers to contribute to the codebase.
The big difference here is that a senior developer should be able to do this from the ground up, and on all syntax levels of the code. This means a proper code design that guides your teammates, expanding into architecture and how your system relates to the software your neighbouring teams or rest of the company is making.
A senior engineer is slowly expected to carry a team in more than just code. They are expected to represent the team, communicate with the business, give presentations, provide guidance and coaching.
| Skill | Expected level |
|---|---|
| Write for a computer | High |
| Understand the business | High |
| Write for a human | High |
Coaching a senior engineer
If all the coding skills required of a senior have been acquired, the game changes and coaching becomes a different beast altogether. The 3 jobs require less attention: it’s more about refinement rather than learning new things.
There is a secret 4th job though: The social aspect of it all.
Coaching a senior is all about helping them develop the skills to support and represent their team. So your task as a coach helping them by offering advice on the soft skills, like The art of not answering questions or Improving your communication skills.
Coaching becomes a lot harder too because we’re dealing with softer skills than harder skills, and it’s less likely you’ll be sharing a lot of time together. Because soft skills often do not produce a tangible output, it’s hard to participate enough to continuously offer guidance. This means growth as a senior engineer is at least as much their responsibility as it is yours as a coach. Self-reflection becomes a valuable skill. Offering regular 1-on-1 sessions might be the best approach here.
The staff+ engineer
I’m limiting myself here to experience levels below staff engineer. The range of skills involved in staff engineering is very wide and vastly differs between companies, teams or your preferences. It’s also fairly recent that categorisation and guidance for staff engineers has become a subject so is still in the process of crystalising as a knowledge base. I would recommend The staff engineer as a resource if you are looking more into this.
Skills you want to train as a coach
The art of asking questions is probably the most important one.
Improving your communication skills is also important in your journey, for coaching your colleagues as well as communicating outside your team or with stakeholders.