A 10 Year Retrospective of a Passionate Software Engineer
Since year 9 of my career I have been waiting to write this post. I was waiting to retrospect and look back at my path, and a decade of engineering was sounding like a nice point in time to do so.
I am now well into year 13 of my career, so as any software project — I am late to deliver.
Why am I writing this?
I mentor junior and mid level engineers, and one common theme that many of them mention is the lack of clear “progression path”, or what is the expected level at each point in the career timeline.
I see this article as a way to benchmark on how my career timeline looked like.
Every engineer does a lot in each year of programming, but I tried to distill one main theme of each year of my career progression.
It’s important to mention that in no way do I think my path is the right path, or the best path (I actually quite certain it isn’t), but it’s the path this humble engineer went through. It is also not the full one, but rather a gist of important milestones.
Year 1 — Learn to code
I’ve graduated from a good university, and what was clear when I began actual engineering work is that the coding level of fresh graduates is quite low. Most of our degree is focused on learning how to learn (and a lot of calculus), but our fingers didn’t see enough coding mileage.
So year one was just thousands of coding hours.
The code level was probably quite poor, but I’ve learned to deliver features, and just found my own phase of coding.
In the yearly review my manager’s main feedback was that the code I deliver wasn’t up to par with the quality standard of the team, and was buggier than expected 🙁. I doubled down on getting better.
🏁 If I had to sum it up to one achievement — I was able to deliver working features.
⏱️most time spent on coding
⬆️progress made throughout this year: minor
Year 2 — Processes, People, being part of a team
I started to “feel” how the company operates, although most of my time was still coding, I was a more integral part of a team, I had more opinions and I was starting to matter on a team level.
I was working more with people, mostly through requirements, reviews, etc.
🏁 If I had to sum it up to one achievement — I was able to become a confident, pleasant team member to work with.
⏱️most time still spent on coding with more emphasis on code quality (less bugs, more tests)
⬆️progress made throughout this year: medium
Year 3 — Complexity
The organization is now sure I can deliver, and more responsibility is passed down to me, I was leading quite large software components with more complex interfaces.
If until now each interface was “given to me”, and I just assumed it to be the absolute truth, now I was the one designing the interface, and maybe even questioning the design of the existing ones.
Through this more complex kind of work, I was in more contact with the product organization and customers, and it became clear that customers and engineers speak completely different languages. Each word used is nuanced with different expectations on each side.
I’ve decided to understand the customer better, and eventually learned to ask better questions, making sure what the customer wants, and what I understand and intend to implement, are the same things.
I’ve become quite a good engineer — customer middleman, I’ve became a domain expert.
It’s also become clear that I have a mentor that is helping me, and has a significant impact on my level. He was one of the veteran engineers in the organization, we had a click in one of the projects I was working on. Looking back — the impact on his mentorship (and of others) was a differential factor in leveling up.
This year had one of the pivotal moments of my career — Learning to unblock myself at any cost.
I was waiting for something from a colleague that was preoccupied by more urgent tasks.
I decided that even though this is not my discipline — there’s no reason I can’t do some basic electrical circuits. We had a short sync, I took a tool box, built a simple resistor voltage divider, and unblocked myself.
It will later be a major theme in how I operate — full ownership, learning even outside my discipline, and pushing features even when they seem to be blocked.
🏁 If I had to sum it up to one achievement — I was able to design and integrate mid-large software systems
⏱️most time still spent on integration and design
⬆️progress made throughout this year: Large
Year 4 — Dunning Kruger, Doubling down on learning
In year 4 I’ve hit hard in the face by the Dunning Kruger effect and I’ve acknowledged the hard truth:
I am thinking I am a much better developer than I really am.
My big red flag for it, was that I moved to a new project, and when I began working on the new project, I was “feeling” the codebase level isn’t great, but I didn’t have the means to express why, not did I have a clear path on how to fix it.
It was just a hunch, I was lacking domain language and expertise. I started leveling up!
I read clean code, I started going to meetups and conferences, and most importantly — I started nudging and taking more face time with our tech leads — asking them how they would address the problem I am trying to solve.
I can’t stress this enough — quality time with senior engineers is a huge stepping stone.
My tasks went from “just get it done” to “learn all you need to get it done right”.
🏁 If I had to sum it up to one achievement — exponential grown in the art of coding
⏱️most time back being spent on coding, now emphasizing on the art of code.
⬆️progress made throughout this year: exponential
Year 5 — Leading, Learn to “glue”, The art of coordination
I am getting things done, I’m proficient in a programming language (at the time it was C#), It’s time for some management skills.
I got my first team and project to lead.
We were 3 engineers, working on the project. It wasn’t the most challenging one, but it was ok.
I learned to motivate people enough, learned to delegate (which is a key skill of a good manager or leader), I learned to put checkpoints and milestones without micromanaging.
I was required to coordinate multiple parties, hold a lot of context in my head, and make sure nothing falls through the cracks.
Eventually I’ve really sharpened one of my (at the time) weakness — coordination and tracking. I now consider this to be one of my strong suits.
It became clear I was the glue for the projects I worked on, even those I am not managing.
I look back 7 years since, and it’s clear to me that communication, coordination and project management are important skills that no one thinks of when thinking of the “engineer’s path” — but it is one of the major roles of a senior engineer.
🏁 If I had to sum it up to one achievement — letting go, and delegating
⏱️most time spent in coordination, ticket management and talking to colleagues.
⬆️progress made throughout this year: large
Year 6 — Having Fun
Although it wasn’t the first time I enjoyed engineering (I enjoy it most of the time), in year 6 the stars aligned, and one of my best friends joined my engineering org, and we were staffed to work together on a project. It was crazy fun.
On the more professional ladder vertical — it was quite similar to year 5. Not much growth happened. Which led me to pivot and switch a workplace.
⏱️most time spent in coordination and documentation
⬆️progress made throughout this year: minor
Year 7 — SaaS, Cloud and Scale
I was eager to learn how Facebook and Google handle their massive scale, so I went to work for a hyper growth SaaS startup.
I switched technology stack, and was diving deep into cloud (AWS), infrastructure, Devops and how scale works. To be more precise, I was doubling down on how scalable systems are being built (I started from reading Martin Kleppmann’s Designing Data-Intensive Applications which I highly recommend).
It was my first encounter with Microservices with strict SLAs and multi-instance systems, which drove me to learn patterns of building resilient systems (some of which I blogged about in the engineering for failure post).
Again, I had a colleague who informally became a mentor, and had a major impact on my professional growth.
🏁 If I had to sum it up to one achievement — learning patterns of resilient systems and devops
⏱️most time spent in coding
⬆️progress made throughout this year: medium
Year 8 — Observability, Observability, Observability + Devops and SRE
It was my first time doing OnCall, and responding to real time production incidents.
I got intrigued, then inspired, and finally fell head over heels for Devops and SRE.
I started to dig into the infrastructure stack, and how our systems were operating in production, anything from CI/CD pipelines to the configurations and description objects of our production deployments.
From there the path to observability was clear, and I got hooked on monitoring, building dashboards, alerts, tuning production while trying to balance production stability and the oncall fatigue.
It became clear that being a developer that “speaks” and understands infrastructure is a super power, and a differentiating factor.
Do yourselves a favor and read Google’s SRE book.
🏁 If I had to sum it up to one achievement — gained real expertise in monitoring and observability
⏱️most time spent in observability platforms and Kubernetes YAMLs
⬆️progress made throughout this year: Exponential
Year 9 — Business metrics and Cost efficiency
I was now quite experienced with building systems, even complex ones, I was never required though to be on budget.
My projects were either:
- expensive by design (to support the phase of hyper growth startup)
- or cheap due to small scale and usage.
I was never required until now to think of the cost of the software, or its unit economics. Year 9 was all about building the same systems, but cheaper, taking cost into design considerations.
This was the year of large cost optimization projects (you can read more this and this one).
We were talking about operational cost in design reviews now. It was much more challenging building the same reliable systems but only under budget.
At one point we scratched the “optimal solution” for a good enough, 10x cheaper solution. Engineering is all about tradeoffs.
It wasn’t only about money, I started seeing, and asking more and more about the business incentives, goals, and KPIs.
I became super business centric.
It became a key part of my day to day, to the point that I was able to convince to take on a project (or reject it) by simply by asking “how will this project increase our KPI of focus”. From here the path was short to start taking more interest in the work of product managers, and I did some leveling up on that front too (I recommend you read inspired very much. Yes, even if you are a developer).
🏁 If I had to sum it up to one achievement — Better focus and understanding of business goals and product metrics (KPIs)
⏱️most time spent in observability platforms
⬆️progress made throughout this year: medium
Year 10 — Year of initiative
It became clear to me that I don’t want to pursue a career in management, nor do I want to code all day long. It’s the mixture of the two that I enjoy most, plus solving complex problems and driving difficult changes throughout the organization.
It set me on a Senior IC career path, taking initiative in my engineering organization, looking for hard challenges to solve, and trying to help level up the people around me.
As I had mentors along the way — I became one for others.
I really believe that leveling up, and creating other senior engineers around you is one of the fundamental requirements of a senior engineer, and making others better is part of my way to make an asymmetrical impact.
It was also the year of achieving a personal goal of mine of giving my first talk at a tech conference 🤘
🏁 If I had to sum it up to one achievement — mentoring other engineers
⏱️most time spent in collaboration
⬆️progress made throughout this year: medium
Year 10+
This will wait for the 20 year retro, but generally I’ve set myself on the Senior IC path, working hard on technical leadership.
I’ll update in 7 years how that went ;)
Timeless truths
Looking back on the path taken, I think I can point out few truths:
- No one is responsible for your career path but you.
Your managers might care enough to do some of that for you, but it’s your responsibility to drive it forward. - Having a mentor is a force multiplier!
It’s literally a means to learn faster, it’s a shortcut! It’s a way to see first-hand how more experienced engineers think and operate.
Find yourself a mentor. - No employer will ever think less of anyone who takes initiative and wants to do more.
It’s totally within your reach to be that person. - Learning through daily tasks is not enough for becoming a top tier engineer (and I’m not saying I am one).
The craft and technology it’s just too complex and requires a lot of passion and time. At least this is my observation. - Nothing — and I mean it — Nothing! is more important than being a decent human being, a pleasant colleague, and a pragmatic engineer.
Nothing is more important than making your colleagues feel comfortable and safe working with you. This becomes even more important as you hold more senior positions.
Final thoughts
I think this is the most personal post thus far.
It was fun looking back, retrospecting, and trying to distill a whole year worth of work to a single achievement, or main occupation. It made me think where I could do better, and where I really did my best.
If you’re a senior engineer — I’d be thrilled to hear your thoughts on my path, or hear your path.
If you’re a junior — mid, start thinking about your career path, ask the seniors around you how they’ve gotten to where they are, take control over your career path.
As always, thoughts and comments are welcome on twitter at @cherkaskyb
