As an engineer with 15 years of development experience, one of the first things that made me “get it” was a simple statement:

Good code is expressive, not impressive.

I remember wondering at the time, what is the essential difference between the more expressive and the more impressive?

In fact, being more expressive means being clear, specific, and specific. Therefore, a good piece of code needs to solve a specific problem. Behind the time and effort that goes into writing such a piece of code is a very clear, specific, concrete goal, and the code must actually achieve that goal.


Impressive, on the other hand, means leaving a strong personal mark or imprint on the process of writing code. A piece of code with its own complex structure, mixed with a variety of esoteric algorithms, can attract attention, admiration and applause from others. It can satisfy your vanity, but also translate into the wrath of the engineer who will take over your maintenance. If he happens to be a grumpy person who knows where you live, you may not be so happy about what happens next.

This is why programmers should choose to be smart, not smart. A shrewd able to foresee the development engineers need to have the own what behavior under what circumstances what consequences, and to “what kind of writing your own code”, “why write”, and “the code in the future there may be how the evolution of” the three problems has clear cognition. In short, smart engineers don’t do fire-fighting development; they write code with the belief that problems should be solved once and for all.

“Smart” engineers, on the other hand, are quick to develop and know how to do all sorts of dirty tricks to make code look “working.” Smart engineers have the ability to quickly “cut corners” to solve any problem at hand. But over time, those fragile code buildings built from band-aids and duct tape will collapse and shame everyone who worked on them. As Steve McConnell, the renowned American Software engineer and founder of Construx Software, wrote in his 1993 book, A Complete Book of Codes:

Programming, like working for the CIA, is not about being secretive and opportunistic.


Smart developers don’t bend the wind. They write plain but simple code that doesn’t shine, but doesn’t go wrong.

There are other habits that savvy engineers can learn from.

According to Martin Fowler, chief scientist at ThoughtWorks,

Anyone, including a fool, can write code that a computer can understand, but only a good programmer can write code that other people can understand.

Programmers sometimes feel that they have something to prove, or that they need to show others that they can do the job they’re doing. This leads them to prioritise the more complex and difficult solutions to every problem they try to solve, while ignoring the most straightforward and simple solutions that are right in front of them. This is one of the worst mistakes every development engineer can make.

Smart programmers write code directly, which is easy to maintain, optimize, or refactor in the future, doesn’t have any weird or unpredictable problems, and other colleagues can read it and see exactly what it’s trying to do. And new, unusual algorithms or development ideas, coupled with the tired but proud expression of a programmer who has been up all night, can sometimes look great to superiors or colleagues. But it is also likely to shine more brightly when it leads to an abject failure.


Whenever you’re writing code, and your ego starts to get to you, ask yourself this question: “If you leave this work for two months, will you be able to understand it when you come back?” If your answer is yes, then you can completely according to their own ideas and intend to write the code, just for your successor, please show leniency ─ ─ to explain this code does not need too much, please put a comment in the right place, for all kinds of variable naming reasonably, and modular processing it as much as possible.

High quality code, like a joke. If you have to go through extra interpretation to make sense of it, it’s not good code.

The late Edsger W. Dijkstra, a Dutch systems science expert, renowned software developer and computer science pioneer, once proposed that

Focusing on the “why” instead of the “what” can make you a better development engineer.


There are many ways to optimize your code, such as using more memory, or running faster, or using different algorithms and logic. Either way, a savvy developer will make a wise decision if circumstances permit. But before embarking on any optimizations, they follow a strict “don’t” rule:


Why would I do that? Is this code good enough? Is there any benefit to running faster, knowing exactly how the program will be used and the environment in which it will run? These are all questions you should ask yourself in advance.

Optimizations can only make sense in terms of cost and effort if a very important application is running slowly and the development team wants to make it faster while maintaining robustness, accuracy, and clarity. However, a program that runs fast but gets the opposite result is still meaningless. Efficient code optimization can often be more rewarding, but if you don’t do it the right way, you can end up with more bugs than benefits.

Whatever optimization you do, it should be significant and measurable. Don’t always rely on intuition. Intuition is always a poor compass.

Reuse rather than write new code

Vic Gundotra, a former senior vice president at Google, had a point that hit the nail on the head:


Before WRITING code, I had to figure out what they really wanted.

Savvy programmers prefer to look at the code first and then look around for viable, existing solutions. Others like to “rebuild it the right way.” In most cases, these people are wasting time on the same wheel.

Don’t be afraid to spend time looking. Searching the Internet or your code database for proven solutions will help you learn about common approaches to similar problems, as well as the pros and cons associated with them. That’s why smart engineers take longer to look at code before they write it. Because rewriting a whole new piece of code always takes more time, cost, and effort. Don’t do this unless you absolutely have to.

So when you need to complete a task, it’s best to check to see if someone has already done something similar. It’s not cutting corners, it’s saving unnecessary effort.

Challenge yourself

The Ancient Greek philosopher Aristotle once said,


If what you’re doing isn’t challenging, then doing it isn’t going to make you better.

Smart programmers will always challenge themselves, or rather, take every opportunity to challenge their own code. They always have the humility to realize that there is no perfect code, only better code.


Savvy programmers also don’t feel comfortable staying in their comfort zone and deploying in the same pattern over and over again. They make a conscious effort to avoid dogmatic thinking about their code preferences and are always looking for ways to do things better, even if it means spending time learning new things.


Smart programmers are not attracted to flashy ideas and fancy features. They are pragmatic enough to realize that there is no perfect solution and that every great feature or magic trick comes with a different downside.

Dare to ask others for help

Sophocles, the Ancient Greek playwright and tragic poet, believed that


If each of us could truly help each other, no one would need good luck anymore.


As a programmer, you always think of yourself as a more rational, smart person. In fact, quite a few development engineers are truly gifted. But sometimes programmers are overconfident that they know everything and can solve any problem with their brains. After all, no one wants to go into a work meeting and admit, “I don’t know this,” or know nothing about the new feature they’re about to deploy.

So they keep telling themselves, “I’ll figure it out on my own. I was always on my own, and I can still be.”

Savvy programmers, however, don’t see it that way. They know when to ask for help and when to think for themselves. They are well aware that any delay could spiral out of control and end up with everyone on the team watching deadlines draw closer and closer under constant anxiety and almost hopeless pressure. That’s why smart programmers are brave enough to expose their weaknesses and ask for help when necessary.


Asking for help is not a question of competence, it actually reinforces the trust and confidence of others that you will do whatever it takes to fulfill your responsibilities and deliver on time as expected. You’ll be remembered as an aggressive, confident developer who wants to get better every day.


As Kubbra Sait, winner of The Best Female Presenter award in India, actress and model, said,


Asking questions is the first step to getting better.