The belt-color meritocracy

“Nothing under the sun is greater than education. By educating one person and sending him into the society of his generation, we make a contribution extending a hundred generations to come.” — Dr. Kano Jigoro, founder of judo.

Colored belts, in martial arts, are a relatively modern tradition, having begun in the late 19th century. It started informally, with the practice in which the teacher (sensei) would wear a black sash in contrast against the white uniform (gi) in order to identify himself. This was later formalized by Dr. Kano with a series of ranks, and by replacing the black sash (in addition to a white belt, holding the gi together) with a black belt. Beginners were assigned descending kyu ranks (traditionally, 6th to 1st) while advanced ranks were dan (from 1st up to 10th). At a dan rank, you earned the right to wear a black belt that would identify you, anywhere in the world, as a qualified teacher of the art. Contrary to popular opinion, a black belt doesn’t mean that you’ve fully mastered the sport. Shodan is taken, roughly, to mean “beginning master”. It means that, after years of work and training, you’ve arrived. There’s still a lot left to learn.

Over time, intermediate belt colors between white and black were introduced. Brown belts began to signify nearness to black-belt level mastery, and green belts signified strong progress. Over time, an upper-division white belt began to be recognized with a yellow belt, while upper-division green belts were recognized with blue or purple. While it’s far from standard, there seems to be a general understanding of belt colors, approximately, as following:

• White: beginner.
• Yellow: beginner, upper division.
• Green: intermediate.
• Purple: intermediate, upper division.
• Brown: advanced. Qualified to be senpai, roughly translated as “highly senior student”.
• Black: expert. Qualified to be sensei, or teacher.

Are these colored belts, and ranks, good for martial arts? There’s a lot of debate about them. Please note that martial arts are truly considered to be arts, in which knowledge and perfection of practice (rather than mere superiority of force) are core values. An 8th dan in judo doesn’t mean you’re the most vicious fighter out there (since you’re usually in your 60s when you get it; you are, while still formidable, probably not winning Olympic competitions) because that’s not the point. These belts qualify you as a teacher, not a fighter only. At that level, knowledge, dedication and service to the community are the guidelines of promotion.

Now, back to our regularly scheduled programming (pun intended)

Would colored belts (perhaps as a pure abstraction) make sense for programming? The idea seems nutty. How could we possibly define a rank system for ourselves as software engineers? I don’t know. I consider myself a 1.8-ish ikkyu (1-kyu; brown belt) at my current level of programmer development. At a typical pace, it takes 4-6 years to go from 1.8 to 2.0 (shodan); I’d like to do it in the next two or three. But we’ll see. Is there a scalable and universally applicable metric for programmer expertise assessment? I don’t know. 

To recap the 0.0-to-3.0 scale that I developed for assessing programmers, let me state the most important points:

• Level 1 represents additive contributions that produce some front-line business value, while level-2 contributions are multiplicative and infrastructural. Level-3 contributions are global multipliers, or multiplicative over multipliers. Lisps, for example, are languages designed to gift the “mere” programmer with full access to multiplicative power. The Lispier languages are radically powerful, to the point that corporate managers dread them. Level-2 programmers love Lisps and languages like Haskell, however; and level-3 programmers create them.
  
• X.0 represents 95% competence (the corporate standard for “manager doesn’t need to worry”) at level X. In other words, a 1.0 programmer will be able to complete 95% of additive tasks laid before him. The going assumption is that reliability is a logistic “S-curve” where a person’s 5% competent on tasks 1.0 levels higher, 50% at 0.5 above, and 95% at-level. So a 1.8 engineer like me is going to be about 85% competent at Level-2 work, meaning that I’d probably do a good job overall but you’d want light supervision (design review, stability analysis) if you were betting a company on my work.
• 1.0 is the threshold for typical corporate employability, and 2.0 is what we call a “10x programmer”; but the truth is that the actual difference in value creation is highly variable: 20x to 100x on green-field development, 3x to 5x in an accommodating corporate environment such as Google, and almost no gain in a less accommodating one.
• About 62% of self-described professional software engineers are above 1.0. Only about 1 percent exceed 2.0, which typically requires 10-20 years of high-quality experience. The median is only 1.1, and 1.4 is the 85th percentile.
• At least in part, the limiting factor that keeps most software engineers mediocre is the extreme rarity of high-quality work experience. Engineers between 1.5 and 1.9 are manager-equivalent in terms of their potential for impact, and 2.0+ are executive-equivalent (they can make or break a company). Unfortunately, our tendency toward multiplicative contribution leads us into direct conflict with “real” managers, who consider multiplicative effects their “turf”.

Programming– like a martial art or the board game Go, both being uncommonly introspective on the measurement of skill ad progress– is a field in which there’s a vast spectrum of skill. 2.0 is a clear candidate for shodan (1st dan). What does shodan mean? It means you’re excellent, and a beginner. You’re a beginner at being excellent. You’re now also, typically, a teacher, but that doesn’t mean you stop learning. In fact, while you can’t formally admit to this too often (lest they get cocky) you often learn as much from your students as they do from you. Multiplicative (level 2) programming contributions are fundamentally about teaching. When you build a Lisp macro or DSL that teaches people how to think properly about (and therefore solve) a problem, you are a teacher. If you don’t see it this way, you just don’t get the point of programming. It’s about instructing computers while teaching humans how the systems work.

In fact, I think there is a rough correlation between the 0.0 to 3.0 programmer competence scale and appropriate dan/kyu ranks, like so:

• 0.0 to 0.4: 8th kyu. Just getting started. Still needs help over minor compilation errors. Can’t do much without supervision.
• 0.5 to 0.7: 7th kyu. Understands the fundamental ideas behind programming, but still takes a lot of time to implement them.
• 0.8 to 0.9: 6th kyu. Reaching “professional-grade” competence but only viable in very junior roles with supervision. Typical for an average CS graduate.
• 1.0 to 1.1: 5th kyu. Genuine “white belt”. Starting to understand engineering rather than programming alone. Knows about production stability, maintenance, and code quality concerns. Can write 500+ line programs without supervision.
• 1.2 to 1.3: 4th kyu. Solidly good at additive programming tasks, and can learn whatever is needed to do most jobs, but not yet showing leadership or design sense. Capable but rarely efficient without superior leadership.
• 1.4 to 1.5: 3rd kyu. Developing a mature understanding of computer science, aesthetics, programming and engineering concerns, and the trade-offs involved in each. May or may not have come into functional programming (whose superiority depends on the domain; it is not, in high-performance domains, yet practical) but has a nuanced opinion on when it is appropriate and when not.
• 1.6 to 1.7: 2nd kyu. Shows consistent technical leadership. Given light supervision and permission to fail, can make multiplier-level contributions of high quality. An asset to pretty much any engineering organization, except for those that inhibit excellence (e.g. corporate rank cultures that enforce subordinacy and disempower engineers by design).
• 1.8 to 1.9: 1st kyu. Eminently capable. Spends most of his time on multiplier-type contributions and performs them well. Can be given a role equivalent to VP/Engineering in impact and will do it well.
• 2.0 to 2.1: 1st dan. She is consistently building high-quality assets and teaching others how to use them. These are transformative software engineers who don’t only make other engineers more productive (simple multiplierism) but actually make them better. Hire one, give her autonomy, and she will “10x” your whole company. Can be given a CTO-equivalent role.
• 2.2 to 2.3+: Higher dan ranks. Having not attained them, I can’t accurately describe them. I would estimate Rich Hickey as being at least a 2.6 for Clojure, as he built one of the best language communities out there, creating a beautiful language on top of an ugly but important/powerful ecosystem (Java), and for the shockingly high code quality of the product. (If you look into the guts of Clojure, you will forget to hate Java. That’s how good the code is!) However, I’m too far away from these levels (as of now) to have a clear vision of how to define them or what they look like.

Is formal recognition of programmer achievement through formalized ranks and colored belts necessary? Is it a good idea? Should we build up the infrastructure that can genuinely assess whether someone’s a “green belt engineer”, and direct that person toward purple, brown, and black? I used to think that this was a bad idea. Why? Well, to be blunt about it, I fucking hate the shit out of resume culture, and the reason I fucking hate it is that it’s an attempt to collate job titles, prestige of institutions, recommendations from credible people. and dates of employment into a distributed workplace social status that simply has no fucking right to exist. Personally, I don’t lie on my resume. While I have the career of a 26-year-old at almost 30 (thanks to panic disorder, bad startup choices, and a downright evil manager when I was at Google) I feel like I still have more to lose by lying than to gain. So I don’t. But I have no moral qualms about subverting that system and I encourage other people, in dire circumstances, to engage in “creative career repair” without hesitance. Now, job fraud (feigning a competency one does not have) is unacceptable, unethical, and generally considered to be illegal (it is fraud). That’s different, and it’s not what I’m talking about. Social status inflation, such as “playing with dates” to conceal unemployment, or improving a title, or even having a peer pose as manager during a reference check? Fair game, bitches. I basically consider the prestige-title-references-and-dates attempt to create a distributed workplace social status to be morally wrong, extortionate (insofar as it gives the manager to continue to fuck up a subordinate’s life even after they separate) and just plain fucking evil. Subverting it, diluting its credibility, and outright counterfeit in the effort to destroy it; all of these are, for lack of a better word, fucking awesome.

So I am very cynical about anything that might be used to create a distributed social status, because the idea just disgusts me on a visceral level. Ranking programmers (which is inherently subjective, no matter how good we are at the assessment) seems wrong to me. I have a natural aversion to the concept. I also just don’t want to do the work. I’d rather learn to program at a 2.0+ level, and then go off and do it, then spend years trying to figure out how to assess individuals in a scalable and fair way. Yeah, there might be a machine learning problem in there that I could enjoy; but ultimately, the hero who solves that problem is going to be focused mostly on people stuff. Yet, I am starting to think that there is no other alternative than to create an organization-independent ranking system for software engineers. Why? If we don’t rank ourselves in a smart way, then business assholes will step in and rank us anyway, and they’ll do a far shittier job of it. We know this to be true. We can’t deny it. We see it in corporate jobs on a daily basis.

A typical businessman can’t tell the difference between a 2.0 engineer and a 1.2 who’s great at selling his ideas. We tend to be angry at managers over this fact, and over the matter of what is supposed to be a meritocracy (the software industry) being one of the most politicized professional environments on earth; but when we denigrate them for their inability to understand what we do, we’re the ones being assholes. They police and measure us because we can’t police and measure ourselves.

So this may be a problem that we just need to solve. How does one get a black belt in programming? Most professional accreditations are based on churning out commodity professionals. We can’t take that approach, because under the best conditions it takes a decade to become a black belt/2.0+, and some people don’t even have the talent. This is a very hard problem, and I’m going to punt on it for now.

Brawlers and Expert Experts

Let’s peer, for a little while, into why Corporate Programming sucks so much. As far as I’m concerned, there are two categories of degeneracy that merit special attention: Brawlers and Expert Experts.

First I will focus on the Brawlers (also known as “rock stars” or “ninjas”). They write hideous code, and they brag about their long hours and their ability to program fast. There’s no art in what they do. They have only a superficial comprehension of the craft. They can’t be bothered to teach others what they are doing, and don’t have enough insight that would make them passable at it anyway. What they bring is a superhuman dedication to showing off, slogging through painful tasks, and kludging their way to something that works just enough to support a demo. They have no patience for the martial art of programming, and fight using brute strength.

Brawlers tend, in fact, to be a cut above the typical “5:01″ corporate programmers. Combine that with their evident will to be alpha males and you get something that looks like a great programmer to the stereotypical business douche. Brawlers tend to burn themselves out by 30, they’re almost always men, and they share the “deadlines is deadlines” mentality of over-eager 22-year-old investment banking “analysts”. There is no art in what they do, and what they build is brittle, but they can do it fast and they’re impressive to people who don’t understand programming.

Let’s think of corporate competition as a fight that lasts for five seconds, because power destroys a person’s attention span and most executives are like toddlers in that regard. In a three-minute fight, the judoka would defeat the brawler; but, in a 5-second fight, the brawler just looks more impressive. He’s going all out, posturing and spitting and throwing feint punches while the judoka seems passive and conservative with his energy (because he is conserving it, until the brawler makes a mistake, which won’t take long). A good brawler can demolish an untrained fighter in 5 seconds, but the judoka will hold his own for much longer, and the brawler will tire out.

With the beanbag coming in after 5 seconds, no one really lands a blow, as the judoka has avoided getting hit but the brawler hasn’t given enough of an opening for the judoka to execute a throw. Without a conclusive win or loss, victory is assessed by the people in chairs. However, the judges (businessmen, not programmers) don’t have a clue what the fuck they just watched, so they award the match to the brawler who “threw some really good punches” even though he failed to connect and would have been thrown to the ground had the fight lasted 5 seconds more.

Where are Brawlers on the engineer competence scale? It’s hard to say. In terms of exposure and knowledge they can be higher, but they tend to put so much of their energy and time into fights for dominance that the quality of their work is quite low: 1.0 at best. In terms of impressions, though, they seem to be “smart and gets things done” to their superiors. Managers tend to like Brawlers because of their brute-force dedication and unyielding willingness to shift blame, take credit, and kiss ass. Ultimately, the Brawler is the one who no longer wishes to be a programmer and wants to become more like an old-style “do as I say” manager who uses intimidation and extortion to get what he wants.

Brawlers are a real problem in VC-istan. If you don’t have a genuine 1.5+ engineer running your technical organization, they will often end up with all the power. The good news about these bastards (Brawlers) is that they burn themselves out. Unless they can rapidly cross the Effort Thermocline (the point at which jobs become easier and less accountable with increasing rank) by age 30, they lose the ability to put a coherent sentence together, and they just aren’t as good at fighting as they were in their prime.

The second category of toxicity is more long-lived. These are the people called Expert Beginners by Erik Dietrich, but I prefer to call them Expert Experts (“beginner” has too many positive and virtuous connotations, if one either takes a Zen approach, or notes that shodan means “beginner”). No, they’re not actual experts on anything aside from the social role of being an Expert. That’s part of the problem. Mediocrity wants to be something– an expert, a manager, a credible person. Excellence wants to do things– to create, to build, and to improve running operations.

The colored-belt metaphor doesn’t apply well to Brawlers, because even a 1.1 white belt could defeat a Brawler (in terms of doing superior work) were it not for the incompetence of the judges (non-technical businessmen) and the short duration of the fight. That’s more of an issue of attitude than capability, I’ve met some VC-istani Brawlers who would be capable of programming at a 1.4 level if they had the patience and actually cared about the quality of their work. It’s unclear what belt color applies; what is more clear is that they take their belts off because they don’t care.

Expert Experts, however, have a distinct level of competence that they reach, and rarely surpass, and it’s right around the 1.2 level: good enough to retain employment in software, not yet good enough to jeopardize it. They’re career yellow belts at 1.2-1.3. See, the 1.4-1.5 green belts have started exposing themselves to hard-to-master concepts like functional programming, concurrency and parallelism, code maintainability, and machine learning. These are hard; you can be 2.0+ and you’ll still have to do a lot of work to get any good at them. So, the green belts and higher tend to know how little they know. White belts similarly know that they’re beginners, but corporate programming tends to create an environment where yellow belts can perceive themselves to be masters of the craft.

Of course, there’s nothing wrong with being a yellow belt. I was a novice, then a white belt, then yellow and then green, at some point. (I hadn’t invented this metaphor yet, but you know what I mean.) The problem is when people get that yellow belt and assume they’re done. They start calling themselves expert early on and stop learning or questioning themselves; so after a 20-year career, have 18 years of experience in Being Experts! Worse yet, career yellow belts are so resistant to change that they never get new yellow belts, and time is not flattering to bright colors, so their belts tend to get a bit worn and dirty. Soot accumulates and they mistake it (as their non-technical superiors do, too) as a merit badge. “See! It’s dark-gray in spots! This must be what people mean when they talk about black belts!”

There’s a certain environment that fosters Expert Experts. People tend toward polarization of opinion surrounding IDEs but the truth is that they’re just tools. IDEs don’t kill code; people kill code. The evil is Corporate Programming. It’s not Java or .NET, but what I once called “Java Shop Politics“, and if I were to write essay now, I’d call it something else, since the evil is large, monolithic software and not a specific programming language. Effectively, it’s what happens when managers get together and decide that (a) programmers can’t be trusted with multiplicative work, so the goal becomes to build a corporate environment tailored toward mediocre adders (1.0 to 1.3) but with no use for superior skill, and (b) because there’s no use for 1.4+, green-belt and higher, levels of competence, it is useless to train people up to it; in fact, those who show it risk rejection because they are foreign. (Corporate environments don’t intentionally reject 1.4+ engineers, of course, but those tend to be the first targets of Brawlers.) It becomes a world in which software projects are large and staffed by gigantic teams of mediocre developers taking direct orders with low autonomy. It generates sloppy spaghetti code that would be unaffordable in its time cost were it not for the fact that no one is expected, by that point, to get anything done anyway.

Ultimately, someone still has to make architectural decisions, and that’s where the Expert Experts come in. The typical corporate environment is so stifling that 1.4+ engineers leave before they can accumulate the credibility and seniority that would enable them to make decisions. This leaves the Expert Experts to reign over the white-belted novices. “See this yellow belt? This means that I am the architect! I’ve got brown-gray ketchup stains on this thing that are older than you!”

Connecting the Dots

It goes without saying that there are very few shodan-level programmers. I’d be surprised if there are more than 15,000 of them in the United States. Why? What makes advancement to that level so rare? Don’t get me wrong: it takes a lot of talent, but it doesn’t take so much talent as to exclude 99.995% of the population. Partly, it’s the scarcity of high-quality work. In our War on Stupid against the mediocrity of corporate programming, we often find that Stupid has taken a lot of territory. When Stupid wins, multiplicative engineering contributions become impossible, which means that everyone is siloized into get-it-done commodity work explicitly blessed by management, and everything else gets thrown out.

Brawlers, in their own toxic way, rebel against this mediocrity, because they recognize it as a losing arrangement they don’t want; if they continue as average programmers in such an environment, they’ll have mediocre compensation and social status. They want to be alpha males. (They’re almost always men.) Unfortunately, they combat it by taking an approach that involves externalized costs that are catastrophic in the long term. Yes, they work 90 hours per week and generate lots of code, and they quickly convince their bosses that they’re “indispensable”. Superficially, they seem to be outperforming their rivals– even the 1.4+ engineers who are taking their time to do things right.

Unfortunately, Brawlers tend to be the best programmers when it comes to corporate competition, even though their work is shitty. They’re usually promoted away from the externalized costs induced by their own sloppy practices could catch up with them. Over time, they get more and more architectural and multiplier-level responsibilities (at which they fail) and, at some point, they make the leap into real management, about which they complain-brag (“I don’t get to write any code anymore; I’m always in meetings with investors!”) while they secretly prefer it that way. The nice thing, for these sociopaths, about technology’s opacity in quality is that it brings the Effort Thermocline to be quite low in the people-management tier.

Managers in a large company, however, end up dealing with the legacy of the Brawlers and, even though blame has been shifted away from those who deserve it, they get a sense that engineers have “too much freedom”. It’s not sloppy practices that damaged the infrastructure; it’s engineer freedom in the abstract that did it. Alien technologies (often superior to corporate best practices) often get smeared, and so do branch offices. “The Boston office just had to go and fucking use Clojure. Does that even have IDE support?”

This is where Expert Experts come in. Unlike Brawlers, they aren’t inherently contemptible people– most Expert Experts are good people weakened by corporate mediocrity– but they’re expert at being mediocre. They’ve been yellow belts for decades and just know that green-belt levels of achievement aren’t possible. They’re professional naysayers. They’re actually pretty effective at defusing Brawlers, and that’s the scary bit. Their principled mediocrity and obstructionism (“I am the expert here, and I say it can’t be done”) actually serves a purpose!

Both Brawlers and Expert Experts are an attempt at managerial arrogation over a field (computer programming) that is utterly opaque to non-technical managers. Brawlers are the tough-culture variety who attempt to establish themselves as top performers by externalizing costs to the future and “the maintenance team” (which they intend never to be on). Expert Experts are their rank-culture counterparts who dress their mediocrity and lack of curiosity up as principled risk-aversion. So, we now understand how they differ and what their connection is.

Solve It!

I did not intend to do so when I started this essay, in which I only wanted to focus on programming, but I’ve actually come upon (at least) a better name for the solution to the MacLeod Organizational Problem: shodan culture. It involves the best of the guild and self-executive cultures. Soon, I’ll get to exactly what that means, and how it should work.