Write code as if you will be maintaining it for the rest of your life
Jul 22, 2024
code
start
career
life
rest
2 min read
You can ask 100 different people what any programmer should know and be able to do, and get 100 different answers. This can be both overwhelming and frightening. All advice is good, all principles are sound, all stories are convincing, but where to start? And, more importantly, once you start applying best practices, how do you maintain the right level and make them an integral part of your programming practice?
I think the answer lies in your mindset or simply in your approach. If you are indifferent to your fellow developers, testers, managers, sales and marketing staff, as well as end users, you will not feel the urge to, for example, conduct test-driven development or write clear comments in the code. I think there is a simple way to change your attitude and develop a desire to release products of the highest quality:
...
➦ Use quantitative criteria
Jul 17, 2024
ms.
system
criteria
time
work
users
3 min read
“Fast” cannot be a requirement. Nor can “having a good response time.” Or, let’s say, “scalable.” The main reason is the lack of objective criteria for meeting such requirements. But users still need these characteristics. The architect’s task is to ensure that the system possesses the necessary qualities and to balance the inevitable contradictions that arise. between them. Without objective criteria, the architect depends on whims the client (“No, I can’t accept the program – it doesn’t work fast enough”) and the developers, obsessed with their compulsions (“No, the program isn’t ready yet – it doesn’t work fast enough”).
Usually, we try to record all such requests, just like any other requirements. But this record often looks like a set of vague epithets: “flexible,” “easy to accompany,” and so on.
...
➦ Improve the code by removing it
Jul 16, 2024
advice
yagni
system
code
requirements
client
tip
2 min read
Less is more. It’s a clichéd short maxim, but sometimes it’s really true.
Over the past few weeks, among the improvements I made to our code was the removal of some of its fragments.
We were developing the project following the principles of extreme programming, including YAGNI (You Aren’t Gonna Need It). But human nature is imperfect, and in some places we made mistakes.
I noticed that our product took an unjustifiably long time to perform certain tasks—simple tasks that should have been completed almost instantly. This was all because we overcomplicated their implementation—with all sorts of trinkets and bows that were actually unnecessary but seemed useful at some point.
So, I simplified the code, improved the product’s performance, and reduced the overall code entropy, all thanks to removing unnecessary functions from the project code.
...
➦ One binary file
Jul 15, 2024
in •
GIT
environment
bazaar
git
code
changes
version
production
3 min read
I have encountered projects where part of the code was rewritten during the build process so that a separate binary file was generated for each runtime environment. This approach always complicates things unnecessarily and creates the risk of incompatible versions appearing with each installation. At the very least, several almost identical instances of the program are built, each intended for installation in its corresponding environment. Too many moving parts arise, which means more opportunities for error.
Once, I worked in a team where after every property change, it was necessary to save the code and conduct a full build cycle, so the testers were idle every time a minor bug was found (did I mention that the project also took an incredibly long time to build?
...
➦ Hard work does not justify itself
Jul 10, 2024
act
work
week
hours
project
software
3 min read
Every programmer needs to be convinced that intense work is often unjustified. You can deceive yourself or your colleagues into thinking that by staying late at the office, you are making a significant contribution to the project. But in reality, by working less, you can achieve more—sometimes significantly more. If you are trying to work “productively” and with focus for more than 30 hours a week, you are likely overworking. It might be worth considering reducing your workload, which will allow you to work more efficiently and accomplish more.
It may seem that my statement contradicts common sense and is generally debatable. However, it is a direct consequence of the fact that programming and software development, in general, require continuous knowledge expansion. As you work on a project, you will come to better understand the subject area and, hopefully, find more efficient ways to achieve your goals.
...
➦ 
