IT Meritocracy. Part 2: Less Programmers Making More.
Economic Perspective
Let’s skip the debate of Austrian vs. Keynesian economics i.e. whether one’s professional excellence (production) automatically sells and thus should be recognized and rewarded regardless of the customer demand.
IMHO there is a huge demand for next-generation (business process automation) software, albeit only noticeable after one stops thinking of reinventing Facebook or Snapchat. Compare some slick consumer product e.g. a smartwatch app to the grayish Win95 era application you use at work. If not an alphanumeric mainframe terminal — still seen at most auto dealerships and half of retail stores. Who cares, right? That ancient crap works. If every engineer used the same “good enough” logic, we’d have still walked around with brick phones and pagers.
Assuming your product is craved by the customers, what would your, programmer’s compensation primarily depend on? Right, the development costs. If you are stronger and smarter, than others, your output will be greater and thus the same or better product, comparable with your competitor offerings, will require a smaller team of experts like you.
Less people making more.
Doesn’t get any simpler, does it? That’s, in a nutshell, the economics: good for you (and me) and bad for tens (hundreds) of code monkeys you single-handedly replace, meaning several layers of staffing aka “bodyshop” middlemen taking the lion’s share of the abused outsourced code monkey “billing rate”, which is 25% lower at best than the stateside “slash-architect” level developer’s, if some didn’t know.
Teamwork posters look great at factories, burger shops, military recruitment centers, and all other minimum wage places. Seen any at doctor’s offices or law firms? Why our unique, highly creative, and for the most part comparably paid (for the skilled few, that remain) occupation is subject to that managerial BS?
Fewer (moving parts) is always better — not only from the reliability, but also the performance perspective. Recall the Golden Rule of Mechanics aka First Law of Thermodynamics: the one about energy. There are no magic software development tools to reduce the amount of work: project’s scope in terms of business rules, etc. Empowering fewer engineers to “pedal in a higher gear” brings the friction and other loss of good energy to the minimum.
But then someone’s loss is somebody else’s (recruiter’s, consulting shop’s, or even manager’s hired to lead a big team) profit, right? Speaking of the latter (managers), can one shrink his/her team by “motivating” fewer individuals to work harder? “Facilitating” smarter work? I am afraid the only way to facilitate performance is technical: inventing those higher-geared bicycles: the equipment well-paid pro athletes are trained to use 100% of to win races. I’ll talk about my “cycling tech” in depth in this series.
Moving on. Sorry to bring another economist: evil Karl Marx into this discussion. I am sure others came up with the same economic predictions around the same time if not before Marx, but he a) is undeniably best-known for looking at the civilization from the labor perspective, and b) was pushed down my throat in the middle and high school, so some of his logic stuck.
Why everyone on Earth has to work for living in the 21st Century? With all of Marx’s outrageous Utopian projections the one about the automation has come true, hasn’t it? He said, that after the robots free the mankind from tedious manual labor, the remaining occupations will be creative and rewarding. People would work just for fun. In a society w/o money, duh, where everything is free? Here we go: programming. Will the future look like a giant Google — minus the compensation? The food is free there. So are bikes — no need for a car. Technically no one needs a house either. You can sleep in one of them, pods.
The main Marxism flaw was the “communistic conscience”, which meant two things. First, a person would be happy with “reasonable” i.e. a bicycle instead of a car. It’s not even a CF road bike or full-suspension mountain one at Google. Alright, I’ll stop poking Google. Let’s focus on the more outrageous side of said “conscience”. With only creative jobs left, everyone was still expected to work (in a working class heaven, duh). Marx envisioned, that somehow: through genetic manipulation, magic education, etc. every person on Earth would become smart and artistic.
Guess, he needed another, modern day visionary, whose last name also consists of four letter and starts with “M”: Musk. If only Elon was 10 years older, born in the good old Soviet Union… I can vividly imagine the Red Square May Day parade. Red banners with “Marx + Musk = communism”. Robotize the Earth and leave it to the creative people, sending the rest to Mars.
I am against any discrimination: by IQ or skin color and accent, doesn’t matter. But with all due respect, let’s get our occupation rid of code monkeys. There is a limited number of true programmers on Earth, India included. It didn’t increase or decrease after the budget-conscious American CFOs “discovered India” (on a mass scale) in the early 2000s. The only thing, that changed, was matching capable engineers with projects in need of their expert skills. It affected my Indian geek brothers the most, burying them under millions of bodyshop-supplied “bodies” with unverifiable cookie-cutter resumes, the hiring channels are now flooded with.
Equipped with the right tools, which I’ll explain in this series, the limited worldwide community of programming experts is capable of delivering all of the software the world will need in the next couple of centuries, until the AI takes over. Let the few capable programmers do what they love and excel at, delivering the next-generation software, banks, insurance carriers, and hospitals suffocate w/o. More importantly, bring that technology to smaller businesses, that cannot afford an IT department or even five Salesforce developers — at “outsourced” $25/hr.
Learning Perspective
Everyone has a general idea how code monkeys look and act, but who are the experts? Matrix-inspired “enterprise architects”? Action movie geeks saving the world with a single terminal command? Typically “ls -al”, if you pause and look closer. MIT and CalTech PhDs? Kaggle leaders? Hackathon winners? Job seekers with the hottest abbreviations in their resumes? Or it is about recruiter-mandated “years of experience”?
Enough sarcasm. Google and Amazon have their criteria and tests: algorithmic interviews. I have mine: the portfolio of work. This is my biased and personal view of the industry. Take it for what it’s worth. In my world the only thing that separates a senior from a junior is the first six months on the very first job. Oh, and if you are wondering about the fifty shades in between, there is no such thing, as a “mid-level” software developer from the engineering perspective — the only one, that matters.
Unlike many other engineering specialties, that rely on centuries-old knowledge base, our occupation requires constant learning. The technology changes every year, not to mention it is so vast, one cannot possibly cram everything. We need to repeatedly research new things e.g. the best tools for the job, and “unlearn” anything irrelevant for the task at hand, freeing up the brain’s RAM.
Nothing is really forgotten. It can be refreshed in hours — yes, like riding a bike. I know, IT recruiters and the non-technical managers who write clueless “years of experience” job descriptions for recruiters would most certainly disagree. Take it from my 25 years in IT. Absolutely any of today’s programming concepts, techniques, or tools can be learned (to the expert level) in the matter of days.
The ability to learn on the spot is what separates seniors from juniors. If a junior developer doesn’t “learn to learn” within six months to a year, thus becoming senior, he/she remains junior for life, meaning negative performance: the constant investment of time to teach him/her new stuff and inevitable rework of the junior’s code.
Note, that learning is not limited to programming. A senior developer is always a generalist i.e. an expert in semi-technical e.g. UI design and non-technical fields like the business domain. Speaking of the latter, after months spent on coding the business rules and debugging them every programmer ends up knowing the customer’s business process better, than any user, whether it cramps one’s geek style or not. Why not embrace it? Why not talk to the customer directly — eliminating the business analyst, let alone the solution architect? Every “coder” is de-facto THE end architect making the actual decisions what tool/package to use and how (directly, with workarounds, et.). Programmers, that is experts, who should be doing 100% of world’s programming, don’t need vague architectural “guidance” and advice on what to use. Here we go again. Fewer professionals doing and earning more.
Everyone starts junior, helped by senior colleagues. Even paid nothing (interns), junior developers are the most expensive ones in a true software company e.g. a lean startup. They consume at least one senior developer’s precious time. Add the “CPU-switching” time, a senior developer needs to decompress from the intense task he/she is submerged in, clear some of his/her brain RAM, go and help, then recall what he/she was doing before that and submerge again. Last, but not least comes the clean up: fixing juniors’ mistakes, which can be quite costly.
I know, all of that sounds foreign to a typical non-technical (e.g. MBA) “manager”, wondering what’s the big deal of dropping something and helping another team member when he/she asks. Basic professional courtesy and positive attitude, right? A friendly smilie. Genuine concern about the coworker’s problem. Asking “Do you need help?” and “What can I help you with?” is easy. I am not being sarcastic. Just merely pointing out the difference between two jobs: projecting friendliness and actually helping — to solve some (technical) problem. Not to facilitate solving it. Not to mitigate the risks. To go and get something done. Any fellow geek would understand.
There is a drastic length difference between managerial and programming tasks. A typical manager deals with hour-long meetings and occasional phone calls. The task doesn’t last longer, than a meeting or call, and can be offloaded immediately after. Whether, despite all our efforts to “divide and conquer”, many programming tasks last for days, progressing from a fuzzy idea to the researched and refined vision — the point where any manager or “architect” would consider his/her job done, while it is only 1/3 complete for the programmer, faced with the actual coding (which will reveal more problems and require workarounds) and then testing/debugging. We don’t deliver documents of vision or “architecture”. We build working products.
Does that extreme focus and long attention span turn most senior developers into jerks? Are the stereotypes true? Are all of us introverts and “lone wolves”? Not really. Let’s speak the managerial language: team effort and teamwork. Man-hour consulting and bodyshops aside, a software development team doesn’t just mindlessly type code and log hours. It works according to the schedule, where one member’s output feeds another one’s task. Sorry for being Captain Obvious. Everyone is familiar with Gantt diagrams, right?
Yes, the estimates are approximate (getting more accurate as the project goes along), and yes, there are unforeseen circumstances. However out of those, the last thing a senior developer expects is his junior colleague completely blowing his/her task, others depend on. Now, one can of course try to give juniors only the simplest self-contained tasks, but what would they learn doing those? Not to mention it wouldn’t be a very robust teamwork, would it?
Unlike headcount-centric realization of IT department budgets and “funded” startup vaporware, there are no “simple” tasks in real-life projects, lead by experts, who eliminate low-level coding through software development automation. A tough dilemma, huh? No “learning” tasks. Only the real ones, tightly woven into the project’s schedule. Meaning inevitable beginner screw-ups. Any of us have said it at least once: “I would have done your sh-t from scratch 100 times faster”.
You spend two hours (or days) patiently teaching a junior how do implement a certain feature, watch him screw up, and spend four hours/days fixing his crap by completely rewriting the code, because you cannot move forward with your tasks until the failed one is complete. Then you spend another two hours on the code walk-through comparing your code with the junior’s, so he/she can realize all of the mistakes, hopefully remembering the lesson. Add a couple of hours of “CPU-switching” and investigating what went wrong after it was reported “almost” working. Vs. just spending the four hours to do it yourself. You know the answer: not enough hours in the day to write everyone’s code.
Do they teach how to solve problems like these in business schools or at least (sorry for sarcasm) PMI institute? It’s a technical issue, isn’t it? Does it make “management” an engineering activity? Undoubtedly in my world — another skill a generalist can pick up in addition to (adequate e.g. “admin theme” based) UI design, business analysis, and “architecture”. Sales? No. Geek brains are wired differently. For starters, we talk in boring long sentences, trying to communicate the complete unbreakable piece of logic — instead of projecting positive emotions, pausing, and judging the customer’s emotional response.
The math above seems pretty logical, doesn’t it? 2 + 4 + 2 + 2 hours vs. 4 hours — meaning the 6 hours invested in teaching the junior — hoping that he/she won’t make the same mistake again. The main measure of a junior developer performance is not the tasks he/she successfully completes. The last line of defense: his/her mentor is prepared to rewrite that code anyway. It is about how fast and well the junior learns. Not to code. Leave algorithmic excellence to Mr. Cormen and his hiring zealots at Google. It is learning to learn i.e. look for the information in the right places, so the junior developer won’t need anyone pointing at them again in a few months.
Who came up with the term “junior” anyway? There are no juniors and seniors, only future seniors and current ones. People capable of programming — the Earth has a limited supply of. There are no “coders” let alone “offshore” code monkeys with unverifiable education, skills, and work experience. What’d coders do in a tight project — led by experts, that eliminated all of the boilerplate “coding” e.g. DAOs and DTOs in Java?
In other words there are two groups in IT: the programmers, who write working software by doing whatever it takes (business analysis, UI design, architecture, and last, but not least “management”), and bodyshop-supplied “bodies” who don’t write working code, but log hours and earn the staffing middlemen their margins.
How Much Is Fair?
What is a fair compensation cap for the “select few”? Pre-outsourcing wages: 1990’s $90/hr ($180K) and 2000’s $125/hr ($250K), which, adjusted for inflation, is $180/hr ($360K) in 2018? Apparently that’s the math Google used. Did top-paid developers deliver real products/services in 1990 and 2000? Or they didn’t do anything special beyond the glue code and bug fixing, simply leveraging the general shortage of programmers to negotiate their compensation? “Good question”, huh?
The next one is even better. What happens after the developer reaches his/her cap e.g. at my startup? Unthinkable for many (IT leaders), I let my top employees go. Well, not exactly. I help them found their own startups — taking my cut of course. Why would I cap someone’s growth? It’s not charity or camaraderie. It’s business. Everyone wins. Primarily the customers.
Otherwise it’s a very simple math (for an established project): five developers making $200/hr ($400K) each: directly of course, as experts don’t want to, and in fact are never found by recruiters to begin with. That’s $2M in labor costs. The alternative — a typical “IT organization”? Using the most common 80/20 rule, it’s 80 code monkeys at e.g. the lowest bodyshop rate of $20/hr ($3.2M) plus the 20 mediocre, but not completely illiterate “developers-slash-architects” tasked with the clean-up — at the recruiter’s $150/hr ($6M), only half of which actually goes to the developer.
I know, I know. You spotted an unsubstantiated claim of five developers replacing a 100. Spoiler alert: my software development platform is called Px100 aka Productivity x100. I can single-handedly replace a 100-dev (80+20) team. It’s not rocket science. Just the right technology — to write less code and “pedal in a higher gear”: explained here.
