The secret to effectiveness is high-quality code, not an efficient manager.

One of the most overloaded professions by idiots is managers overseeing programmers. Not all, but those who have never been programmers themselves. Those who think they can "increase" efficiency (or enhance "effectiveness"?) using methods from books. Without even bothering to read those very books — there’s a video after all.

Those who have never written code. Those for whom Hollywood films about programmers are made — you know, the ones where they check emails through the command line. Those who are only interested in metrics, deadlines, and their own salaries.

Those who make up the majority.

But they are idiots for another reason. They want efficiency, or at least effectiveness (come on, manager, Google the difference), without understanding either. Not grasping the essence, the process of achieving results, the losses occurring in that process, the costs of development. In short, working with a programmer as if they were a black box.

They rushed into managing programmers for one reason: there’s hype, money, a market, and a bunch of other idiots like them. There’s a place to get lost.

If there was hype in mechanical assembly manufacturing, they would have rushed there. Useless generalists. I wouldn’t be surprised if the guy selling Christmas trees in our neighborhood in December is an IT manager on vacation.

In short, if you have a chance, kick these guys out. Don’t worry, they will find jobs. None of them will ever produce anything decent until they become programmers themselves. Because they do not understand the essence, the mechanism, the logic of the process they manage.

Alright, enough about managers. Now, let’s get to the point for programmers. How to increase development efficiency by learning to write quality code.

To improve efficiency, you need to solve problems faster without sacrificing quality. To solve problems faster, you must be able to write quality code right away. Both "quality," "write," and "right away." I’ll explain with a metaphor.

Writing quality code is like speaking a foreign language proficiently. When you don’t know the language, you spend a lot of time formulating your thoughts in it.

When there’s a need to say something quickly, you just slap together some words, often not the right ones, forget about articles, the correct word order, not to mention verb tenses and poor pronunciation.

If there's time to formulate a response, you'll have to open a dictionary or an online translator, wasting a lot of time crafting your thoughts. The feeling, however, will still be unpleasant: you speak the answer, but you don't know if it's correct or not. Similarly with code - it seems to work, but whether it's quality or not is anyone's guess.

This results in a double loss of time. Time is spent coming up with an answer, and time is also spent formulating that answer—it's quite a bit, really.

If, however, the skill of writing quality code is present, the answer can be formulated immediately as soon as it forms in your mind, without wasting extra time on translation.

The skill of writing quality code helps in designing architecture. You simply won’t consider incorrect, unimplementable, or poorly structured options.

In summary, the skill of writing quality code significantly speeds up problem-solving.

But that's not all. Thanks to manager 'valenki', there's a hitch - we have no reason to write quality code. The manager doesn’t review the code, the client doesn’t review the code. We rarely show each other code, only occasionally in some projects where there's an assigned 'code checker' or periodic refactoring.

As a result, in most cases, poorly written code goes into production or to the client. The person who wrote the poor code develops a lasting neural connection - it’s not only acceptable to write poor code, but necessary - it gets accepted, and they’re even paid for it.

In the end, there's no chance for the skill of writing quality code to develop at all. The code written by a hypothetical employee is never checked by anyone, ever. The only reason they might learn to program properly is internal motivation.

But this internal motivation conflicts with plans and productivity requirements. This conflict is resolved in a way that’s clearly not in favor of quality code, since no one reprimands for poor code. But there are consequences for not meeting the plan.

What to do? I see and suggest 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 (hey, dude, take a look at my code, please). The key here is not to sugarcoat things, not to try to present code criticism politely. If the code is bad, we say it outright: the code is bad. With clarifications, of course, and recommendations on how to improve it.

But this path is also somewhat flawed. Its applicability depends on the point at which contact occurs. If the work has already gone into production and it turns out that the code is bad, there’s no point in rewriting it. More precisely, the incentive—metrics will also drop. Managers will rush in and overwhelm with performance requirements. And don’t even try to explain to them that bad code will inevitably lead to bugs—it will backfire on you. You can only take on the commitment not to do it that way again.

If the work hasn’t been submitted yet or has just started, then criticizing the code (or its project or idea) can have practical value—people will do a good job.

The second path, the coolest one, is to engage in open-source development in your free time. The goal is for a bunch of programmers, actual programmers, to see your code and comment on it. Inside the company, everyone is too busy. But programmers around the world have free time, and if you write something useful from a practical standpoint, they will definitely take a look inside.

The main feature, in my opinion, is writing code in your free time because it won't create a conflict between code quality and speed of delivery. You can spend a year developing your project. You won’t be pressured by deadlines, specifications, money, or bosses. Complete freedom and creativity.

Only through creative freedom will you understand and feel what great code is, you’ll see the beauty of programming languages and technologies, and you’ll appreciate the joy of business tasks. Plus, you’ll learn to write quality code.

However, this will require you to spend your personal time. Like any other form of development, really. Consider this not as a cost, but as an investment—in yourself.

Source: habr.com