The two DHH-approved programming habits that will make you a good programmer

I’m not a great programmer; I’m just a good programmer with great habits. - Kent Beck (the guy who invented TDD)

Shouldn’t you develop good coding habits right from the beginning? It would certainly be easier. After all, you don’t want to have to unlearn your bad habits once you’ve become more advanced. It just seems logical that you’d would want to learn TDD at the same time that you’re learning to code, right?

Yeah, it makes sense – theoretically. But what about from a practical standpoint? What if you got started coding and you didn’t even know about TDD? What if you didn’t know about version control, or refactoring, or encapsulation, or design patterns?

What if you – gasp – learned about all that stuff after you started programming? Do you have to go back in time to tell your past self not to start programming until you’ve learned all the best habits?

Of course not. You’re always learning. Just look at what these random developers I found on Twitter have to say:

Programmers get embarrassed by old code... and that's okay!

DHH’s two key programming habits

But habits matter immensely. So what habits should you focus on? Let’s see what DHH has to say…

There you have it, straight from the Hansson’s mouth. The only way to become a good programmer is to:

  1. Read a lot of software
  2. Write a lot of software

Do you see the difference between these habits and some of the other habits like TDD and refactoring? I’ll wait.

You can actually read and write a lot of software today. They’re not habits that you’ll discover down the line and wish you had known about from the beginning.

And isn’t that a more fair way to treat yourself? Why would you beat yourself up for not even knowing about something? I wouldn’t do that to you… and hopefully you wouldn’t do that to yourself either.

The best thing is, when you read a lot of software, you start to get ideas about how other programmers think. You can ask questions. Why did he write all those little tests? Why did she organize her code into all those methods? Why did that team choose to use modules instead of classes?

You won’t get the answers right away – that’s part of the fun! But then you can apply those ideas to your own software.

You’ll gain experience. You’ll gravitate to TDD because you’ve experienced the joy of working with tight feedback loops. You’ll refactor because you’ve identified patterns in your code and want to make them more obvious. You’ll write code that’s easier to read, because you’re the one that has to maintain it.

You’ll do all these things because you’ve actually experienced what happens when you do them, not because some blogger – or even Kent Beck or DHH! – told you to.

Read a lot of software, and write a lot of software. All the other habits will come as a byproduct of these two habits.

Related: How you can learn more by writing code than by reading it

Become a better Ruby developer with free RubySteps lessons