One of the most idiot-laden professions is managers who manage programmers. Not all, but those who were not programmers themselves. Those who think that it is possible to “increase” efficiency (or increase “efficiency”?) using methods from books. Without even bothering to read these same books, the video is a gypsy one.
Those who have never written code. Those for whom Hollywood films about programmers are made - well, those where they watch email using the command line. Those who are not interested in anything other than indicators, deadlines and their own salary.
Those who are the majority.
But they are idiots for a different reason. They want efficiency, or at least effectiveness (come on, manager, Google what the difference is), without understanding either one or the other. Without generally understanding the essence, the process of obtaining the result, the losses that occur in this process, the costs of development. In short, working with a programmer as if he were a black box.
They came running into the management of programmers for exactly one reason: there is hype, money, the market and a bunch of the same idiots. There is a place to get lost.
If there was hype in mechanical assembly production, we would run there. Station wagons suck. I wouldn’t be surprised that the guy selling Christmas trees in our neighborhood in December is an IT manager on vacation.
In short, if possible, shoot these guys in the neck. Don't worry, they will find a job. None of them will ever do anything decent until they become a programmer themselves. Because he does not understand the essence, mechanism, logic of the process he controls.
Okay, enough about managers. Now to the point, for programmers. How to increase development efficiency by learning to write high-quality code.
To increase efficiency, you need to solve problems faster without losing quality. To solve problems faster, you need to be able to immediately write high-quality code. And “high-quality”, and “write”, and “immediately”. Let me explain with a metaphor.
Writing high-quality code is like speaking a foreign language correctly. When you don’t know a language, you spend a lot of time trying to formulate your thoughts in it.
If you need to say something urgently, you just stick on some words, often not the right ones, you forget about articles, the correct word order, not to mention verb tenses and poor pronunciation.
If you have time to formulate an answer, you will have to open a dictionary or an online translator and spend a lot of time formulating your thoughts. The feeling, however, will still be unpleasant: you say the answer, and you don’t know whether it’s correct or not. It’s the same with the code – it seems to have been written, it seems to work, but whether it’s of good quality or not is a mystery.
It turns out to be a double waste of time. It takes time to come up with an answer. It also takes time to formulate this answer - and not so little.
If the skill of writing high-quality code is present, then the answer can be formulated immediately, as soon as it has matured in the head, without spending additional time on translation.
The skill of writing high-quality code helps when designing architecture. You simply won’t consider incorrect, unrealizable or hand-me-down options in your head.
To summarize: the skill of writing high-quality code significantly speeds up problem solving.
But that's not all. Thanks to the felt boots managers, there is one catch - we don’t have a reason to write high-quality code. The manager doesn't look at the code, the client doesn't look at the code. We rarely show code to each other, only sometimes, in some projects where there is a designated code “checker” or periodic refactoring.
It turns out that in most cases the shitty code goes to production or to the client. A person who has written shitty code forms a stable neural connection - it’s not only possible to write shitty code, but it’s also necessary - it’s accepted, and they even pay for it.
As a result, the skill of writing high-quality code has no chance to develop at all. The code written by a conditional employee is never checked by anyone. The only reason he will learn to program normally is internal motivation.
But this internal motivation conflicts with plans and requirements for efficiency and productivity. This contradiction is clearly not resolved in favor of high-quality code, because people don’t even criticize people for shitty code. And for failure to fulfill the plan - even so.
What should I do? I see and propose two paths that can be combined.
The first is to show your code to someone inside the company. Not reactively (when asked/forced), but proactively (uh, dude, look at my code, please). The main thing here is not to post sugary snot, not to try to put criticism of the code in a polite form. If the code is crap, we say so: the code is crap. With explanations, of course, and recommendations on how to make it better.
But this path is also so-so. Its applicability depends on the point at which contact occurred. If the work has already gone into production and it turns out that the code is crap, there is no point in redoing it. More precisely, the reasons - the metrics will also sag. Managers will rush in and crush you with efficiency requirements. And don’t even try to explain to them that the shitty code will definitely come back in the form of bugs - it will backfire on you. You can only make a commitment not to do this again.
If the work has not yet been delivered, or has just begun, then pouring shit on the code (or its project, idea) can have quite a practical meaning - the person will do it normally.
The second way, the coolest one, is to do open source development during non-working hours. What is the goal: for a bunch of programmers, namely programmers, to see your code and speak about it. Everyone inside the company has no time. But programmers all over the world still have nothing to do, and if you write something useful from an application point of view, they will definitely look inside.
The main trick, in my opinion, is writing code during non-working hours, because the contradiction between the quality of the code and the speed of delivering the result will not work. Write your development for at least a year. Neither deadlines, nor technical specifications, nor money, nor boss will put pressure on you. Complete freedom and creativity.
Only in free creativity will you understand and feel what great code is, see the beauty of language and technology, and feel the charm of business tasks. Well, you will learn to write high-quality code.
True, this will require you to spend personal time. Just like any other development. Look at it not as a cost, but as an investment – in yourself.
Source: habr.com