House building is one of the most common analogies to developing software. While you're required to follow some constraints (hardware, business), you're also given some leeway in how you go about it. However, we, the developers, have two advantages over house builders, which is the only physical work we do is entering text. And while the latter is required it's only a minor part in developing good and practical solutions.
But often when beginning, we made the mistake that this is the only thing that matters. Writing code and the tools we use are more important than the solution that we use them for. I think most of our time should be devolved to planning and designing. And we can do so by reducing the time we take writing code. Here are some techniques that can help you do so.
Automation
When starting a new project, you often have only one file and just a few commands to run the code in this file. But as your project grows, more commands need to be entered and often they will have conditional parameters based on your current intent. And entering those commands manually takes time.
I believe that if I do something that is recurrent, it should be automated, even if it's only once per day. From shell scripts to specialized task runner, there are a plethora of solutions that you can use to reduce the time you spent compiling, testing and deploying things. The good news is that most of the online tools we use often provide a CLI equivalent which makes it more easier for us. And a lot of them can connect with each other easily or through third-party services.
Know your tools
The Pragmatic Programmer book dedicates a whole section to the tools that we use to develop software (And it's still relevant, even if you're using an IDE as the latter is just a cohesive structure for those tools). You have to know your tools, their capabilities as well as their limitations. From the shell to your text editor, you'll often find that your productivity increases along with your mastery of the tools you're using.
Even learning the shortcuts of your current editor can result in a huge productivity boost. It's faster using a sequence of keys that using the mouse. I use aliases for the commands that I find myself typing every day. I often read the manual just to explore in what new way I can use the tool. Being familiar with your tools is a necessary step if you want to reduce the time you spent using them and increase your productivity.
KISS
As a programmer, we must resist the urge to overengineer our solution. While design patterns are useful, they are not a silver bullet. Remember that you're writing code for humans, not the computer. What you're writing will be maintained in the future, and your job is to make it easy for the next person to do so. Strive for clarity and simplicity. This one-liner could make you look smart, but it may result in lost hours trying to understand its purpose. A simple solution is always better than clever in the business world. So don't spend the whole day trying to optimize that function if it already satisfies the performance criteria.
My belief as a programmer is that you don't have to work hard to bring value to your work. You're tasked with creating practical solutions to problems and your tools should not be a hindrance to that objective. And you should also keep in mind that your code (the physical aspect of your solution) will be the responsibility of another person in the future (or your future self). So you should make it easy for them to pick up where you left.
Top comments (3)
"Remember that you're writing code for humans, not the computer."
Always loved that sentence.
I think design patterns are more for humans rather than for computers.
Yes, but you can easily overuse them and make the code too abstract to understand. Nothing beats a code with clear intent.