I was speaking to a former colleague recently and in talking about my struggle to find opportunities as a coder he asked me if I’d ever thought about becoming a people manager and that he’d always thought I might be good at it. It’s something others have told me as well in recent years but not something I believe suits my strengths or skill sets. But it did get me thinking about if I ever did become a manager, specifically a manager of engineers / programmers / developers, what I’d want to have been told and taught to me at the various stages of my career.

Entry level / junior developer

Don’t be afraid to ask questions because you feel like it might make you look unskilled or like you don’t know something. There’s a lot you’re not expected to know right now and a lot of mistakes you’re unfortunately going to have to experience to learn from rather than being handed that wisdom. And that’s okay. 

Your role is to figure out what problems excite you or that you’re particularly adept at tackling. To learn and explore and share the new technologies, frameworks, ideas, and tools you find with more experienced developers who might have a bit more Life responsibilities that don’t always allow the freedom to do that. Also frankly they might be a little more cynical and jaded and therefore not as open minded as you are. That’s not to say that everything you find is going to be valuable or used. But if you find even one tool or plugin or whatever that saves your colleagues a lot of time and effort not only will you be helping your team but people will notice and that will help your career.

You should also be seeking out mentors. They don’t have to be much more experienced than you. Just someone with similar vibes who you can build rapport with. If you are a white male presenting developer I’d strongly suggest you seek out someone that isn’t the same so that you have exposure to a viewpoint you might otherwise not be granted access to. It will make you a better developer but more importantly a better person. There are also countless examples where homogenous development teams have blind spots. See early iPhone face ID.

Mid level developer

You should be even less afraid to ask questions and many of them should be around gaps you need to fill to get that next level up, which not everyone achieves. You should also be wary of the trap many fall into at this point of overconfidence and its dangerous transition sometimes into being dismissive of others less experienced or non-coders. You don’t know what you don’t know yet and being humble about that will make you a better colleague and help you succeed. Regardless of level there is always someone smarter than you or with a better understanding of certain problems.

You should still be learning and exploring new things, although it’s understandable that it may not be to the amount of earlier in your career. You should be focusing on growing niche skills that excite you and trying to mentor and build up less experienced developers. Growing your code review skills here is both mandatory and immensely beneficial as understanding both what to critique and how to do so based on the individual will be an invaluable skill that also translates to other paths if you decide to branch out of being a developer. It also makes you look more critically at your own code, which will make you a better developer.

You should start the transition from “how do we solve this problem” to “should we be solving this problem” / “what is the real problem we’re trying to solve”. This is often the key unlock for moving from mid level to senior, in my opinion. It’s not easy and you’ll never fully grow out of it, but being able to take a step back and think about things from a higher level is good for your career and personal growth. 

Finally, and this is more subjective and possibly just my opinion, you should make sure you’re starting to have something – hopefully several things – that give you joy and purpose beyond coding. A partner, kids, hobbies, pets, faith, volunteering, community, etc. Career and financial stability are important but they are not the only important thing. Of all the important things career may, arguably, be the least important beyond achieving some financial stability. Also these things help your mental health which makes you a better human and, therefore, a better developer.

Senior Developer

This is where things can really get interesting and frustrating. You’re going to be asked to do a lot more non coding things, mainly meetings. So. Many. Meetings. A good skill here is getting good at saying no and having the courage to do so. To unnecessary meetings or features. But tactfully, not blowing it off outright but thinking about what the real goals may be and suggesting solutions towards those. Could that meeting be once a week instead of three times a week? Could it be something asynchronous like some shared documentation, a slack thread, email, wiki page, whatever?

By now you should have mastered, or be close to mastering, the idea of solving the right problems, not just the ones presented to you. Of identifying the real pain points and fixing those, which sometimes – but don’t always – match up with what you’re asked to build. You should be mentoring and reviewing code more than you’re writing it. Your job is not to write code. Your job is to level up the next generation to their maximum potential. I know, it sucks, you’re at the point in your career where you’re the most adept at quickly solving problems more optimally than you ever have before. But you solving one problem is not as valuable to your team as teaching several others to solve multiple problems better. Be humble, be kind, be patient, and be curious.

Ask your younger colleagues, especially ones near the beginning of their careers what excites them out there. Then dive into it, possibly pairing with them to do so. Pick it apart. Let them show you what they think is cool about it. Show them some of its limitations that they might not have grasped. Don’t destroy their enthusiasm, this is again about teaching – teaching them to think critically about new frameworks, libraries, tools, etc. 

Shower your colleagues with praise, sprinkle them with criticism. In retros, meetings, code reviews, or pairing. If they contribute something cool or find something useful make sure managers know it. Help them in their career. Be the champion you wished you’d had when you were in their shoes. 

Tech Lead

I dabbled at being a tech lead, but I was never really one. So if I’m being honest I’m not entirely sure what it really requires since I could only observe it from the outside. But for the ones I worked with that I liked it was mostly what a Senior Developer would do with the added responsibilities of thinking more broadly around architecture and tooling – with the idea being to make your developer colleagues’ lives more productive but, more importantly, easier. 

Also just sort of acting like a buffer from bad ideas. Sometimes a stakeholder or management will get a “big idea” that you know is going to be a boondoggle. Either from experience seeing something similar tried in the past or just understanding that not all people in charge are there because they’re good leaders. Unfortunately, some are just the loudest in the room or the most adept in corporate politics. You can’t always save the team from these but sometimes you can take on doing a spike to show feasibility – which sometimes leads towards them realizing that it’s not really worth it or not really what they want with a much smaller investment of time and frustration. Sometimes you can draw on past experience where you did something similar, it didn’t work, but you eventually settled on a better solution and using that anecdote to make them pause and, hopefully, rethink.

One thing I will say is if you have someone like that on your team, and I’ve had a few, make sure you let them know how much you appreciate them. Because it’s gotta be exhausting and draining sometimes and knowing that it’s actually helped others makes it easier to suffer.