How to grow as a software engineer comes down to a shift from executing tasks to effecting change: design before you code, mentor others and lead work without waiting for a title. Mid-level engineers should start with design and mentoring.
This list is built around the mid-to-senior transition and draws on published career ladders and engineering guidance. For related notes on the craft, browse the software engineering blog.
Selection criteria and ordering
A move is included here when a published career ladder or engineering guide treats it as a senior-level skill and when you can practise it in your current job. The moves form an ordered sequence, from habits that build technical judgement to those that make your impact visible. It is a sequence rather than a ranking, because the right first move depends on where your current work leaves gaps.
- Named in a public source. Each move maps to a skill that a ladder, role description or practitioner guide spells out, so you can check it against your own employer’s expectations.
- Practicable in your current role. Nothing here needs a new job or a new title before you begin.
- Leaves evidence behind. Documents, reviews and shipped work give a manager something concrete to discuss at promotion time.
What the levels actually describe
James Shore’s published software engineering career ladder grades each skill on four levels: None, Learning, Proficient and Fluent. Fluent means the engineer uses the skill automatically, without special effort, whenever it is appropriate. The Software Engineer title in that ladder requires six skill sets, including Basic Design and Basic Leadership. At the bottom, Associate Software Engineer 1s are at the start of their career, while a Software Engineer 1 can contribute to the work of the team without explicit guidance.
CodeSignal’s guide to becoming a better software engineer draws the next line. A good engineer delivers high-quality code, writes effective tests and reviews contributions from peers. A great engineer is a force multiplier for the whole team, and the guide describes the step up as a shift from executing tasks to effecting change. Once you work without guidance, the growth moves below are about multiplying other people’s output, not only increasing your own.
Design and communication moves
Write the design down before you code
CodeSignal advises designing the software architecture of your programs before you code them. A role blueprint for senior engineers from DevOpsSchool lists system and component designs as senior output, written as lightweight design docs or RFCs that include tradeoffs, constraints and rollout plans.
The practical step is to write a short design document for your next non-trivial change and share it before implementation starts. This suits engineers who mostly implement designs handed to them. Keep it light: the aim is to expose tradeoffs and rollout questions early, not to produce paperwork.
Explain your mental model to others
Shore’s ladder places technical diagramming, explaining your mental model and ensuring everyone’s voice is heard in its Advanced Communication skill set. Treat your design document as the place to practise all three. Add a diagram, state your assumptions plainly, and invite the quietest reviewer to comment first.
This move suits engineers whose work is sound but not widely understood. Its limit is that explaining only helps if the audience can respond, so choose a forum where questions are welcome.
Code reading, review and mentoring moves
Read more code than you write
Vadim Kravcenko’s notes on the habits of great software engineers observe that strong engineers read code at least as much as they write it. Reviewing other people’s changes is the easiest way to do this on a schedule, and it feeds directly into design judgement. Our guide to code review best practices covers how to make that time useful for both author and reviewer.
This move suits anyone who ships a lot but rarely sees how colleagues solve similar problems. The limit is that skimming approvals teaches little; read for the reasoning behind a change.
Mentor and share what you know
Mentoring and coaching appear in Shore’s Advanced Leadership skill set alongside peer leadership, comfort with ambiguity, risk management and intermediate facilitation. DevOpsSchool describes the senior duty as coaching junior to mid-level engineers through pairing, design reviews and structured feedback, and Revelo’s software engineer career path overview likewise lists leading and mentoring junior engineers among senior responsibilities.
Kravcenko adds a self-interested reason: sharing knowledge lightens your pager load because more teammates can debug the system. Begin by pairing with a newer colleague on a real task rather than scheduling a formal programme. The limit is time, since mentoring competes with your own delivery, so agree the scope with your manager.
Leading beyond your own tasks
Lead technical work without managing people
DevOpsSchool’s blueprint describes senior engineers leading epics without acting as a people manager. That matters for the mid-level to senior transition: the step is a wider technical scope, not a move into management. Volunteer to own an epic’s plan, break it into tasks, name the risks and keep teammates informed of progress.
This suits engineers who want more influence but not a reporting line. The limit is that the opportunity must exist on your team, so raise it explicitly in one-to-ones instead of waiting to be assigned.
Improve the workflows around the code
CodeSignal notes that engineers who understand the full software lifecycle can propose ideas to streamline workflows such as code review and on-call, and that improvements like this can save many engineering hours. Look for a recurring annoyance in your team’s process, propose a small change and measure whether it helps.
Build something end to end
A side project gives you a complete piece of work to design, ship and explain. The star wars api project on this site is one example of building an app from start to finish, and a project like it is a safe place to try design documents and diagrams before using them at work.
Getting promoted
Promotion rules differ between employers, so find your company’s ladder first. In Shore’s ladder, an engineer becomes eligible for promotion to a title once they are fluent in all the skills for that title and for all previous titles. The ladder also offers step promotions, such as Software Engineer 1 to Software Engineer 2. Managers in that system evaluate skills by talking to team members and observing the engineer’s work.
The same author describes an earlier approach in which engineers gathered evidence and each piece contributed towards promotion. Either way, the practical advice is the same: list the skills your ladder asks for, mark where you are Proficient and where you are Fluent, and keep dated examples such as design documents, reviews you led and people you coached. Revelo adds that engineers moving up from entry level need additional experience and qualifications gained by developing projects alongside a team, so seek out shared projects rather than solo work.
Lessons that hold up over years in the job
Kravcenko’s notes contain several habits that pay off over time. Quick hacks feel good until a later quarter, when the feature needs a tenth tweak, so weigh the cost of a shortcut against how often that code will change. He also tries to model the impact of a change in two hops minimum, meaning you consider what depends on the thing you touch and what depends on those dependents.
He also points out that coding can take anywhere from 20% to 80% of a week depending on the team. Do not measure your growth by how much you type: a quiet week of review, design and mentoring can move you further towards senior than a week of pure implementation.
Choosing your first move
Pick the move that closes your most obvious gap, not the one that sounds most senior. The table compares the moves that map directly to named ladder skills.
| Move | Skill it builds | Best suited to | Limit to watch |
|---|---|---|---|
| Written design docs | Design and technical diagramming; tradeoffs, constraints and rollout plans | Engineers who mostly implement designs from others | Only useful if colleagues read and comment |
| Mentoring and coaching | Advanced leadership; pairing, design reviews and feedback | Engineers with a newer teammate nearby | Takes time from your own delivery |
| Leading a technical initiative | Peer leadership, comfort with ambiguity, risk management | Engineers who want senior scope without managing people | Needs an initiative to exist and your manager’s agreement |
| Explaining mental models | Advanced communication; making sure everyone’s voice is heard | Engineers whose sound work is not widely understood | Needs a forum where questions are welcome |
| Gathering promotion evidence | A record of work counted towards promotion | Engineers preparing a promotion case | Ladders differ in how promotion is judged |
Skill names in the table come from James Shore’s career ladder and the DevOpsSchool senior role blueprint.
Frequently asked questions
Does a senior title mean a late-career engineer?
Not necessarily. In Shore’s career ladder, Senior Software Engineer 1s are still fairly early in their careers despite the name, so aim at the skills rather than at years served.
Do I have to become a manager to be senior?
No. DevOpsSchool’s senior role blueprint describes senior engineers leading technical initiatives without acting as a people manager.
How do managers judge skills on a career ladder?
In Shore’s ladder, managers talk to team members and observe the engineer’s work. That makes it worth sharing your work openly with teammates, since their view feeds the assessment.
Is leadership only for senior engineers?
No. CodeSignal notes that leadership is often confused with seniority and that you can lead from any position within a team, so you can practise it before you hold a senior title.
