Looking back through my blog posts, you’ll see that I talk a lot about good developers being less about the ability to write super-awesome-amazing code and more about the attention to detail and quality.

• https://nuggets-knowledge.com/2021/04/25/dont-let-the-little-things-accumulate/
• https://nuggets-knowledge.com/2021/02/20/building-the-habits-that-lead-to-quality/
• https://nuggets-knowledge.com/2020/08/08/motivation-vs-discipline-or-i-only-want-to-do-the-fun-stuff/

The thing about this is, I figured this was more or less the known industry standard. I assumed that professional developers were all on the same page and agreed with this. (If you go read Reddit or SoylentNews, it seems that way at least. Everyone asserts that they are a brilliant developer who does all these things.) Thus, when I am in leadership roles in projects, I make the blanket assumption that developers will be professionals. Left to their own devices, they will do things like write unit tests, perform virus scanning on downloaded container images, patch their third-party libraries, and use source code control. I try to follow the management principles of trusting the team and unblocking things, not prescribing mandates.

Well, unfortunately, this has resulted in negative consequences. I have led projects where I trusted the developer team to be professional and do the right things. I left them alone and instead worked to empower them: unblocking issues, providing well requirements, protecting them from bureaucracy, those types of things.

And the result? A team that was working independently from each other, with no source code control, instead just writing code and saving it in folders on their hard drives. And then deploying said code without testing or source code scanning. The results were exactly what you’d expect, messy.

The hard-learned lesson for me is that you cannot simply rely on good intentions and hope. As a result, you have to set some guardrails around your developers, which probably causes frustration that you are “slowing them down” and “introducing unnecessary processes.” Here are some of the ways I’ve found to find a balance between over-regimentation and “the wild west.”

Communicating the Expectations Clearly and Early

As I stated above, I frequently assume that the developers on my time favor unit tests, source code control, security practices, and the like, and I don’t need to hound them on it. But I’ve found it is valuable to communicate the expectations anyways. At the beginning of the project, and at regular intervals, provide this guidance both in writing (emails, on your wiki, etc) and verbally (on team meetings, during standups, during one-on-one conversations, etc). List out very clearly the things you expect to happen (source code control, unit tests authored, static source code scans or linters, etc.)

Validate the Expectations as Part of Workflow

If you are following agile practices (you are, aren’t you?), then that means you already have a structure in place: sprint planning, a backlog, standups, tasks/stories. So make use of those and ensure that the guardrails and practices are built in the process. Ensure that sprint stories have the correct definition of done, such as “unit tests authored” and “code checked in to the repository.” And when you attend the sprint meetings, ensure that those criteria are met. Support the development team when they state that this will cause a schedule impact, and be the advocate to the customer or stakeholder on this.

Support the Automation Development

One of the reasons that I’ve found that developers aren’t performing these tasks is friction. https://nuggets-knowledge.com/2021/04/11/how-to-get-things-done-eliminate-the-friction/ Here’s an example: anytime you are writing python code, even if it is just a simple systems administration glue script, why aren’t you running pylint? The easiest way to address this is to integrate pylint into your IDE, and get in the habit of addressing the identified issues. But the key to making this work is giving the developers time to set up the automation tools. Take a one-week sprint and identify it as a buildout and preparation phase. Identify all the places that tooling can be added to your workflow.

Ultimately, it all comes down to communication and expectation management with the developers. You cannot assume they will “do the right thing.” As the leader, you have to demand it. And even further, you have to trust but verify and hold the team accountable for doing the right thing, even if it makes you unpopular.