The article A programmer should not solve business problems caused a strong discussion (and even an answer with the exact opposite statement).And, it’s funny that it all came down to dogmatic reasoning from the category of “programmer must”, or “business should”. As if, we are talking about a system that works for a common goal, and the only problem is to configure it correctly.In fact, everything is much more complicated, and a business with a programmer has very different goals. Therefore, speaking about who, whom, and what should, it looks like a statement that the buyer should not steal goods in the store. Yes, it should not. More precisely, he should not steal, if he speaks according to the rules of formal logic. Simple, understandable, accepted by the overwhelming majority. So what? Does this mean that the store can fire guards and take down cameras?In my first article on Habré, I considered the situation from the perspective of the employer (business), and explained the principles that I follow in order to find people who will solve the problems of the business . And why is it so important.But there is one caveat, and it is that people who are not taken up by interviewers like me, with due dexterity, achieve more than those who benefit. And there is good reason for this - they successfully maximize the skill that is most correlated with the income of the programmer - the ability to sell oneself. How, - I will tell in this post.Disclamer, . . , , , , Junior -> Middle -> Senior -> Lead dev -> Tech lead -> Architect -> Chief architect -> CTO.
Formulation of the problem
First of all, we will figure out what each of the parties wants to achieve:Business wants a cheap and timely solution to its IT tasks, satisfying expectations, and, in the case of advanced management, also creating new business development opportunities.The programmer wants to cultivate his value in the labor market, maximize working conditions (including $, schedule, tightness of control, benefits & perks), solve problems by which you can increase your credibility, and get satisfaction from the solution.Conflict
Actually, it’s easy to come up with an example where there is a win-win, such as developing a proprietary DBMS kernel, where a programmer solves atypical applications of the olympiad level, drags himself from this, speaks at conferences, and then sales increase sales, showing customers how to efficiency and stability of the core than competitors, they will save on infrastructure.But we will not talk about such cases. Let's talk about the cases faced by the vast majority of programmers who make ordinary decisions over and over again. Another online store, another online casino, another operating day for an ordinary non-technological banking business ...And there is an acute conflict. Because timely, reliable, predictable, cheap and well-supported solutions are made on time-tested technologies. Conditionally, if the admin panel of your online store with an ASP.NET kernel is written in WebForms, and the code authors are still not going to leave with you, then the control panel of the newly created recommendation system should also be written in WebForms, although the .NET Core + Angular + TypeScript bundle 1000 times better, and indeed WebForms is a mess. After all, the team that wrote the 500 forms will write the 501st quickly, reliably, bypassing the rake. And the business will get a good solution.For programmers who have realized the value of WebForms in the market, writing on it can be like torture, because they perfectly understand that during the writing of this form, they will increase the value of the business, but at the same time lower theirs, because while you stand still, the industry runs past you. Therefore, in this situation, any sane programmer (even if he is a co-owner, after all, no one will guarantee that the store will live forever, and it will be very painful to look for work in case of bankruptcy of the store) will try to somehow get the right to complete the task on something then fresh and in demand, of course, spending more time at the same time, allowing more bugs, stepping on more rakes.It is clear that this situation is exaggerated. But the essence remains the same regardless of the domain and technology.A simple code on a time-tested, non-HYIP, well-known team solution gives business predictability and reliability, and the team degrades. Code on a new hype framework and / or with high algorithmic complexity gives development to the team, but the business suffers risks for this. A focus on a deep understanding of the subject area by the programmer can significantly increase the value of the business (to write exactly what is required and not to write what is not necessary), but does not increase the value of the programmer (knowledge of accounting is rarely asked above in the market for programmers) on technologies and algorithms, on the contrary.After all, a programmer who is well aware of algorithms and technologies easily finds work with a boost, while for business most of the knowledge is redundant and inapplicable. And a service written on fashionable frameworks with the correct use of patterns and the correct algorithmic complexity will not greatly help the business if it does not do what was expected.Yes, there are side factors. For example, hype topics simplify hiring, and the infernal legacy reduces the outflow of existing personnel (people would like to leave, but nowhere), but these are nuances, and they are not so important.Solutions
So, let’s imagine the moment when the programmer realized that the business wanted to slightly reward him (okay, say, to postpone his development) for the sake of a common cause. What can be done?Obey. And lose in their own interests. Comments are redundant.Directly go to conflict. So say, I'm not your slave. If you want a primitive copy-paste code with a deep knowledge of accounting, look for a fool. I won’t do that. Perhaps a ride once. But there is no need to talk about a career here.To convince the business that they need exactly what you need.This is one correct option for the programmer. Yes, it is difficult to achieve with a high technical level of the manager and low persuasion skills of the programmer. But it's always worth a try. After losing, you can always choose p1, and go save up until the next time. And by winning, you get respect and a sense of value from the business and your professional growth at the same time.The only question is how to get this holy grail?Here we will look at some fascinating stories.History 1. About the head of the department Vasily
Vasily was one of the most experienced programmers in the corporation. Over the course of a twenty-year career, he has grown from a junior programmer to a department head. He had 40 people with direct subordinates, resolving issues directly with the founder, and not with the CEO and his deputy, like other managers of his level. And still peeing code to stay in shape. He made his career due to the fact that he had exceptional intelligence, and, in addition, business could communicate with him in the same language. Prior to this, Vasily was in a constant race. He made promises, and with all his might reached them. For this he was adored. Yes, it was rumored that he always requested too long deadlines, but, on the other hand, he moved them much less often than other department heads.And then he was recognized as the best manager of the year, they began to set everyone as an example, and Vasily (who in his heart never ceased to be a programmer) realized that it was time to learn new technologies, and at the expense of his subordinates to experiment with new approaches, in particular, with DDD.The flagship product of the Vasily department, the automated workstation (AWP) of the futures trader, helped to earn a lot of money, and over the years of operation almost all the bugs were caught in it and polished to a shine. The problem was that it was a desktop application for Windows (while everyone around was switching to the web), and used MSSQL as a DBMS, which, according to Vasily, was also a stone age, because relational DBMSs were used while people did not learn how to make normal bases.And now we are talking about the need to write an automated workplace for an optional trader. The project was somewhere around 6 months, including entering the topic of a new team and beta testing, if we fork the turnips of the futures terminal, and replace a number of modules. But, damn it, to make another product using outdated technologies ... Well this is not interesting. Yes, and people will have to hunt above the market, because no one wants to harness such things (and the ability to hunt and keep people 20% below the market was Vasily’s killer feature), and therefore, the fact of hunting above the market would have shaken his reputation.Therefore, what did Vasily do - he convinced the CEO that for the sake of profit and stability of the business, everything should be written with 0, a new team, always under the web, and not a single byte from the old solution, although it would take 2 years. Given his reputation and career experience, it was not that difficult.Two years later, the decision was in prod. Fresh frameworks, MongoDB, DDD, work from the browser, not a single byte from the terminal for futures ... True, mountains of copy-paste, architecture that does not allow integrating algorithms without crutches, rewritten from 0 modules, where the elegant algorithms from the futures workstation were replaced by tons of boilerplate code. Basil, however, raised his authority quite well. The optional workstation for a long time cited as an example to other managers. After a couple of years, Vasily still fell into disgrace, but that's another story.In total, the bottom line: Vasily figured out new technologies, inflated the staff, increasing its importance, and the business remained completely confident that it helped the business and once again fulfilled its promises.History 2. About the lead virgin Anton
Anton, in his 30s, loved learning new technologies and solving olympiad problems. He occupied an almost ideal place for his type, - was the lead maiden of the infrastructure team. Anton knew the specifications and the latest architectural trends very well. And Anton’s favorite intellectual challenge was to come up with the rationale for how hype technology would help the business, and where exactly it would be worth shoving it. In this he was supported by the architect, who was also not averse to probe the new rake with Anton's forehead. As a result, Anton was invited to talk with FAANG, where he went through the entire theoretical part without problems, and brilliantly completed the task of designing the Ebay architecture (although nothing of the kind was required in the previous work). Then he set sail in the USA, and left behind him 3 highly loaded modules in the prod, which now no one wants to maintain and develop,because no one understands how (and why) they work.Total, in the bottom line: Anton clearly knew what he wanted and came to his goal, taking the maximum from his employer. The business was also sure that Anton was a very valuable employee, because, as I already mentioned, he always carefully thought out the rationale, even when they were wild for people in the subject.The story of the architect Ivan
Timlid Ivan and Timlides Vladimir and Yuri sawed the product under the leadership of architect Sergey. Sergey brought all three of them to the company, and the four of them made key decisions. After the product went on sale in 4 years of operation, but was still far from stability, the leadership attacked Sergey and he left with his head held high. Following him, Vladimir and Yuri left.At one point, Ivan became the only bearer of knowledge about what was written (except for the senior and middle, whom Sergei did not particularly devote to the general vision). Feeling that it smells of fried, the leadership appointed Ivan as an architect with the corresponding staff in the hope that he would not leave. To which Ivan said, they say, this, of course, is good, but this is not enough so that I do not leave. If you want me to support what we saw with Sergey, then let me rewrite everything with 0. Business reluctantly agreed. Ivan received a salary, position, and the ability to write everything from 0 in one day.Total: Ivan correctly understood what the business problem was - the business is panicky afraid that what they saw during Sergey’s time may fail, and there’s no one to figure it out. And he pressed the business to the maximum.Total
Whether you want it or not, but for the sake of a career, $ and the opportunity to do things interesting for yourself, you will at least have to talk and think about business value. Yes, you can bring it, not bring it, or even bring the negative. But in this system of relations, the longer the value chain you control for the one who pays looks, the stronger will be the negotiating position and the ability to do what you want, rather than declare.