How to write better code
My previous blog post took off on Twitter. It pointed out a problem: Insisting on the obligation to follow certain rules at all times isn’t actually helping people work better. The most common question (or objection) I got to the blog post was: So how do we teach new coders how to code well. This blog post is about that topic.
First learn to collaborate
The most important skill we should teach is how to work well with others on a shared code base. In my career, it took me many years before I started getting good at this, but it had the most impact on my effectiveness. So this is where I want to start with developers who are getting ready to join the work force. On almost all projects we work on, our success will depend on others.
Working with others can be taught. Here are some techniques that have worked for me:
- Pair programming. Good pair programming requires training, but there exists training styles like coding dojos and code retreats. Some of the best programming instructors in the world use pair programming actively as part of their training.
- Code reviews. I work so much with pair programming that I personally give code reviews a lower priority. But many teams find great value in them.
- Patience. When working with pair programming, it’s easy to get stuck in arguments. Our profession says almost nothing about interpersonal skills, yet we depend on them all the time. Try this: When pair programming and you see your pair making a mistake, wait to see if she spots it herself before breaking in.
- Humility. I often get asked “how do I convince others to write clean code”. Of course, the question assumes that you’re right and they are wrong. Most of us are absolutely rubbish at the skill of changing our minds. When pair programming, if your pair want do something you think is wrong, try indulging them. At worst, you get the chance to teach them something. At best, you learn something yourself.
Unless you are in a situation where you write all the code yourself, collaboration skills are paramount. It doesn’t matter if you “know” what the code should look like if you can’t agree with your team.
Now, let’s talk about code!
If you are one of the people who skipped ahead to this section, please go back and read about collaboration. Seriously. Nothing I say about code will help you if you can’t work well with others.
Go ahead, read it again. I’ll wait here.
Good to see you back! Now let’s talk about learning to write good code. Of course good code is crucial to professional success. If the code base is better, you spend less time fixing bugs, you have an easier time changing the code in the future and your team will have a better time working with you. This is understood.
Learning to write good code is quite simple: You have to read code, you have to write code, you have to change code, you have to observe what is easy and what’s hard, and you have to delete code and start over again.
For the first of these points, great books help you to read code: Clean Code, Implementation Patterns, Refactoring, the Art of Agile, the Pragmatic Programmer, Practices of an Agile Developer, Design Patterns. I’ve enjoyed reading all these books immensely. These books will teach you considerations such as low coupling, high cohesion and simple design. They will teach you useful principles like Single Responsibility Principle and the Open-Closed Principle (although I find I almost never refer to the rest of SOLID). The patterns and principles teaches you words to discuss code with your team.
For the second of these points, Test-Driven Development is one great way to learn how to write code. I enjoy doing coding katas myself and often use them for teaching. But the most valuable skill when writing code is one I learned at code retreats (thank you, Corey Haines!). Learn to delete code you write. I don’t just mean refactor it to be smaller. I mean that for coding exercises, highlight all the files and press the delete button. I mean for production code, after spending a few hours working on a task, (occasionally) git reset --hard HEAD.
The hallmark of great code is how easy it is to change. Can you navigate in the code? Can you spot errors quickly? Do you know where to make a specific change? You can learn by reading about principles, but the most safe teacher is to expose yourself to more experience. (I’m planning to write a blog post on how principles sometimes, but not always coincide with good code). When you write and change code, reflect on how limitations of the code and your current skillset impedes the changes you want to make.
In short: Code more, listen to the code and listen to your peers.
Can you release smoothly
I almost forgot the #1 quality of good code: It has to be used! Release cycles of teams can vary from several times per day until a few times per year. If you can release your code at will, you can learn both about your code and your users. When the whole team learns that you will release again tomorrow, or next week, priorities of “now or later” gets easy. When you release only a few times a year, people get stressed and discussions get heated.
I’ve almost always find that team under-appreciate the value of spending time on build and deployment tools and scripts.
“Don’t do stupid stuff on purpose”
If you find code you’re unhappy with, it bears remembering that it is that way because it got that way. People did what they did because of reasons. Those reasons are valid, whether it was because the surrounding needs changed, because the developer had insufficient experience, because of pressure to finish, because they wanted to go home to their family instead of sitting late in the office or maybe they just had a difference in opinion on what’s good code.
Not everyone agrees with this, “what about those who just don’t care?” After 20 years of working as a programmer, I have never encountered anyone who just didn’t care. I have encountered programmers who had different preferences from my own, I’ve encountered programmers who are delivering under short deadlines, I’ve encountered programmers who get praised for making appearant progress at the expense of writing good code. And I’ve encountered many programmers who don’t care as much as me about the code. Having other interests in our life is an excellent reason to spend less time polishing code.
But I’ve never encountered a programmer who just doesn’t care. Have you? I’d love to learn from your story.