Followup to “The seeds of its own destruction”

I want to expand on a recent email titled “The seeds of its own destruction”. The basic idea of that email was that the things that makes tech platforms better (better support, better libraries/frameworks, better documentation, better community) also erode the price premium early adopters can charge for their knowledge of that platform.

List member Mohan Embar wrote (shared with permission):

_Nice article. Hope you’re well.

> If your value proposition is currently limited to your technical skill only, I propose you change that.

Dunno. I’ve always been able to command a pretty penny for C++, especially when you start getting into older, arcane stuff like COM / MFC, etc. Not saying this is my only value proposition, but if I were looking for consulting work, I’m pretty sure I could snap my fingers and get a C++ gig and I’m not seeing new programmers flocking to this in droves. IMO, specialization can still work for solely a technical value proposition if:_

  • the technology is dying and arcane, but a few shops need to support that legacy code
  • it wouldn’t scale to have droves of new programmers flock to this old technology because there are newer, shinier things out there
  • you are content not to want to scale your business beyond the work that you or the handful of people you know that are proficient in this technology can find
  • this work provides an income stream that you’re satisfied with

Just my $0.02.

My response to Mohan’s excellent point:

_I think you’re right. I think something different happens when a platform reaches maturity (today’s article was more about the pre-maturity tech lifecycle). The platform stops being sexy and attractive to younger devs who really enjoy climbing new learning curves all the time, and so the supply of cheap eager people shrinks or dries up altogether, leaving a talent pool of more mature, seasoned devs who know their value and can negotiate more effectively based on that value. The nature of the work seems to shift as well, away from “move fast and break things” greenfield projects and towards supporting and extending legacy code that has massive business value but isn’t very exciting or shiny.

Is this consistent with your experience?_

And finally, Mohan’s reply to my reply:

Yeah – you totally nailed it. Also, C++ is objectively more difficult than newer languages like Java, C#, etc. where the libraries are much more extensive out-of-the-box and you don’t have to deal with freeing memory, etc. I’m an absolute expert in C++, but it’s definitely not the first thing I reach for when I develop anything from scratch because it’s an order of magnitude more cumbersome and laborious than other alternatives. The flip side of the coin, though, is that this legacy stuff is a goldmine for people that have expertise in this stuff, without an iota of anything else added to their value proposition, and I’ve yet to see any kind of course curriculum anywhere which trains new people on older technologies.

Thanks for letting me share your insightful reply, Mohan!