After doing a hackathon-style project recently, I recognized that our small innovation team was lead by their good habits. We could have built our project out of “throwaway code” and its possible that by doing so, we could have had a more interesting project completed. But in doing so, we wouldn’t have created any value for any user, we would only be left with a pile of tech-debt.
“It’s easier to do the right thing 100% of the time than 98% of the time.
Jonathan Spier, CEO of Rev
This quote rings especially true when writing software. If your default is to write code as a stream-of-consciousness without first taking a step back and building a sound mental-model, if you avoid testing, and never bother to refactor rot from your code, guess what kind of code you’ll be writing. That’s right, a rotten, untested, unintelligible code base that you can only be sure works on your machine right now.
So don’t let that be your habit. Start building good habits now, and do these things every time you write code. Even for your hackathon projects, even for your random ideas that might not live for another day. Make that your default, and you’ll always be writing good code. And when its time to fold your hackathon project into production, it will be production ready code.
Here are some of the good habits I recommend building into your process:
1. Create a model of your code before your write it
A useful model can be manifested in many ways. For some its a UML diagram, for others, it’s a mind map or work-flow. It could be sharpee on a napkin. Some people are great at building mental models and keeping it in their head (I’m not, so that doesn’t work for me, but it might work for you).
Whatever your method, these are the criteria for a good software model.
- it can easily be understood by any other engineer on the project
- it expresses a solution to a real business problem, in language that is used by non-technical people in the business
- it leaves out implementation details, such as database technologies or specific libraries
2. Collaborate early and often
This is really important. The best way to do this is to pair on the start. Robert C. Martin, in his description of XP (extreme programming) says that you should pair 100% of the time and in an iteration, every engineer should have paired with every other engineer (Agile Software Development, Principles, Patterns, and Practices). On paper, pairing sounds like it would halve your output, but it practice, it will more than double it.
But since none of you are really going to dedicate yourself to pairing, you can at least collaborate as often as you can throughout the project. That means when you have created your model, share it with the team and get their feedback. When you have a good idea for how you will implement your feature, describe it in slack and get feedback.
Once you have a few commits, create your PR and start asking for feedback. You will always find something you can improve when you have more than one person looking at the code. It also forces you to write code that other people can understand. As a rule of thumb, I like to assume I am always wrong about my assumptions, always making a mistake somewhere, and am eager to let others on my team help me discover those issues. Its through this collaborative process that we write the best code of our lives.
3. Use test-driven-design
Everyone loves this idea on paper but almost every engineer I’ve ever worked with, even very experienced ones, want to dive right into implementation without considering tests, whatsoever.
The benefits of TDD are numerous and well documented. I’m not going to dive down that well in this article, but I can say that in-practice, following TDD will save you time and effort, and you’ll feel better about the code you’re writing as you write it.
This is a habit that is very hard to create. But I strongly encourage you, especially if you are early in your career, to start now. Every time you write a new piece of code, start by writing a test. Ask yourself some questions about what should the code do? How do you know it’s working?
Doing this as a habit means all the code you will ever write is testable, tested, and well thought-out before it was written. And you won’t find yourself scrambling to write tests at the end of a project, which literally everyone hates doing.
Other Habits?
What I’ve described are the general habits I think are most important for any software engineer. What are some other great habits to build into your routine? What are some bad habits to avoid? Let me know in the comments.