Last time we went over some super high-level ideas about how you can be a good individual contributor (that is, not a manager), purely from a technical angle. But what about non-technical ways to be a better software engineer? Let’s dive in.
Keep the list of tasks you’re working on straight. This is really a two-parter. First, you need to keep a list of things you work on. This can be a list of bugs or feature requests in your bug tracker, but eventually you’ll need to track actual things you need to do. “Talk to so-and-so about the race condition in the XYZ server.” “Work on the presentation explaining what the XYZ server is and how new hires can ramp up on it.” So make sure you can track that stuff too, even if it’s as simple as using Keep or Inbox’s reminders or even a piece of paper and a pen. The second part of this is keeping the list straight. It’s easy to get lost in the day to day of your job and forget to actually manage this list, but if you don’t, then you fall into a mode where you’re just responding to the loudest thing on your plate. That is, if somebody pings you and says “hey my thing is the most important thing”, it then preempts whatever you were working before and now you’re chasing that until the next thing grabs your attention. So keep a list or be real good at context switching. Or both, but also keep the list.
Get things off your plate that shouldn’t be there. You have a list of things to work on. But the first thing you have to do with this list is a round of triage on it. Specifically, is somebody asking you for something just because you’re the only one they know on that team? This happens a bit to me – I’m a point of contact for a few services I work on, and as a result, people pass me bugs and know I’ll route them to the right place. But this means I have to keep a close eye on incoming bugs. If I go super deep on building a new prototype or server for a few days and a bug comes in that shouldn’t be on me, then anyone who is free can’t take the bug because they don’t know about it and people on the other side are frustrated because their bug isn’t being looked at, when it could be. So get those off your plate as fast as possible, to make room for things that do matter. Specifically…
Work on things that matter. Now that you have the list of things to work on that actually are your things to work on, prioritize it. There’s an order of magnitude difference between “this feature blocks the launch” and “code cleanup”. This is definitely not to say that code cleanup isn’t important. We’ve had code cleanup bugs where the bug was “this integration test takes 45 minutes to run and it has to be run on every code submission”. That’s way more important than “this feature blocks the launch”, since we have multiple people on our team who eat that cost multiple times a week, and the blocking features tended to be small code changes. Alternatively, upgrading your unit tests from JUnit3 to JUnit4 is a good thing to do, but not as important as that feature blocking the launch. But I like to mix them both in every once in a while to keep things interesting – if the thing that blocks the launch takes a while to build / deploy / test on a real device, and the code cleanup thing is fairly mundane, then you can do both to try to stay in the zone. This also means that you just might not work on certain bugs, and that’s fine too. If your incoming bug rate exceeds your outgoing bug fix rate, then you probably need more people on your team, so (assuming you can afford it) hire them.
Don’t be a hero. This one is the most important one. Taking a ton of extra work and overburdening yourself is one of the worst things you can do with your career. This isn’t to say that you should be lazy. But what happens if you take on a ton of extra work and burden yourself? You might get some thanks. But you’re burning yourself out and you’ve sent a signal to your peers and management that you can take on extra work, so what happens? You get more work to do, and now you’ve created momentum towards burning out. And then you hang in there until you get promoted and bail on the team, and now the team loses all this institutional knowledge that you were the only one that had because you were so busy fixing bugs that you didn’t write this stuff down. This is one I’ve seen happen a LOT, so don’t do that. Be happy. Enjoy what you work on and do a good job with it, and think of other cool things to work on. And if you see somebody else pushing towards burnout, and if you have a good relationship with them, talk to them so they don’t end up in that kind of situation.
Figure out who you don’t like to work with, and don’t work on projects with them. The converse is true, but to a lesser extent: figure out who you do like to work with, and do work on projects with them. The negative one is more true, because there’s a reason why I don’t like working with certain people on projects. They move too slow. They can’t be counted on to do the thing they promised they would do. Their coding style is bug prone and relies on you to be the reviewer who catches all the mistakes they made. They have super strong opinions about things and don’t hold themselves to the same standard they’re trying to force on you. The list goes on and on, but one negative person really does drag the whole project down, and you need multiple positive people to undo that negative person, who then feel drained in doing so. You might be forced to work on a project with a negative person, but you can at least work on things that don’t directly integrate with their work (usually, but not always). On the other side, if you are working with people you really like, let them know. It’s easy to say “yeah they know they’re doing fine, no need to say anything”, but you really should thank them and let them know you like working with them.
Like before, hopefully these help in some way! They aren’t set in stone, so tweak them or discard them as you see fit.