I’ve been on dozens of different teams in my years working as an engineer, and I’ve come to find your team needs to find ways to balance quality and swiftness if you are to meet your goals.
Teams that move too slowly in an attempt to produce the best software possible often fail to meet deadlines. Teams that move too swiftly in total disregard for quality often come screeching to a halt with technical debt. How do you balance this?
I’ve found it’s a mix of pragmatism and judgment. It’s about asking yourself what can wait, what cannot wait, doing the best with the allotted time, and holding yourself accountable for the changes you promise to make later.
It’s not easy to know what can and cannot wait sometimes. It’s very beneficial to have some senior folks who can call out the things that have killed their teams in the past. Experience on teams is SO valuable. Folks that have scars are SO valuable.
Another thing to consider is those things we call “best practices.” We must ask ourselves who they are best for, the client or our team. Oftentimes, we are not willing to break the rules even if it would be best for our client. An example I look to in recent years is putting your CSS in your JavaScript files. Mixing HTML and JavaScript when I first started was a huge NO-NO. Then come to find out, for projects without tight performance requirements, CSS-in-JS provides a fantastic developer experience that can increase the delivery speed of teams. As the old maxim states, first learn the rules so you know how to break them effectively. Best practices should be guidelines, but we should never stop using our judgment on if they’re right or wrong for our particular problem.
Sometimes teams slow down too much in the code review stage of delivery. How many times has your team’s momentum come to a halt when the pull request is opened? I can recall some teams I’ve worked on where the pull request lead times were a solid week, and oddly, the smaller the PR, the longer it took to merge that sucker. Engineers love to discuss code. I won’t lie, I do too, but don’t lose sight of the goal. Quality is important, but don’t spend hours discussing nitpicky items. Also, adopt a code formatter and have your team stick to it. There should be ZERO discussion about indenting, quotations, operators, etc. That should be handled for you.
The last thing I want to say on this topic is the importance of verbal communication and being available. Teams can lose so much speed when they aren’t using verbal communication. I love asynchronous communication and writing back-and-forth, but sometimes you can cut down the time with a five-minute huddle and a conversation.