Stories about Software


The Polyglot’s Dilemma

Few things seem as institutional to the programming world as what I call the experience tuple.  A company needs to hire someone to automate something, so, naturally, it asks the software development group to make alphabet soup for dice.com.  “We need someone with (C#, XML, HTML, JS, ASP, MVC, REST, Angular, AJAX) with (React, MSTest, Moq, CSS) as plus.”  Presumably then, polyglot applicants stand a better chance.  But I’d argue that they also face something I’ll call the polyglot’s dilemma.

Hold on to your hats, programmers, because this will get counter-intuitive before it makes sense.  With that in mind… where to start?

Problem Solvers and Problem Transformers

Well, perhaps categorizing hired software developers as problems makes for a good start.  I don’t mean problems in a negative sense, but rather in the same vein as puzzles.  A business hires software developers for some broader purpose.  Maybe they work on internal automation that reduces operating expenses.  Or perhaps they produce software sold as a good or service and add to top line revenue.

In either case, the business implicitly says “I need help increasing our profitability.”  And you show up saying the following.

I have (8, 10, 10, 4, 6, 3, 1, 1, 0) years of (C#, XML, HTML, JS, ASP, MVC, REST, Angular, AJAX).  Now while the rest of you figure out how to make use of me, I’ll be over here sharpening the saw with some code katas.

Whenever I’ve had management responsibility, I’ve subconsciously put people into two buckets.  Problem solvers take a problem I have and make it go away.  Problem transformers take a problem I have and solve it by bringing me the next problem.  (I’m omitting non-performers who don’t solve problems at all as beyond the scope of this post.)

For instance, take the problem of a malfunctioning production server.  A problem solver would go off and come back with a functioning production server, somehow.  A problem transformer would come back, report that the problem was caused by a faulty power supply and ask what I wanted to do about that new problem.

As programmers, we behave as problem transformers.  We present ourselves and our skill sets as problems in need of management solutions.

Solving the Programmer Problem (Surface Version)

Alright, so let’s say that a programmer dutifully applies to an open position with a resume full of experience tuples.  And let’s also say that this results in a hire and an accepted offer.  That programmer can’t simply wander in and become useful by starting to write logging libraries.  Something else has to happen.

In corporate parlance, this programmer enters as a non-capitalized resource.  And, yes, I use the term resource deliberately here, in spite of the dehumanizing connotation.  In fact, that’s kinda the point.  Like a file cabinet or a data entry contractor, that’s the role we play when we enter an enterprise without any pretense of participating in said enterprise’s strategy.

Entering this way, we require two flavors of management in order to do anything useful.  Someone has to understand the intersection of tech and business strategy, and someone has to understand the intersection of tech and the organization’s domain.  Usually some combination of management flavors handles this: program managers, product managers, line managers, project managers, etc.  Sometimes an architect enters the fray as well.

Thus the enterprise divides itself.  Programmers bring the experience tuples.  Others bring strategic understanding of why those experience tuples matter to anyone.  And those others then solve the programmer problem.

Solving the Programmer Problem (Realpolitik Version)

Let’s take a different look now.  Recall my definition of the corporate hierarchy and also my definition of the journeyman idealist.  I elaborate extensively on these concepts in Developer Hegemonybut the definitions in the posts should suffice.

Inbound developers generally enter as pragmatists or journeyman idealists.  Both archetypes occupy the bottom of the corporate pyramid and both report to (mostly) idealists in management.  The actual stack ranking among the line level folks matters only to the line level folks.  They play stack ranking games with no actual organizational stakes in the grand scheme of things.

The idealists report to upper management, which consists entirely of opportunists.  The opportunists, the organization’s real strategic players, manage everyone.  Since they have relatively few direct reports, they manage the organization indirectly, using narrative and culture.  And so, in the context of zero sum, pyramid organizations, they create culture that feeds a narrative advantageous to the organization.

To put it more bluntly and tangibly, they get idealists (journeyman and regular) to believe that the company’s interests mirror their own.  And they get them to force that culture on pragmatists who don’t buy it, but don’t fight it.  The opportunists thus solve the programmer problem by creating a culture of maximizing the programmer’s value to the organization while caring not at all for the programmer’s market value or external prospects.  (An entirely rational thing to do, I might add.)

Solving the Programmer Problem (Applied Version)

For the sake of simplicity picture a custom app dev shop.  You see these either operating as so-called “consultancies” that build custom websites or else you see them within extremely large organizations, acting as internal agencies.  In either case, these organizations tend toward relatively flat pyramids and they sell margin on human labor.  This makes their political currents relatively straightforward.

Let’s say that I start just such a shop.  I take a business plan and some letters of intent to a bank, secure a business loan, and get some web developers on the payroll.  We do .NET, PHP, Ruby, or Java.  Bob’s your uncle.  Then I go and sell accordingly to organizations in need of web apps.

If I hire you to have on the payroll indefinitely, I have a vested interest in you having skills a mile wide and an inch deep.  I can gloss over the lack of depth during sales, but I can’t work with the lack of breadth.  If clients want us to augment their Ruby development organization’s staff, I can’t send them the foremost experts in a specific set of .NET technologies.  But I can send them relatively mediocre Ruby folks and collect margin without getting sued.

So what do I do?  Well, I seek to create a culture that places a high degree of value on generalizing.  I create a culture that values polyglots with experience tuples.  And I capitalize on hired programmers by deploying them interchangeably to as wide a client base as possible.  These programmers serve the company well, and I reward them with standard corporate COLAs and the occasional raise and “senior” added to their previous titles.

The Journeyman Idealist Culture Conduit

As a mechanism for creating this culture, I rely heavily on journeyman idealists, specifically.  In the programming world, programmers tend to look up to them, be they pragmatist or journeyman idealist.  So the key to manufacturing favorable culture lies in aligning journeyman idealist values with the company’s values.  This can prove harder than it sounds, since journeyman idealists tend to value “the craft” more than the company.

But in the case of generalizing and experience tuples, these interests align nicely.  You see, learning many programming languages and techs fluently — becoming a polyglot — makes you a better programmer.  And the journeyman idealist values this first and foremost.  So, if I run an agency, I enlist the journeyman idealists to sell experience tuple breadth as a virtue to all of the organization’s programmers.  Don’t learn a new language or two because I can sell your labor more easily.  Do it because it’s really in your own best interests!

Now, in our line of work, I actually don’t need to sell this particularly hard.  Journeyman idealists flow freely among organizations and cross-pollinate these concepts.  As a result, we have an entire industry that operates under the wrongheaded assumptions that programming skill translates directly to profit and that breadth across domain and tech makes for a good career strategy.  Or, I should say, we have an industry of pragmatists and journeyman idealists that operate under this assumption.  Opportunists know better.

Generalist Culture in Action

Watch this video by John Sonmez.  I went out looking for other voices to add to my own about the career merits of specialization.  John certainly agrees.  But I stumbled on this video, and it presents an absolutely perfect concretion of what I’ve talked about so far.

In it, a reader writes to John saying, in effect, “I like to generalize.”  He then cites his company’s apparent motto as the motivation for his own take: “we specialize in not specializing.”  That represents exactly the sort of thing that an opportunist translates from “this makes it easier to sell your labor” to “we have high-minded cultural principles that we ask all of our highly esteemed software engineers to live up to.”

That slogan practically drips with opportunist indirect management.  In our industry, we’ve been perversely encouraged to hold in the highest esteem the very approach that makes our labor and ourselves fungible commodities.  To put that in plainer terms, if we identify ourselves by the languages we use and we all strive to learn all of those languages, we become completely interchangeable.  And nothing suits my agency better than an army of interchangeable coders.  I can easily mix and match them, and I can also easily replace them.

When we aspire to generalizing as a key plank of professionalism, we maximize how a company can deploy us.  In other words, we make ourselves a textbook problem for strategic opportunists to solve.

The Polyglot’s Dilemma

So let me now come full circle to talk about the polyglot’s dilemma.  In the current world of software development, learning multiple languages and notching more and more techs makes for good business.  But it makes for good business in a perpetual subordinate, journeyman idealist context.  Generalizing, for the individual programmer, is a locally maximizing activity (and, I would argue, a tragedy of the commons situation for the industry, but that’s a topic for another day).

As you examine your own career prospects, you face the polyglot’s dilemma.  On the one hand, broadening and deepening your experience tuples means more interviews, more offers, and marginally better job situations.  It ensures that you remain relevant, sharp, and gainfully employed.  In our industry, it ensures high demand for your services.

But on the other hand, it ensures high demand for your services as a low-level resource and bit organizational player.  It ensures a permanent spot as pawn and not player in every game you enter.  And that’s because generalizing over the years and across the technologies isn’t strategic.  You’ve never figured out how to solve anyone’s actual business problems — you’ve only figured out how to make yourself a perpetually sharp saw for others to use.

The Case for Specialization, But Only If You Do It Right

I understand Xander from John’s video when it comes to specialization.  His thinking (I assume) goes something like, “I can get jobs if I introduce myself as a C# programmer, but not if I introduce myself as a C# programmer specializing in C# 6.0, specializing in Linq extension methods.  I want to remain a generalist.”

I see this misalignment of “specialist” definition a lot.  Forget about languages and frameworks.  Seriously.  C# or some subset thereof is not a specialty.  Recall my differentiation between problem solvers and problem transformers.  Specializing in technologies makes you a problem transformer.  You need to solve problems.

For Developer Hegemony, I interviewed a woman named Sally Lehman.  She caught my eye as an interesting person both due to an ability to secure work at non-traditional organizations and also as someone who managed to carve out a niche entirely within a corporate context.  She had three different full time roles that oriented around a specialization in email delivery, including one with Github.

Sally understood how to solve problems rather than transform them.  She has a legitimate specialty.  “I help organizations with email.”  Whether she chooses to maintain that, augment it, or even abandon it at some point, she nevertheless has it.

If someone from a company for which Sally very much wants to work bumps into her in an elevator, she can explain in a sentence or two how she could make a real impact.  Could you?  Or would you just start talking about how many “years of XML” you have?

Getting off of the Treadmill

Why does this matter?  Why does it prove advantageous?

If you’ve been at this a while, what I say here will really resonate.  You can easily think of your programming career as one of adding more and more language/framework/methodology/etc gunk to your resume, the way you collect Stack Overflow points and badges.  But, unlike Stack Overflow, the stuff you’ve done before expires.  For instance, I have a good bit of VB6, VBA, and some Perl under my belt.  But those techs increase my current marketability not a whit.

You can’t model our language learning as a walk forward.  You have to think of it as walking in the wrong direction against a treadmill as the landscape changes and makes our old knowledge archaic.  And if you measure your marketability and value to a company in terms of the techs you currently know, you’ll spend a career running the wrong way on a treadmill to keep up.  If you get stuck somewhere doing a Pascal project for 4 years, you might come up for air at the end only to find yourself unemployable.

But now imagine that you, like Sally, acquire a specific expertise.  Now you can sell yourself on the sorts of problems that you can solve for organizations instead of selling yourself on how easily they can deploy you as a fungible resource.  Of course you need to learn new things to keep up with your specialty.  But you control that learning and position yourself as an expert, instead of trying in exasperation to explain to some HR employee that you’ll have no problem picking up C# since you’ve spent a lot of years in Java and C++.

What’s the Takeaway

I always seem to generate the longest posts when I talk about office politics and techie careers.  Today presents no exception, and I feel acutely aware that I should wrap.  But I want to do so with a tangible takeaway.

I’m not disparaging companies or opportunists for encouraging a culture that makes developers swappable.  That’s just good business sense, and it mainly happens subconsciously.  I’m also not disparaging developers for complicity in this scheme.  It’s just the way business is done, so it wouldn’t occur to most people to contemplate an alternative.

But now that you see an alternative (I hope), start to contemplate it.  I encourage you to stop notching languages and frameworks as part of a Sisyphean spring against the motion of the treadmill.  Instead, take a critical look at what your company has you doing, and start trying to think in terms of the business problems you solve for them instead of the languages that you know.

From there, extrapolate to defining a career narrative wherein you’re the expert in solving some specific problem, like Sally.  This won’t pigeon hole you beause you need not always lead with it.  But it will make you expert in an area and give you a framework for solving, rather than transforming problems.  Experts have an easier time getting both contract and fulltime gigs, and they can also move fluidly into consultative or managerial roles.  Do this, and you’ll create many more career options for yourself, and you will escape the polyglot’s dilemma.

Want more content like this?

Sign up for my mailing list, and get about 10 posts' worth of content, excerpted from my latest book as a PDF. (Don't worry about signing up again -- the list is smart enough to keep each email only once.)

newest oldest most voted
Notify of

S’funny, I was thinking about this exact thing today. I don’t know what it’s like elsewhere, but in Australia, you *have* to go through an agency, virtually no-one hires directly. So, while yes, there’s a problem with employers issuing long lists of TLA’s as requirements, it’s even worse when you’re dealing with agents, since they have *no idea* what any of it means. I started work in the early 90’s, and back then, I sold myself as a “C++ guy, on Windows, I’ve worked with Oracle and Sybase”, and that was it! Nowadays, I’ve seen lots of JD’s with tuples… Read more »


I had someone asking me how many years of xml do I have? what do you answer? 10 years but since you ‘work on xml’ one day a year, it’s actually 10 days? 😉

Erik Dietrich

You should look at them with a totally straight face and say, “60 years of XML experience.”

Erik Dietrich

I’m with you on the non-sustainability of the current model. The tuple-matching, combined with assembly line interviewing produces a low probability matching scheme. This, in turn, adds to the overall churn of developers cycling in and out of companies rapidly. Philosophically, I think this process is so bad that you could just hire people totally at random and not do much worse. As I think about what I said here, I believe a follow-up post might be warranted. Your experience makes sense to me. If you go to some journeyman idealist that’s interviewing you (or worse, an agency recruiter) and… Read more »


Unsustainable it is, but I’m not sure if that, by itself, is going to be enough 🙂 From an agent’s point of view, the system is working perfectly – they present a bunch of candidates, the client picks “the best one”, mission accomplished, they get paid – so they’re not going to want to change anything. From the employer’s point of view (whether they use an agency or not), they see a bunch of candidates and, somehow, have to come up with a way of choosing one, but the dev landscape has become so badly fragmented that it’s difficult to… Read more »


Finding the right specialty is a challenge I’ve been trying to address in my own career. On the one hand, I don’t want to prematurely specialize in something that is going to become obsolete in 5 years, or is going to lead to potentially very unsatisfying kinds of work. On the other hand, I think the unfortunate reality is that older engineers have a harder time competing for undifferentiated, generalist positions. I’ve been trying to compile a list of strategies to help me strike the balance between over-specialization and undifferentiated generalization. Here’s what I have so far (while I’m not… Read more »

Erik Dietrich

I think that’s a lot of really good advice right there, FWIW. I especially like the quote, “don’t specialize in anything with a version number.”

I think one frequently overlooked way to specialize is at the intersection of domain and tech. For instance, something like “I help banks secure the data access layer of their web apps.” No real mention of any specific tech, and it ages well.


I’m glad you approve, part of my purpose in sharing is sanity-check my strategy. I also appreciate your point about business specialization. The business domains I’ve spent most of my time serving are in the Enterprise IT/Data Center market, so I try to follow news related to those subjects, and I interact somewhat regularly with domain experts at my job. I think including learning goals involving business domains is a good idea. Still, I feel like there are some potential risks. What if you specialize in CRM solutions for small businesses only to have Salesforce eat your lunch? Is the… Read more »

Erik Dietrich

I think there’s risk in any value proposition that you offer expiring, no matter what it is and no matter how specialized or general. For instance, “I’m a Pascal developer” is/was pretty general, and that’s not exactly a growth industry. Segmenting by domain or target market has similar risk as well — if you’d sold something to Atkins Diet participants, that’d have been great for a while and then died. So you always need to be prepared to evaluate your prospects and adjust to market changes. For instance, say you did specialize in building custom, lightweight CRM implementations and more… Read more »


You may be underestimating the ability of opportunists (and capitalism) to commoditize just about everything and everyone. Let’s say Sue, a peer of Sally, specializes in database performance. Like Sally, she has an easy time with her elevator pitch: “I make your database performance problems go away”, she says. And that is fine. But while IT is not lousy with credible db performance specialist as it is with, say, Java coders, they are not exactly a rara avis either: there is a whole underworld of db performance shops, either as one-(wo)man guru operations or small consultancies. So what’s a gal… Read more »

Erik Dietrich

It seems to me that’s less the fault/work of the C-suites of clients or employers and more an issue of the laborers failing to position themselves or establish a niche. In other words, if you’re in a given market where “database performance specialist” can be commoditized, then you need to differentiate yourself somehow to avoid being a commodity. I mean, the client could always throw a commodity generalist at a specialized problem, but if you’re a specialist and can show them that they’re better off hiring you, then they’ll bite.