Image by John Hain from Pixabay
Wait… I’m a Sr. dev?! Maybe a better title would be “Don’t just take everything a Sr. dev suggests as the best way to do everything, because they can’t possibly know the best way to do everything!” But, that’s not click-bait-y enough.
I bring this subject up because, Friday, I spent the whole afternoon writing an article about how to do something in Angular. A Directive, an entire NgRx feature, and how to use it all in some templates… It was a clever solution to a problem, that we have been using internally, that I thought I would share with the world. I sent the draft to some fellow ng-conf Champions for review. Over the weekend I received a truly humbling response…
… do you know that Angular Material already provides this option? — Duncan Faulkner
Well, no! I didn’t know that! I spend a lot of time in this documentation and still missed it!
And, that’s why you shouldn’t trust me. Or, you should only trust me up to a point. I can’t possibly know everything there is to know about Angular, or anything else for that matter. Angular is an ever-changing landscape with multiple 3rd-party add-ins that are also ever-changing.
Was my solution “wrong”? No. It worked. But was it “right”? No. It required more work from developers in the template and the unit tests. They actually had to think about it.
Don’t make me think. — Steve Krug
So, what’s a non-Sr.-dev to do? Exactly what a Sr. dev should be doing. Read, research, ask questions, … LEARN! And then teach! Share what you learn, present alternative solutions, and come with justifications for your approach. Now, I’m not advocating for challenging everything coming down from Sr. devs and architects. But it never hurts to validate that a solution is on the right track, or, in my case, missing something that should be completely obvious.
How I wish that any of my devs had said something as simple as “Does the library provide any global configuration?” That would have saved us all a lot of work (and the story to go back and rip all the other work out).
I try to humbly accept my mistakes. I publicly apologized to my team for the headaches my approach caused. They’re minor, but they were unnecessary. And I presented the solution and the story for how to fix it. And I hope that my openness means that they will trust me. Just, not too much!
Don’t Trust Your Sr. Devs! was originally published in ngconf on Medium, where people are continuing the conversation by highlighting and responding to this story.