{"id":655,"date":"2013-04-22T16:15:42","date_gmt":"2013-04-22T16:15:42","guid":{"rendered":"http:\/\/sasamat.xen.prgmr.com\/michaelochurch\/wp\/?p=655"},"modified":"2017-03-04T06:21:59","modified_gmt":"2017-03-04T06:21:59","slug":"the-shodan-programmer","status":"publish","type":"post","link":"https:\/\/sasamat.xen.prgmr.com\/michaelochurch\/wp\/?p=655","title":{"rendered":"The shodan programmer"},"content":{"rendered":"<p><strong>The belt-color meritocracy<\/strong><\/p>\n<p>&#8220;<i>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.<\/i>&#8221; &#8212; Dr. Kano Jigoro, founder of judo.<\/p>\n<p>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 (<em>sensei<\/em><em>)\u00a0<\/em>would wear a black sash in contrast against the white uniform (<em>gi<\/em>) 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\u00a0<em>kyu<\/em> ranks (traditionally, 6th to 1st) while advanced ranks were <i>dan<\/i> (from 1st up to 10th). At a <em>dan<\/em> 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&#8217;t mean that you&#8217;ve fully mastered the sport.\u00a0<em>Shodan<\/em> is taken, roughly, to mean &#8220;beginning master&#8221;. It means that, after years of work and training, you&#8217;ve arrived. There&#8217;s still a lot left to learn.<\/p>\n<p>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&#8217;s far from standard, there seems to be a general understanding of belt colors, approximately, as following:<\/p>\n<ul>\n<li><span style=\"color: #9999ff;\"><strong>White<\/strong><\/span>: beginner.<\/li>\n<li><span style=\"color: #cc9900;\"><strong>Yellow<\/strong><\/span>: beginner, upper division.<\/li>\n<li><span style=\"color: #009900;\"><strong>Green<\/strong><\/span>: intermediate.<\/li>\n<li><span style=\"color: #9900ff;\"><strong>Purple<\/strong><\/span>: intermediate, upper division.<\/li>\n<li><span style=\"color: brown;\"><strong>Brown<\/strong><\/span>: advanced. Qualified to be\u00a0<em>senpai<\/em>, roughly translated as &#8220;highly senior student&#8221;.<\/li>\n<li><strong>Black<\/strong>: expert. Qualified to be <em>sensei<\/em>, or teacher.<\/li>\n<\/ul>\n<p>Are these colored belts, and ranks, good for martial arts? There&#8217;s a lot of debate about them. Please note that martial arts\u00a0<em>are<\/em> truly considered to be arts, in which knowledge and perfection of practice (rather than mere superiority of force) are core values. An 8th <em>dan<\/em> in judo doesn&#8217;t mean you&#8217;re the most vicious fighter out there (since you&#8217;re usually in your 60s when you get it; you are, while still formidable, probably not winning Olympic competitions) because that&#8217;s not the point. These belts qualify you as a <em>teacher<\/em>, not a <em>fighter\u00a0<\/em>only. At that level, knowledge, dedication and service to the community are the guidelines of promotion.<\/p>\n<p><strong>Now, back to our regularly scheduled programming (pun intended)<\/strong><\/p>\n<p>Would colored belts (perhaps as a pure abstraction) make sense for\u00a0<em>programming<\/em>? The idea seems nutty. How could we\u00a0<em>possibly<\/em> define a rank system for ourselves as software engineers? I don&#8217;t know. I consider myself a <a href=\"http:\/\/michaelochurch.wordpress.com\/2012\/01\/26\/the-trajectory-of-a-software-engineer-and-where-it-all-goes-wrong\/\">1.8<\/a>-ish <em>ikkyu<\/em> (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 (<em>shodan<\/em>); I&#8217;d like to do it in the next two or three. But we&#8217;ll see. Is there a scalable and universally applicable metric for programmer expertise assessment? I don&#8217;t know.\u00a0<em><br \/>\n<\/em><\/p>\n<p>To recap the <a href=\"http:\/\/michaelochurch.wordpress.com\/2012\/01\/26\/the-trajectory-of-a-software-engineer-and-where-it-all-goes-wrong\/\">0.0-to-3.0<\/a> scale that I developed for assessing programmers, let me state the most important points:<\/p>\n<ul>\n<li><span style=\"line-height: 13px;\"><strong>Level 1 represents <em>additive<\/em> contributions that produce some front-line business value, while level-2 contributions are <em>multiplicative<\/em> and infrastructural.<\/strong>\u00a0Level-3 contributions are <em>global multipliers,<\/em> or\u00a0multiplicative over multipliers. Lisps, for example, are languages\u00a0<em>designed<\/em> to gift the &#8220;mere&#8221; programmer with\u00a0<em>full access to multiplicative power<\/em>. 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\u00a0<em>create<\/em> them.<br \/>\n<\/span><\/li>\n<li><strong>X.0 represents 95% competence (the corporate standard for &#8220;manager doesn&#8217;t need to worry&#8221;) at level X.<\/strong> 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 <a href=\"http:\/\/www.wolframalpha.com\/input\/?i=100+%2F+%281+%2B+exp%28-2+*+log%2819%29+*+%28x+%2B+0.5%29%29%29+from+x+%3D+-1.0+to+0.0\">logistic &#8220;S-curve&#8221;<\/a> where a person&#8217;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&#8217;d probably do a good job overall but you&#8217;d want light supervision (design review, stability analysis) if you were betting a company on my work.<\/li>\n<li><strong>1.0 is the threshold for typical corporate employability, and 2.0 is what we call a &#8220;10x programmer&#8221;<\/strong>; 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.<\/li>\n<li>About 62% of self-described professional software engineers are above 1.0. <strong>Only about <em>1 percent<\/em> exceed 2.0<\/strong>, which typically requires 10-20 years of <em>high-quality<\/em> experience. <strong>The median is only 1.1, and 1.4 is the 85th percentile.<\/strong><\/li>\n<li>At least in part, <strong>the limiting factor that keeps most software engineers mediocre is the extreme rarity of high-quality work experience.<\/strong> Engineers between 1.5 and 1.9 are manager-equivalent in terms of their potential for impact, and 2.0+ are <em>executive<\/em>-equivalent (they can make or break a company). Unfortunately, our tendency toward multiplicative contribution leads us into direct conflict with &#8220;real&#8221; managers, who consider multiplicative effects their &#8220;turf&#8221;.<\/li>\n<\/ul>\n<p>Programming&#8211; like a martial art or the board game <i>Go<\/i>, both being uncommonly introspective on the measurement of skill ad progress&#8211;\u00a0is a field in which there&#8217;s a\u00a0<em>vast<\/em> spectrum of skill. 2.0 is a clear candidate for\u00a0<em>shodan<\/em> (1st\u00a0<em>dan<\/em>).\u00a0What does shodan mean? It means you&#8217;re excellent, and a beginner. You&#8217;re a beginner at being excellent. You&#8217;re now also, typically, a teacher, but that doesn&#8217;t mean you stop learning. In fact, while you can&#8217;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\u00a0<em>are<\/em> 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\u00a0<em>are a teacher<\/em>. If you don&#8217;t see it this way, you just don&#8217;t get the point of programming. It&#8217;s about\u00a0<em>instructing<\/em> computers while\u00a0<em>teaching<\/em> humans how the systems work.<\/p>\n<p>In fact, I think there is a rough correlation between the 0.0 to 3.0 programmer competence scale and appropriate\u00a0<em>dan\/kyu<\/em> ranks, like so:<\/p>\n<ul>\n<li><span style=\"color: #666666;\"><strong>0.0 to 0.4:\u00a0<\/strong><\/span>8th\u00a0<em>kyu<\/em>. Just getting started. Still needs help over minor compilation errors. Can&#8217;t do much without supervision.<\/li>\n<li><span style=\"color: #999966;\"><strong>0.5 to 0.7:<\/strong><\/span> 7th\u00a0<em>kyu<\/em>. Understands the fundamental ideas behind programming, but still takes a lot of time to implement them.<\/li>\n<li><span style=\"color: #9999cc;\"><strong>0.8 to 0.9:<\/strong><\/span> 6th\u00a0<em>kyu<\/em>. Reaching &#8220;professional-grade&#8221; competence but only viable in very junior roles with supervision. Typical for an average CS graduate.<\/li>\n<li><span style=\"color: #9999ff;\"><strong>1.0 to 1.1:<\/strong><\/span> 5th\u00a0<em>kyu<\/em>. Genuine &#8220;white belt&#8221;. Starting to understand\u00a0<em>engineering<\/em> rather than programming alone. Knows about production stability, maintenance, and code quality concerns. Can write 500+ line programs without supervision.<\/li>\n<li><span style=\"color: #cc9900;\"><strong>1.2 to 1.3:<\/strong><\/span> 4th\u00a0<em>kyu<\/em>. 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.<\/li>\n<li><span style=\"color: #009900;\"><strong>1.4 to 1.5:<\/strong><\/span> 3rd\u00a0<em>kyu<\/em>. Developing a mature understanding of computer science, aesthetics, programming\u00a0<em>and<\/em> 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\u00a0<em>when<\/em> it is appropriate and when not.<\/li>\n<li><span style=\"color: #9900ff;\"><strong>1.6 to 1.7:<\/strong><\/span> 2nd\u00a0<em>kyu<\/em>. 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).<\/li>\n<li><span style=\"color: brown;\"><strong>1.8 to 1.9:<\/strong><\/span> 1st\u00a0<em>kyu<\/em>. 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.<\/li>\n<li><strong>2.0 to 2.1:<\/strong> 1st\u00a0<em>dan<\/em>. She is consistently building high-quality assets and teaching others how to use them. These are <em>transformative<\/em> software engineers who don&#8217;t only make other engineers\u00a0<em>more productive<\/em> (simple multiplierism) but actually make them\u00a0<em>better<\/em>. Hire one, give her autonomy, and she will &#8220;10x&#8221; your whole company. Can be given a CTO-equivalent role.<\/li>\n<li><strong>2.2 to 2.3+:<\/strong>\u00a0Higher\u00a0<em>dan<\/em> ranks. Having not attained them, I can&#8217;t accurately describe them. I would estimate Rich Hickey as being <em>at least<\/em> 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&#8217;s how good the code is!) However, I&#8217;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.<\/li>\n<\/ul>\n<p>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&#8217;s a &#8220;green belt engineer&#8221;, 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&#8217;s an attempt to collate job titles, prestige of institutions, recommendations from credible people. and dates of employment into a <em>distributed<\/em> workplace social status <em>that simply has no fucking right to exist<\/em>. Personally, I don&#8217;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 <em>evil<\/em> manager when I was at Google) I feel like I <em>still<\/em> have more to lose by lying than to gain. So I don&#8217;t. But I have no <em>moral<\/em> qualms about subverting that system and I encourage other people, in dire circumstances, to engage in &#8220;creative career repair&#8221; without hesitance. Now,\u00a0<em>job fraud<\/em> (feigning a competency one does not have) is unacceptable, unethical, and generally considered to be illegal (it <em>is<\/em>\u00a0fraud). That&#8217;s different, and it&#8217;s not what I&#8217;m talking about. <em>Social status inflation<\/em>, such as &#8220;playing with dates&#8221; 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&#8217;s life even <em>after<\/em> 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.<\/p>\n<p>So I am very cynical about <em>anything<\/em> 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&#8217;t want to do the work. I&#8217;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&#8217;t rank ourselves in a smart way, then business assholes will step in and rank us anyway, and they&#8217;ll do a far shittier job of it. We know this to be true. We can&#8217;t deny it. We see it in corporate jobs on a daily basis.<\/p>\n<p>A typical businessman can&#8217;t tell the difference between a 2.0 engineer and a 1.2 who&#8217;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 <em>one of the most politicized professional environments on earth<\/em>; but when we denigrate them for their inability to understand what we do, we&#8217;re the ones being assholes. They police and measure us because we can&#8217;t police and measure ourselves.<\/p>\n<p>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&#8217;t take that approach, because under the <em>best<\/em> conditions it takes a decade to become a black belt\/2.0+, and some people don&#8217;t even have the talent. This is a very hard problem, and I&#8217;m going to punt on it for now.<\/p>\n<p><strong>Brawlers and Expert Experts<\/strong><\/p>\n<p>Let&#8217;s peer, for a little while, into why Corporate Programming sucks so much. As far as I&#8217;m concerned, there are two categories of degeneracy that merit special attention: Brawlers and Expert Experts.<\/p>\n<p>First I will focus on the Brawlers (also known as &#8220;rock stars&#8221; or &#8220;ninjas&#8221;). They write hideous code, and they brag about their long hours and their ability to program\u00a0<em>fast<\/em>. There&#8217;s no art in what they do. They have only a superficial comprehension of the craft. They can&#8217;t be bothered to teach others what they are doing, and don&#8217;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\u00a0<em>just enough<\/em> to support a demo. They have no patience for the martial art of programming, and fight using brute strength.<\/p>\n<p>Brawlers tend, in fact, to be a cut above the typical &#8220;5:01&#8243; corporate programmers. Combine that with their evident will to be alpha males and you get something that\u00a0<em>looks like<\/em> a great programmer to the stereotypical business douche. Brawlers tend to burn themselves out by 30, they&#8217;re almost always men, and they share the &#8220;deadlines is deadlines&#8221; mentality of over-eager 22-year-old investment banking &#8220;analysts&#8221;. There is no art in what they do, and what they build is brittle, but they can do it\u00a0<em>fast<\/em> and they&#8217;re <i>impressive<\/i> to people who don&#8217;t understand programming.<\/p>\n<p>Let&#8217;s think of corporate competition as a fight that lasts for five seconds, because power destroys a person&#8217;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 <em>looks<\/em> more impressive. He&#8217;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&#8217;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.<\/p>\n<p>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&#8217;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&#8217;t have a clue what the fuck they just watched, so they award the match to the brawler who &#8220;threw some really good punches&#8221; even though he failed to connect and would have been thrown to the ground had the fight lasted 5 seconds more.<\/p>\n<p>Where are Brawlers on the engineer competence scale? It&#8217;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 &#8220;smart and gets things done&#8221; 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 &#8220;do as I say&#8221; manager who uses intimidation and extortion to get what he wants.<\/p>\n<p>Brawlers are a real problem in VC-istan. If you don&#8217;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 <a href=\"http:\/\/michaelochurch.wordpress.com\/2013\/02\/28\/gervais-macleod-5-interfaces-meritocracy-and-the-effort-thermocline\/\">Effort Thermocline<\/a>\u00a0(the point at which jobs become easier and less accountable with increasing rank)\u00a0by age 30, they lose the ability to put a coherent sentence together, and they just aren&#8217;t as good at fighting as they were in their prime.<\/p>\n<p>The second category of toxicity is more long-lived. These are the people called <a href=\"http:\/\/www.daedtech.com\/how-developers-stop-learning-rise-of-the-expert-beginner\">Expert Beginners<\/a> by Erik Dietrich, but I prefer to call them Expert Experts (&#8220;beginner&#8221; has too many positive and virtuous connotations, if one either takes a Zen approach, or notes that <em>shodan<\/em> means &#8220;beginner&#8221;). No, they&#8217;re not actual <em>experts<\/em> on anything aside from the social role of\u00a0<em>being<\/em> an Expert. That&#8217;s part of the problem. <a href=\"http:\/\/michaelochurch.wordpress.com\/2012\/12\/26\/careerism-breeds-mediocrity\/\">Mediocrity wants to\u00a0<em>be<\/em> something<\/a>&#8211; an expert, a manager, a credible person. Excellence wants to\u00a0<em>do<\/em> things&#8211; to create, to build, and to improve running operations.<\/p>\n<p>The colored-belt metaphor doesn&#8217;t apply well to Brawlers, because even a 1.1\u00a0<em>white<\/em> 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&#8217;s more of an issue of attitude than capability, I&#8217;ve met some VC-istani Brawlers who\u00a0<em>would<\/em> be capable of programming at a 1.4 level if they had the patience and actually cared about the quality of their work. It&#8217;s unclear what belt color applies; what is more clear is that they take their belts off because they don&#8217;t <i>care<\/i>.<\/p>\n<p>Expert Experts, however, have a distinct level of competence that they reach, and rarely surpass, and it&#8217;s right around the 1.2 level: good enough to retain employment in software, not yet good enough to jeopardize it. They&#8217;re <em>career yellow belts<\/em> at 1.2-1.3. See, the 1.4-1.5\u00a0green<em>\u00a0<\/em>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&#8217;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&#8217;re beginners, but corporate programming tends to create an environment where\u00a0<em>yellow<\/em> belts can perceive themselves to be masters of the craft.<\/p>\n<p>Of course, there&#8217;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&#8217;t invented this metaphor yet, but you know what I mean.) The problem is when people get that yellow belt and assume they&#8217;re done. They start calling themselves\u00a0<em>expert<\/em> 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. &#8220;See! It&#8217;s dark-gray in spots! This must be what people mean when they talk about black belts!&#8221;<\/p>\n<p>There&#8217;s a certain environment that fosters Expert Experts. People tend toward polarization of opinion surrounding <a href=\"http:\/\/michaelochurch.wordpress.com\/2013\/01\/09\/ide-culture-vs-unix-philosophy\/\">IDEs<\/a> but the truth is that they&#8217;re just tools. IDEs don&#8217;t kill code; people kill code. The evil is Corporate Programming. It&#8217;s not Java or .NET, but what I once called &#8220;<a href=\"http:\/\/michaelochurch.wordpress.com\/2012\/04\/13\/java-shop-politics\/\">Java Shop Politics<\/a>&#8220;, and if I were to write essay now, I&#8217;d call it something else, since the evil is large, monolithic software and not a specific programming language. Effectively, it&#8217;s what happens when managers get together and decide that (a) programmers can&#8217;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&#8217;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&#8217;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.<\/p>\n<p>Ultimately, someone still has to make architectural decisions, and that&#8217;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. &#8220;See this yellow belt? This means that\u00a0<em>I<\/em> am the architect! I&#8217;ve got brown-gray ketchup stains on this thing that are older than you!&#8221;<\/p>\n<p><strong>Connecting the Dots<\/strong><\/p>\n<p>It goes without saying that there are very few shodan-level programmers. I&#8217;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&#8217;t get me wrong: it takes a lot of talent, but it doesn&#8217;t take\u00a0<em>so<\/em><em> much<\/em> talent as to exclude 99.995% of the population. Partly, it&#8217;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.<\/p>\n<p>Brawlers, in their own toxic way, rebel against this mediocrity, because they recognize it as a losing arrangement they don&#8217;t want; if they continue as average programmers in such an environment, they&#8217;ll have mediocre compensation and social status. They want to be alpha males. (They&#8217;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 <em>lots<\/em> of code, and they quickly convince their bosses that they&#8217;re &#8220;indispensable&#8221;. Superficially, they seem to be outperforming their rivals&#8211; even the 1.4+ engineers who are taking their time to do things right.<\/p>\n<p>Unfortunately, Brawlers tend to be the <em>best<\/em> programmers when it comes to corporate competition, even though their work is shitty. They&#8217;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 <a href=\"http:\/\/www.daedtech.com\/complain-bragging-your-way-to-the-top\">complain-brag<\/a>\u00a0(&#8220;I don&#8217;t get to write <em>any<\/em> code anymore; I&#8217;m always in meetings with investors!&#8221;) while they secretly prefer it that way. The nice thing, for these sociopaths, about technology&#8217;s opacity in quality is that it brings the Effort Thermocline to be quite low in the people-management tier.<\/p>\n<p>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 &#8220;too much freedom&#8221;. It&#8217;s not sloppy practices that damaged the infrastructure; it&#8217;s engineer freedom <em>in the abstract<\/em> that did it. Alien technologies (often superior to corporate best practices) often get smeared, and so do branch offices. &#8220;The Boston office just had to go and fucking use <em>Clojure<\/em>. Does that even have IDE support?&#8221;<\/p>\n<p>This is where Expert Experts come in. Unlike Brawlers, they aren&#8217;t inherently contemptible people&#8211; most Expert Experts are good people weakened by corporate mediocrity&#8211; but they&#8217;re <em>expert<\/em> at being mediocre. They&#8217;ve been yellow belts for decades and just <em>know<\/em> that green-belt levels of achievement aren&#8217;t possible. They&#8217;re professional naysayers. They&#8217;re actually pretty effective at defusing Brawlers, and that&#8217;s the scary bit. Their principled mediocrity and obstructionism (&#8220;I am <em>the<\/em> expert here, and\u00a0<em>I<\/em> say it can&#8217;t be done&#8221;) actually serves a purpose!<\/p>\n<p>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 <a href=\"http:\/\/michaelochurch.wordpress.com\/2013\/02\/20\/1410\/\">tough-culture<\/a> variety who attempt to establish themselves as top performers by externalizing costs to the future and &#8220;the maintenance team&#8221; (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.<\/p>\n<p><strong>Solve It!<\/strong><\/p>\n<p>I did not intend to do so when I started this essay, in which I only wanted to focus on programming, but I&#8217;ve actually come upon (at least) a better name for the solution to the MacLeod Organizational Problem:\u00a0<i>shodan culture<\/i>. It involves the best of the guild and self-executive cultures. Soon, I&#8217;ll get to exactly what that means, and how it should work.<\/p>\n<p>  <a href=\"http:\/\/feeds.wordpress.com\/1.0\/gocomments\/michaelochurch.wordpress.com\/1695\/\" rel=\"nofollow\"><img decoding=\"async\" alt=\"\" border=\"0\" src=\"http:\/\/feeds.wordpress.com\/1.0\/comments\/michaelochurch.wordpress.com\/1695\/\" \/><\/a> <img loading=\"lazy\" decoding=\"async\" alt=\"\" border=\"0\" height=\"1\" src=\"http:\/\/stats.wordpress.com\/b.gif?host=michaelochurch.wordpress.com&#038;blog=12019234&#038;post=1695&#038;subd=michaelochurch&#038;ref=&#038;feed=1\" width=\"1\" \/><\/p>\n","protected":false},"excerpt":{"rendered":"<p>The belt-color meritocracy &#8220;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.&#8221; &#8212; Dr. Kano Jigoro, founder of judo. Colored belts, in martial arts, are a relatively modern tradition, having begun in the [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[21],"tags":[],"class_list":["post-655","post","type-post","status-publish","format-standard","hentry","category-apr-2013"],"_links":{"self":[{"href":"https:\/\/sasamat.xen.prgmr.com\/michaelochurch\/wp\/index.php?rest_route=\/wp\/v2\/posts\/655","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sasamat.xen.prgmr.com\/michaelochurch\/wp\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sasamat.xen.prgmr.com\/michaelochurch\/wp\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sasamat.xen.prgmr.com\/michaelochurch\/wp\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/sasamat.xen.prgmr.com\/michaelochurch\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=655"}],"version-history":[{"count":1,"href":"https:\/\/sasamat.xen.prgmr.com\/michaelochurch\/wp\/index.php?rest_route=\/wp\/v2\/posts\/655\/revisions"}],"predecessor-version":[{"id":656,"href":"https:\/\/sasamat.xen.prgmr.com\/michaelochurch\/wp\/index.php?rest_route=\/wp\/v2\/posts\/655\/revisions\/656"}],"wp:attachment":[{"href":"https:\/\/sasamat.xen.prgmr.com\/michaelochurch\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=655"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sasamat.xen.prgmr.com\/michaelochurch\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=655"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sasamat.xen.prgmr.com\/michaelochurch\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=655"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}