About slow programming

From a translator: when developing Web-payment.ru , a site with monitoring exchangers and a lot of sections on payment systems, I intuitively used the principles described in this article. Subconsciously, I knew them, but could not articulate. I suggest you familiarize yourself with an interesting approach shared by an experienced programmer, the author of many books Jeffrey Ventrella.

My dad often told me: "Slow down, son, you are doing things too fast."

I happened to work in many high-tech startups in the Gulf of San Francisco. Now I am 52 and I program slowly and carefully. I can be thought of as a sort of designer squeaking code. Reading the post further, you yourself will understand.

Recently, I worked on a project with a group of young coders who believe in the effectiveness of very fast , small iterative changes in the code. Programming slowly side by side with them was a problem for me. We were recommended to work in one common code base, it is as if we were boiling together one large pot of soup, and provided that we actively interfered with it continuously, something would certainly appear wonderful and complete.

But nothing happened

Many of these coders had the false belief that there are no irreplaceable engineers and that none of us should be responsible for any particular piece of code. Any coder should be able to change any part of the code at any time, because, in the end, we also have such smart services as github , which allow you to manage and merge any number of asynchronous directories made by any number of coders. As long as everyone does regular commits and doesn't break anything, everything will be very good in the end.
')

Complete nonsense

You can not just throw out of the design process. It has existed ever since civilizations appeared, and even the newest and smartest development tools, no matter how clever they were, could not replace collective cooperation in the real world, and the advanced practices of humanity, through which cathedrals, railways, and full-length feature films.

In the same way, no matter how much you program, you will never be able to create a tool that would allow you to fully develop the software at the same speed as the monkey coders team.

Arrhythmia

My slow programming in a fast programmer environment was like some form of arrhythmia. That is, my rhythm of writing the code simply disappeared in the iterations of other coders, who scribbled it like a machine gun. My programming style suggests a completely different duration of work on projects of very different complexity. Each branch begins with research, trial and error, hacks and temporary variables. In fact, all this can be compared with the construction of scaffolding around a building under construction. Gradually, the picture emerges. A little later, I go back to work, put all the dots on “i” and put the final touches. The result of each such session of creativity is something like a ready-to-use code. (I never leave “in the workshop” nothing extra after work). Adding a branch of the developed code to the repository is equivalent to the appearance of a new strategy, project design, or architectural object.

It happens that when, after all my efforts, an adult living organism appears on the light, I go back and start everything all over again, because it seems to me that I understood how to make it better. Sometimes it works and sometimes not. You can probably only find out about this when this creature has already been formed and is looking directly at me.

But let's go back to our programmers and their soup pot. We are faced with the following problem: how can even the fastest coder come up with a good creative solution in the absence of overall stability in the program ecosystem, where there are no quiet backwaters within which the development and idea design process originates?


Any coder who claims that fast programming is no different from slow (except for speed) simply does not understand the benefits that design provides. Studies of modern neuroscientists have established that the volley of neural impulses in the brain spreads like fluid that reaches all parts of the brain associated with thinking and consciousness, and causes them to respond only after a certain time. For the same reasons, a good idea also needs time to mature.

Slow motion programming

According to Wikipedia: “the movement for slow programming is part of the slow movement . This is a software development philosophy that emphasizes code quality, careful design, software testing, and thinking about the development process. She recommends avoiding the use of crutches, too fast development cycles and writing code with no bugs. ”

In addition, Wikipedia also gives us information about “Slow Software Development”: “While adhering to a flexible development methodology , software development teams around the world are looking for projects whose results can be predicted in advance, and strive to build a solid career, respecting a rational balance between work and personal life. They suggest using practices such as pair programming , code revision, and code refactoring , which results in more reliable and more streamlined software applications. ”

The popularity of software development with the support of venture capital here in the San Francisco Bay is now growing at an insane rate. Money that acts as a driving force imposes unnaturally exaggerated demands on the process of developing creative thought, which in fact is best left to the natural biological rhythm of evolution. Faster does not always mean better. In fact, sometimes slower means faster - in those moments when everything promised is fulfilled in practice. How digital technologies usurp our natural temporal rhythms is described in the book by Douglas Rushkov Present Shock .

There is another problem: an almost religious obsession with technology, accompanied by a fetishistic love of development tools. People wonder why software turns out to be so crap (yes, it really sucks ), but it turns out that it is because of obsession with itself. Fast programmers first make mediocre utilities that help in writing code, and then endlessly improve them, creating more and more mediocre solutions to improve previous, same mediocre developments created earlier.

That's why I believe that we need adults, women, educators, and creative people within the application development cycle. More humane people, less human objects . I'm not talking about the influence of such people on the process from the outside , when we plant them in tech support, or instruct them to decorate the interface design. I mean the inner side of the process , the need to ensure that the programs resonate with all of human society as a whole.

How glad I am that I am not a blind typing typist

One of my friends - an adult woman, a software specialist, somehow noticed with a grin: "Programming applications and typing on the keyboard are different things." Everyone knows this, but remembering this from time to time will not hurt anyone. Brendan Enric already wrote about this. We, programmers, spend our time knocking fingers on the keyboard, and from the side of such physical activity it looks as if it is programming. However, in reality, programming is an act of connecting together the concept, language, logic and speculative constructions into a certain form, such that it can be stored in the computer's memory.

My wife often goes into the yard and asks me: "Do you code?". And often I answer that “Yes”, but in fact, at such moments I, as a rule, cut branches with shears or work with compost.

Plants, dirt, and secateurs have much the same relation to programming as keyboards and flickering screens.

Today we live in a transitional period: the industrial era and the economy, whose main measure of success is growth, are replaced by an era of sustainable development. Yes, new software and new businesses need to grow, of course. However, in order to be viable, they must grow slowly, with love and care, as it happens in the process of making good wine or raising a child.