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.