I recently met up with a couple of fellow engineers, and in passing I mentioned that I always tried to do some amount of coding every day, even when I was a distinguished engineer at Uber . For some reason it came as quite a surprise that I was “allowed” to code at that level.
Thinking more about it, it probably shouldn't be a surprise. As a senior engineer you're constantly pulled into design discussions, reviews, planning meetings, interviews, status meetings, and much more. And there's just no way there's time for all of it, so you end up having to say no to a lot of people.
Saying no can always be hard, but I personally have always prioritized being close to the actual code. That is probably harder than it sounds, and people often ask me how I have planned my career to get to where I am, so I thought I'd give my take. Let me first of all say that I have never planned my career as such. Instead, I have always operated under some fairly strict principles, and it seems from looking at people I've mentored over the years that these principles are fairly useful (and at the very least they got me to distinguished engineer at a pretty big tech company, which seems to count for something). So, here goes:
Write code every day . If not every day then almost every day. It doesn't have to be super advanced code, it can just be bug fixes or refactorings. This by the way requires you to always have a functional development environment. Because there might eventually be so much else going on that there might only be 30 minutes or an hour here and there to sit down and write code, and then it's no good if it takes a while to start the development environment.
Review code every day . This is almost as important as writing code, and it both allows for you to learn from others and for others to learn from you. I don't wait for people to ask for review, when I have time I'll just review whatever is queued up. I also sometimes do what I call drive-by reviews, which is reviewing code that's not from my own teams (in those cases I usually don't leave blocking comments, just general advice on structure and style).
Be lazy! Not in the sense of not working, but in the sense of not repeating yourself or making other people repeat themselves. Repeating comes in many shapes, but typically it's when you in order to do one thing also need to do something else. A small example from Beyond Work : starting out, the process for creating a pull request was:
Find an issue in Linear
Copy the branch name
Checkout main and pull
Create a new branch
Write code and commit
Push to origin
Open GitHub and create a pull request.
Nothing out of the ordinary here, but stuff like this annoys me a lot. So it took me about 30 minutes or so to write a small Python script that has two commands: linear branch and linear push. The first will list open Linear issues, and when you pick one it will create a fresh rebased branch with the right name. The second will push to origin, mark the branch as tracking, and open a PR. This helps not only myself but everybody.
We used to joke that the ctrl/cmd-c/v shortcut should be disabled, because when you're copy/pasting it's usually because you need to repeat either yourself or someone else, and that shouldn't be necessary.
Be selfless . I've had many people ask me what to do if you don't receive credit for a piece of work you've done. My answer is always to just keep executing. It will become clear to everybody that you are doing great things, and great things usually get rewarded. Another part of being selfless is to think about how you can improve the lives of others as an engineer. The more senior you get the more of the picture you can see, and that allows you to also spot inefficiencies. It can be small stuff like the PR process above, or it can be large architectural changes.
Use your power . Not to force your opinion through, but to create alignment and support your team and company. For example, I've seen many cases where internal tools are broken, and people just complain to their teams about it, but not directly to the owners of the tools. The owners might not know about the tools being broken (which is bad in itself), or they might not realize what the full impact is. Here it can really help if you step up and engage with the owners to fix the issues.
Less FOMO, more delegation . Meetings make you feel important. More meetings make you feel more important. And it's very easy to feel that you're missing out on a lot of the action if you're not there. But the thing is, meetings actually don't require your presence, especially not when other people from your team are there. So you should delegate responsibility, have them take care of some of the meetings (and the work that inevitably follows from the meetings). If something important comes up, they can always reach out to you. And yes, sometimes you really should have been there, but that has never been the end of the world for anyone.
Carve out responsibilities . This is typically in cooperation with managers, but make sure you don't have all the interesting projects to yourself. Put other engineers on the team in charge and be explicit about their responsibilities, and once you have put them in charge then stay off unless asked for feedback or if something very bad is about to happen.
Let people fail . Part of delegating responsibility is allowing people to fail without penalizing them. The greatest learning experiences come from failing, so let people fail once in a while. Sometimes I'll have a discussion with someone on how to solve a problem, we talk about different solutions, and even if I know that the solution proposed is not going to work, I let them do it and learn from that. And of course, I try to never gloat afterwards. There are of course cases where failure is not an option. When we built the stateful deployment system at Uber, one of the main focus points was to never lose data, so if someone would propose something that would cause data loss that would of course not be allowed.
Own your mistakes . Sometimes (probably more often than I like to admit), I make a wrong decision or don't properly consider alternatives, even when presented with them, and later on it turns out that I was wrong and someone else was right. Even though it's a bit painful, I then try to be open about it and not cover it up, and give credit to whoever was right.
Always be tinkering . You can't learn everything, but as an engineer I'm always curious as to how things work, so (mainly in the pursuit of laziness) I poke around in libraries, tools, etc, to learn how they work and how to use them. It doesn't always lead to something that's directly useful, but much of it does come in handy over time. I usually don't spend a lot of consecutive time on this, but if I need to wait for a build, or an update of something, or I have 10 minutes between engagements then I might as well try something out.
Some might ask “what about being a good role model, leading from the front, motivating people, etc?” To me, those things matter, but the way you do it is through your actions and principles - in my case the ones mentioned above.
All of this said, I just like building stuff. Other people might have different motivations, so don't take this as absolute truth - but I will say that I have mentored a fair number of software engineers over the years who have benefited greatly from this way of thinking. Also, there are other good resources about software engineering out there -
's book and
's newsletter and book are both great examples.
And finally, do let me know if any of this is useful. If so then I might cover some more techniques I find useful as a software engineer who also have to deal with people a lot of the time 🙂
First published on LinkedIn, 14 January 2024.