Two years ago, I started my journey as a software engineer. I threw away a successful career in search engine optimization, and jumped into web development.
The first few months were awful. From day one, I had to relearn everything I knew about being a professional. Gone were the days of delivering polished work I was proud of that was a testament to my expertise. Instead, I was writing code in a language I picked up a couple months before, putting my name to it, and immediately receiving feedback on it. I knew it wasn’t ready or good enough, and yet I had gone as far as I could alone. I had to expose my ignorance to my peers to get my work finished.
Software development is unlike any other profession I’ve encountered. It is a daily lesson in humility, vulnerability, and trust, especially as a junior engineer. The quicker you learn to be humble, vulnerable, and trusting of your colleagues, the quicker you’ll reap the rewards of the community around you. Nowhere is this more true than in a pull request.
Embrace the Feedback Loop ASAP
As a junior software developer, you are constantly required to put yourself out there before you’re ready. Take the pull request as a prime example. You’ve just finished code. You think it works; it’s got unit tests and you’ve tried it out. Now you want to merge it. But first it has to meet the standards of engineers with years more experience than you. And they’re about to give immediate, specific feedback, some of which may require refactoring or restarting, setting you back hours or days.
In my previous career, I had to interpret feedback from reactions of clients. So often, I made a deck, presented it to a client, and they were happy, disappointed, or worst: pissed. It wasn’t a positive learning process. A poor reception to work was met with embarrassment and was followed by triage with my boss to ensure our mistakes (whatever we guessed them to be) were never repeated. Such an experience was demoralizing, confusing, and left me less confident than I had been before.
Contrast that to a PR: You submit the smallest workable batch of standalone code changes that you can, and minutes later, colleagues can leave specific feedback, in context! They suggest smarter techniques, improvements in the code that will make it more useful to others, and new things you’ve never heard of. All this while the work is fresh in your mind, having just been completed. And if you don’t know how to make the feedback work, you pair up with that person. They teach you what they know, and you can immediately apply it, increasing the likelihood that it will stick with you and decreasing the chances that you’ll make that mistake again.
Push Before You’re Ready
If you’ve joined software development mid-career, you may be used to being an expert; to submitting only work you’re proud of, that’s been polished to a shine. Do yourself a favor: get over that real quick.
As a junior engineer, you frequently can’t wait until you’re proud of your work. You’re just too slow. You may not even know how to get it to 100% yourself!
You must push before you’re ready.
In the early days, get your code to 80%, and push it. Push it before you’ve polished it, because chances are good that you’ll have to rework and re-polish anyway.
This takes the pressure off you. Know that early in your career, you can rely on your community of engineers to catch you, and get you across the gaps in your knowledge. They’ll take your code from good enough to great. You must allow others to make up the 20% with you. You simply won’t finish in time without them.
Vulnerability is a Critical Engineering Skill
Make no mistake, submitting code as a junior engineer is an incredibly tough learning curve for the uninitiated. You must find the balance between submitting work you’re proud of versus pursuing perfection to the detriment of the team’s efficiency.
You must embrace this vulnerability. All of your engineering peers are experiencing it alongside you. Feedback is not (or should not) be personal. It’s an invaluable source of knowledge for fledgling engineers. Pull requests and pair programming can give you feedback in context, and show you the real application of the code you want to create. Lean on your senior engineers to help you connect the dots, and embrace that feedback loop.
Now this is going to be scary, especially if you are already an expert in a different area, and are transitioning to becoming an engineer. That aspect sucks. For a long while. You’re not an expert anymore. And everyone knows it.
Lean in to that fear, and lean on your colleagues. They’ve been where you are and the good ones want to help you across the gaps. The quicker you get past the anxiety of being professionally vulnerable, the quicker you can learn from your fellow engineers. If you embrace growth as constant in engineering, before long, you’ll occasionally find yourself on the other end of the PR, giving valuable feedback, and feeding the cycle anew.