One of the most important lessons that I learned as a developer 15 years ago was this simple thought:
Good code is expressive, not impressive.
I remember when I heard this I asked “What is the difference?” And received an answer.
“Expressive” - understandable, unambiguous and specific. And if so, writing expressive code will require working with a specific task. The investment of time and energy in its creation serves a specific purpose, and the result corresponds to the expectation.
Impressive is a code that is remembered. Writing code that is remembered for its complex structures and algorithms, although scratching your ego, will be a real pain for someone who will support it in the future. And if the latter turns out to be a maniac who knows your address, God save you from his anger.
That is why a good developer is wise, not brilliant. A wise developer has not only intelligence, but also the ability to constantly think about the consequences of his actions. He knows what specific code he writes, why he does it and, most importantly, how this code will behave in the future. Or, if simpler, the wise developer is trying to treat the disease, not the symptoms.
“Ingenious” developers, having the same intelligence, on the contrary, think only about the present. They can solve current problems quickly and effectively. That's just the mountain from their hacks and tricks constantly accumulates and once crashes the code, burying the reputation of all involved. This is why Steve McConnell once correctly remarked:
Programming is not a job at the CIA; you don't have to be smart.
And wise developers do nothing savvy. They write boring and simple code that is easy to understand. No more, no less.
Here are a few more principles of wise developers.
They prefer simplicity
Martin Fowler once said:
Any fool can write computer-friendly code. A good developer writes human-readable code.
Sometimes developers have a desire to assert themselves. Show others your talent. And they begin to look for abstruse solutions for every problem they encounter, although a simple solution is right at hand. And this is one of the worst mistakes that a developer can make.
A wise developer writes straightforward code. It is easy to maintain, optimize and refactor if necessary. The code does not do something tricky, everyone who encounters it immediately understands roughly what is happening “under the hood”. Advanced and unusual algorithms prove to be excellent during the night sprint for coffee and energy, but they fail a lot later in production.
When the ego begins to slowly tempt you during programming, ask yourself: “If I return to working with this code after 2 months, can I remember what exactly is happening here?” If the answer is “yes”, then go for it. Remember, however, about your colleagues who someday will have to work with this code.
The code is like a joke. If it needs to be explained, it is bad.
They know when (not) you need to optimize your code.
Edsger Dijkstra once correctly remarked:
A good developer focuses ON WHAT, NOT ON WHAT HELP when writing code.
However, there are many different ways to optimize your code. Each of them is associated with a change in the amount of memory consumed, processor time and a specific algorithm. And wise developers choose this path pragmatically.
But before starting to improve something, they follow the golden rule of “do no harm”.
For what purpose am I going to change something? Perhaps the program already perfectly solves the task? Given how and in what environment the program will be launched, is there any sense in making it faster? All these questions must be answered by yourself before you begin optimization.
Any optimization makes sense only in the context of labor and returns, if the program is important, and it is really slow, and there are reasonable reasons to believe that it can be optimized while maintaining reliability, correctness and clarity. No one needs a program that produces erroneous results, no matter how fast it is. Well-optimized code is better than not optimized, but with the wrong approach, the exact opposite is true.
Remember: any performance changes during optimization must be measured. Intuition in this matter is a poor helper.
They prefer to use rather than create code.
Vic Gundotra hit the bullseye, once saying:
You start by writing code. I start by finding a solution.
And wise developers follow suit. They start by looking for ready-made code. Although it seems to some that they will now do everything from scratch “how to”, most end with the banal invention of a bicycle.
Feel free to google it. The search for solutions, whether online or in your own code base, is already useful even from the point of view of studying the approaches that worked previously in similar problems, as well as their pros and cons. That's why wise developers spend a lot of time reading someone else’s code before writing their own. Creating code from scratch is always worth the time, money and energy. Do not waste resources until it really becomes necessary.
So when solving another problem, first try to see if anyone has solved it before you. You do not avoid your work, you avoid unnecessary work.
They try to be better.
Aristotle once said:
If you are working on something that you already know how to do, you will not get better.
Wise developers are trying to improve themselves, or rather their code at every opportunity. They are modest enough to realize that they have not yet created their best code.
They do not sit out in the comfort zone over and over again using the same approach. They are doing their best to ensure that their own habits do not become dogma for them. They are constantly looking for ways and opportunities to do better, especially if they can learn something new in the process.
Wise developers are not fascinated by fashionable technology and cool features. They are pragmatic enough to understand that a silver bullet does not exist and any approach has its pros and cons.
They are not afraid to ask for help.
Socrates pronounced:
If we were constantly helping each other, no one would need luck.
As developers, we like to think of ourselves as smart people. In addition, among us there really are geniuses. But we are also inclined to believe that we should know everything in the world. And really, who is pleased to say in front of colleagues: “I do not know”? Who wants to admit that the new technology for him is a set of hieroglyphs?
Instead, you quietly whisper to yourself: “I will figure it out on my own. I’ve already done so many times before, I can now. ”
Wise developers do not do this. They know when to think for themselves, and when to ask for help. They already know that dragging out a request for help only kills time before the deadlines, which will harm the whole team. Therefore, they are not afraid to seem incompetent and ask for help when it is needed.
A timely request for help will not undermine the faith of colleagues in your capabilities. It will strengthen confidence in you, as a professional, ready to do everything necessary to meet deadlines and achieve high-quality results.
As Cubra Sait once remarked:
Positive changes begin with questions.