每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，欢迎关注开源日报。交流QQ群：202790710；微博：https://weibo.com/openingsource；电报群 https://t.me/OpeningSourceOrg

今日推荐开源项目：《可爱即是正义 react-kawaii》传送门：GitHub链接

推荐理由：唯有可爱才是永恒不变的正义，这个项目就是一个应用于 React 中的可爱组件集合，它最大的特点就是使用了非常多的弧线和表情让组件看起来非常圆滑，兴许你在使用 React 创建这样可爱风格的页面的时候可以考虑一下这些组件。

表情和基础部件的组合：

今日推荐英文原文：《Programmers and Managers》作者：Maksim Solovjov

原文链接：https://medium.com/@maksimsolovjov/programmers-and-managers-868faa16d20f

推荐理由：介绍了一本看起来非常不起眼的书——Programmers and Managers

Programmers and Managers

I did not expect much from this book. I bought it in one of those antique-book-buying binges, and now I can’t even remember who recommended it to me. For three pounds it was a bargain anyway.

The previous owner was the Massachusetts Community College Library. The book had only one official reader: someone had to return it by the 6th of April, 1978.

From the very first pages, I realised that I’m in for something unusual. The author was an anthropologist. He became interested in programmers as they became widespread, some even moving into his neighbourhood. (The book shows its age in noting that many were women.) Despite the proliferation of the profession, nothing much was written about the work relationship between programmers and their managers. If the topic was mentioned at all in some management literature, the portrayal of programmers was usually not flattering. So the author decided to fill the gap.

Being an anthropologist, he studied each by observation, attempting to figure out what was really happening. That was hard. First, he identified that despite dozens of titles, he could partition all “software workers” into three groups: coders (technicians), programmers and analysts. Coders did least creative jobs, mostly just punching characters. Programmers worked on all aspects of writing a program, but in an organisation they could be further specialised. Their job, while more creative than that of coders, still involved a lot of routine. Analysts designed full systems and broke them into parts to be implemented by programmers. Their job was most loosely defined, since it often involved managerial and sales elements, and represented in microcosm internal conflicts present in many of the organisations.

He then spotted that, as a trend, this division mimicked class divisions present in other engineering jobs. (Implying America has social classes in 1970's is probably the most sure way to not get your book read…) Coders usually had little tertiary education. Programmers had vocational training from a community college. Analysts came from elite technical universities. This educational background correlated with the occupations of their parents. Generally, coders came from families of much more modest means compared to analysts.

This division was not incidental. Initially, programmers resembled medieval crafters much more than white-collar engineering workers. Much of the training was done via a master/apprentice model. There were not many tools for separation of labour; programming was a complex artisan endeavour. This meant that the programmer you hired had to be skilled enough to solve any problem they might encounter.

With the advent of structured programming and code modularisation, it became possible to split the work into parts of different complexity. You no longer had to maintain 5 highly-skilled specialists: one expert and 4 junior programmers would do. Much like in Adam Smith’s pin-making example, the latter team is also likely to be more productive overall.

The author’s narrative on structured programming jarred my programmer ears. To his credit, he goes into great pains to affirm that yes, both programmers in general and Dijkstra et al., who created the technique, in particular, they see structured programming simply as a tool to do their job better. And yet, from the managerial perspective, it is a tool for process control. Structured programming allows to de-skill and routinise the work overall, bringing it closer to a factory model.

I wish that was the only blow to my sense of self-importance… The author decided to investigate the real role of a programmer in an organisation. This was complicated by high salaries most programmers commanded, oftentimes placing them on-par with line-managers in terms of remuneration. However, the pay package came from the supply/demand imbalance, rather than essential status of the job within the organisation. For most organisations, a programmer was either a clerk — a person who does the job defined by a manager, or an engineer — a person hired by a manager to automate production process. Ultimately, the relationship was subservient.

While he was at it, the author reminded that twentieth-century engineers are not the same breed as nineteenth-century ones, who much more resembled modern day small businessmen and managers. At least the progress wasn’t kind across the board.

To rub some salt into my wounds, the author then went over techniques employed by managers to keep programmers happy and create a sense of career growth. From dual career ladders (where one can progress as an engineer or as a manager), out of which one is in practice always much shorter, to title changes without much difference in the essence of the work, to regular pay increments until you get fired — most of these are omnipresent in a modern software shop. In most of them, only managers get real career growth: they manage a team, then a product area, and then move to defining policies and no longer manage. The growth on the management ladder brings executive authority in allocating resources and pursuing business opportunities. The growth on the engineering ladder, once you are an analyst, at best brings more responsibility and accountability.

(The author observed that the growth from coder to a programmer to an analyst is, in practice, also elusive. Often there are educational barriers associated with a higher position, effectively confining coders to coding. Not something I’ve ever observed directly, given that throughout most of my career my coworkers had stellar academic credentials or even PhDs. Yet, I’ve witnessed people denied promotion due to lack of education in traditional factories, so it’s not hard to believe that this is the case in many workplaces that employ software workers too.)

Then there are tools for control. Chief of them is insisting on individualism and a perverse definition of “professionalism”. Individualism is routinely stressed in a workplace, for example, by insisting that pay information is private. Moreover, everyone is individually assessed. The fact that people square in their heads the belief in individual treatment with salary bands attests to incredible capacity of human mind for dealing with cognitive dissonance.

This individualism is especially useful in case someone gets fired. Individual performance implies individual responsibility in such matters, so as far as most employees are concerned, any unfair treatment is an individual matter to sort out between the manager and the employee. This is something which I, unfortunately, was a witness of.

The professionalism that is usually brought up is redefined to mean something else from what a real profession entails. A professional body is controlled by peers, who limit the entry into the field via certification. It is a descendant of a Medieval guild. That’s the exact opposite what an employer would want for software workers, since they are scarce as is. When the employers bring up the concept of “professionalism”, they usually mean doing what told without much fuss.

As I finished the book, I found myself in a state of mild shock. I wanted to argue with the writer, and yet I could not. There was no explicit judgement of these events: while the author liked programmers, he did not state that cost optimisation is bad and that routinisation of work should stop, for example. He merely stated that it is happening, and programmers should better be aware of it.

When I was in school, I made good money by building custom websites. Nowadays, creation of websites at that level is automated, routine, and doesn’t bring even a tenth of revenue it used to. Most people can do it themselves with a website builder. I never intended for this to be my profession, and moved on to more complex pastures. My skills became obsolete, but luckily for me, I no longer depended on them for living anyway.

Yet, how many of such transformations can one do in their life? The author wrote that programmer’s career is short (unfortunately, he did not elaborate too much on his rhetorical question whether it is skills or salary that becomes obsolete). I wanted to disagree, but then again, recently I was asked for the third time, after someone witnessed my work environment, whether anyone over thirty works in my office. While the answer is definitely yes, this made me think.

In a weird way, “Programmers and Managers” reminded me of the work of Thomas Malthus. He postulated that population growth is exponential while food growth is linear, and hence a catastrophe always comes to restore the balance between the population and resources. Just as he formulated this idea, industrial revolution kicked-in at full speed, and exponential productivity growth confined Malthusian world to the past. Yet, should the productivity growth stop, his reasoning might be relevant again.

Similarly, “Programmers and Managers” made a lot of negative predictions, which did not materialise over the years. Due to ever-growing demands on the complexity of systems we want to build, the modern programmer was not entirely reduced to an assembly worker. But just like our capacity for productivity growth is not a given, neither is this insatiable demand for novel things to automate. When you are a programmer, obsolescence is always around the corner.

Whether you are a programmer or a manager, I can’t recommend Philip Kraft’s “Programmers and Managers: The Routinization of Computer Programming in the United States” enough.

2018年12月8日：开源日报第275期

Programmers and Managers