If you’ve read my other articles, you may have noticed a trend that I like to focus on engineering happiness, and having people do what they do best, while removing all of the other noise involved in the software development process. My favorite measure of success is looking at the number of days an individual engineer or team is able to write actual code. There are several “engineering intelligence” tools that can help collate this data for you, my preferred one is Velocity by Code Climate.
Of course there are many valid reasons someone isn’t able to commit code every single day. They could be sick or on vacation, they could be catching up on code reviews or triaging production issues, perhaps they are knee-deep in new integration documentation, or meeting together with colleagues in an on-site session. More often than not though, there’s a “smell” that something isn’t working as expected in the process.
What to look out for when your team’s coding days have dropped or aren’t improved:
- Release days – if you find that one or more engineers have to stop writing new code to gather around a production release, you should optimize your process to remove engineering from it. My preference is to create a release-when-ready process and enable the Product team to initiate their own releases when they are prepared to verify it’s working post-release.
- Too many meetings – this one is especially true if you see most of the team not committing any code on a particular day. In one instance, I discovered a team that was in meetings for more than four hours on a single day! We ended up shortening those meetings, creating clearer agendas, reduce some attendance, and shuffling which days they were on.
- Not committing at meaningful checkpoints – this could be because they are earlier career and aren’t in the habit of doing this yet, or perhaps they’ve broken down the work into chunks that are too large.
- Not pushing commits at least once a day – this is another one that could just be a habit that hasn’t formed yet, or it could be that don’t see the benefits of having continuous integration run more often.
- Not using draft PRs – related to not pushing often, some engineers will keep all commits local until a grand reveal when they are ready for code review. By pushing for using draft PRs, it provides visibility to the entire flow of work and allows you to pair more easily and get early feedback.
- Going down rabbit holes – this one is very common. It tends to affect engineers that try to grasp an entire ecosystem before making a smaller change. Sometimes that’s necessary depending on the feature request, but oftentimes, you need to work with them to timebox their digging, answer any questions relevant to the new feature, and try to have them focus on what’s most important.
- Over-engineering / “research” – this one surprisingly occurs more often in senior engineers. Sometimes they veer off into extensive research or re-architecting something unnecessarily, or bring up new refactors or tools that shouldn’t be considered at the current time. What I do is give people an avenue like a tech roadmap or a wiki page to put the ideas in writing and then refocus them on the work at hand.
- Story too big / not scoped appropriately – sometimes the work is just too much for an individual story and it takes a lot more design and thinking upfront. While you shouldn’t avoid these entirely, it’s worth asking if now is the right time to tackle the larger unit of work at once.
- No stories to work on – on some teams, it’s not always clear what to do when you’ve wrapped up work assigned to you in the current sprint. Do you grab a bug someone just reported? Do you work on that refactor you identified was needed? Do you add more test coverage? Do you grab from the backlog? Make sure whatever option you decide is very clear to everyone on the team or else some engineers will fall into decision atrophy and not do anything (or at least not what you’d want them to do).
- Not focused on feature delivery – focusing on shipping new features should be a clear goal of all teams. Try to make this as clear as possible. Occasionally you’ll run into an engineer that just can’t focus on continual feature delivery. They get stuck on process improvements or new development tools and spending most of their energy on trying to convince you, or worse the team, that it’s worth the time to stop feature delivery and address immediately.
- No target date they’re working towards – this one could be an entire article by itself. Some or maybe most dev teams don’t like to think about dates at all, but then Parkinson’s Law comes into play where the work tends to take up much more time than needed. As long as people are aware that dates can move as needed, they are helpful as a forcing function to back into different checkpoints in the process and see what’s realistic.