AN ENGINEERS EXPERIENCE
If you'd like to see a more complete summary of my work experience, please visit my LinkedIn page.
The first month of my career taught me two lessons, 5 years apart.
I was hired to work for a small company called Advatech Pacific (later bought out by General Dynamics) straight out of college. When I joined, I was essentially Programmer #4. I was excited to be in the real world, eager to prove that I could really be an engineer (but who doesn't have a healthy dose of imposter syndrome when they start?). I got my first couple tickets out of the way, and by week two I felt like I was working on the "real stuff", having moved on from bug fixes on to implementing new code that our team and customers would rely upon. I spent a week working away at my new ticket, got a few notes from my boss, submitted my code for review...
Wait, it was accepted? My boss didn't go through and leave change requests in every file I touched? He didn't leave a dozen comments, filled with valuable insight and gently scolding me for my immature code? Or simply rewrite everything "the right way", the way that someone with 20 years of experience would do?
I'd expected that I, a newly-minted junior engineer, wouldn't have a shot at putting new code on the product. Any code I wrote would likely be buggy or inefficient, lacking a professional touch. Of course I was just trying to write quality code for my task, but as a recent addition to the team I was also focused on getting the issue done quickly to impress. I wanted to prove I could do it, imagining I would learn from the changes made by more qualified engineers building on top of the mediocre work I would provide.
Don't expect anyone (including yourself) to redo your work "the right way" later. Do it the right way, now.
I'm sure whatever tasks I was doing at the time were appropriately minuscule, hand-picked by my boss. I know for a fact that he reviewed the code, too. He's incredibly intelligent and I learned a lot from him at my first job (and still do at my current job). And yet I still came away from my first real task with a lesson that has been a hard and fast rule for me ever since. It gives me patience when I'm going slow, confidence when I resist unrealistic timelines, and pride when the tools I've made are pushed to their limits.
The next lesson came much later and after transitioning to my next job, where I've grown into leadership positions in multiple facets of the company's structure. A few years ago, as I started to get those opportunities, I found myself reflecting on the story above. I was the tech lead for a set of product improvements, working with a new code base, and now found myself the gatekeeper for code reviews. Crawling through merge requests, I found myself frustrated with the code written by my team, and simultaneously overwhelmed by the Slack messages I received asking for help. It was at this point that I realized the value of the patience and trust my boss had shown me years earlier:
Fostering a confident team is more important than doing things your way.
Maybe your way saves a couple CPU cycles. Maybe it's easier to understand. Heck, maybe you just like the way it looks more. It's so incredibly easy to become nitpicky, even when the situation doesn't call for it. Are you writing code for NASA? Will saving a minute of CPU time per year truly make a difference? Most likely, you should instead take the opportunity to build up the confidence of the engineer writing code for you. Show them that you trust them to make decisions, to write code their way, to fix the problem how they think it should be fixed. If you micro-manage their code without good reason, they'll shut down: they won't find their way through the problem themselves, but instead will ask you to solve every little decision for them and will consume your work time.
Enforcing "your way" will only slow you down: save yourself the effort, and build a better product faster by cultivating a team that trusts you as much as you trust them.