14 Best Practices For Developers
The following are some things I have learned on my programming journey, and I hope that they help you too. You may find that you do not agree with all of these points, and that is okay. I’m still refining my personal best practice rules for development. My hope is that these will guide you to approaching problems better and make you a more effective programmer.
- DRY - Don't Repeat Yourself
A wise programmer will design solutions in which variables and templates can be updated in a single place and will cascade naturally. Build structures and models in such a way as to not repeat things. This is a solid rule to always keep in mind when developing code and building models - avoid repetition, seek elegance.
I was once told that a good programmer is a lazy programmer. While this isn't necessarily true, the point is that a good programmer will write code and implement solutions that don't require busywork and repeated human interaction. Think of how to build things so that nothing is repeated. Sometimes you can't avoid repetition, but usually you can. At worst, minimize it. - Write your code so that the next developer editing your code can understand it
This can be the future you, in several months, trying to figure out why you are doing something. Add meaningful comments and structure things so that it is easy to read. You'll thank yourself someday. - When choosing between optimization and organization, organization is better
It is preferable to have a solution that is easily readable and less efficient rather than a solution that is tightly optimized and hard to read. We've all been there. We've crafted a super-efficient solution only to come back to it months later and get lost trying to find out what we did. Debugging such a solution becomes exceptionally difficult. Now imagine being another developer who is trying to modify your code. Long story short, readability & logical organization are better than optimization. - Write your code with the future in mind, but don't go too far
Knowing when to stop optimizing is important. This is completely dependent upon the objectives and what you know about the future. In some projects, you know a certain part will be implemented, and it is perfectly fine to code for that. However, if you are coding for a future piece of code that may or may not even be used, be wary. You could very well be wasting time building for something that may never be implemented. As developers, we sometimes have idealized versions of the way things should be and can get carried away creating the 'perfect' solution. Be careful that what you are planning on building is actually valuable, and that it is part of the solution's objectives. You don’t want to spend time building features that were not asked for and are discarded when the solution is implemented. - Realize that if you are a hammer, everything will look like a nail. Resist the urge to only use solutions that you are comfortable with.
It is natural to reuse solutions that we have used in the past. The problem begins when we discard other possible solutions because we are only comfortable with one. If you are a cms expert, don’t try to solve all of your problems with cms solutions and methodologies. Sometimes it is better to have a code solution for a problem rather than an intricate cms solution. Sometimes the opposite is true. Sometimes you need to use a different programming language. Sometimes you need to use a server-side solution instead of a client-side one. The point is, you should take a step back and ask yourself, “What is the best way to solve this?” - Keep an open mind about new technologies, but don't jump on the bandwagon just because it is new and shiny
There will always be a new buzzword, a new CSS declaration, a new javascript library, a new server technology that is gaining steam and looks like the best thing ever. Be smart enough not to abandon all of your tried and true solutions for a shiny new one with no track record of success or support. You will often find small problems within new solutions that you did not count on. If it is a new technology, it may also be that there is no real support for your problems yet, either.
If you are adopting a new technology for the first time, you either need a factual reason to use it (it is a better, cleaner, more modern solution) or because you can afford to experiment and try something new in your project. Be aware of your project’s objectives and choose the solution that makes the most sense. - If possible, get a complete view of the whole problem so that your solution's effectiveness is maximized
It can be common to be presented with a small problem and build a solution to that problem, only to find out later that a better solution existed when taking the whole project into account. As a developer, you should try to get a grasp of what is happening in relation to your problem, and question why you need to do what is being asked. Oftentimes a more concise solution exists when seeing the big picture. - If you are faking it, it's probably wrong
In your solution, if you are faking certain functionality, making it appear that you are doing something when in reality you are not, you are probably doing it wrong. This especially applies to front end development, such as HTML elements and CSS rules, but it could also apply to backend processes. It isn’t necessarily wrong to accomplish an objective in a non-standard way, but in my experience when you are faking some functionality, you are probably doing it wrong by making things too complex. Keep it simple, make the solution straightforward. Often many unexpected issues will begin to surface after creating a solution that is “faking it.” - In programming, consistency is king
If you do something one way in your solution, you should probably keep doing it that way in your solution. If you are editing someone else’s code, try to match their style and how they are doing things. The code will be easier to modify and understand. - Save previous programming solutions for future use
You will find that after you solve a particular problem, the same problem will present itself in a subsequent project. It is a good idea to save solutions to recurring programming problems to save you time. If your solution isn’t outdated, there is no reason to reinvent the wheel again. - “That's the way we've always done it” isn't good enough
Don't do things one way just because that's how you've always done them. This leads to antiquated code, outdated solutions, and missing out on more optimized technologies. Always be willing to ask why you have to do things the way you have been doing them. Your goal should be to provide the best solution to the problem, and that sometimes means challenging existing ways of thinking. There comes a point when tried and true solutions become antiquated. Be smart enough to identify outdated and non-optimal solutions. - When troubleshooting frustrating problems, ask a fictional friend for help
Also referred to as “Rubber Duck debugging”, the idea is to describe your problem to someone who knows nothing about it. In the process, you will often discover a solution all by yourself. If you can find a solution without taking up another developer’s time, it is a win-win for everyone. - Value the "zone", prioritize your time accordingly
Programmers have a certain “flow” in which they operate, which is often referred to as “the zone”. We often have multiple objectives with different clients in a day. Switching between solutions and interrupting your flow will cost you effectiveness. You can also often plan out your time so that similar problems are grouped together (perhaps they implement similar technologies or have a similar problem) so that the time lag associated with switching projects is minimized. It also helps me to plan out what tasks I will be doing ahead of time - it helps my mind transition faster from one task to the next. - Sometimes best practices aren't best
There is a famous line in the Assassin's Creed series, "Nothing is true, everything is permitted." While I would not go quite that far in regard to development, you should keep in mind what best practices are for. They are intended to help you get the best solution most of the time. There are edge cases where a practice isn’t actually the best practice for that solution. Sometimes you are editing someone else's code and can't refactor things. Sometimes the client has a limited budget and doesn't care that their code is 'better' (even though they should). Knowing when to step out of the rules is something that only experience can teach you. That said, you must have a very important reason to override your best practices, and it can NEVER be because you are lazy.
I hope that you found these points helpful!