Bridging the Gap Between Junior and Senior Engineers
I typed up a comment in /r/cscareerquestions recently, where I described a few of the areas I really needed to work on during the early stages of my programming career, and tied that into why I think senior engineers should stop worrying so much about their technical skills becoming obsolete.
I think there are a number of soft skills we don’t emphasize enough in the community, which all have the potential to exponentially increase the impact of our work (as individual contributors and technical leads).
Code review etiquette, gracefully pushing back on scope creep, explaining highly-technical issues in a way that intuitively makes sense to every other department, maintaining your composure when production blows up and it’s a race against the clock, etc.
The response was pretty overwhelming, so I decided to extract everything out into a Medium article, since a couple people in the thread asked for a more permanent copy that looks nice when you print it out.
Question from the original post in /r/cscareerquestions:
I enjoy programming and even learning in my spare time, but I still feel like I’m on a treadmill in terms of learning everything I need to know. I have this nagging voice in my head telling me that staying in a career where things are changing so quickly is bad, because when you’re older, your experience isn’t that valuable since it’s in old/obsolete tools, etc, plus it gets more difficult to learn new tech when you have other responsibilities.
It comes back to that familiar question of why should a company pay you for your experience in old tech, when they can hire an eager kid who knows the latest tech for 1/3 your salary (and is willing to work late, etc.)
I feel like I should try to become a BA or PM or some kind of business domain guy, since these types of roles tend to not be hit as hard by old age as programmers. I’d rather not, since I like to code, but I feel like I’ll have no choice. I’m also an average programmer, not some whiz.
Raw coding ability is important, but I felt like our protagonist missed some of the big reasons why companies are often happy to pay seniors a boatload of money (when entry-level developers are willing to work for peanuts):
- How maintainable is your code? Do other engineers constantly tap you on the shoulder, and ask you to explain how everything works? Are your variable names descriptive? Are your methods self-explanatory? Whenever you find yourself copying and pasting multiple lines, do you extract the functionality out into a reusable service?
- Do people benefit from the comments you leave on their pull requests? Do you offer constructive criticism, or is your feedback a little rough around the edges? When you find a gap in someone’s knowledge, do you simply say “change this line from ABC to XYZ”, or are you able to coach them through why their approach probably isn’t optimal, and have them walk away feeling better about themselves as a developer? They just learned something new, after all.
- If 100,000 users create accounts today, will your code start throwing a bunch of timeouts and 500 errors? Are you sure that your PR will fix the issue? Do you know how to benchmark your changes and prove it?
- How good are you at breaking extremely technical issues down into simple language that every other department at the company can understand? Did you let a bunch of engineering jargon slip when explaining to marketing why that one feature isn’t really feasible?
- Do you have a deep understanding of object-oriented programming? Does the system architecture you came up with “just make sense”?
- How’s your writing? Are you able to get your point across when replying to emails, or do people usually walk over to your desk after you hit Send so they can ask you for more context?
- Do you proactively reach out to senior management with ideas that would make your team more effective? When you want to see a process change implemented, are you capable of explaining the benefits to all of the parties involved? Can you get everyone excited about the change? Can you follow through, and make sure the new process actually sticks?
- Do you respect everyone else’s time? When you ask me to help you pair through a problem, can you describe the exact part of the codebase you’re having trouble with (line numbers that are throwing exceptions, describing the six approaches you’ve already taken before I waste time repeating the work, sending me relevant stack traces)? Do I have to pry all of this information out of you? Is it already open on your MacBook before I walk over to your desk?
- When scoping out large projects with other departments, how in-depth are your questions about the new features you’ll be developing? Are you able to flesh out every single edge case before you start coding? Are you able to recognize scope creep early, and put a stop to it before the entire team is stuck burning their Saturday afternoon in the office?
- How well can you multi-task? Does your brain get overloaded? Similarly, when working on those big features, the ones that touch like 50+ files… can you keep them all in your head at once? Have you developed solid note-taking habits? How do you plan on keeping track of the five million things that are going to pop up before you leave today?
- How do you react when a piece of code that you wrote is causing the billing page to error out, and your lead engineer has to cancel their dinner plans so they can stay late and help you fix the problem? Do you get emotional? Can you still think rationally? Are you able to detach from the situation, and remind yourself that every developer on the planet ships buggy code every couple days?
- Do you understand how business works? Do you understand why software engineers can demand such insane salaries, even when unemployment breaks into the double digits? Why is programming such a valuable skill set? Why is the customer willing to pay your company $50,000/yr for some super basic web forms? Do you feel like they’re getting ripped off?
- Can I trust you to interview candidates? Are you good at sizing people up with limited information, and visualizing how they would fit into the team? Can you recognize when an exceptional engineering candidate wouldn’t quite mesh with the company culture? Would you recommend that we pass on them? In a similar vein, even if you know 5 minutes into the Zoom session that someone isn’t getting an offer, are you able to make sure that they still have a positive experience chatting with you? Word travels fast on the internet.
- It’s December 28th. You’re stuck in the office. You went a little crazy this year and burned through all your PTO by mid-September. The higher-ups are out of town for the holidays. Do you still show up on time? Are you going to put in a half-assed day, since the principal isn’t around to punish you? Should we keep you around if you’re not pulling your own weight?
- Opportunity cost is a real thing. How good are you at balancing technical debt and moving the business forward? Do you refactor every tiny coding style issue you find? It can be painful to say “this piece of code is annoying, but it works, it will take four hours to clean up, and my time is probably better spent building out this other feature that tons of customers are begging for”.
- Do you know how to give your manager feedback on their performance? Do you have a good working relationship with them? Do you see them as the enemy? Are you actively trying to make their life easier? Reduce their stress levels? Do you ever say the words “is there any annoying stuff that I can take off your plate?” The company hired that person for a reason. They might be more experienced and qualified than you think.
- How good are you at putting out production fires? Do you panic and freeze up whenever shit really hits the fan (AWS outage taking the website down, accidentally dropping the customer_invoices table, some bug causing data leakage between different user accounts)? Do you crumble underneath the pressure, or can you keep your composure, and communicate effectively with other departments while fixing the issue?
While I can’t speak for every junior engineer out there, I do know that I was an emotional wreck when I started working in the field eight years ago.
Extremely confident, terrible at communicating with people, couldn’t handle constructive criticism without throwing a hissy fit, got into heated arguments with my boss over nothing, wasted countless hours on problems that didn’t matter at all, always bitching and moaning about why I deserved a huge raise (when I didn’t put in the extra effort to earn one), consistently played ping pong and video games for 45 minutes a day (after my hour-long lunch)…
Did I provide a bunch of value to my employers?
Yes.
Could you leave me alone for 30 minutes and be sure I wouldn’t immediately bash my head into a wall?
Not a chance.
Senior developers, on the other hand, just make problems disappear.
They reduce stress. They hit deadlines. They know how to write maintainable code that will stand the test of time. They cost a lot more money. They give (somewhat) accurate estimates. They can spot flaws in the current process, and get everybody to buy into their ideas to improve it. They can mentor the fresh grads. They’re not going to drop an F-bomb during Tuesday’s conference call with your biggest client.
Lots of people decide to stop climbing the ladder at this point, and I don’t think there’s anything wrong with that. Programming is one of the most mentally stimulating careers out there, and plenty of businesses are willing to shell out a lot of money for veterans who can keep things running smoothly.
That being said, there will always be that small group of engineers who will eventually decide to hang up the IDE one day, and begin making the transition into management. ☠️
Gross.
tl;dr: From what I can tell so far, it’s optional, and definitely not for everyone.
If you have solid communication skills and actually want to spend your entire day in meetings (so you can remove distractions and help your teammates find more time to get productive work done), it can be a pretty rewarding gig.
If you take the job for any other reason (pressure from your employer, higher pay, anxiety around your technical skills becoming obsolete even though you just read my blog post), then you’re probably gonna have a bad time.
Looking back on my journey, it all started with me trying to carve out a couple hours every week (in between heavy coding sessions) to focus on…
- cleaning up how we conduct technical interviews, so we can have a better signal-to-noise ratio with candidates (improving the questions we ask, rethinking our email templates, should we require homework assignments, is the job description still accurate, where are we posting the ads, how would I respond to this posting if I was looking for work, how can we give candidates a deeper understanding of our company culture and development process before they make their decision)
- working with the product team to scope out upcoming work at a more granular level, so that there’s very little back and forth required between them and the engineer who will eventually pick up the JIRA tickets
- organizing team building activities and group lunches
- pushing back on the CEO/CTO when the upcoming quarterly goals they’re considering sound a little bit too optimistic, and would most likely cause the rest of the team to burnout and start sending their resumes around
- hopping on weekly check-in calls with some of our biggest customers (to answer all of their technical questions personally, and make sure the relationship stays healthy)
- investing 6 months into a proactive security audit, to continuously refine our internal processes at each checkpoint in our company’s growth
- figuring out where other developers have gaps in their knowledge, and exposing them to the techniques they’re missing out on (in a way that makes them excited to expand their skill set): manipulating CSV files with vim macros, useful 2–3 letter programs to use in a linux terminal, advanced SQL commands, how to make PR descriptions more descriptive, explaining how load balancers work, chatting about the difference between merging and rebasing, etc.
- helping the design team flesh out which features are easy to develop before they spend hours converting the wireframe into a high-fidelity mockup
- improving our process around letting the other departments know when new features drop (writing better release notes, answering any questions they have during our weekly internal product demo, helping them write external documentation that our clients will understand), since a feature that no one knows about isn’t going to solve any actual problems
The list goes on and on, and most of it doesn’t require Visual Studio.
Lots of senior engineers wind up going down a similar path after a couple years, and before you know it you have six people reporting to you.
Thanks for making it to the end!
I hope you enjoyed reading this piece as much as I enjoyed writing it.
For additional perspectives, check out this article’s discussion on the /r/programming subreddit. It has a number of great comments in it.
