Why Do We Optimize Code?
Probably an obvious question for most of us as software developers in the industry. I'm guessing you've all heard some of these phrases while on the job - "Why is it taking so long?", "Can you speed this up somehow?", "This website is loading slower than a snail on crutches." and so on...
There are several reasons why we optimize code:
Performance: Optimizing code can improve the performance of a program, making it run faster and more efficiently. This can be especially important for applications that need to handle large amounts of data or perform complex calculations.
Scalability: Optimizing code can make it more scalable, meaning that it can handle an increasing number of users or data without a significant decrease in performance.
Resource Utilization: Optimizing code can reduce the amount of memory and other resources that a program uses, which can be important for systems with limited resources or for mobile devices with limited battery life.
Maintainability: Optimizing code can make it easier to maintain, debug and update. This can reduce the development time and cost.
Security: Optimizing code can also help to make it more secure, by reducing the risk of vulnerabilities or exploits that could be used to compromise the system.
How Come Developers don't write optimized code the first time around?
A silly question, but I've heard it before. Let's explore the reasons why we can't always magically write perfect code on the job.
One of the main reasons is due to time constraints and pressure to deliver. When faced with tight deadlines and high expectations, developers may prioritize getting the code to work over making it readable, maintainable, and efficient. This can lead to code that is difficult to understand and maintain, and may have performance issues. Additionally, lack of proper planning and design also can lead to poor code.
Another reason why developers may not write good code all the time is lack of experience or knowledge in certain areas. For example, a developer who is new to a programming language or framework may not have the same level of expertise as someone who has been working with it for many years. This can lead to poor code quality, as the developer may not know the best practices or idioms of the language or framework.
Optimize for Readability First
When optimizing, developers often focus on execution speed and memory consumption, but fail to consider the importance of code readability. Us developers spend a majority of our time reading code, whether it's for debugging, checking commits done by others, or learning new libraries. Therefore, it is crucial for code to be easy to read, follow, and understand in order to reduce development time and cost.
A use case of this situation I recently encountered was when a Junior Developer was tasked to optimize some code written by a Senior Developer. The junior came to me and simply said the code was "too complicated" for his skill level. After doing a quick code review, he wasn't wrong, the code was very tricky. The code was dense, lacked comments and did very many tasks and database calls within just a few lines. This code did not take readability into account. If this senior developer took time to implement readability into their code first we never would've been in this situation. Hence the reason why I wrote this article.
Further Thoughts
- Optimization for readability to make reading and debugging code easier, thus reducing development time and cost in the future.
- Avoid unnecessary one-liners. Especially if you are doing it just cause you can. This is sacrificing readability.
- Add some comment to your code, especially on those scary complex algorithms that nobody wants to touch with a ten-foot pole.
TL:DR - Developers often prioritize execution speed and memory consumption over readability, but that readability is crucial for reducing development time and cost.
Top comments (2)
However, readability is purely subjective and we do need to very careful how zealously we encourage 'clean' or 'readable' code - as it can have a detrimental effect over time on the quality/ability of developers.
Great perspective Jon, I haven't thought of it this way before. That article linked really helped explain your view further.