Engineers often think "The path to improvement is to just do technology harder". Learn more technology, become a deeper subject matter expert, etc. While this is not wrong, it's also not entirely accurate either. You cannot ignore the above skillset as you advance in your career.
— Sean Kelly (@StabbyCutyou) May 31, 2018
Something I’ve slowly realized over the years is that there’s more to writing software than the technical: as you move up the ladder, the scope of your work and the skills you’ll need are no longer just about writing code.
Personally, I’ve never really liked management; I would rather write code than manage people, thank you very much. However, moving upwards doesn’t necessarily mean sticking only to the technical: there’s more to it.
For instance, I never paid attention to writing good commits at the start of my career, and the commits and commit messages I wrote when I was much younger were just barely passable, if not completely terrible — I often just rephrased the change I made in the commit message, without explaining its rationale, or my commits would combine several unrelated changes. Some of that could be attributed to the version control systems I used at the time — Subversion and CVS had no affordances, really, for editing commits, so you had to be more deliberate about your changes, which is tough.
As well, more experience also means more leadership, and leadership doesn’t necessarily mean only managing people, or leading a team. It just means more responsibility and accountability, and that often transcends technical details: it means that as you go up the ranks, you have to worry more and more about a larger slice of the pie, of the software system you’re building: you have to deal with things like the impact of your own damn code on customers, and other stakeholders — and the more senior you become, the more those concerns are your concerns too, and the more they loom larger.
At my first job, my only concerns were getting my part of the software out the door, while ensuring standards are kept. I knew at a theoretical level that version control was important, and since we didn’t have any, I helped implement something that the entire company could use — but I was only concerned about ensuring people committed their code, not whether they had good commit messages, or that the commits made sense, or that they weren’t checking in binary build artifacts.
Now, in every project I get into, I worry more about things like the cost of maintaining the software, and even how much it would cost to run and support the software — and I usually try to communicate these to the customer in clear language.
I also now worry about the health of a project, outside of the technology stack or dependencies being used: I worry about things like maintainability, about domain knowledge, and about communicating things.
I worry now about whether the source code I (or my teammates) write is readable; I worry whether bugs are being tracked, whether there’s an actual process that the team has agreed upon for tackling bugs and features, that there’s actual communication in the team.
I think that’s a key part: communication is paramount now. As you grow more senior, you realize that communication is everything, that however great your technical chops, it all doesn’t matter if you cannot communicate well with your teammates.
And communication goes beyond readable code: it also means communicating progress or lack thereof. Again responsibility and accountability: as you grow more senior, you have to acknowledge your own failings more often.
That means being absolutely honest to yourself about your mistakes, and communicating that to the team when those mistakes impact the project — especially when they impact the project. Responsibility, accountability, communication.
So, the path upwards, the way to level up I think is to grow those soft skills that you’ve always thought you never needed. Writing software isn’t just writing software: even if I think we’re still too young to have earned the right to be called an engineering discipline, a whole lot of the work we do is engineering in the broad strokes: it’s all of the things that other engineering fields do think about, I think.
Do I think I’m senior enough? I don’t know, there’s still a whole lot more to learn. But I’m definitely ready for it now. Still don’t want to manage, but that doesn’t mean I won’t.
Previously: Writing Readable Code