Yepp, more things I wish I'd known when I started, 5th edition.
You can find the first article in the series here.
And the previous article here
You read code more often than you write it. Optimize for reading
Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do. _Donald Knuth
This feature is extremely important and management is pressuring you to ship it ASAP?
Are you working in an extremely lean environment and have no time to write good code?
I get it, you are too busy to write good code. I'd be inclined to say that writing bad code is never justified, but I'm also aware that there are some tough situations at work. Still, writing bad code with the excuse of saving time is not only unprofessional, but it also doesn't work.
The reality of our profession is that we read code much more often than we write it. Some say by a factor of 10:1, in my experience, it can be a bit more than that. By writing code that is hard to read, you are making the most common task more difficult to achieve.
In computer architecture, there is a concept called Amdahl’s law. It gives you a theoretical estimate of the speedup resulting from improving just a small part of the code. One of the main insights of the law is that it makes little sense to parallelize a part of your program that runs just a couple of times. If you want to see a bigger speedup you might have more luck with a smaller improvement in the parts of your code that run more often.
We can apply the same logic to writing code. If we read code more often than we write it, we should spend our time making it as easy to read as possible. Even if writing easy-to-read code takes twice as much time (even if it takes 10 times), it's still a wise investment.
Spend time writing good code, no time is saved in the long run by writing sloppy code.
Don’t optimize prematurely
The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming. _Donald Knuth
I remember when I started to program, I was OBSESSED with the speed of my programs.
I thought that it was the only thing that mattered, or at least close to the top of the priority list. So I spent a lot of time making small tweaks for my code to run faster. There were two big problems, that in retrospect are obvious, but I was too naive to realize:
- I had no idea what I was doing. Those 'performance optimizations' were horribly implemented and usually did more harm than good.
- No one cared about the speed at which my toy programs ran, and most software I've written since ran at good enough speeds by default.
The reality is that in most commercial software development, those optimizations are not needed. Our current hardware and infrastructure provide satisfactory speed out of the box. You should instead spend time creating code that is easy to read and well-architected solutions. If there is a performance problem, you can use profiling tools to find out the problematic part of your code and apply optimizations to that part, which is easier if:
- You know that you actually need the optimization.
- Test coverage is good and CI is in place.
- The project is written and structured using best practices.
The main point is, premature optimization harms your code and usually is not even required. In most situations, just throwing in more powerful hardware is easier (and cheaper, if you count the cost of engineer-hours) than hand-tweaking things.
For some cases like embedded systems or other forms of low-level programming, squeezing as much performance as you can out of your hardware makes sense. For web apps or some other form of consumer software, optimization should happen only if there is a real need. A better architecture, more powerful hardware and redundancy are other options with a usually bigger impact on performance.
So don't optimize your code until you find out if you really need it, go for a clean and obvious solution first.
Learn to learn
Technology moves fast, and keeping up with the changes requires you to be able to learn new things quickly.
Cultivating your ability to learn is a good way of investing your time, despite the challenges of our age. On one hand, the fact that we've never had this much material available should make things easier. At the same time, the disruption of social media and other distractors make it more difficult to focus on learning in-depth.
Having the discipline to work through books and tutorials, and to practice your skills will set you apart from all your peers. Learning, like other activities, is something you get better at if you do it frequently. If you feel that reading books to learn things is too hard, I can guarantee you that it will get easier after your fifth book.
Remember that your programs are made of thoughts and ideas, the contents of your head are the raw materials for the craft. Spend time expanding your knowledge, it's the only way of controlling the direction your career takes.
Oh but I also knew all these things.
It's ok, maybe in the next article you'll find something you didn't know yet.
Thank you for reading, I hope you learned one or two new things or at least got something new to think about.
What to do next:
- Share this article with friends and colleagues. Thank you for helping me reach people who might find this information useful.
- Read the next article in the series.
- Chad Fowler elaborates more on these topics and offers some really good advice in The Passionate Programmer. This and other very helpful books can be found in the recommended reading list.
- Send me an email with questions, comments or suggestions (it's in the About Me page). Come on, don't be shy!
