Learning in a World Where Programming Skills Aren't That Important
Learning in a World Where Programming Skills Aren't That Important
Want to work for Google? I admit that would be cool. But wouldn't be even cooler to be the dev that disrupted Google? To do that, you'll need more than CS knowledge.
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
Today's question is one I've gotten a LOT, but have struggled to answer. I didn't want to write on the subject until I had what I considered to be a coherent, defensible position. So I've pondered and stewed. And I think I'm finally ready to answer. Be warned, though. This post will probably be lengthy and, at times, a bitter pill. But I think it's important.
Here's the question, as a composite from all of you who have written me about it.
How will experience work, especially at the entry level, in the efficiencer world?
What on Earth is an Efficiencer?
A little background, for anyone who isn't up on the secret language of the DaedTech blog. Efficiencer is a neologism that I used to describe what I perceive as the more business-savvy, more autonomous software developer of tomorrow. I've written a number of posts about it, but I actually defined the term in my book, Developer Hegemony.
Briefly, efficiencers are different - more - than programmers. Programmers ingest specs and spit out source code. Efficiencers solve problems. To illustrate, consider the following.
- You go to a programmer and say, "I need an ASP MVC website that uses Entity Framework, .NET Core, and SQL Server on the backend." The programmer says, "sure, boss, give me the wireframes and I'll code it right up for you."
- You go to an efficiencer and say, "Right now our company takes all of our orders over the phone, and our website is purely ornamental. I don't know how this will work, but I know that we need the ability to take orders over a website, 24 hours a day to keep up with our competition." The efficiencer says, "I help businesses like yours automate their ordering process, so don't worry, I'll make sure your site not only competes with, but outperforms, those of your competitors."
Can you spot the difference? Can you tell which professional needs six layers of management and bosses in order to do anything useful, and which one IS the boss?
The Conundrum of Entry Level Efficiencers
The programming world of tomorrow is one in which we, as software developers, stop being the least important people in the software development industry. In my book, and in general, I propose a future in which efficiencer firms, structured like law firms, consist of efficiencers (professional automaters) who call the shots and delegate things like project management (status reporting and schedule coordinating) to subordinates, instead of superiors.
That has resonated with a lot of people. People like the vision in general, but it leaves a lot of folks wondering about the question that is the subject of this post.
What does entry-level efficiencer-hood look like?
The Efficiencer Career Plan in the Short to Medium Term
I won't bury the lede any further. I'll answer the reader question here, in this section. What will follow for probably thousands of words after that is an explanation and the pot-stirring controversy that I mentioned. You'll see why I need to explain further after reading the efficiencer career path.
- Skip a CS program, because that's not worth the investment anymore.
- Do whatever is necessary to get yourself an entry-level programming job (Boot camp, lateral transition, self-taught, whatever),
- Spend 2-4 years as a corporate programmer in a few jobs, where you get paid to learn programming. This is kind of like a doctor's residency: you're an actual programmer in the wild, but also a student.
- Quit your job and become an actual efficiencer because 2-4 years is plenty of time to become as good at the general skill of "programming" as anyone needs to be. After your employed residency, you should start to focus on your particular specialty and on growing your brand/career/business.
Alright, deep breaths. To channel emperor Palpatine, "I can feel your anger. It makes you stronger, gives you focus."
How can I possibly make this claim? 2-4 years of programming is barely enough not to make a mess, let alone to perfect this elusive craft. Am I out of my mind? Or maybe just an idiot?
An Interlude of Preemptive Defense
If you're a regular reader or someone who knows me, feel free to skip this section. If you're a new reader, I'll offer a bit of detail about my background.
Am I just an idiot, suffering from Dunning Kruger? Sure, for argument's sake, I'll identify as an idiot. But I'll push back a touch on Dunning Kruger. Here are some salient facts about me.
The Import (or Lack Thereof) of My Background
While I may be an idiot, I'm an idiot that is very, very clearly on the long side of the 2-4 years I'm talking about. So if you find yourself offended by the time and education I'm saying that you're wasting, think of how much more my own realization about this stuff offended me.
- The degrees were great, but I earned them a long time ago and the landscape has changed.
- My income has way more than doubled since I stopped working as a salaried programmer.
- I've found that teaching generalist programming is far more valuable than doing it.
- I turned down the job offered to me for acing the R-Tree interview in favor of something better.
- I quit the company for whom I wrote that directed, acyclic graph implementation, and they shuttered the whole product line (and went bankrupt) shortly after.
- These days, I have a pretty great lifestyle and a ton of autonomy.
I mention all of this only to demonstrate that I come neither from a position of sour grapes nor from one of armchair quarterback. I've lived the diminishing returns of the non-efficiencer path. But forget about me. Let's talk about Jill, instead.
Programming Skills Don't Matter to Your Pay
To bolster my hypothesis about diminishing marginal returns on programmer skill, let's consider a hypothetical programmer named Jill. Jill is a rock star. She's such a 10x programmer that she works at Google and makes the entire Google staff of 10x programmers look like 0.1x programmers.
I suppose this makes Jill a 1000x programmer. Yep, she's that good. She got tired of how clunky the git command line was, so she taught herself Mandarin and wrote a Linux shell in assembly language from scratch where every git command-arguments permutation was a single character. Jill learned every line from every episode of Star Trek and every Star Wars movie before she ever watched any of them. She IS the most interesting programming ninja in the world. And she works at Google.
Do you know what she does at Google? Well, she single-handedly keeps them ahead of all comers in web search speed. Her grasp of CS fundamentals, cache invalidation, asynchronous programming, distributed systems, and other things that make mortals shake in their boots ensures that nobody will ever gain a nanosecond on her in scaled search.
Do you know what this is worth to Google - an ace in the hole that ensures no fast follower will ever drink their search milkshake? Billions.
Do you know what they pay Jill to keep her on staff? Probably $200K per year.
I mean, they'd pay her more, but you know, there's the whole pay matrix and everything. You can't make too much more than your manager and all that. So she makes/saves them billions, and they pay her an extra $50k per year on top of $150K or whatever the average Google software engineer makes. Out at Mountain View Headquarters, that probably means she can upgrade from a studio apartment to a 1 bedroom.
Programming Skills Don't Matter to Your Company
I can imagine you seething with the injustice of it all for poor Jill. She makes Google billions and they give her an extra $50K per year. But, really, what should they pay her?
Should they pay her a million per year? If they really wanted to do this, they could find a way around the HR pay matrix. But doing so would alert her (and competitors like Microsoft) to her strategic importance. And she's an employed individual contributor, so giving it her all for asymmetrical reward is just kind of expected.
Of course, she's welcome to go off on her own. She could blast off out of Google and make a go of building her own search engine. Go for it, Jill.
Jill, who has spent her entire life convinced of the programming meritocracy and the value of the craft, could go off on her own (assuming a way around her non-compete). But then Jill's not a programmer anymore. She's, well... she's an efficiencer, specializing specifically in fast search techniques at scale. And her algorithm is worth precisely nothing until she can productize it, market it, secure funding for it, and then find a way into a market that Google sits astride like a malevolent colossus, supportive to Jill the Grunt, but ruthless against Jill the Competitor.
So, what is Jill's ninja-rock-x contribution really worth? In real, actual dollars? It's worth $50k per year if she's lucky.
Do you know why? Because being really, really good at programming in a vacuum just isn't valuable.
And Jill is a cartoonish hypothetical, 100x as good as anyone at Google, capable of single-handedly serving as the Einstein of search. My profile of Jill drastically overstates the case for programmer value. In the real world, Jill is a 1.00001x programmer compared to the next programmer in line behind her at Google, who is probably pretty good at programming.
Kidding Ourselves About Programming Skills
When I think of my programming career, I muse that I've learned more programming languages than I can probably recite off the top. I actually learned functional programming almost two decades ago, long before it was cool. So that means that I've encountered multiple languages from all three major programming paradigms.
At one time I convinced myself that this made me a great programmer. I started with C++ as my first language. Add to that a functional language called ML, Perl, PHP, C, C#, Java, Python, VB, and probably some stuff I can't remember, and I got REALLY well rounded. Taking in the peculiarities of significant whitespace, understanding type erasure and generics, weighing the pros and cons of multiple inheritance.... all of this was SUPER important. It made me a true, well rounded professional.
Or so I told myself.
That was what I told myself because humans like to write a narrative that values their own experience. Yep, without the insight from 10 programming languages, there's no way I could have written some miscellaneous line of business application. Oh, sure, I could have written it, but I wouldn't have crafted it. It would have been slightly harder to maintain and had a slightly higher cost of ownership. All of that was important, dammit!
Or so I told myself.
Diminishing Returns and Just Barely not Drowning
Does each programming language you learn make you a better-rounded programmer? Of course, it does. But here's a term to learn and hold onto for the rest of this post: diminishing marginal returns. We like to think that each marginal language/framework/etc. that we learn is important, but it really isn't in terms of growing our skills.
At least, it's not important in the way that we tell ourselves. How does it actually matter? Well, as long as you want to program, you have to drink from an endless fire hose of new languages or risk drowning.
As I mentioned, I entered the workforce knowing C++. But that wasn't the language of the emerging web in the enterprise, so I learned Java. And that was great until I took a job with a .NET shop, where I learned C#. Over the years, I picked up new languages, frameworks, and whatnot. I liked to think that I was doing so in pursuit of some higher goal of being a master generalist. But I was really just trying to keep current and thus stop companies from replacing me with someone fresh out of school and for half the money.
As we age in this industry, we find existential fright in the thought of replacement with "junior" developers or, worse, "offshore" developers. "A terrible idea!" we protest. "They will write terrible code whereas we, polyglot veterans, will write elegant code!" We spin the narrative of vast experience in many languages as a virtue so that employers will believe it. And so that we'll believe it ourselves.
But all of our years in all of these different languages aren't actually valuable. In reality, we're just having the same year or two of experience over and over again as we learn this year's language or framework anew.
The Actual Value of Programming Skills
If we stop for a breath at this point, I get that this seems depressing. But I want to be merciless in making my case for the way of the efficiencer and my claim that you only need 2-4 years or programming experience before you should start punching your dance card with experience other than generalist programming.
So let's really get brutal by using charts. Take a look at this mockup I created to illustrate the value of automation and programming.
Remember what I said about marginal returns? Here's what I think of, roughly, as marginal returns that the industry reaps on programming skills. Illustrated above, in red, we have the value a consumer of programming and automation realizes from any successful automation. I'm estimating that half of the value comes from any programming that makes it to market, however terribly written. Here's the split overall.
- The world realizes 50% of the value of programming from it just existing (red).
- You get up to 75% if that programming is decent (orange).
- Then up to 90% if that programming is good (yellow), which brings you into a highly maintainable territory.
- Call it 95% if that programming is great (green).
- And, finally, the last 5% to bring it up to 100%, comes from Jill (blue).
How do I arrive at these figures? It's inexact to be sure, but you can infer exponential proliferation of inexperienced developers writing code, as described by Uncle Bob. Half of all software is always being written by people with very little experience. And, in spite of this, software still gets written.
What does all of this mean? Well, it means that there is substantially more business opportunity in finding barely automated or non-automated things and getting them to decent than there is in anything else.
The Diminishing Value of Programming Skills
What I just outlined is a baseline. It's actually probably more skewed, and that's because of Agile software development.
Why? Well, Agile aims at de-risking app dev for the business. And what does de-risking entail? It means finding a way to help companies drawing from limited talent pools do more with, well, less talent. Agile development involves practices like pair programming, early feedback and inspection, collective code ownership, rigorous testing, continuous integration... In short, Agile involves assuming, finding, and correcting mediocrity.
If you look at the graph above, Agile shifts it. It commoditizes software development, letting people with less experience contribute meaningfully much earlier in their careers as fungible team members. We wind up with a new spectrum:
But agile has been around for a while, and we're on to newer and greater things. I'm not talking about "lean" and other project management fads, but rather more technically oriented movements. We've broken the barriers between development, deployment, and operations and called it DevOps. We've made ever greater strides in testing from the unit level on out to production. We do dark launches, have chaos monkeys test our stuff, and de-risk architecturally with microservices.
With every single one of these steps forward, we further commoditize app dev. We automate error detection, remediation, and analysis. We turn web/mobile development into paint-by-numbers activities on the whole, and we wind up with marginal returns that look more like this.
So to return to my efficiencer plan, think of it this way. The red and orange represent "we've completed it and it's somewhere between passable and decent." With 2-4 years of good, solid experience, you will reach or surpass this level of skill. You will then find yourself in the 95th percentile of value delivery, making you a 950x programmer to Jill's 1000x. Somewhere, a recruiter just swooned.
The Life of a Non-Efficiencer
Alright, time for a breath. I've made a case for the unimportance of marginal programming skills that depresses even me. But, really, it's not all bad. If you want to spend your career as an individual contributor software developer, because you really love writing code and learning new techs, you have a great life in store for you. Seriously.
Here's your career path, expressed in today's dollars.
- Start working as a software developer at $60K per year or whatever entry-level people make these days.
- Job hop enough that 5 years in, you're a senior developer making around $110K.
- Gradually earn a promotion to something like "principal developer" or "tech lead" or "architect" and top out at $150K, maybe.
- Spend the rest of your career crankin' code 9-5, drinking from the "new language per year" fire hose, and earning $150K per year while doing it.
That's a good life. I imagine that you're a one percenter as far as income goes across the globe, and you've realized an incredible life hack of receiving an incredible wage for doing your hobby (and yes, I'll call "perfecting your craft" as a generalist a hobby, but I'll get to that in a minute).
That's hard to beat and nothing to be ashamed of. Full stop.
But understand this fully for what it is. It's awesome, but it has a very specific and clear upper bound. You'll make a lot of money, but your opinion will never really matter, and you'll always have 8 different bosses, Bob. You'll always be the least important person in your field of software development because you'll be too busy chasing frameworks and techs to weigh in on why anyone pays for what you do. And, perhaps worst of all, look at the figure in the next section.
The Non-Efficiencer Career, Visualized
Let's say that you embark on a career as a programmer, resolving that you'll never sell out and go into management. And, of course, that you'll never go off on your own as an efficiencer, since you didn't know what that was until a few minutes ago.
Here's a visualization of your career. After 2-4 years, you'll get yourself up to about 95% of the value delivery capacity that you can offer as a generalist. Then, for the next 41 years, you'll fiddle, learn new frameworks, stay afloat, and tinker in the diminishing marginal returns area of that last 5% (unless, that is, you pull your hands off of the keyboard and start devoting more of your time to mentoring others. This is an example of the sort of specialties I alluded to for efficiencers).
In other words, you'll achieve 95% of your career's value in the first 10% of your career.
I often write about how stupid the interview process is at big tech companies. When interviewing potential Jills, Google (and any company like it) is looking to separate that tiny blue band from the tiny green one.
It might be sort of comical in the scheme of things if it didn't represent a more disturbing and value-destroying distraction. Much as you'll spend your career chasing the nearly meaningless green and blue bands, corporate interview processes seek (and fail) to distinguish between those bands.
But the actual distinction isn't the point. Rather, the point is convincing you that the distinction actually matters in the slightest.
The Destructiveness of the Programmer Skill Fetish
So if you spend your career in the green and yellow, you'll have a nice life. You'll enjoy yourself, and you'll get to call your hobby a "craft." And it truly is a hobby because you put more and more into it without getting anything monetary back. But you do it dutifully and pretend that getting slightly better at techs matters more than, say, learning just a little about business.
However, you'll also participate gamely in something unfortunate.
Companies that employ software developers deploy interview processes that are Google-esque in trying to separate the blue from the green (or the blue from everybody else). But as I illustrated earlier with Jill, that's actually not all that important to those companies. Someone in the green or even the yellow represents a serviceable stand-in for Jill, and interviews are actually useless for telling the color bands apart anyway. But that's not really the point.
The point is to convince you that the value distribution really has vast tracts of yellow, green, and blue, with only a tiny bit of red and orange. The point is to convince you that a career spent earning only cost of living increases and no actual promotions is worthwhile because you're getting better. And the point is to keep you completely distracted, improving in the tiny yellow/green/blue bands when, really, anyone from the red or orange with a modicum of business sense could capitalize on their programming skill and do far better on their own.
If Jill, the 1000x programmer, leaves Google and does even just the slightest bit of business savvy planning, she'll build a Google-killer. And then Google will have to buy her out for millions. It's a much better deal for them to distract her with the yellow/green/blue obsession. "Jill, you're FAR too valuable to worry about that business-y stuff. Just specialize in search, administer whiteboard trivia interviews, and take advantage of our staff of onsite masseurs. Leave the business stuff to us."
The Way of the Efficiencer
I intended all of that meaty explanation to justify my course of action for the aspiring efficiencer. Recall that efficiencers are interested in the business of automation, rather than in fetishizing command line syntax and frameworks.
So the efficiencer needs to get good enough at programming to automate without making a total mess, but not any better until a business situation demands improvement. Get too much better and you're in diminishing returns territory, getting paid to indulge a hobby rather than to have a career.
I say this from the efficiencer's chair. I still program to this day, and I love it. And I love getting better at it and learning new ways of doing it. I love the craft of it!
But it's been years since I let anyone pay me to program, let alone programmed for an hourly wage. Why? Because programming, for an efficiencer with my experience, is either (1) a pure hobby or (2) in pursuit of a non-salaried business interest (in my case, I do both).
So, if you're an aspiring efficiencer, follow the career path of a software developer right up to the point where somebody starts threatening to slap you with the ubiquitous "senior" title.
Take "senior" literally and assume that it does (and should) represent the twilight of your salaried programming career. When people get it into their head to 'promote' you to senior software engineer, that should signal to you that it's time to leave your residency and start your real career.
What Comes After Your Salaried Software Developer Training Wheels?
The questions I get concern the entry-level efficiencer only, but it's worth asking what happens next, after graduation from your residency. And it's also fair to wonder whether this is sustainable. After all, in Developer Hegemony, I do predict an exodus from wage programming.
The latter question is quicker to answer. This is a path for today's entry-level efficiencer, and it will be for the foreseeable future. Down the line, with far fewer wage gigs, it will look different, of course, but we can cross that bridge when we come to it.
So what does the efficiencer's life look like after earning the "senior software engineer" promotion and responding with, "wow, I'm flattered, thanks, and I quit!" To answer that, I'll close on an upbeat note. Frankly, your efficiencer professional life looks largely the way you want it to. And this can include getting better at highly technical concerns, provided they fit with your specialty and value proposition.
Remember the hypothetical efficiencer that helps automate ordering processes? Well, that efficiencer probably needs to learn a lot about cryptography and shopping cart APIs. For the specific kinds of consulting that I do, I build IP and research the finer points of static code analysis.
You can be extremely technical, and you can dig really deep into things. They just have to form part of your professional specialty or business. Learning your 15th MVC framework or burying yourself in CS coursework for interviews doesn't count. That's the generalist trap, and it's the sort of thing that gives you nearly zero meaningful return after a few years in the industry.
So, in the end, how do you become an efficiencer from the entry level? You learn enough about programming to automate things and enough about business to know why people pay you to automate those things. Then you specialize, figure out what skills actually matter for your clients, and you go out and help them.
Published at DZone with permission of Erik Dietrich , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.