How I stopped hating and fell in love with development

The article Fear and Loathing in IT made me sad. Not because I share the feelings of the author, but because they are shared by many good developers, killing themselves, their projects, industry and human progress in general. Here is the mahanul, huh?


No matter how enthusiastic a futurist I am and an adept in automation, this article is about more mundane than a brighter future. Therefore, I will leave the fate of mankind next time. Now I want to finally speak about the huge volumes of negativity, pain, fear and hatred lurking in the depths of the IT community, covered by a small warm layer of hype technology and cool engineering solutions.

Disclaimer


From my own experience, I know how difficult it is to apply what is being discussed in outsourcing, especially on huge projects. I don’t want most developers to think “well, now” and close the article, but I don’t know how to lure, but I don’t want to deceive either. Therefore, I ask you: go on, not everything is so bad.

Excessive complexity


The author of the original article emphasized the obvious thing: the developer no longer controls the operation of his solution. For many, it was very comfortable, giving a sense of calm and control. And this comfort remains the starting point: until now, despite the transition from the category of creators to the category of artisans, the programmer is still trying to enjoy the process of creating something from nothing. Using other people's creations this pleasure can not be achieved, you feel at best a mosaic , successfully selected stones. (But mosaic is also an art, what is wrong here? Hmm ...).

Accept the inevitable. Only select characters of myths could create planets from nothing. Using the appropriate components, applying well-known approaches and thinking carefully , you can create an elegant system and enjoy comparable to that of a "pure" creation. And it will work at any level: from the new enumeration to the design of a high-load system.

Technically, everything is not so rosy. And two things are to blame: time and colleagues. Our decisions must satisfy two criteria: costs should be lower than expected medium-term benefits, and support costs lower than long-term ones. Therefore, with the existing development volumes, we inevitably come to decisions like “use this client everywhere”: it is fast, and the whole team knows how to work with it. And if the client is quite popular, then future team members will be able to. Look for a balance between the extremes of exalted creation and soulless conveyance, enjoy finding it!

Too Much and Interviews


Choosing the perfect component for the current solution is unlikely. Even if he exists, he is one in a thousand. Each developer / team / company chooses something for themselves, learns to circumvent pitfalls ... and begins to demand the same experience from others. This is stupid. As stupid as clinging to lost control over your creation.

Every time I read another story of the pain from the interview “they want to know the full list of changes in ES6,” I am sad. They want to know only one thing: will you suit their team. And “they” are us, only on the other side of the table. We do not know how to ask, and do not know how to answer.

Break this vicious circle of misunderstanding! Stop taking interviews and start looking for a job for yourself. Say what you think. Accept that your team is one of twenty. Find her.

Stop looking for someone who knows the same thing, and start looking for someone who will give you something new. Ask what is important to you. Accept that by asking knowledge questions you are simply writing a detailed summary. Find someone who will speak the same engineering language with you, share your principles and development approaches.

IT people


Also people. People are different, while xenophobic; quite a useful trait in terms of natural selection. It does not help when working in a team, and little can be done about it: it will be interesting for the checkers to play their toys together, the hardcore engineers will, creating a couple of words, create eternal things together.

Accept: people are different. If you need people - look for "your".

Probably the maximum amount of hatred is associated with managers. And here we are again in a vicious circle: the manager does not want or cannot do his job - and therefore we turn away from him and do everything ourselves. He's useless anyway. This question goes into

Business


Many copies are broken on the battlefield of Business with Technology. I don’t feel like repeating myself, so I’ll omit a large piece of context and go straight to the main point.

Only the developer is responsible for crutches in the solutions. Only business (represented by PO, PM, directors, etc.) is responsible for project failures. And here you need a lot of strength. Learn to calculate the price of quick solutions. Learn how to prove that saving a month now will lead to two months of overrun tomorrow. Or will not. Accept that good code does not solve problems on its own, but business does not want to bury itself in technical debt!

You may refuse to play bulshit bingo. Call a spade a spade before they reach you and you will call them beautiful . Names. A developer can afford to be honest - he has no budget and no responsibility. In a pinch, it’s easy for a developer to find a new job where they’re a little less afraid of honesty. Give your honest expert opinion on the problem and solution, and let the business solve it. And distinguish unwillingness to decide from finding a solution. We accustomed the business to the fact that you can make a quick hack. They know that if you push a little, we will give the result five times faster. This is a rejection of the decision, and we should not indulge in such behavior. The manager, in search of a solution, will decompose and prioritize, trying to show the result in due time. And we are obliged to help with this.

The Curse of Outsourcing
Everything that I'm talking about makes a lot of sense when a structure appears between the real business and the developer, for which the business is development itself. Natural causation is seriously affected when there is a side for which the development and successful functioning of the business is not important. For which only the amount of resources spent on development matters, and the more the better. And even when outsourcers allow developers to communicate with the customer directly, on the other hand, in the depths of a huge corporation, there may be an indifferent manager, irresponsible and limp. At one time, I just ran away from a similar situation, and I have nothing to advise.

The developer should understand the business just enough so that the time to formulate questions and understand the answers is comparable to the time to search for a technical solution. We can no longer say “give me a cake and I will do everything”, such a cake is almost the whole solution. Our work is no longer in rearranging bytes manually, we now have much more time to analyze the whole picture. But we should not accept "there is a bunch of tasks, sort out what is there and how." Business very often saves time on finding a business solution, and the task of the developer is to see that there is nothing to develop, and point this out to the business. This is hard work, and not for everyone.

About myself


At 20, I was coding for days and gladly went to work.
At 25, I saw how bad everything was and suffered, expecting Friday and a pet project in which everything is fine.
At 30, I am passionate about work ... happily meeting Friday and the weekend.

I do not know what will happen in another 5 years, but I hope that I will not be disappointed in the current beliefs.
Our area gives us a lot - freedom of expression, development, knowledge, interesting experience and decent money. Our region is very young, it is still a craft, and we do not have a dynasty of artisan ancestors. We do not yet know how to work in it. Therefore, we are angry, suffering and burn out.

My decision is the presumption of rationality. I no longer draw conclusions about a person by his code, e-mails or drag-and-drop. Even more, I try not to think badly because of what he says or does. After all, while we are working on a common cause, and until he said directly “I want to harm the project,” he is my ally, and together we can do more than individually.

Nobody has said so far, although I sometimes drive some colleagues into this corner :)

Source: https://habr.com/ru/post/479296/


All Articles