Hey there, Jordan here 👋. You’re probably familiar with most of my articles being a “how-to” guide. Those guides come from my real-world experience and lessons I learned—usually from mistakes I made.
This article is going to cover the 5 biggest lessons I had to learn the hard way through feedback that surprised me. Each of these shaped the engineer I am today.
Hopefully, sharing these lessons with you will help you avoid some of my mistakes.
Caveat: These are lessons based on my personal experience. You may have experiences that tell you a different lesson. If you do, feel free to share with me in the comments. I’d love to discuss it with you!
Lesson 1: Bring solutions. Not problems.
I was a Senior Engineer on a team that relied on 2 other sister teams for data.
The data we requested from one of our sister teams came back painstakingly slow. Because our requests to them took 500ms-4 seconds, customers would see 3+ second loading times.
That team knew about the problem but they were swamped with competing priorities.
Unfortunately, I didn’t make it any better.
I made more callouts to the problem in team retros and team channels. That on its own isn’t such a bad thing. But the vibe I gave off was, “This is a serious problem your team needs to fix” rather than “Can we work together on a solution to this?”
I didn’t realize I was doing this at the time until the feedback came from my manager.
I could have scheduled a 1:1 with one of the team leads and collaborated on a plan to resolve it, rather than making anyone feel bad about the problem.
Although I intended to make things better for our teams and customers, I could have done it in a way that made our team feel great in the process.
Something like this would be much better:
The performance of the endpoints are causing 3+ second loading times for both of our customers. I’d love to work with you on options for resolving this together. How can I help?
Steve Huynh’s recent video gives a great example of doing this wrong vs doing this right too.
Lesson 2: Clean code isn’t the end goal
As a junior engineer, I was ruthless in code reviews I gave. I wouldn’t let a single “bad-looking” piece of code go into production.
And it made one of my teammates pretty darn upset with me.
It got raised to my manager which led to a conversation between the 3 of us where we resolved it, but it wasn’t a pleasant situation to be in.
Surprisingly, after this, I didn’t learn as well as I should have. I scaled back a little bit, but then I had an issue with a different teammate constantly pushing back on my comments.
It would lead to multi-comment back-and-forths in GitHub and some tension between us.
I asked my coach at the time what I should do, and he said, “What would happen if you let 50% of your comments go? Is every comment worth fighting over?”
My answer: “The code would be slightly less clean.”
Now think about this: Is “the code being slightly less clean” worth the tension between you and your teammate? No.
So I started being more relaxed about my comments. I commented less, made it clear what was a nit, and approved most of the time unless I had a serious concern.
What happened? My “nit” comments were accepted more often. There was trust between me and my teammate. Rather than them feeling attacked, they felt like we were working together.
Clean code isn’t the end goal. Collaboration is.