In simplified terms, a programmer is a person who is able to describe a task in a language understood by a computer. A computer, in turn, is any electronic computing device which can execute unambiguously defined sequences of commands by transmitting electrical impulses (at least at the time of writing these lines). However, programs in their modern sense are written not so much for computers as for people.
The computer does not care about the quality of the architecture of the program system; the choice of names of classes, functions and variables; comments and other minutiae of life. The evolution of programming languages owes its evolution to limited human capabilities. For a machine, a language consisting of zeros and ones is quite understandable and natural (native) – binary code. Compared to the binary code, even the assembler seems a big step forward, because the human brain is not designed to memorize numbers.
Modern programming languages try to enable developers to model real objects in the form of abstract models. For example, it is much more convenient to manipulate a concept such as “image” rather than “array of pixels.
Remember that in most cases good code is code that is easy to understand (both for you and other people). There are exceptions, of course. In particular, there may be a need to optimize a program for speed of execution or memory consumption. However, premature optimization often seriously undermines the quality of your project. Remember: optimize only what is guaranteed to work. Code profiling will help you with this. Optimizing before you make any measurements is a waste of time at best. Without a performance gain assessment, you won’t even be able to say unequivocally that the code hasn’t become less optimal than it was before!
The reality is that software projects these days are on such a scale that at least a few developers are needed to achieve acceptable release dates. In this case, the importance of code quality becomes even higher. The way you think should be clear not only to you, but to the rest of the team as well. Try to suppress the desire to show off your erudition by using too complex structures and language constructions, if you can use a simpler analogue. Reading your code, others should get the feeling that it is simple. Simple in a good sense (not primitive). So simple that you can’t imagine it any other way. If you can do that, you’ve succeeded.
But don’t forget that there is a downside to collaborative development. You must be able to read other people’s code, and this can be more difficult than writing comprehensible code yourself. Of course, in a well-organized team, the architecture of the application should be such that each developer is assigned a set of system modules to work on. This avoids most version control conflicts when incompatible changes made by different programmers occur within the same file. But be prepared for the fact that at any time it is you who will have to pick up someone else’s modules. After all, no one is immune (anyone can fall on his head traffic light).
Agile development techniques welcome “pair programming” and “collective ownership of the code. Explore these techniques. Perhaps some of these will work for your development team.
Here are just a few books on the subject that I can’t help but mention, and highly recommend reading:
- Perfect Code. A Practical Guide to Software Development. A must for careful and thoughtful reading;
- Clean code: creating, analyzing and refactoring. WARNING. Propaganda of flexible software development methods
- Perfect Code. Good training in reading other people’s code, of which there is a lot in this book.