Why programmers fail to make money: Haskell's multidimensionality and never-ending burden

Original author: Michael O. Church
  • Transfer
I'll start the discussion with a very sad tweet from Chris Allen (@bitemyapp):
"I'm a little sad that some organizations are repeating the mantra" You can use haskell "to get sensible engineers cheaper."
- Untyped is unsane (@bitemyapp) June 3, 2014

For those who don’t know: Haskell is a productive and powerful language that allows programmers, at least talented, to write the correct code quickly. Compared to Java development, speed is 2–5 times faster with comparable performance and fewer errors. Chris rightly pointed out that a developer using Haskell most often does not get a decent reward. If you firmly decided to use functional programming, you will earn less than colleagues who rake the C ++ code bases in banks, accumulated over 30 years. Somehow it's all wrong. Why are economic sanctions applied to programmers using more powerful tools? Unlike managers who prioritize the benefits, programmers really want to do their job as best as possible.

From now on I will characterize this situation as a “Haskell burden." This burden is hardly due to the low cost of services or the greed of companies using Haskell. This is not the case. In my opinion, this is characteristic of the entire industry. The salary level of beginning programmers in 2014 is quite high, but at the same time, promotion and salary increase often do not correspond to the real increase in the value of the programmer for the business and even its actual costs (for example, housing costs, training, etc.). The most effective programmer’s weapon in the competition is his reputation. And to earn a reputation is more difficult for someone who concentrates on any one particular language. And this is not the fault of Haskell. There is almost certainly a similar burden for Clojure, Erlang or Scala.

In addition to programming languages, this applies to any factor that positively affects a career. In most cases, programmers quickly reach the peak of career growth, burying their talent, and employers are well aware of this. Therefore, work related to some interesting tasks, such as machine learning, new projects or advanced tools, is paid lower. This approach is usually not surprising for programmers, since everyone is sure that it is unpleasant work that should be paid better. This is a real disaster, the long-term effect of which is reflected not only in the career of programmers, but also in the industry as a whole. Market signals should increase the attractiveness of the most profitable investments, but in the software industry, the situation seems to be diametrically opposed. For work which promotes the career of a programmer, often pay unreasonably little. In addition, such tasks are usually distributed behind closed doors and jealously guarded, decisions are more political in nature, and the winner, as a rule, is forced to agree to unreasonably high costs.

What's wrong with the Haskell burden?

As already mentioned, the phenomenon that I called the “Haskell burden” is not unique to this language. It is common to all software related tasks, unless it is “ frying fish”". Therefore, a high-level specialist cannot count on a salary equivalent to his qualifications. However, constantly changing the vector of development, you will not become an expert in your field. This requires focus, determination and hard work. Specialization is needed, and any exceptions only confirm this rule. A professional with five years of experience can create 3–50 times more value for his company than the novice “errand boy”. But what additional benefits does an experienced employee get? Yes, almost none. The need to “keep fit” within the framework of their specialization (and to abandon tasks that are little related to it) weakens the position of such a professional. Over time, the available “work front” narrows significantly, which negatively affects the income of a specialist. On the other hand, when changing a specialty, a high-class professional goes into the category of newcomers to the competitive labor market, so he will also fail to reach the desired level of salary. So much for the vicious circle.

That is why the closed distribution has, in addition to moral, also economic aspects. This approach makes it impossible for the company to realize the lion's share of the potential value that its employees could create. In addition, this makes people less mobile, since they can switch to another job only if there is a predetermined role corresponding to their specialty. In the long run, this will result in a denial of the need to acquire expert knowledge, the skills of talented programmers will be unclaimed, and the industry as a whole will slide to the level of mediocrity.

Program for the rich and live with the poor. Program for the poor and live ... with the poor

Artists and writers like to repeat: “Sell to the mass consumer - you will live richly. Sell ​​to the rich - you will be among the mass consumers. ” This common expression refers not so much to social classes as to the low financial result of high-quality work. Poets earn much less than "Stakhanovists" who produce tons of base literature in record time. “Haskell's burden” is an extrapolation of this principle. Programmers who undertake only high-quality tasks (“program for the rich”) are likely to often sit idle or sell their services at a lower price.

Does this mean that every programmer should immerse himself in Java in two years, for example, and stop there? Is this approach optimal from an economic point of view? “Selling to the poor” means fulfilling boring and monotonous specialized tasks that a novice would do as well. Programmers who adhere to this tactic still live with the poor. Within the framework of such an approach to programming (highly specialized business logic) scaling is impossible. The volume and approaches to the work of the writer will not change, even if the number of "users" of his novel increases from 10 to 10 million people. Such scalability is not available to programmers, and projects that provide opportunities for scaling, growth and increase the return on labor costs are tasks “for the rich”, which any programmer willingly connects to (we have already discussed why such projects do not pay off). Therefore, adhering to the programming strategy for the masses, you will also quickly run into your ceiling, unless you dopolitical move and do not become a leader. But executives sell, not create, software products. These are ex-techies with established methods for managing and solving technical problems. Once these methods were true, but now they are outdated, so they are as far from optimum as non-techies are far from it.

In other words, from the programmer’s point of view, the problem of “poor” and “rich” will look like this: you can solve high-class tasks and completely surrender to the favor of employers, since there are few such problems, but you can do “consumer goods”, which practically does not scale. None of the two proposed routes will lead a programmer to buy their own home in San Francisco.


Perhaps the most interesting thing in a programmer's work is the variety of tasks to be solved. New technologies are emerging, and programmers must study them, even if employers who do not take the risk and adhere to the concept of anti-intellectualism will not pay for it. What does it take to become a good programmer? Thirty years ago, for this it was enough to master the C language and study approaches to developing the program structure. Five years ago, a software engineer had to know the basics of Linux and MySQL, several languages ​​(Python, Java, C ++, Shell), as well as compromise solutions. In 2014, the concept of " full stack”Has incorporated such a wide range of technologies that only a few own all of them. Andy Shora, the author of the essay at the link above, gives a beautiful definition for such unique people, calling them "macho-programmers all-in-one":

I understand why companies are desperate to hire professionals of this level. The fact is that really high-class specialists are often lost in the gray mass of under-educated people who think they know everything.

Thirty years ago, the linear ordering method was quite applicable to assess the programmer’s skill. An ideal portrait of a programmer of that time: a C compiler can write, has a concept of numerical stability, can master a new language or a manual platform. If you periodically needed help or your algorithms showed low efficiency, you were reasonably considered a beginner or a mediocre programmer. In 2014, everything is already far from the case. There is too much to know and be able to! For example, I have no idea how to create a visually appealing casual game. I’m on you with linear algebra, so I can cope with artificial intelligence and gameplay without much effort, but with the graphics and the final “refinement” everything will be much more complicated, because I do not see the fundamental difference between Candy Crush and almost the same ones. but much less successful games. Here you need a special user interface and user experience.

Linear ordering will no longer help you draw a portrait of a good programmer. Now it’s easier to say what the programmer is NOT doing. His field of activity has become N- dimensional. This is one of the reasons for the low tolerance for beginners, women, and simply sensible, but inexperienced beginners. The question of which of these measures is important and which is not is political and subjective; it does not have an exact, well-established answer. Today, those who do not know the scripting language will be losers. Tomorrow they will look askance at everyone who does not understand the JVM stuffing. Each company has its own standards, which are constantly changing, and our colleagues often not only do not know how good they areas programmers, but they also cannot understand by what criteria it is evaluated. It also explains the terrifying confusion surrounding software development requirements. For the most part, the "work" of a software company is aimed at its own definition of a "good programmer" and, accordingly, the selection of optimal tools.

I am not saying at all that multidimensionality is bad. On the contrary, this indicates the maturity and diversity of this field of activity. The problem is that we allowed anti-intellectuals and non-techies to leverage in their industry. They insist on the application of the linear ordering method to assess competence mainly for the sake of achieving their own mercantile goals. It is at the junction of mercantilism and multidimensionality that the main "pain points" arise.

In addition to everything, the fundamental hypocrisy of employers is observed, because of which it is terribly difficult for a programmer to plan his career growth. When hiring a programmer, the company requires that he clearly describe his specialization. If your specialization is vague and there are gaps in your track record, they won’t even talk to you. And after the candidate has become an employee, the company simply refusestake into account his specialization. If the programmer insists that some tasks do not fall within his competence, that is, he will also clearly define his specialization, as required by the employer at the very beginning, then he will be hanged with the label "he does not know how to work in a team." Engaged in machine learning for ten years? Great, but for now fix the legacy Rails code base. It would be funny if it were not so sad. Companies present unlimited requirements for employees, but do not provide them with the opportunity to accumulate the necessary experience. As a result, the choice is made for political reasons, or specialists in the field of self-PR “pop up”, but neither of them really knows how to program.

Haskell's Endless Burden

The Haskell Burden is not just a programming language problem. Any programmer who insists on his specialization significantly narrows his potential scope of work. He will not be able to achieve the desired level of income. As new specializations and dimensions emerge in the software industry, an increasing number of people are taking on the burden of Haskell. Today, Lord Business is introducing autonomous areas such as DevOps and Data Processing and Analysis, which, despite their positive intentions, work for our anti-intellectual colonizers and separate us from each other. Idea (absolutely true, by the way) that if a programmer is fluent in Haskell, he can become an excellent analyst or operating engineer, for some reason they are scared. They do not need a dynamic labor market. Lord Business has a strong dislike of specialization, when we defend our core competencies, he wants to make us interchangeable specialists of a wide profile (“full stack”). However, he himself does absolutely nothing to eliminate the confusion and isolation resulting from multidimensionality. These power-stupid idiots can afford at their discretionremove 90% of leading programmers from work based on superficial knowledge of the differences in technology. That is, they can control us, especially if the distribution of projects is closed to them. But more importantly, the size of our reward depends on them.

Here's how they managed to shoulder the burden of Haskell, which has no end in sight. If this is the market situation, then junior engineers can receive a relatively large salary. But the artificial obstacles associated with the closed distribution of tasks and the hypocrisy of employers force us to put up with inadequate specialization and separation, as a result of which practically no prospects remain for senior engineers. Engineers who create 10 times more value for the company than their younger colleagues can receive only 25% more. Moreover, they, according to Lord Business, should be glad that they are “given” real projects!

If we want to correct the current situation, then we must take a step forward and begin to independently manage our own affairs. We should call a spade a spade, responding to the hypocrisy of the Lord of Business, which requires a clear definition of specialization in hiring, but refuses to take it into account in the future. We must say our decisive “no” to the closed distribution of projects and the artificial deficit as a whole. Multidimensionality and specialization are good things in themselves (even very useful ones), but only with the proper level of management. We cannot entrust this task to the anti-intellectuals from the “colonial government”, who currently control the software industry and play against us at every opportunity. It is time to take matters into our own hands.

Also popular now: