Tech Wars Any creative field undergoes periods of divergence and convergence, and technolo gy is no exception.

Right now, we re in the late swing of a divergent phase, with a plethora of new languages, frameworks, paradigms and methodologies so vast tha t it s impossible, at this point, even to know a respectable fraction of them. The re are back-end programmers who know nothing of Javascript, and front-end guys who ve never used a profiler. That will end, as people grow tired of having to learn a new technology stack with every job change, and also as the dimensionality of th e bilateral matching problem between engineers and employers becomes intolerable . As painful as convergence can be, such a time will come out of necessity. For a single company, convergence is often enforced internally, with approved too ls lists and style guides. Often the communication that drives these decisions ta kes a familiar form: flame wars. These partisan fights are common in technology. There s one set of programmers who believe Java is the only language that has a right to exist and that, if you re n ot using an IDE, you re using stone tools . There s another contingent that thinks ever ything should be written in Ruby, because that s what Rails is in and why do we ne ed another goddamn language? There s a third that s fixated on C++ on the basis that , if you can t manage memory, how can you make sure an application performs? For n ow, I don t care who s right in this really, that depends on the problem, because the re clearly isn t one language to rule them all and language or style comparisons are not what I care to discuss today. I think we can all agree these flame wars are stupid and counterproductive. Do tabs/spaces debates really require long email c hains? No, they don t. This, if anything, is the thing I dislike second-most about programmers. The wor st thing about programmers is that most of them (although this is a largely a pr oduct of a corporate environment that rewards mediocrity) lack taste and curiosi ty, and therefore never become competent. The second-worst is that, among those who have taste, most of the heated debates come down to superficial nonsense. Ye s, code quality matters. It s critically important; it can make or wreck a company . Cosmetic differences, on the other hand, are just not that important or intere sting. Tooling choices are important, but rarely as critical as opinionated engi neers make them out to be, in the sense that they re rarely existential matters fo r the company. Closed allocation is cultural death, and unethical management wil l ruin your startup, but the difference between Python and Scala is unlikely to be lethal. Can you write performant systems using mostly Python? Of course. Can high-quality, attractive code be written using an inelegant language like C++? Y es, it can. I have strong preferences regarding languages, but I ve learned over t he years not to take them too seriously. More dangerous than picking a suboptima l language is not getting any work done because of partisan bickering. Language and tool wars are an outgrowth of a careerist idiocy that one would exp ect software engineers to be above. Engineers engage in this hyperbolic mudsling ing because their career needs, in a typical corporate power struggle, often nec essitate some control over the technical environment and that s often a zero-sum sq uabble. The software industry isn t a real meritocracy, but it insists on looking like one, so the object of the game is to convince the team to use the tools wit h which one is most familiar, in order to become (because of tool fit, not intri nsic superiority) the most productive. This is the problem with technology in th e late-autumn phase of a divergent spell: an engineer s job performance is going t o be more of a function of his match with the work environment and tools than of his overall competence, so there s an enormous incentive to change the game if on e can. There s more individual gain in changing existing technical choices than gr inding away at regular work. Most software engineers have learned this, and I ca n t count on one hand the number of times I ve seen a company go through a scorchedearth code rewrite because some douchebag managerial favorite only knew one lang

uage, and (of course) that language became the only possible option for the firm . This is terrible for the company that has to reinvent all of its technical ass ets, but beneficial to the favorite who naturally becomes the master of the new technical universe. In a world of tight deadlines, short employment stints, and extremely detailed j ob requirements, this is only getting worse. It s no longer acceptable to spend mo nths in a ramp up period on a new job. It won t get a person fired, but you re unlikel y to get the best projects if you don t blow someone away in your first 3 months. So you need to find or carve out a niche where you can use tools you already kno w, in order to get some macroscopic achievement (a launch ) as soon as possible. Th is forces companies into one of two undesirable alternatives. The first (sprawli ng divergence) is to let everyone use the tools they like, and the predictable r esult is siloization as engineers stick to the tools they already know how to use, rather than take the time to understand what other people are doing. Taking the se systems into production and supporting them becomes a nightmare, because they often have 7 different NoSQL databases to support what s essentially a CRUD app. The other (enforced convergence) is to require certain uniformity in development . The company becomes an X Shop for some specific language (or database, or method ology) X. That s when the flame wars begin, because everyone is going to have an e normous stake in the choice of X. Now, it s not enough for X to be the best tool f or your project; you have to shove X down other peoples throats in the company, o r you won t be able to use it at all. This also falls down as necessity requires e xceptions to the uniformity requirements, and the decision of who can get an exc eption becomes immensely political. In truth, we as programmers are, in many companies, behaving like executives, sp ending more time arguing about how to do work than doing the actual work. This, I think, is the fall-down calamity of the software industry. It s why 50 per cent of people who are professional programmers won t be, seven years from now. So ftware engineering is all about improvement building things that didn t exist befor e, automating tedious processes and it s only natural that we want to improve ourse lves. In order to get better, one needs a reliable stream of increasingly high-q uality projects. What makes great software engineers extremely rare (and they ar e) isn t a lack of talent alone; the limiting factor is the paucity of quality wor k. At a certain point, one reaches a level where it s difficult to get quality wor k, even for a qualified (or overqualified) engineer. You end up spending more ti me convincing managers to give you good projects (playing politics, acquiring co ntrol of the division of labor) than you actually get to spend on the work. Peop le get enervated and drop out, or they become managers and lose touch with the d ay-to-day process of writing code. Tooling wars are one component of this nasty slog that programmers have to enter in order to have a shot at the best work. What s the solution? I mentioned the alternative to uniformity, which is the everyo ne uses whatever they want divergent approach that often generates an intolerable support burden. It can work, but it will fail in the typical hierarchical corpo ration. When you have this proliferation of creativity and ideas, you need two t hings. First, there has to be a pruning process, because some of what is produce d won t be very good. Managers never get this right. Their decisions on what modul es to keep (and, thereby, force engineers to maintain and use) and which ones to burn will be based on political factors rather than code or product quality. Se cond, it requires extremely strong cross-hierarchical communication, because it requires that people begin to make technical choices based on the long-term bene fit of the group rather than short-term productivity in an attempt to acquire stat us. People who are building technical assets will need to actually give a damn a bout making their clients succeed, as opposed to the selfish, parochial goal of pleasing managers. You won t get this kind of communication and pay-it-forward att itude not as prevailing behaviors, rather than occasional serendipities endowed b y the comfortable in a closed-allocation company.

The open-allocation sociology is one in which there is cross-hierarchical collab oration because the conceptual hierarchy necessitated by the problem doesn t conge al into a rigid hierarchy of people. Because there s so much internal mobility, ot her teams are potential future teammates, and people will generally treat them w ell. What this means is that, while there will be divergence in the name of expl oration and creative license, people will also take care of the convergence task s, such as integrating their work with the rest of the company and teaching othe r teams how to use the assets they generate. For a contrast, the closed-allocation sociology is one in which people strive, i n the short term, for the image of superior productivity, in order to advance ra pidly into a role where they control the division of labor instead of being cont rolled by it. This encourages people to diverge carelessly, for the twin purpose s of (a) appearing highly productive and useful, and (b) creating personal secur ity by generating technical assets that, although management can be convinced of their importance through political means, become so opaque to use as to leave o ther teams beholden to their creator. Of course, this productivity is illusory, the reality being that costs are externalized to the rest of the company. The he avy-handed, managerial antidote is to mandate convergence, but that inducing bat tles regarding which technologies and approaches live and which die. The result are hyperbolic, counterproductive and fear-driven arguments that devolve into th e technical flame wars we all know and loathe. As long as we have hierarchical corporations and closed-allocation regimes where one must either control the division of labor or be controlled by it, we will h ave endless flame wars over even the smallest of technical choices. The stakes a re too high for them not to exist.