Get best of the week

People who understand the work of a programmer can be found anywhere

People who understand the work of a programmer can be found anywhere. And at the same time - and in the work of accountants, managers, cashiers, designers and even penguin flippers. These guys love abstractions even more than the programmers themselves.

For example, there is such an abstraction as KPI. Another Scrum. Kanban Corporate culture. Soft skills. Etc.

To understand the work of a programmer, and most importantly - ways to increase its effectiveness - these people try through abstraction. Not from within the profession, but from the outside. We pull the owl on the globe. We adapt the abstract model to the profession, and try to understand and improve something, based on the rules of the model.

To improve the programmer’s work through Scrum, you need to make him glue stickers and get up on mitaps. So it is written in the training manual. In Kanban - re-stick stickers more often. For the corporate culture to work, you need to get the programmer to learn the hymn. Through soft skills - let him learn to speak. Etc.

Three groups of abstractions are especially popular. The first is serial production methods like Kanban or even conveyor. A worker who has sharpened the same details for years is the same programmer, right?

The second is project management methods like Scrum or Waterfall. It is clear that the intervention of the method looks soft - like, you solve the problem in a programmatic way, and behave in a scramble manner between tasks. But there is diffusion, in both directions. That the waterfall slogan “meet the deadline”, that the Scramov’s “aaaa, kherachim-kherachim-krachem!” affect programming “magically”.

The third is e-gay gay methods. You just need to make friends all, as in kindergarten, hang the balls, and the code is written. Well, what.

Let's go on the other side. Not from the outside, from distant galaxies of incomprehensible abstractions, but from the inside. The programmer's mind will understand how to increase the programmer’s efficiency, and what he should do. This is not for long, everything is too simple if you are from the inside.

The best way to increase programmer’s efficiency is to eliminate losses in the process. First of all, time loss. Losses - a huge amount. Up to 97% of the time, to be honest.

But they are difficult to see, because it’s not clear that this is a loss. It seems that a man sits, works, does something, does not lie on the bed, does not smoke, does not chat about an outsider. But, with a high probability, at the moment he is losing time.

Or stands on a meeting, sits at a meeting, lies on a couch by a staff psychologist, runs along a corporate treadmill, or is tightly clamped in a massage chair. Is it useful?

How would a person who understands the work of a programmer would classify losses? No, not like that - would he even start doing this? Of course. This is such a Project. The dissertation can be written - “types of loss of programmer’s time and ways to eliminate their influence on the financial, productive and moral and ethical results of managing small and medium-sized businesses in Russia during the era of change”.

Everything is much simpler, I think. Based on the assumption that there are more losses in our work than useful activities, it is easier to understand what is “useful activity”, and everything else should be considered as losses. It’s also easier to understand who a healthy person is than to remember the names of all diseases.

I suggest this wording for the programmer: you are busy doing useful work if you write a unique code.

Simple, capacious, and understandable. Everything else is either explicit or implicit loss so far.

It is clear that this is not an absolute filter, but rather a litmus test that gives out the spectrum, degree, and not one / two strips. And, alas, all the activities listed in the preamble do not pass through this filter.

Explicit losses are easy to name. For example, I am reluctant to work, and I went to the social network to look through the tape. Or I can’t decide which implementation method to choose, and I go for a walk, and along the way I forget that I wanted to think about the problem, and return without a solution. Or even went to bed at work. Or my head hurts so that I can’t talk, not to mention programming.

Explicit loss - when you obviously are not doing anything related to the task. True, this yourself is not always obvious, because man protects himself in front of himself. Well, how smokers prove to everyone and to themselves that their hourly breaks have a positive effect on work.

Implicit losses are more difficult - we are used to considering them to be useful activities. Well, or we were convinced that without this in any way. A programmer can’t cope without a mitap, a deadline and a daring song. Often, losses are hidden behind the wording “I am sitting and thinking.” I think about the architecture of the solution, I choose a problem for myself, I can’t decide whether I can make a toggle switch or checkbox, use a ready-made function with pre / post-processing, or write my own, look for code examples on the Internet, rummage through dependencies, etc.

I do all this because I cannot write unique code. I met some obstacle that does not allow me to start or continue, and try to overcome it. As a rule, on their own.

If you do not divide your activities into useful and losses, then you will not be able to establish self-control. It will always seem that it is busy with something necessary and important. And me and everyone around.

Such a definition of useful activity as “you write a unique code” simplifies everything. Whatever you do, you can always quickly answer the question, is this crap or something else.

If you write a unique code, you are busy. Write straight, sitting at the computer, and tapping your fingers on the keyboard.

If you do not write unique code, something is wrong. You were either frankly distracted, or stuck, or you were dragged into the next pulling of an owl on the globe, so that later you could receive a prize and defend a dissertation to protect. And your task is extremely simple - return to writing unique code as soon as possible.

Yes, you noticed, probably, that I constantly repeat the word “unique”. Well, of course, if you write code that someone has already written, and you can use this code, then you lose time.

Actually, that's all. Now at any moment in time you know what you are doing. You either do business, or you lose time.

Show this text to your manager. Already he will think up how accountants, cashiers, handymen and penguin turners will “write a unique code”.

More articles:


All Articles