What I’d want to know at the beginning of my career.
Dear Junior Engineer,
I hope you’re already having fun! Sure, you’ve probably already faced some challenging days. Even after 20 years of engineering, I still have my share of them. Whether you’re new to this work or not, there are and will always be obstacles, pitfalls, and learnings. From my triumphs, mistakes, colleagues, and mentors — I’ve learned so many lessons about what it takes to succeed as a developer. And as we close out another pivotal year (pardon the pun), I’d like to share some advice with you as you start your own professional journey.
Ask for Constructive Feedback
As the saying goes: the more you know, the more you know how much you don’t know. I don’t expect that all feedback I receive should be positive. Positive feedback is great — and it was helpful for me to get affirmation early on when I was getting familiar with a new system — but critical and constructive feedback is more valuable to your growth. Ask for it. A lot.
Create an environment with your team, your mentor, and anyone you work with that makes them comfortable providing you feedback. Nothing is more difficult than providing constructive feedback to a defensive person, so model the behavior you desire from your team. Push aside your insecurities and be open to feedback. It takes practice, but you’ll get better at receiving — and giving — feedback over time.
It’s Not Just About Producing Code
I remember all too often getting caught up in the process of completing feature after feature. It’s easy to check a box, complete a task, and move on to the next one. But don’t forget: you’re not a human code generator nor a specification-document paster. A button here, a reverse chronologically sorted list there… but why? I’m constantly reminding myself to take a step back to ask myself — and my team — why we are even doing a task in the first place.
You and your team’s output is important, but what’s even more important are your outcomes. The difference is this: outputs are the artifacts you make — code, libraries, features, products, and the amounts thereof; whereas, outcomes are the consequences or purposes of these outputs. In other words, outputs are “things,” while outcomes are goals. It doesn’t matter if you and your team are the most efficient engineers in the world if the outcomes of your work are not progressing the team towards its goals.
Be a Problem Solver, not a Puzzle Master
This is a different but related topic to the one above. As developers we fall into the following trap often: we focus on solving puzzles, not solving problems. What’s the difference between a puzzle and a problem?
Solving both puzzles and problems is satisfying, revealing, and educational. Solving a complex puzzle or problem can be intellectually rewarding and exhilarating. Unfortunately, puzzles are often meaningless distractions and time-wasters despite the satisfaction gained. Solving problems unblocks you and helps you accomplish your goals.
So, you’re feverishly trying to optimize your app’s search feature to make it a few milliseconds faster — is this a distracting, wasteful puzzle or a critical problem to solve? It depends! If the search feature is the most used customer feature then you might be saving the company. But, if you just stumbled upon this unused code and you remember reading a blog article a while back about a new technique and… well it just could be better and it’s annoying you then this might be a puzzle for another day.
Be a problem solver. Again, step back, get out of your own head, and ask yourself, “What am I trying to accomplish? Is this important?”
Find A Wide Variety of Mentors
Software and product development is a vast, complicated field with nearly infinite techniques for getting things done. Therefore, I caution you against finding a single person to show you “The Way,” and instead, suggest you find several people to show you a few ways. As much as I think my dogma is usually right, someone else’s catma might be better for the problem you are solving.
Also, your mentors do not have to be grizzled oldsters. Again, cast a wild net of experience level and tenure. I frequently rely on the advice and guidance of developers with far fewer years of experience than I have.
Bonus tip: I once waxed poetic about old dudes (and dudettes) who know SmallTalk. That advice remains the same. If you meet any SmallTalkers do not let them get away!
Be Cool, But Not a Hotshot
It’s great to get noticed, rise through the ranks, and feel like you’re on the fast lane to success. It’s an amazing feeling, especially if you work among peers you admire that are paying respect to your output. But I can’t stress enough how important it is to remain humble. Where I work, 10x developers are not superstars because they’re that much better at writing code — it’s because they make their teams better. And to make your team better, you have to remain humble, because no one wants to support someone who is arrogant.
It’s a Team Sport
I have some sobering news: you’re dispensable. The project and company will not crumble if you suddenly win the lottery and quit. While I have no regrets about any decision I made regarding my career, I definitely said “No” to some opportunities because I convinced myself that my company and project needed me. (Oh, I was so important!) Yes, I was valuable. But I was wrong to think that if I left, the company wouldn’t be able to continue on in my absence.
You should never create a bus count of one. If your company structures projects like this then you should advocate to eliminate this risk by growing your team and sharing your context. If you cultivated your role as the critical lynchpin then you are at best acting selfishly, but worse immorally by intentionally setting yourself up as the vector for success and failure of others. What happens when (not if) you burn out, fail, or leave? Does the project collapse? Does your team fail? It better not. Don’t get so wrapped up in your own rockstar mentality that the band breaks up if you leave.
These are just a few of the lessons I’ve learned over the years. I hope they help you along your journey. And please, to all the readers that have taken the time to listen, I’d love to hear any advice you’ve found helpful in the comments below. Thanks for your time.
Want to work with thoughtful engineers? Check out Pivotal’s careers page.
Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt. At Pivotal, we believe change should be expected, embraced, and incorporated continuously through development and innovation, because good software is never finished.
Letter to a Junior Engineer was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.
