The ugliest, nastiest, code

When teaching developers, I’ll often refer to “the ugliest, nastiest, part of your codebase that you’re all afraid to touch in case it breaks”. When I say that, everyone usually nods their heads. They know exactly what code I’m talking about because any long lived codebase has one. In fact they often even know who wrote that particular code, and its very common for that person to no longer be at the company.

Why technical practices?

Most of the conversation about the agile technical practices tends to stay in the weeds. We talk about whether we should test before or after, whether we should be writing unit or acceptance tests, whether we should be mocking or not, whether PR’s are helpful or harmful. We have discussions back and forth about all of these topics and while they are good details, they sometimes obscure what’s really important.

Why we branch the code

Branching is a great workaround for problems elsewhere in the system that we are unable or unwilling to fix.

Rapid feedback

One of the key things we’re trying to get with Agile is faster and more effective feedback so that we can make better decisions. This extends into to the technical practices just as much as it does in our meetings and processes.

Building capacity when hiring juniors

My comments yesterday on social media about encouraging the hiring of juniors seemed to resonate. So let me tell you about two of the very best teams I’ve worked with. Two teams of juniors, that were freshly hired, many straight out of school and none of them having worked professionally for long.

CI is not a server

We often hear things like “we’ve set up CI”, which makes no actual sense when you consider what CI is. It’s not a server or a tool, Continuous Integration (CI) is an ongoing practice whereby we keep the code continuously integrated. That sounds simple but has more subtlety than you might expect. Many places today that think they’re doing CI, actually aren’t, and as a result aren’t getting the benefit they could.

Too many branches

Most companies have too many active branches in their code repositories. “Active” meaning we’re doing actual development on them.

Test driving prime factors in Go / Testify

This article will show how to “test drive” the prime factors kata in Go with Testify. Testing in Go is built right in, which is great. It’s a very bare-bones implementation though so adding Testify to the mix makes it a lot easier to write your tests.