Labors of the Fastidious Coder

I spend a lot of energy on the coding equivalent of the mantra "cleanliness is next to godliness".

People sometimes think this is extra work but it's not. In fact, it's anything but that.

Fastidious coding is frontloaded work. That is, I'm taking the thing that I know is hardest - keeping my design natural to my problem - and doing that work as soon as I can.

When you do that, code-cleanliness work doesn't start to stack up into a seemingly insurmountable pile.

That psychological effect, alone, is worth the "effort" but there's a subtler, more potent source of value.

Badness compounds on badness. When you let code be bad, you do bad things to get it to work. That makes the code worse.

So, allowing a quality problem to fester not only accumulates redesign work into large chunks but also accumulates work you would never have had to do if you just kept things clean.

Following is a video wherein I spend about an hour cleaning up a test library, among other things. You can think of it as a waste of time or an expression of my perfectionism if you want to, but I would like to offer a different perspective.

What if you watch the video and try to think about all the things that could go wrong if I didn't do that cleanup, this morning?

A Friend Asked Why I Don't Have Comments

The answer is simple.

I don't like the way the blog looks with comments enabled. I think it looks ugly with this style.

If people are interested in discussion, I'm sure I can find a solution that isn't visually-jarring.

Intensive Coaching

I'm going through an intensive coaching experience. The idea is that I spend a full ten weeks with a single team.

I'm a little surprised with the outcome. I knew there would be an impact but the team is progressing a lot faster than I, for one, anticipated.

I don't have enough data to attribute that to the intensive experience, yet. It's also a really engaged and interested team and I suspect that has a lot to do with the progress being made.

I think people have a tendency to be a little superstitious in assigning reasons for success or failure. I don't want to contribute to that but, it's easy to see why someone who went through an experience like this one might be convinced it's the only way to coach software developers.

American Idle

We work a lot, here. We work a lot more than we probably should.

That's not really a problem. Not long ago, where I'm sitting was the frontier. Hard work was necessary to survive and to thrive.

Yet, even in frontier times, people rested. They worked hard and then they rested. Then they worked more.

I think we lost that somewhere along the way. People feel like they need to spend every second working.

The mentality is this:

If you're not busy, you're wasting your time. So get busy.

There are many problems with this.

First, you're way more effective for the period of time shortly after you've rested than you are when you've been working for a long time; at least, that's true for most people. So you lose productivity by trying to stay at full utilization. It's a self-defeating proposition from the get-go.

Next, there's the fact that the impulse to work hard continuously suggests there's something fundamentally wrong with your approach. There's a practically-limitless amount of work to be done. Work needs to be managed and sliced into bite-sized pieces with adequate funding. If heroics are required, then the work isn't really being managed. Mismanaged work is nearly-guaranteed to fail.

Finally, there's the fact that work is probably not the best part of your life. I mean, every workplace wants to be a second home, or whatever, but the reality is that most of us have something else that matters more. We have families. We have hobbies. We have charities. Those are typically the reasons why we work in the first place. Working to the detriment of our higher goals is, again, self-defeating.

So if you want to work hard, great. If you want to cannibalize your life to try to get a little more done, spare a few minutes asking yourself way.

The break will probably help you get more done anyway.

Dependencies, Not Levels

The way we teach people to be software developers doesn't make a lot of sense.

It's one of those things that sounds reasonable so long as it is described in vague-enough terms. The idea is that you build up someone's skills slowly, incrementally.

For instance, some people believe that you should start by teaching scripting. Then promote students to procedural coding. The traditional version of object-oriented design follows. Finally, assuming the person you are talking to has enough understanding of software development, you start teaching design patterns.

The same is true of test-driven development. Start with test never. Then move on to test-after. Upgrade to test-first. Promote to TDD and then, ultimately, to organization-level BDD.

Refactoring gets a similar treatment if it gets any treatment at all.

What's really being proposed is ordering alternative ideas by how difficult they are to completely master.

This doesn't make any sense because it sets up a pattern of wasted effort. You start by teaching someone something the wrong way. Then, after they've attained a modicum of mastery in that way, you tell them it's bullshit and they should do something else.

How do we expect people to react?

I'm experimenting with a different pattern: Start with a skill that doesn't have any dependencies and don't worry about mastery. Just help people get enough to start using it, which really isn't that much. As skill in that area improves, it also enables someone to start learning a skill that depends on it.

In software development, given developers who already have basic coding skills, refactoring is the skill with no dependencies. Refactoring enables design because it's way easier to imagine a new design if you have a chance of getting there safely. Design, in turn, enables TDD because it's easier to imagine using tests to drive your development process when you know you can create and refactor to designs that will enable the effort.

It seems like it's working really well.

Change... Change Never Changes...