This article will show how to “test drive” the prime factors kata in Ruby with RSpec, a spec style unit testing framework.

Years ago now, Bryan Beecham came up with the idea of using LEGO to teach the concept of Test Driven Development (TDD). Since this is a topic most often used by developers, previous trainings had focused on demonstrating this technique on actual code. However, Bryan wanted to introduce it to a different audience; he initially wanted to explain TDD to management and then later to other non-developers on the teams. To do this, he needed to be able to illustrate the concepts away from the actual source code. And thus was LEGO-TDD first created.

In the last article, we showed how pattern matching could solve FizzBuzz. It’s a deliberately simple example so let’s look at something a little bit more complex.

I’ve long advised people to learn multiple programming languages, as each new language you learn will make you better at all the ones you already know. Not just languages with different syntax, but languages that challenge how you look at problems.

Research shows that code comments rarely stay in sync with the code they’re describing. Other psychology research shows that incorrect comments are worse than no comments at all. Should we get rid of code comments entirely or are some worth keeping around?

Many years ago, I came in one morning to a client, to discover the website down and the email server completely unresponsive. Naturally, we assumed that we we’d been hacked. What else could take down two unrelated systems at the same time?

This week I heard “A developers job is to write great software” and I disagree. A developers job is to solve problems for their clients. We have a tendency to get so focused on specific skillsets like “I write code” that we miss the entire point of why we’re doing it.

I was recently talking to someone who had an old codebase that they just couldn’t work with anymore. So they rewrote it from scratch and within six months, the new code was just as bad as the old. They were no further ahead, despite having invested a significant amount of time and money. This is a common story and it doesn’t have to be this way.

Spikes were an interesting idea that have become massively abused and it’s time that we just stop using them.

I was recently talking to a developer who had just been promoted to tech lead. They were asking what they should be doing differently now. I suggested the first things I’d focus on are that their job is now…