Hacker News Reader

If there is an economic cap on the value of a developer, it doesn't derive from how much code they produce.

Value differentials for programmers derive from knowing the right code, not typing up any code that suffices, and I think pay reflects that. 1 KLOC of the right code can easily be better than 10 KLOC of the wrong code, even if the 1 KLOC is buggy and the 10 KLOC has no bugs.

I think programmers are valuable in a power law way, and this can be based on intelligence, domain knowledge, experience, math skills, and other things.

You can command a much larger salary if you either have technical/math abilities that almost no one else has (like a Google search engineer), or you can have an economically valuable product sense (like a proven, high-paid early start-up engineer), or you can know a domain in an economically useful way (many technical founders).

Programming is an army-of-one kind of job, even if you work in a larger team. Insightful programmers are better than dogged ones by orders of magnitude. I look for programmers who are creative, self-driven, and knowledgeable.

EDIT: I ended up editing this for the first 18 minutes it was live. Premise is the same, but I wanted to work on how I said everything.

In my book, edits like this are fine. You turn a draft into a post-revision work and it makes the site better, especially for folks who aren't reading it conversation style.

I agree with this sentiment. It's more effective to find the correct company and correct project within that company to make sure the lines you write are valuable. That's where the money comes from. I know some dudes who are smart and great coders who are making (relatively) little, because they are working on fun things with limited economic value. On the other hand, there are guys who are merely good programmers who are making a lot more, because they sought out projects with very high value and impact and moved those forward. Although it's hard to say how either group can complain too much considering the relative luxury of even entry-level programming jobs in this market.

Part of the reason that startups can be so lucrative is not that a lot of code is being produced, but that code doing something never before done is being produced. The code is not the product, the behavior it's implementing is. It's a subtle distinction, but an important one.

I tend to agree with your basic premise, and I realize that in the general case it is impossible to do analysis. But my fundamental point was that a programmer's salary is limited by that programmers replacement cost. We talk about ageism here now and again, and it is out there, but it is more common in my experience that people who had their salaries ratchet up because their management didn't know what else to do, end up being paid more than their replacement cost. If they try to find a job at a different company, the hiring managers might evaluate their salary requirements as unreasonable. That particular story is way too common in the Bay Area.

  From an economic standpoint, being able to generate 1000 lines of syntax error
  free code per day, is perhaps the best possible programmer you could be, but
  its never worth more than 10 programmers generating 100 lines of syntax error
  free code a day.[1] So yes, there is an economic limit on your pay.

If all you ever do is code functionality that other people dream up, in a system design that someone else specifies, then I agree completely. For a lot of engineers, that's how they operate. Maybe that's how they want to operate, maybe that's the best way for them to operate.

For other coders, and this depends as much on the company and corporate structure as it does on the individual, they are the ones dreaming up new products, new approaches to old problems, layout solid foundation that 100s or 1000s of engineers can build upon, or specifying an approach and methodology which ships the product 6 months sooner with twice the functionality or half the bugs. They are the engineers that make your entire organization not only more efficient, but literally capable of things that they weren't capable of before. That's when you start getting into the same type of ROI from that programmer as that SVP is supposed to be providing.

The problem is most organizations simply aren't organized to promote and reward these engineers, and that's the "dead end". The last time I worked for a company I didn't own, literally the only way I could find to make any real money was to do my programming inside the sales organization, so I could be paid on commission for writing code for "major accounts" which would only later be taken up by the core engineering team and become a full-fledged product line.

Being a quota carrying engineer, with variable compensation and benefits like 'Presidents Club' was living in a different world from the engineering org. What I found was that, when working for someone else, in order to justify significantly higher pay, I had to be more directly driving increasing sales. Doing the exact same work inside of the engineering org, even with the same sales impact, would have paid significantly less.

For the big tech companies, this is exactly how they are organized. Software companies that don't have job titles like "principal software engineer" and "distinguished software engineer" which rank at director/VP level are going to have a hard time as software becomes more and more critical.

Principal software engineers, fellows, and most of the related titles don't write code, in my experience.

Being able to combine programming with communication, sales, and analysis skills can be incredibly valuable, though. That 1000 line/day programmer, if he looks around and observes the functioning of the org, could probably easily find several areas where those 10 programmers are writing 100 lines/day that could easily be automated away. If he can then write a solution that does this and sell it to upper management, he's clearly been more productive than all of them combined. This is where you find the programmers who get paid several million a year.

Agreed, but if she can observe the "functioning of the org" then she probably will try management at some point. There is an old quote my Grandfather had which went something like "soldiers control battlefields, generals control objectives, and kings control countries." The gist of it was that if you could see the path to success you rose to the level where you could use that vision to make that level of change happen.

"she"?

Several tech bloggers/writers (Ben Horowitz of a16z is probably the most prominent) have taken to using female pronouns when referring to unspecified tech leaders (CEOs, founders, high-level engineers). This is a way to combat sexism and unconscious bias in the tech community - by sorta jarring you out of your expectations of what gender a prominent tech person is, you're made to consciously think "Why wouldn't a woman be in this position? Why is my default assumption that a high-performing engineer is male?" Much like your post.

Anyway, I support this trend and I've been known to do it myself sometimes. It's a little disorienting when the hypothetical subject of a thread flips genders halfway through, but the person is only hypothetical anyway, so why not?

> So yes, there is an economic limit on your pay.

As a mere programmer, sure, but senior developers get well into the six-figure range, and with some luck, those stock options are worth quite a bit.

Sure, not everyone gets to work at Google at an early stage, but their IPO minted a good number of 'mere' programmer millionaires.

I think you view (or at least present here) the programming job as pure production measured in KLOCs or something similar, and this is wrong. It is a part of the job, but not the main part. 1 KLOC written by a good programmer may be worth literally orders of magnitude more than 10 KLOC written by 10 poor programmers. The reason is not syntax errors - those are mostly irrelevant as the tools get rid of them pretty quickly. The relevant part is what tools can't do - conceptual build of the code, design, robustness and ability to accommodate change. These terms are very hard to define, especially with rigor that would be convincing to anybody outside of the industry, so there's a lot of hand-waving and "you know what I'm talking about" when we talk about it, but in the essence poor code is poor and great code is great not because the former has tons of obvious errors and the latter does not. It is because you'd spend orders of magnitude more money, time and other efforts supporting and improving poor code than great code. That's where better programmers are providing the edge, not in the KLOC output. If you need KLOC, you don't need great, you don't even need good, you just need "can tie his own shoes" one. But if you need a system that you wouldn't have to throw out and rewrite in 3 years because it became unmaintainable and every fix immediately creates an explosion of new problems - then you need great. That's where 9 women/1 months comes into play.

The problem here is of course as I noted this is very hard to manage and evaluate except way post-factum (and even then there are little of robust tools and methods to do it with any rigor) so it's hard to know for sure. But in many cases, "you know it when you see it".

Why are you assuming that the 10 programmers are less skilled than you are. Take this scenario: You(good programmer) write 1 kloc. 10 other (equally good) programmers write 1/10 kloc but each of them is willing to work for less than 1/10 your pay!* Isn't this a possibility in free market? So may be you dont have any intrinsic value. Your value is a function of how many similarly skilled programmers are out there. Since this applies to all trades, I guess the solution is to move to trades where the supply of "good" labour is less than your current trade. May be that is why the author's friends who moved to management get paid more.

*assume: (communication/coordination overheads) + their pay < your pay

You are right. Programming is a blue collar trade.

That is a bit of a reach to call it blue collar.

I have blue collar friends from high school who envy what programmers do and make and I do what I can to try and persuade/teach them to learn to code and make a better life for themselves.

whoosh

Edit: I thought the original "blue collar" remark was sarcastic. Am I wrong?

Most everyone has forgotten the 2000 dot com crash, when all the computer jobs disappeared. This "learn to code" is just how it was then.

I would bet money that in less than five years, a lot of software people will be unemployed -- again. (If I win, good. If not, good. :-) )

I'm curious - how much money would you be willing to bet on that? At which odds?

I've been through the dotcom crash and minor disturbances after, and the jobs never "disappeared". Yes, there were layoffs, pay cuts and hiring freezes. But not all jobs disappeared, and most of the people who lost their jobs found new ones after a while. I'm not diminishing the pain and suffering of those who got caught in bad situations there, but it's not like the whole IT disappeared and people went back to abacuses and wired telegraph.

>>But not all jobs disappeared

I wrote "all jobs" in one place and in another "a lot of software people [...] again".

Since you were also there, what I meant should be obvious...?

In my Swedish job market, there was also something similar around a decade earlier. But it was not only for software people.

"This "learn to code" is just how it was then." - really? I don't remember it that way. Sure there was lots of people who wanted to get in, and lots of books printed but nothing like the sustained push that there is now.

Blue collar workers can make a lot of money these days, especially if their trade required significant theoretical learning and practical training.

Electricians, mechanics, heavy machinery operators in Alberta can make $150,000 in the oil sands before overtime, plus fly-in/fly-out costs; in the major urban centers, upwards of $100,000. If you're young, add in overtime and you're looking at $150-200k+. Foremen and supervisors can make up to double.

A programmer in the Bay Area will top out around $200k as a senior member of technical staff.

By the article's definition, neurosurgery is a blue collar trade as well.

If you consider blue collar work as "manual labor" and white collar work as "knowledge work", then there likely is a middle-category that is a mix of both - "knowledge work that require you to use your hands to deliver results".

Peter Drucker called these folks "knowledge technologists": http://www.economist.com/node/770819 ... And believed probably will be the majority of workers in a developed countries over the next century.

A) That's not what the post above says, and b) it's not accurate.

Blue collar refers to jobs that involve physical labor. The term arose when people on the factory floor would wear blue coveralls, and people that worked in the offices off the floor would wear white button down shirts.

Why exactly every job needs to have a clear path to CEO or be considered a dead end or blue collar job is a mystery to me.

because unless you can work 40 hours a week and spend another 20 learning new techs as they come out for the entirety of your life, you will become obsolete unless you can move onto other roles. If management is not an option, then chances are very likely that person will be unemployable somewhere between ages 40-50.

and that's only one problem. you may reach (or ever want to) the top, but if there is a low ceiling that is going to put so many pressures on your career.

"Unemployable beyond 40" has been dead for years in the software industry. Probably for decades. There's nothing in current industry that requires you to be under 30 (actually, there are tons of positions which require extensive experience) and technologies don't die that fast - C programming market is still alive, C++ is over 30 and not going anywhere, Java would be 20 years old next year and not disappearing any time soon. The time where experience from 10 years ago was completely irrelevant is past, now you could have been writing in Java 10 years ago and still be doing it today and continue doing it 10 years from now if you'd like so. Of course, you have to keep current, but any trade has that, especially trade which deals with advanced technologies.

you cherry picked the most successful languages, and also ignored how much they changed. you also doubled the amount of time c++ was actually used. 30 years ago COBOL was all the rage I'm sure. And lets face it, knowing just those is not going to get you very many jobs, maybe for a few hundred people in the entire united states.

and people have to look ahead and see the trend. newer stuff is coming out faster and faster. The 'hard' stuff is paying more and more and requires less and less people to do it, while the easy stuff is consistently either being outsourced or made so easy 'anyone' can do it.

and unemployed beyond 40 dead in the industry? are you kidding me? we have less IT/programming jobs today than we had in the late 1990s. Where do you think those people went, they just up and died? they had to pick a new industry

You quite underestimate the number of COBOL jobs. E.g. simple search [1] reveals thousands of COBOL jobs just on one site, and most of these jobs I imagine would not be even advertised on generic job-search sites since these go through consulting firms which already know who they can hire. Deeper research shows there are millions of COBOL programmers now [2] and massive numbers of COBOL applications still in business. Actually, as traditional COBOL programmers start retiring and banks and hedge funds still being in business, programming COBOL may become very very lucrative market, paying very much better than your average Ruby or Java gig.

>>> newer stuff is coming out faster and faster.

I see no indication of this. Actually, most of the things that were with us 10 years ago are still around, and introduction of paradigm-shifting concepts massively slowed down due to massive size of the market which would not allow quick change and incurs massive legacy costs. You could maybe introduce new HTML version in a year in the 90s, but now you're stuck with HTML 4 for decades because literally millions of applications depend on it and they are not going to change, and HTML 5 is rolling out in baby steps, despite all the cool stuff it proposes. Looks what happens to XP - they have a massive install base and now Microsoft can not get rid of it, however hard it tries. Market size is enormous now, and so the pace of adoption of any paradigm-shifting concepts is much slower than before.

>>> we have less IT/programming jobs today than we had in the late 1990s.

Could you back this up with some data? I haven't found the data that support this conclusion. The programming jobs are shifting around and moving, but I don't see IT being smaller now that it is in the 90s, even accounting for the dotcom bust. Where is that "less programming jobs" coming from?

[1] http://www.indeed.com/q-Cobol-jobs.html

[2] http://cis.hfcc.edu/faq/cobol

Edit: removed wrong data.

yes there are a few COBOL 'jobs' scattered throughout the country, but that really doesnt matter. a person can stick with learning one language and hoping it remains relevant for their 40-50 year career, but outliers do not make a rule. theres lots of people doing really well playing the lottery.

making a web page today in 'html' is NOTHING like it was 5 years ago, let alone 10. you're simplifying it way too much.

if you were a web designer, and just stuck with what you taught yourself back in 2005, you would be out of a job. you constantly have to learn new libraries, new languages because no software operates on an island. yes, every field must adapt and add changes, but none so much as like with tech.

all of this is COMPLETELY irreverent anyways. IF you want to be a programmer, and not look ahead to your future to find out what you will need to grow into, BY ALL MEANS. And if you think people will still find your skills valuable even though you don't plan on updating them constantly, good luck.

the point is, if you read the article and dont want to gamble with your future, a programmer is a dead end job in the sense that if you are not moving into some sort of managerial position, there is no where to go.

Nobody says "don't learn anything for 10 years". That would get you in trouble in almost any profession but maybe burger flipping. What I am saying that what you learned in 2005 about HTML is still useful, you just add stuff to it bit by bit, becoming more experienced - and your value actually raises, not declines. Nobody says "do not update your skills". What I am saying is "don't discount the skills you already have". This is additive, not zero-sum - if you know both COBOL and Ruby, it's better than just one of them, and your expertise should cost more even if you don't write COBOL on current project - because you have wider experience and thus probably can see solutions or aspects somebody with narrower experience can not. That's why I think "unhireable by 40" is a nonsense that is long gone from any shop that is interested in hiring actually good programmers and not cheapest coders to generate KLOCs for some contracts where it won't work anyway but it's OK because it means more contracts.

>>> IF you want to be a programmer, and not look ahead to your future to find out what you will need to grow into, BY ALL MEANS.

This is a false dichotomy. I want to be a programmer AND look into my future, and I do, thankyouverymuch. I do not want to be a CEO, it's not a job for me, I'd suck at it. But I don't suck at programming, and that's what I want to do. And I think there are lots of opportunities around to earn your bread and butter on it.

>>> that if you are not moving into some sort of managerial position, there is no where to go.

That's plain wrong - there's everywhere to go, and you confirm it yourself by noticing new things appearing all the time. That's where you go - doing new things! You don't have to have a 'C' in your title to live a fulfilling professional (or personal) life. Of course, if your goal is to have that 'C', go ahead - but there could be many more goals than that.

we have less IT/programming jobs today than we had in the late 1990s.

This site seems to disagree with you: http://www.bls.gov/opub/btn/volume-2/careers-in-growing-fiel... . I work with numerous people over 40 actually.

Also, I beg to differ that learning a new programming language is a big deal. We've yet to see a single complete disruption in the way we program... It's still editors, compilers and debuggers in the end.

    From an economic standpoint, being able to generate 
    1000 lines of syntax error free code per day, is 
    perhaps the best possible programmer you could be, 
    but its never worth more than 10 programmers 
    generating 100 lines of syntax error free code a day.

This is just plain false.

Yeah, Jeff Dean would probably disagree with this post too.