Let’s Review and Learn from the Past
I recently had the privilege of reviewing a large Angular project I led over the past five years. It’s a terrible tangle of four loosely related modules, built by the tragic collaboration of seven developers. Each developer brought their own unique brand of chaos.
Feature teams worked in silos. I led them all. What I didn’t do was say “no” at critical moments. What I really didn’t do was systematize a single code standard.
(In my defense, I was the senior cloud architect, solutions architect, lead developer, DevOps, scrum master, product owner, and technical project manager. Also, I had a newborn. The time of my life!)
During my descent into the wreckage, I found:
- 250 components, but only 110 in use
- 50 route definitions, maybe 20 actually wired up
What I found was schlock.
- Commented-out code blocks, which shouldn’t exist in a live branch.
- Pure functions (not bound to component parameters) that needed to be shared and unit tested.
- Insanely complex functions with no code comments or documentation.
- Inconsistent formatting, with 2 spaces, 4 spaces, a tab stop, sometimes too many linefeeds, sometimes not enough.
The Reality of Code Reviews
I firmly believe you need to make mistakes in order to grow. These problems were caused by me, myself, and I!
How I let my solution get this way pyschological. When I was was a junior, my perfectly functitonal code was rejected by my seniors. I was told to “do it right.” Now that I am a senior, I have the power to reject code. But I don’t want to be that person. I do want to be the person who helps others grow. But, as people don’t learn without the knoweldge of their mistakes, saying “yes” to everything was a disservice to my team.
Coda
Don’t worry, I put some code quality rules in place. We do proper code reviews now, and I review all changes using tools and processes we created together as a team.