Comment by michaelochurch | Hacker News Reader

Comment by michaelochurch | Hacker News Reader

We're smack in the middle of an uncanny valley between two economic periods. The industrial era gave everyone a mediocre income through repetitive work. The technological era brings much more income volatility and (when it reaches maturity, probably late in this century) will inevitably require a Basic Income. It's about concavity versus convexity: http://michaelochurch.wordpress.com/2013/03/14/gervais-macle...

Concave work is that where the difference between top-notch stuff and mediocrity is small-- maybe 1.2x or 1.5x. Convex work means that excellence is so far superior over mediocrity (10x, maybe more) that mediocre work has almost no value.

What we do is convex because we automate all the concave processes. If the work can be commoditized, a good programmer will automate it away. That leaves the hard, creative stuff. So we have a convex input-output profile. That's part of the fun-- you can add 20% more value by being just a little better-- but it's also pretty terrifying to realize how close we are to a "natural" celebrity economy where a few stars are extremely well-paid and most get nothing.

We, however, have a few things that play differently. First, no one except a superior programmer (who become rare as one moves along) can evaluate us. Most CEOs are not only in the dark themselves, but unable to evaluate a CTO, who's unable to evaluate VP/Eng, who's unable to evaluate programmers. It's a classic Design Paradox. I think it's pretty random whether a non-technical CEO gets a decent CTO. Second, even we are in the dark about what makes a great programmer. Is it talent, or experience? Obviously, it's a mix of both... but the rarity of great programmers suggests that either few have the talent, or quality work experience is thin on the ground. We're unlike most people in the corporate world in that we deeply want to get better at our jobs (independent of being more rewarded) and yet the path to that is very opaque. How do you become a great programmer? Get great projects. How does one do that? It's not easy.

The complete opacity of programmer skill and development helps and hurts us. No one knows what we're worth. We don't even know.

As a VP of Operations trying to hire 3 support engineers right now, this post is spot on.

I'm paying you what I think you're worth, and that's a stab in the dark based on what other support engineers in $locale are making, how sharp I think your skills are, and most importantly, how much potential I think you have (I expect one of my candidates to grow into my position at some point when I leave to be a CTO at my next org).

TL;DR People are the hardest part, and we're all still learning how to do it right. Interesting times such as now don't help.

Well said. I find that most that are trying to become great programmers place more emphasis on finding a great team above a great project. Of course, having a great team may be one of your criteria for what makes a project great.

I don't think the path to greatness or the concept of programmer skill are as opaque as you suggest, even for non-technical evaluators of talent, once we at least have some small set of evidence and indicators available that tend to suggest talent.

For example, if I'm approached by an engineer from a major player like Google, I immediately have at least an idea that the engineer should be better than average, simply based on the fact that this engineer has already been vetted by Google's hiring process. That in itself isn't a guarantee of talent or 'fit' (fit isn't entirely relevant to this discussion), other than the ability to pass a rigorous interview which does not make one great, but it's an indicator, and chances are that engineer will probably be given a pass on a first phone screen. Someone who has held a job for years at an esteemed tech organization (need not be globally known) probably had to do something right to keep their job. Not foolproof, but fairly reliable.

Running references is another way to get some indicators. Granted, if a candidate can't find 3 people to say nice things about them he/she should find another line of work, but when you ask references the appropriate questions you will notice patterns if the references are being honest. I always ask about 'areas for improvement' as well as strengths, and if 3 references provide consistent answers to an area for improvement, I can be sure that is a flaw that should be acknowledged or addressed before hire. If you don't get consistent answers from the first few references, ask for more. Even a candidate's ability to provide references is another indicator of skill (not to mention soft skill, another element of greatness probably). Not foolproof, but usually reliable.

If working in smaller circles, you may know people that worked with this candidate that is not on their reference list. This is potentially dangerous territory to step into but I'd imagine a CEO making a large investment of both cash and equity would want to know what some others think.

Over the past few years, the technical interests outside of employment are becoming another indicator. I've said this before (as have others), but below-average engineers don't read or write Haskell code on weekends. This doesn't mean that all great engineers write Haskell on weekends, but that would certainly be an indicator of technical ability, and that indicator should have very few false positives.

The choices an engineer makes are also an indicator - not a guarantee, but certainly a signal. One might question the skills of someone who leaves a job doing very interesting and complex work for something much more junior or less challenging technically. These decisions start to create a narrative that at least suggest some skill level.

Of course, if we have the benefit of seeing someone's portfolio that is another indicator. It's difficult to judge an individual contribution to a group effort, but taking that type of evidence combined with any solo effort, interview performance, and perhaps a pairing exercise with your company's 'most talented' two developers, shoof provide some body of evidence for a decent talent evaluation.

A non-technical CEO could use similar tactics (not identical) to learn about a CTO, rather than relying on luck or other methods.

What makes anyone great and who decides who is great is tricky business, but it's mostly tricky when we have no prior info to use in the evaluation. The path is perhaps a bit more opaque, but I don't think most programmers really believe they are in the dark (and unable to evaluate talent accurately) as you suggest.

My article wasn't obviously as much about greatness as perceived value and salary disparity. None of the engineers in my article need to be great, or even good, for the disparity to exist. Your points, as always, are well made.

Exceedingly excellent post.

>The complete opacity of programmer skill and development helps and hurts us. No one knows what we're worth. We don't even know.

Times like these create huge opportunity for those who are able to navigate through the uncertainty. It truly is an exciting time.

Determining the theoretical 'worth' of a programmer is difficult because demand for programmers is typically tied up with a firm determining how much value they can get from a particular hire. Where information regarding the value of a skill is difficult to quantify due to the largely tacit nature of the skill, valuation is difficult.

It is, however, possible to examine value by examining the differences in demand. If a firm compares their programming staff to a theoretical programmer, then determine what they would be willing to pay for wrt some specific added value that they would get at a particular level of execution, they can effectively price talent.

The take home point is that your first step to pricing is by way of comparing delivered value. The interesting part here is that programmers will likely discover that their skillsets are highly asymmetric wrt value delivery.

My question is how do we measure delivered value? Seems the push for quantifying contributions (https://news.ycombinator.com/item?id=5462622) might be related to the difficulty in value calculation.

Oh, I don't know how hard it is to get better. All you have to do is point yourself at challenges that are harder than what you've previously done, and then do them. Sure, that's a local optimization process that will be prone to reaching local maxima, but you can always broaden your view to find a larger challenge.

Most of us spend more time on our day job and its dev problems than we do on extracurricular learning. Finding a job (or academic post) that is set up to help you push yourself consistently is the trick.

Most dev jobs don't inherently scale difficulty up to match your constant skill growth. "Good" work (at least the metered, someone-else-is-paying-for-it kind) is subject to a lot of competition.

I wrote about this a fair bit: http://michaelochurch.wordpress.com/2012/01/26/the-trajector...

It's hard to get to (or even near) the 2.0 level without continually getting high quality work. That kind of work is rare in the corporate world and most people never get it.

It's also hard to push yourself to a 2.0 level if you can't work on it full time.

Now, a neat thing about side projects is that they don't have to be 2.0+ to be useful and successful. There are other things that matter just as much. That said, if your goal is to become a 2.0+ programmer, you'll pretty much need access to a quality of work that most developers never get to do at their paid jobs.

Reply on news.ycombinator.com