Don't Call Yourself a Programmer | Hacker News Reader

Don't Call Yourself a Programmer

kalzumeus.com

1,021 points_ouxp267 comments

Okay, I guess as someone with hard-won expertise I'm duty-bound to take slight exception to this line:

Put a backpack on and you can walk into any building at any university in the United States any time you want.

First, the nitpicking: Technically you can't get into Harvard's excellent libraries without actually (a) being a Harvard student, or (b) working for Harvard. (And if you're a programmer, I'm not sure which of those options is going to prove more expensive.) But, of course, the rest of Harvard is open to the backpack-wearer, and MIT even opens their libraries (I'm proud to routinely impersonate a graduate of MIT) so this isn't much of an objection.

On a slightly more serious note: They also won't let you into the labs with just a backpack. If you'd happily accept a sub-market wage to be taught laboratory research techniques, in a piecemeal and haphazard fashion, by sleep-deprived world experts equipped with state-of-the-artish equipment, engineering graduate school is the game for you. And I did kind of enjoy working in the lab, just not enough to keep that as a career. It's not that great a career; you have to love it to stick with it forever.

Now, having said that, I cannot re-emphasize this line enough:

After you’ve escaped the mind-warping miasma of academia, you might rightfully question whether Published In A Journal is really personally or societally significant as opposed to close approximations like Wrote A Blog Post And Showed It To Smart People.

All my journal publications mean nothing compared to the stuff I've scrawled in the margins here at HN.

They also won't let you into the labs with just a backpack.

In a literal sense, no, that's not enough. In a practical sense, if you're serious about doing research and have the necessary background to be able to do good research, finding a faculty member who will invite you to join their group as an unpaid "research assistant" is trivial.

This is literally true.

But I come out of experimental physics, semiconductor engineering, and biology, where "the necessary background to be able to do good research" generally translates to "you have the kind of lab skills training that you can only get by getting a Ph.D. in a lab just like ours, plus you know how to write (or at least contribute vital portions of) successful grants to pay for the equipment you'll be using and the reagents and parts and live animals that you'll be consuming as you work". The thing is, lab benches are expensive, outlandishly expensive in many cases, so you'll have to earn your spot at that lab bench by outcompeting whoever else might want it. The net result is that, yes, with a modicum of talent you can probably always be an unpaid research assistant, but the practical difference between that and a full-time career in research is just a few thousand dollars in salary. ;)

(Or you can learn to build scientific equipment out of hardware found on the side of the road. This can work well, if you choose your field carefully.)

Now, in a field like math or CS where adding you to a research group may require only the occasional spare chair to park you in and a modest 5% increase in the coffee budget: Absolutely, you can dabble in university research as much as you want. This is one of the charms of such fields. Didn't Erdös run his entire career out of spare chairs in other people's offices and apartments? And, of course, MIT is legendary for the excellent work done by people hanging around Tech Square snarfing up spare CPU cycles.

I think we're disagreeing mostly on what "getting into the labs" means. Sure, you can't walk into a lab filled with expensive equipment and start doing your own research; but you could absolutely walk into someone's lab and start helping to do their research. My father studies chemical reactions in supercritical water using a beam of spin-polarized muons from a cyclotron; there's many millions of dollars of equipment involved in his experiments -- yet he still hires undergraduate students, because there's always plenty of grunt work to be done.

Ah, okay, if you want to be an unpaid lab tech I agree that you can get that job pretty darned easily.

It hadn't occurred to me, recently, to have such low standards for hanging around in a lab. ;) The novelty wears off, you see.

EDIT: just to summarize for the audience, I believe cperciva and I are in agreement with Patrick that it's easy to flawlessly impersonate a university student for free; We are debating the extent to which one may also impersonate a junior professor. ;)

Yes, "unpaid lab tech" is a pretty low standard. But if you hang around as an unpaid lab tech for long enough, you start picking up more useful skills and have a good chance of eventually getting paid. (No, I never did this. But I know people who have.)

As for impersonating a junior professor: I wander into seminars and if anyone doesn't recognize me they just assume I'm from the university on the other side of town. Given my age they usually assume I'm a postdoc; but if I was ten years older I'm sure they'd assume I was a faculty member.

Of course, "faculty member from a different institution" doesn't really get you very much.

It's been a long time since I was in graduate school, but, at least in chemistry, there were at least 20 highly qualified and ambitious people waiting for a shot at any seat in a top lab. There was no chance in hell of just walking in there and working for free. The time it would take people already in the lab to bring you up to speed wouldn't be worth it.

> It's not that great a career; you have to love it to stick with it forever.

Many are driven to stick with it because if they don't, they'll get deported.

I love corporate, boring, "soul-crushing" work. Why? Because I can sit down, whip out a basic CRUD form with a small approval cycle in a day. It saves a company 100K over the year, I am loved by the customers, and because it is so simple, it normally requires no maintenance. Maybe we update the fields once a year or so.

At the end of the week, I've already saved the company more than my salary. After a year, I am a critical asset to the company.

After 3 years, I've optimized everything, the ROI slows down, and I move on.

This pattern is not a tragedy. It doesn't crush your soul. It makes you a prized commodity in the business world, with a chance to make a change in your life every few years.

I have usually alternated between 3 years doing this, then 2 years doing startup work. It has given me a much broader base of experience and skill than anyone who stick to one one side of the coin. It also has given me years of experience in large industries (banking, energy, etc.) which I then use to find very real problems to which a startup can be applied.

I have led a very satisfying career, doing this for almost 20 years now.

Corporate work has a lot more to do with the relationships than with the work itself. That's the most important take-away. It's not about how much math you know or what data structures you use. It's how you get along with the guys (and gals) you're doing the work for. You want people who are smart enough to understand that what you're doing is important, but humble enough not to think of what you do as "grunt work" that they could do just as well, and decent enough not to try to "trap" you or to browbeat you into doing as much work for as little as possible.

I'm also not a fan of the "hostage employer" situation. It's a way to get a steady paycheck, but also a toxic relationship that kills you slowly. Better to do the best work you can so that if your client wants to let you go, he can.

If you're doing "boring" corporate work for people you like (and not all "business people" are assholes; it's about half IME) then it can be fun. You do great work for them in a small amount of time, and they pay you well and are happy to have you.

I've met a lot of consultants who can make this work really well. When you choose your clients and don't have a manager-as-career-SPOF, you can develop positive relationships like what you described.

A more important thing is you won't really need much of those data structures and algorithms for nearly 99% of the tasks that your are likely to do in any large corporate/typical business driven software today. Most of the data structures that you will need are covered by the standard tool kit that comes with the language. Most of your common sorting and searching needs come covered with the libraries.

But you sort of need to have other skills, like productivity , delivering extra value to business etc.

Also I don't see why all that is wrong. After all software there is written to make money. And if something helps you do that with ease. It's perfectly OK. You don't have to always take the most difficult path to prove you are good. Doing what is required to 'get things done' is just good enough.

I find that pretty interesting, and quite the opposite of my experience. I'm guessing that it has to do with the size of the boring corporation.

I worked for a mega corp, and redtape and layers upon layers of bureaucracy would pretty much make any project take months instead of a day. Additionally, there were plenty of times where the right arm was working on something and the left arm didn't know about it, so it was also working on the same thing. Finally, the customers didn't really know what they wanted, the databases weren't designed properly by a solid DBA, and really good system architects weren't brought on early in the design, which resulted in an extremely poor working applications.

All-in-all, it was definitely soul-crushing, and I personally have no desire to do it again. YMMV.

I'll add in that I expect 90% of enterprise programming is maintaining someone else's code. It isn't making small CRUD apps, it isn't innovating, it isn't bringing costs down, it isn't bringing profits up.

It is simply maintaining the behemoth they spent a fortune on N years ago which was over-, under- and poorly designed all at the same time. It is just keeping it working well enough that it can continue being used because as long as it is working there's no reason to rewrite it. The words "rewrite" to an executive mean, "do a lot of work and spend a lot of money to make something we already have."

And there will have been non-FizzBuzz programmers working on that project before you.

>>"Programmer" sounds like "anomalously high-cost peon who types some mumbo-jumbo into some other mumbo-jumbo." If you call yourself a programmer, someone is already working on a way to get you fired.

I call myself as a programmer because I enjoy programming and do a lot of programming as part of my job.

It is unlikely that I'll get fired because I run the (tiny) company I work for :). and customers seem to like the products we sell in the app stores.

Prior to starting this company, I was a Principal Development Manager,SDE Lead and Software Design Engineer at Microsoft. Describing myself as a programmer or a developer didn't hurt me there either.

This is not to say that Patio doesn't make a good case about the need to focus on value created. Regardless of profession, you have to focus on the value you create. A doctor saves lives, a construction worker builds homes, a pilot takes people home etc.

It is definitely possible for all of them to use MBA-speak mumbo-jumbo job-titles to describe what they do. Alternately, one could be a bit more of a plain-speaking, straight-talking person and just say that you're a doctor or a programmer or a pilot etc.

It's a very business oriented article.

E.g. "You’re in the business of unemploying people. If you think that is unfair, go back to school and study something that doesn’t matter.)"

I for one have created more jobs than I've destroyed in my coding career. By building a business, as you've done, you're going in the opposite direction of this kind of sentiment.

I think he was merely responding to the idea of unfairness by pointing out much software automates jobs away.

Don't take this the wrong way, but ... really? I find that hard to believe. Pretty much all programming is in the short term unemployment producing, since pretty much all programming is automation. Automating a job means that no one does it anymore, hence one fewer job.

In the long run those people are usually repurposed into productive work, and there are occasional moments where a programmer will create a massive number of jobs (see: whoever implemented adwords, creating an entire industry of professionals to optimize purchasing them). But that's the exception, not the rule.

There are types of programming that create jobs, but you're right, most of them eliminate jobs while making the rich (owners of our companies) richer. Which kind of sucks if you think about it.

The programming that creates job is the kind that sells to consumers. Pretty much any consumer product will create jobs. B2B will eliminate jobs. Most programming is B2B (I think...) because it's easier to take money from other companies.

Examples of programming that creates jobs:

Games

Iphone Apps

Todo lists

Products that make money by showing advertising

If you work for a publicly-traded company, then you aren't really "making the rich richer", or at least not totally. Some of the biggest investors are pension and mutual funds, so it's quite likely that the success of your company is being shared by many fairly ordinary people.

> Which kind of sucks if you think about it.

Yeah, it totally sucked that the tractor came along and eliminated all those coveted farm hand jobs. Software is the tractor of our time.

> Pretty much any consumer product will create jobs.

Such as the iTunes store that overnight closed pretty much every single brick-and-mortar music store in the world (mild, but only mild, hyperbole)?

> Examples of programming that creates jobs:

Games doesn't automate a physical task, but it's silly to assume that they haven't displaced other kinds of entertainment, say, perhaps, comic books. (I consume neither games nor comic books, so I'm speculating)

Whether an iPhone app has destroyed or created jobs depends on the app, after all it's just a computer program like any other. Take magazines and newspapers: There is NOTHING these businesses would like better than to shut down their printers and distribution divisions. Those are, if anything ever was, pure cost centres. Also, any app that lets you do something from your phone that you otherwise had to call a call centre to do probably isn't exactly a job creator.

I don't know how todo-lists earned a spot on the list, but there is no reason to believe that they (and any other "productivity" app, say, a good e-mail client or calendar app) don't, on the margin, raise the barrier to needing a personal assistant/secretary.

Advertising online is just one example of the lower-barriers-to-everything that the Internet has facilitated. Whether the Internet is a job creator probably depends on who you ask: A self-taught Rails dev or a Borders employee.

EDIT: My point, which took a little while to crystallise, is that at businesses the things being automated away are larger and have individual accounts, so savings/consequences are very visible. When you download NYT to your iPad, they don't fire three guys in the printshop, they need a small fraction of one of them less. When you send an e-mail to your mother, a fraction of a person in the mail- or greeting cards industry is less needed. Etc.

As pg pointed out, everybody should be concerned with creating more wealth instead of creating more jobs.

There are economies where are a lot of jobs (low unemployment) but very few wealth and it doesn't seem to stick regardless of what they do. You probably don't want that.

As long as you do your job of creating wealth you can hope somebody else to work at improving wealth distribution process.

Most of programming either creates wealth or conserves wealth, which is a good thing.

Either you're in a Cost Center or a Profit Center. As nearly all day-to-day programming is automation of some kind, costs are cut by eliminating menial labor. Revenues are increased by selling that automation to customers and clients. The sad sorry truth: your software puts people--somewhere--out of a job, thus saving money for that person's employer/customer. That's your value proposition.

Now of course, the economy on the whole is not a zero-sum game. But you don't see that at the micro-economic level. It is rare indeed that a programmer creates new jobs without negative consequences somewhere else in the world...

Once you run the company it doesn't matter what you call yourself. That is probably a great topic for another essay, assuming PG hasn't written it already.

It might matter what you call the company or the product, however, since that is the brand that the people who pay you are seeing.

Programmers are so literal. Let me try and translate: When Patrick says "don't call yourself a programmer" he isn't necessarily saying "never use the word 'programmer' in the same sentence as your own name". What he's saying is: When someone asks you what you do all day, don't just say "I program... stuff" or "I program in Lisp". What do you program? Why? What value do you create thereby?

Right. I might say "I'm a computer programmer", but I usually say it right after "me and five other guys track everything about all video plays for ESPN.com" or a rough equivalent.

See, there you go, that is awesome.

I'm a programmer. I program things. What, specifically, changes pretty frequently still. Going into detail can be useful when trying to score social points from the smalltalk question of "So, what do you do?" But depending on what you program, I think for most people "programming" is sufficient compared to "I currently write software to manage an elastic computer server farm running data analysis jobs for people."

In fact I think the former "programming" can give you more social cred--if you program things the other person can't comprehend an immediate use for, it may hurt you. "Oh you're one of those people that don't do anything useful." If they really want to know, they'll ask, and ask for more details if they care.

Of course, I agree in general that when whoring yourself out to the corporate world it's best to make yourself sound as important as possible as long as possible, which is basically what I got from Patrick's post. "Programmer" doesn't contain enough information to make you seem important enough in BigCo. It's fine for scoring social points.

I think the point is to make your job description less technical, not more. You're not a programmer, you're "the guy who made $X for your company last Y".

That's a good point, it's not just about what you do, the effects matter. But again it fits into the scoring social points game and making yourself look extra important to companies.

It's not just social points, it's access to fulfilling work. The better you do at conveying your unique value, the more likely you are to find someone who's willing to pay you appropriately for work that's right at the edge of your abilities. If you don't market yourself properly you'll be stuck on an HR salary scale (e.g. Programmer III at 105% of standard compensation) doing fungible work.

Doesn't that depend on what sort of job you're trying to get? If someone is hiring for embedded systems development, and your resume has no details about your technical skills, but lots about Providing Value, there's a good chance they're going to wonder if you're technically qualified. They certainly won't be impressed if your attitude in the interview is: ok, sure, I don't yet know all of these details, but anyone can pick up a language in 3-4 weeks; did I mention I'm really good at creating business value?

If you were a carpenter, you wouldn't tell your friends "I hammer things all day", you'd tell them that you make things out of wood. I'd argue that the fact that you spend your day "programming" is more of an implementation detail of the bigger picture that your job is to create software.

If you were a carpenter, you'd tell your friends you're a carpenter.

If you were a janitor, you'd tell your friends you're a sanitation worker.

If you were a stripper, you'd tell your friends you're an exotic dancer.

Patio is saying we should say "engineer" instead of "programmer" because programmer has similar connotations to janitor.

In my experience, 'engineer' has closer connotations to janitor than 'programmer'. Certainly in the UK, engineering as a profession has a big image problem because the average person doesn't distinguish between e.g. a heating engineer (who fixes the boiler) and say, a civil engineer (someone with a Masters degree + 4 years professional experience and accreditation).

People I know who are programmers all have professional jobs and by and large are earning more than those I know who are engineers. That's probably not a representative sample of 'programmers' though.

tl;dr: 'engineer' doesn't sound too professional either, at least in the UK. IMO Software Developer sounds better than either, and that's what I tell people I am.

In North America an engineer is either a train operator, someone with a university degree in "Engineering", or a programmer. So you can see the difference.

What you describe as an engineer would probably be called a technician here in the US - somebody with a relatively specialized skill set whose responsibilities are mainly operation or maintenance of equipment or systems.

Or to put in a comic-friendly way: "It's not who you are, it's what you do that defines you".

Agreed, I'm doing programming.

Another way to frame this point -- that's kind of like asking a novelist what they do, and having them answer "I type out sentences, in English".

No, even if they started with "I'm a full-time writer", they'd follow up with "well, I've had two novels published -- I guess you'd categorize it as literary fiction? -- and I'm finishing up the draft of a third."

If you are a "programmer", what does that mean? Do you do anything of value? To whom? Do you know? Or do you program whatever you're told to program (inasmuch as you can figure it out, and it's their problem if the specs were bad) because that's how you earn your paycheck?

If you're in the latter category, and that's the only thing you grasp about the work you do, that's a pretty big limiter on your future.

Back in the day, John Carmack would micro-blog on the finger protocol (http://en.wikipedia.org/wiki/Finger_protocol). finger johnc@idsoftware.com got you Carmack's .plan file, a well-written and, for a time, frequently-updated journal of whatever programming challenges he happened to be facing at the time. finger @idsoftware.com got you the id corporate directory, a simple list of about 20 names and titles. The only titles were CEO, designer, and programmer. In a tech world awash, even then, with countless software engineers, senior software engineers, senior members of technical staff, architects, chief architects, CTOs, rock stars, and ninjas, it was always refreshing for me to see Carmack's humble programmer listing.

All of my heroes in the field are programmers.

When you have become sufficiently well known for your technical expertise, you can once again call yourself a programmer. If you're lucky, you may have gotten there while calling yourself a programmer. Patrick's point is that most people can more easily get there by not calling themselves programmers.

This is because -- with the exception of computer scientific research -- the impact programming parts of one's contributions nearly always pale in comparison to the product or service one has created. Feel free to call yourself a programmer, but be prepared to answer the questions "of what" and "to what end"?

I agree with your sentiment and hate the lame titles programmers apply to themselves, but you're missing a key point. Calling yourself a programmer is fine when your company's product is the software you write. If I work at id or at a company that sells iPhone apps and I call myself a programmer, it's obvious what value I create. But for the people making internal business software (90% of programming jobs according to Patrick) a programmer is associated with costs rather than profits, so it's a bad idea to craft an identify as a "programmer".

> If you really like the atmosphere at universities, that is cool. Put a backpack on and you can walk into any building at any university in the United States any time you want. Backpacks are a lot cheaper than working in academia. You can lead the life of the mind in industry, too — and enjoy less politics and better pay. You can even get published in journals, if that floats your boat. (After you’ve escaped the mind-warping miasma of academia, you might rightfully question whether Published In A Journal is really personally or societally significant as opposed to close approximations like Wrote A Blog Post And Showed It To Smart People.)

The degree of arrogance in this article is astounding. I've worked at Google, Microsoft, and IBM, and the work I've found most satisfying is in grad school.

To each his own. If you let something like this guide your life decisions, you have much bigger issues to deal with than finding a so-called "README.txt for your career as a young engineer".

You missed the point of the article. You can do cool thing even at large companies iff you put yourself out there and look for opportunities that interest you. You can also get paid for it if you are smart.

I think you have put it very well. This is something that I have always wondered. Leave alone some bad places, lets take the example of a good place. Consider a large corporation which is a pretty good place. But you also have a your usual large organisation crowd-control policies.

If a person can't make use of good opportunities, experiment and learn in such a place, I doubt whether the same guy will do any good at a reputed place(like big web shops today) or even a start up.

Or more appropriately, only people who are capable of doing good in large corporates can do well in a start up. Or vice versa. If you can't do well in big company without any thing stopping you, you are not likely to do well in a start up either.

Start up's are not some magical places of congregation which will give you edge over your career without any considerable effort. Wherever you are, you've got take personal interest and steps to learn, work and make your mark.

It's actually pretty hard to get on to the most interesting projects in large companies. Your first project is a roll of the dice, and you usually have to do well on that first one to get an upgrade on your second.

Yes, there's cutting-edge work going on at Fortune 500 tech companies. It's about 5% of the workload, and it's competitive to get onto these projects. You're competing against PhDs who have been with the company for 10+ years, have major internal accomplishments to their name, and are objectively more qualified than most of us are.

This doesn't mean you shouldn't try. There are other benefits to working at these large companies (high salaries, good benefits, and work that, even if unglamorous, is a part of something successful people care about). I do think, however, that the idea that a 25-year-old can walk into Intel and Oracle and expect to be allocated to cutting-edge work because of raw talent, is patently absurd.

Most large software companies have 6 de facto tiers which may not correspond to job titles: Freshman, Junior, Senior, Lead, Senior Lead, and Fellow. The type of work you get depends largely on this tier:

Freshman: low-impact but "fun" projects, "bait" work designed to ease you into the company. This is what people get straight out of school.

Junior: mid-priority but grungy projects, maintenance of others' architectures. Keep in mind adverse selection: the good architects generally want to assist in the maintenance load for their creations, while the bad ones tend to run like hell.

Senior: mid-priority but more interesting and autonomous projects. Opportunities for junior-level IC (individual contribution) on high-priority projects. This is where most people are expected to plateau.

Lead: leadership roles on low- and mid-priority projects, plus encouragement toward IC on high-priority work. Good point from which to move into middle management if one hits a technical plateau.

Senior Lead: leadership roles on mid- and high-priority projects, plus expectation of IC on high-priority work. Fun but low-priority work is generally not accepted (it won't get you fired, but you'll stop advancing and your peers will think you're wasting your time.) Most SL are trying to get into lower-upper management (yes, large companies have a de facto lower-upper, mid-upper, and upper-upper management) because so few people make it to the next technical tier.

Fellow: complete autonomy, high degree of influence, implicit trust. Ability to flit between high-priority and low-priority projects based on what one wants to do.

To get interesting technical work and enough income to raise children in NYC or SF without an awful commute, you generally need to make it into the Fellow tier, which is much harder than moving into management. At Lead, you have enough autonomy and status to take on whatever project you want, but having real influence (or high income) requires going higher, and going higher requires spending a substantial portion of your time (40+ hpw) on grungy work because that's what Senior Leads do.

The bitchiest tiers are Junior and Senior Lead. Juniors have something to lose (3-4 years' career investment) and are skilled enough to take the worst of the work (middling priority maintenance, both unglamorous and underappreciated). Senior Leads are the one you see on-call at 11:30pm despite having two kids. And if you think working on a mid-priority, grungy project is bad, imagine what it's like to manage that project and have to deal with people quitting, transferring, or getting fired at a rate of 2-3/year.

Move to Seattle. You can raise a family on a Senior Engineer salary and take a short bus to work.

How long have you been out of grad school?

If you are still in grad school... Write us back in ten years and tell us how academia is coming along. Meanwhile, carpe diem.

If you're out of grad school, tell us how much more awesome your career is than those of your relatively-untrained peers. More money? More respect? More challenges? What?

I went to grad school, and then I did a postdoc, and these things were indeed very fun hobbies [1], though very very expensive in lost income and opportunity cost. But now I support a large number of PHP apps, make significantly more money than I did as a researcher, have significantly more impact on human lives than as a researcher, work less hard than a researcher... And am, gosh, approximately ten years behind my peers career-wise. Oh, those expensive hobbies!

Still, nothing wrong with having hobbies. Just do be sure to know the difference between hobby and career. It can be similar to the difference between the transient and the steady-state.

And if you're out of grad school and have managed to secure an awesome steady-state career as an academic researcher with job security and good pay and time to spend with your family, your other hobbies, and your community, please do write back and tell us again how arrogant we are.

---

[1] In much the same way, I imagine, that the triathlon is fun.

The main arrogance, I think, is his claim that journals are just blog posts with more elitism, combined with a strange sort of anger towards academia (which doesn't seem to be based on knowledge of how academia works; it's not much of an ivory-tower fairy land, but really quite industry-like, with professors as managers in charge of running moderate-sized organizations, which they need to do PR, mentorship, and management for, along with generating revenue streams to keep the lab provisioned and grad students / postdocs paid).

As for journals, I like blogging, and hope to see academic publishing move towards a more online, networked open model, but I simply don't think we're anywhere near that. A typical blog post and a typical journal article are miles apart, today, and very few novel scientific results are produced in blog posts. So if your goal is to advance science, you're probably going to be part of academic culture in one way or another, and probably going to publish your results in conferences or journals. That's also possible to do outside academia or an industrial research lab, but relatively few people outside those kinds of settings actually manage to get the time to do so, since their local incentives don't reward it. In some cases they actively hinder it; I've been working with some game-industry people who hope to publish some of their AI techniques in venues like (http://www.aiide.org/aiide11/), but publishing is often vetoed by their management.

All sorts of stuff in there.

Patrick stated that you can submit journal articles without being employed by a university or think tank. This is true.

He also stated that, while it is perhaps thrilling to get a journal article published to an audience of hundreds, it is perhaps nearly as thrilling, plus one hell of a lot less work, to write essays on HN for an audience of tens of thousands. This is also true.

Don't conflate the two statements. Scientific papers and blog posts are not the same thing, I don't think Patrick is claiming they are, and I'm actually quite doubtful that they'll ever be the same thing. (Anonymous peer review is important, blogs don't support it, and the online systems that do support it don't look much like blogs, they look like online scientific journals.)

Now, on to other good stuff:

academia... [is] really quite industry-like

Indeed, it is very much like an industry. One with a tiny handful of customers, one of which is usually a major government. Often the government is the only customer. The difference between working for, say, a major military contractor, or a major pharmaceutical company, and working for a university is getting smaller every day.

It's nice work so long as your customer is buying. Once your only customer stops buying, however, finding another one can be a real pain.

Meanwhile, it's true that industry doesn't generally give a hoot about publishing new discoveries, often preferring to keep things secret. This is too bad. However, before we conclude that the only alternative is to become a professor, let me suggest that one could also look for a job where you can sell solutions to customers and keep control of your own IP, publishing it as you will. If you want to be told many stories about how this can work, go to an open source software conference.

let me suggest that one could also look for a job where you can sell solutions to customers and keep control of your own IP, publishing it as you will. If you want to be told many stories about how this can work, go to an open source software conference.

I believe this is possible, but if your goal is to do novel scientific research and publish the results, it's exceptionally uncommon. I rely on all sorts of statistical and machine-learning techniques developed by other people, for example. It's relatively common to set up shop as an independent data-mining consultant, and you can fairly easily pay the bills that way. So you might think that they've produced some of the results I rely on. But the way the economics work out, independent consultants rarely spend much time on basic research. The actual techniques and advances, as a result, come almost exclusively from researchers in academia and industrial research labs.

In fact, I can't actually think of any influential advances in machine learning from the past few decades developed by independent researchers. Heck, looking through the R packages I use, even the software seems to come mainly from a mixture of universities and places like Rand (biggest surprise in this mini-inventory: lots of stuff from Merck, who I wouldn't have expected to be open-source-friendly).

Nonetheless, that's actually my medium-term goal, so I hope you're right. ;-)

the way the economics work out, independent consultants rarely spend much time on basic research

Am I wrong to read this as: "After forty hours a week spend on doing well-paid work for clients, it's hard to find another thirty hours to scour literature and write up results, while still having a life?"

Because I'd be cautious in assuming that academics work much less than seventy hours a week. ;)

It's true, though: Doing an actual stint in academia is the right way to get a lot of scientific publications out. But: It doesn't pay well. It's not the most effective way of keeping yourself alive, or creating clear and saleable value for others. That's why I call it a hobby. You are taking time away from more valuable pursuits to advance the field, teach people, and maybe even practice a little art.

I'm sad to see that people think my use of the word hobby is so demeaning. I'm a big believer in hobbies. Here's my philosophy of the ideal life: You're born, you enjoy a series of hobbies (some of which may be deadly serious, like Steve Jobs' hobby of inventing the future), and then you die. I suppose I could look for a better word, but if the word doesn't express the concept of loads of fun it's not the right word.

Apparently writing essays on HN is the hobby of the day for me...

I'm still an undergrad so it'd be completely logical to just ignore my opinion, but..... you went from doing research to supporting PHP apps? Did you initially want to go into more researchy things and then decide "this is boring, I want to just support PHP apps instead", or did you go into research knowing you'd eventually want to do something like supporting PHP apps?

I'm unsure about my own career but going to grad school and doing research (potentially at a company, after I graduate) is definitely something I'm seriously considering, primarily because I feel like (perhaps naively, I don't know) I want to be doing more interesting, "fundamental/ground-breaking" work in cs, and not just managing PHP apps for some company, or something along those lines. I don't see much personal value/fulfillment in that.

Did you initially want to go into more researchy things and then decide "this is boring, I want to just support PHP apps instead"?

Yeah, stripped of all the romance and intrigue, that's basically it.

Things I would tell someone in your position:

Don't underestimate the wonderful things that money can do for your life.

Don't underestimate the joy of being given money by grateful customers because you have made them incredibly happy in real time by doing something that's completely trivial for you, like running EXPLAIN on a SQL query from the slow log and then doing an OPTIMIZE TABLE and a CREATE INDEX and refactoring a simple loop to use a hash properly.

Know this: Even "fundamental" and "ground-breaking" work may only be read by a few dozen people, then filed away, perhaps never to be of any use at all, except as a very important footnote in the paper that catches fire ten years from now. And the large majority of research projects take five or ten years and then fail to discover anything noteworthy. Learn to be perfectly happy with that, or do something other than research.

Do not underestimate the fundamentally slow and boring nature of research. It is a long, long game, the kind of game that started before you were born and that may make only a handful of moves in your lifetime. Your field may go backwards for decades at a time. Don't worry, do good work, all will sort itself out eventually.

You will spend literally decades getting it right, exploring all the important side tracks, perfecting the difficult techniques. Going to school in science, reading other people's science, is about novelty, because you discover new things as quickly as you can read. But your own science is about consistency. Think of Knuth, who started his grand project nearly fifty years ago and who is up to volume 4 of 7.

Remember that, by the time you are the world expert in some fundamental and ground-breaking field, it won't seem that special to you. It's like being the world expert on your own backyard. You will know more about half of the plants in your yard than mankind was meant to know, but you'll also live in secret terror because people expect you to know about the other half as well, and you know that you really don't. And, unless you're lucky and the soil in your backyard turns out to contain the cure for stomach cancer, you will never meet anyone who particularly cares that you're the world expert on your own backyard. It will bore people almost as much as talk of PHP applications bores people. [1] Except at the annual convention of backyard fetishists. There's a couple hundred of you in the world. Those conventions are the highlight of your professional year.

Read the life story of Gregor Mendel. That's you. Now, by all accounts Gregor Mendel had a pretty good life, puttering around in the pea patch, but he was out of biology, and dead, before people figured out he was on to something. That's fundamental research for you. Don't go into research because you want to be a superstar. Go into it because you like puttering around with peas and hanging out with the other smart gardeners.

Start writing a research grant today, even if the first draft sucks, even if it takes you months to read the existing literature and figure out something new and interesting to propose. I used to think it was torture for universities like MIT to force first-year grad students to pick an adviser at the time of admission and propose their own research. Now I'm not so sure. Practice grant-writing now, because that's really what your future in research is about. If you can't sell your line of research to the customer in advance, you don't want to be a researcher.

Read A Ph.D. is Not Enough, read Hamming's You and Your Research, and good luck to you! Grad school in science or engineering may or may not be a mistake in any particular case, but at least it's one of the most survivable mistakes you'll ever make.

Oh, that's right, I almost forgot: For god's sake, survive. Be alert for signs of depression. First-year grad school is overwhelming, and actually getting out of grad school can be even harder. Hardest thing I ever did.

---

[1] There is at least one exception to this rule: You can take up cancer research. The good news: People will fall over themselves to thank you for heroically working on cancer, even if all you really do is change the light bulbs in the oncology department elevator. It will be only slightly surreal. The bad news: If you actually talk about cancer, which is an absolutely fascinating subject, civilians will always be grossed out, at least subliminally. Often, they will be utterly terrified. You see, the word cancer will never again mean the same thing to you as it does to everyone else.

Just a note regarding cancer research. I'm a developer and have been to a number of conferences. The one I enjoyed the most was almost unrelated to computers - cancer research and systems biology conference. It was an amazing experience to see how much it was similar to a dev meetup. How everything you thought you knew about cancer and what people know about it (do they?) is gone now. It was great to see how cancer research has it's own mini-universe of startups, academia, corporations and simple jobs inside the larger academia container. An eye-opening experience I would really recommend. (just take a friend who can translate some crazy expressions to programmer-acceptable language)

To the list of articles to read before heading for grad school, I'd add Philip Greenspun's http://philip.greenspun.com/careers/women-in-science

I have a summary of it here: http://bfrsblog.blogspot.com/2011/07/what-every-prospective-...

And "Everything I wanted to know about C.S. graduate school at the beginning but didn't learn until later: http://www.cs.unc.edu/~azuma/hitch4.html

It's sad when academia is demoted to a "hobby." For me at least, money is less important than having discretion to work on novel projects.

Also, I never called anyone arrogant, but rather the article itself. Big difference. I don't know Patrick personally, so I wouldn't label him as such.

money is less important than having discretion to work on novel projects

Sure. Like I said: talk to me in ten years.

Maybe you'll still believe that academia gives you freedom to work on whatever you like. All my academic friends do. They are devoted and talented enough that they can soar blithely above the fact that:

A) In academia, you work where the research grants are. You are free to start a research project in an underfunded corner of academia to the precise extent that you are free to run your laboratory without any income;

B) You will spend the majority of your time writing those research grants.

C) Because your grant proposals can be anonymously torpedoed by any one of your colleagues with sufficient clout, you will actually spend a lot of time with your finger in the wind, carefully adjusting what you're working on to stay in tune with the zeitgeist.

None of the above feels much like freedom to me. Your own mileage may vary, of course. Maybe you're in CS and you can run your lab on a relative pittance. Maybe you'll meet a rich benefactor who loves to fund whatever you want to do. Maybe you can hold down a day job until your peers give you funding for your novel project, like my former field's big hero Judah Folkman did: His proposals to study antiangiogenesis went nowhere for something like fifteen years, so he just kept his day job as Director of Surgical Research at Children's Hospital Boston and kept trying. What can I say? Clearly my advice would have been useless to Folkman. Patrick and I are trying to advise the median programmer, not the fourth standard deviation.

Agree with m0th87.

Right after my undergrad, I worked in the industry for 5 years and then went to Grad school. Since completing the grad school it has been 10 more years in the industry.

My industry experience has been great so far and I love what I do. I consider my Grad school experience as an enlightening and enjoyable period of my life.

Not everyone has a bad grad school experience. No need to beat down the academic experience. A lot of people gain from it. A career in academia is not the same as being a student.

It seems to me that both are being looked down upon here.

... And am, gosh, approximately ten years behind my peers career-wise. Oh, those expensive hobbies!

That is the hardest part to stomach. I've also wasted the better part of a decade, pursuing what seems to now be "pie in the sky". Guys who got GPAs way behind me, are now way ahead of me.

I worked at a startup for 2 1/2 years, quit, went to grad school in math, did a postdoc, and am now a professor.

For me it was a wonderful choice. I didn't like the startup work for precisely the reasons patio sort of hints at. Our business was primarily about making money, and we had to focus on what customers actually wanted rather than what (I thought) would be most interesting, most challenging, or most elegant. Nothing wrong with that, but going to work was a drag in the morning.

Now there are downsides to academia -- committees, teaching freshmen who don't want to learn, and yes I have to write grant proposals -- but the bottom line is that all of my research (and most of my teaching) gives me a deep sense of satisfaction. What I am learning and teaching, mathematics, is inherently perfect -- even if our understanding of it isn't. I could not say the same of the half-baked APIs I was writing wrappers to as a professional programmer.

Now about opportunity costs... I don't follow you here. I am making about $72,000, which is about half what I could be making in the private sector. But so what? I value my time way more than I value my money, and I want to spend 9-5 everyday doing something I personally care about. And I don't place any value on luxury, which means that $70k is easily enough for me.

And, yes, I have plenty of time to spend with my hobbies, my friends, etc.

There are a lot of people who derive intense satisfaction of providing products that people in the business world need and are happy to pay money for. I have nothing to take away from them. But personally, I am a perfectionist and an idealist, and the opportunity to work in the field of "pure knowledge" is one I am immensely grateful for.

Academia has its disadvantages, but for many, it is incredible. At any rate it is for me.

I'm glad to hear it's great for you. Being a tenured professor in a field with low overhead is great.

However: The median undergraduate won't get to be a prof.

The median grad student won't get to be a prof, however much they might wish to.

In physics the median postdoc won't make it to prof. Too many postdocs. Not enough new profs.

I went to a top grad school and made a bunch of friends. Of all my Ph.D.-holding friends I know of exactly one tenured professor. He recently graduated his first Ph.D. student, who promptly got a junior faculty position. He jokes that his work is done: All of his future grad students will be aimed at positions that don't exist yet. May never exist.

I'm aware that being a successful prof seems like a fun job, just as I'm aware that being Lady Gaga is a silly and remunerative job. But when I advise anonymous people on the internet I try to advise the median person, and the median person ain't going to get tenure, just as the median musician isn't going to be Lady Gaga.

Or is it different in your field? The physicists used to dream of easier advancement in math or CS, but the grass is always greener.

Congratulations on being a winner, by the way. Have fun, and help your students have fun!

Thanks! I will have fun.

Is it different (in math)? Yes and no. There are a bunch of jobs teaching low-level courses (often 3 or 4 a semester) at teaching colleges, most of them in isolated locations, where little or no research gets done. Some people are happy to accept these, some don't want to and take industry jobs. I teach at the University of South Carolina, and with rare exceptions, our Ph.D. graduates work at these kinds of places.

I don't know how other fields are, but it is typically predictable how well grad students will do. I think grad students usually know if they have a reasonable shot at making it big (or semi-big as in my case) halfway through grad school, so they don't have to go through eight years of crap to find out.

One of the things that I see among hardworking smart people is they somehow tend to use 'difficult work' as a yardstick to measure 'good work'. Difficult work need not necessarily be good work. Unfortunately if you fall for this, you will end up wasting a lot of time, effort and energy over years and at the end wonder why you are not as rich as someone who does has half the difficult work as you do.

'Good work' or something that brings long term financial success and happiness is something that adds value to business you are serving to write software. There are also many academic kind of jobs which involve a lot of algorithms, math and precision science which won't deal with much of flavor business software has today. That's not wrong if you are a academician by profession, but that's a serious problem if you are doing software development for a living.

Much large of software development today, has got to deal with learning tools, knowing how to use a programming language to quickly turn idea to code, or fix a bug or add a feature. Apart from this you must also know how to quickly discover solutions to problems, even by searching on the internet. Being able to discover has become more important that being able to invent these days.

Additionally you must know how to push long hours, work late nights and may be on weekends. All this has fundamentally nothing to do with software.

All passion of working on something interesting, changing the world et al is perfectly acceptable in your early 20's when you relatively have lesser responsibilities. As we grow older our responsibilities will only increase, the bills and expenditure will grow up. For vast majority of people, thinking pragmatically in this case is important(I'm not saying this for everybody, some can. Not all will make it, those how will not have to take the most pragmatic way out).

That's probably why start up's are not for everyone. And that's why php et al is still alive. Anything that helps you make those first dollars will win.

This is the sad thing about the real world.

Learn, but use the most pragmatic tool at the moment to serve your business.

> "One of the things that I see among hardworking smart people is they somehow tend to use 'difficult work' as a yardstick to measure 'good work'. Difficult work need not necessarily be good work. Unfortunately if you fall for this, you will end up wasting a lot of time, effort and energy over years and at the end wonder why you are not as rich as someone who does has half the difficult work as you do."

A connection just went off in my head; this sentiment is echoed in Sirlin's 'Playing to Win' series of posts.

"I’ve never been to a tournament where there was a prize for the winner and another prize for the player who did many difficult moves."

It's good advice. I mean, enjoy solving difficult problems, but it is important to recognize that it can be... self-indulgent sometimes. There certainly exist hard problems that are also good problems, but they are not measured with the same units.

I would like to explain this in more detail. Imagine a person is working to deliver a business application, a typical application with a OO language that interacts with a database. And he sort of uses the normal set of tools for the job. He uses a version control system, bug tracking/time tracking systems. He uses scripting to do data heavy lifting tasks, he learns SQL and learns to use various features of a RDBMS. He also learns techniques for medium level scalability(learns how to use cache etc). He learns to use the IDE, the API's. He begins to learn Unix in greater detail and how to use that for development and deployment. He learns how to test, write unit tests. He also learns best practices. He does regular code reviews. He learns the process of collecting requirements, delivering finished stuff. Talking to customers etc etc.

All these things that I mentioned, have virtually very little to do with diving deep into Computer Science aspects. Yet this is the story of nearly every software shop out there. If a person can just focus on doing that stuff properly he can be a lot ahead of the regular crowd. And make real good money too.

This also the place where you can get into project management and still have you handson going. Because there aren't major paradigm changes to this once you get used to them well. All you need to do is keep in touch with some latest stuff and you can really end up making a lot of money. And still continue to climb the corporate ladder, be a good management and have good control over technical stuff.

Now image an another scenario. You join a major big web corp, they hire you to write difficult algorithm stuff. Sure your passion will help you learn. But compared to the first guy your opportunities to interact with business are so scanty you really will miss out the big money stuff. The same thing happens with start up's. Also you will no longer be the reap the management pie, you will always continue to write code. And the biggest problem with our society is management drives the value addition. You will just end up being a implementer in their hands, you won't end driving up much value and with that definition money too. Over the years you miss out on the whole ecosystem, and you just won't have flow to compete with your peers if you ever want to get back and compete with them.

Also the the first kind of jobs have many low hanging fruits to make lot of money.

Also about start up's like OP mentioned:

The high-percentage outcome is you work really hard for the next couple of years, fail ingloriously, and then be jobless and looking to get into another startup. If you really wanted to get into a startup two years out of school, you could also just go work at a megacorp for the next two years, earn a bit of money, then take your warchest, domain knowledge, and contacts and found one.

People have to understand, when you fail you loose time, and also the money which you had else made if you hadn't failed.

Sure go for the funky job. But also understand the risks behind them. Not all start up's, Big web corps are going to help you be big. There are good enough cases where people have made it big working there. But there also good enough cases where people haven't. When everything is going smooth and as expected its all milk and honey, but if it doesn't you are really toast.

I would say, Big corp jobs really are not as bad as they depicted to be. If you do the right stuff(Just do the bare minimum properly), you actually can be quite successful and go quite far both in your career and money wise.

And most important as I said, just merely doing technically difficult job automatically won't imply both career and financial success.

I don't think it's realistic for someone two years out of school to go found their own startup. It's also a mixed bag at your local Megacorp as to whether you'll be able to build the programming knowledge and domain knowledge that would assist you. I'll grant you superior contacts.

I worked for a Megacorp briefly, but it was just a couple of internships: enough to get some real experience on the resume, open-ended and unsupervised enough that I could actually learn a thing or two... but if I'd gone to work for the group that wanted to hire me afterward it would have been a complete waste of my talent as I banged my head against a legacy codebase and dozens of layers of bureaucracy. Instead I went for a little startup, worked with some seriously skilled people, and learned what the heck I was doing... and if the place had fallen apart after a year or two, I'd still have been able to get a much better job than any of my alternatives at graduation.

If you're straight out of college, don't worry much about the salary, or the size of the company -- just go for the team that you're going to learn from. It can be the difference between launching your career and running it into the ground.

You have bought some important points. And they are quite valid.

>>If you're straight out of college, don't worry much about the salary, or the size of the company -- just go for the team that you're going to learn from. It can be the difference between launching your career and running it into the ground.

I would say a MegaCorp experience is important for quite many reasons apart from just programming. There N number of things that are as important as programming to your success. Which you can't really learn in start up's for all sorts of reasons.

Initial MegaCorp experience and then followed by good start up work looks a little better to me.

True, but when entering a new line of business, the ability to solve difficult problems is a competitive advantage that a small start-up can leverage against a large company.

"Use difficulty as a guide not just in selecting the overall aim of your company, but also at decision points along the way. At Viaweb one of our rules of thumb was run upstairs. Suppose you are a little, nimble guy being chased by a big, fat, bully. You open a door and find yourself in a staircase. Do you go up or down? I say up. The bully can probably run downstairs as fast as you can. Going upstairs his bulk will be more of a disadvantage. Running upstairs is hard for you but even harder for him."

Source: http://www.paulgraham.com/wealth.html

That wasn't point of the post, the point was mere doing technically difficult work and then assuming that will help you get that edge is often wrong. Or putting it the other way, you must do what it takes.

The problem is few people take it as a gospel truth that if the problems you work on are difficult you've got win bigger than the guy working lesser difficult problems.

This goes even further with some people who consider the only way to win big is to work with difficult problems.

That is when people get it completely wrong.

Not that I disagree with the statement, but chess tournaments typically have prices for the most beautiful game. For example, http://main.uschess.org/content/view/10961/616 mentions a €500,- daily prize for such a game (in one of the strongest tournaments in the world)

I guess its only a straw man who thinks difficult problems are good for their own sake. As dlo and pg have pointed out, difficulty is a good heuristic to guide decisions. If what you are doing seems easy but is paying good, then sooner or later a lot of people will jump in to do your job or it may be outsourced.

> If you call yourself a programmer, someone is already working on a way to get you fired.

If you work at a place like that, I feel sorry for you.

Even the owner of my company lists himself on Twitter and his blog as just Programmer at RAD Game Tools. Besides being the sounding board for us when we have problems and ideas, he still writes more code than most of us can regularly muster.

Perhaps taken in context one might have read it as "if you describe your sole value as the ability to write code, someone is already working on a way to get you fired".

I understand the context. Patrick's formulation is so commonplace as to be cliche. Code is our medium of expression. There's nothing inaccurate or ignominious about describing ourselves as programmers. To say that the code exists to solve problems is to flirt with tautology.

You still miss the point, though. Patrick isn't saying that calling yourself a programmer is inaccurate or ignominious. He's saying that it's not going to have a desirable effect on the listener. He's saying you should talk about the value you create, rather than the effort you expend.

This is marketing 101- the issue is why would you work somewhere that you have to continuously market yourself just to keep your job? That's what the interview is for.

Personally in my experience working with startups, everyone at the company knows why I'm there, what I do, and there's no question about the value I bring. What I call myself just doesn't matter. I would wish this type of experience for everyone.

But Patrick specifically mentions about the majority of "programmers", those who work for companies big enough such as people above them will barely know your name. Also, be careful about the notion that there is no question about the value you bring to your company. That may be true while the company is doing well, but if the need arises to reduce costs, the question will come up.

A programmer, to me, is someone who is familiar with the entire process of software development. From gathering requirements, to designing interfaces, to writing code, to delivering and supporting the final product. I believe the term normally used to refer to someone who can only write code is code monkey.

You should get out in the real world more and especially talk to people who are not in software development.

What you call a code monkey is what the rest of the world considers a programmer.

Code monkey is not my term. I find it to be a little derogatory, personally. Still, despite that, it is the term commonly used for the job.

Most people in the real world have no idea what it takes to develop software. They believe if someone is a programmer, they can develop the entire thing from top to bottom and everything in between.

It is really only in the tech circles where people see why the job is separated out into different roles for different people. Some there equate programmer with "code monkey," but their opinion is not the norm. And one I do not agree with.

Yep. The real world says a programmer only writes code, a developer does all the rest of the work around programming as well.

Coding ability (the 99% not the 1% of elite coders) is a commodity.

"The question used to be: Does it run? That was enough, because software that worked was scarce...

So if it’s not about avoiding fatal bugs, what’s the business of software?

At its heart, you need to imagine (and then execute) a business that just happens to involve a piece of software, because it’s become clear that software alone isn’t the point. There isn’t a supply issue--it’s about demand. The business of software is now marketing (which includes design)."

http://sethgodin.typepad.com/seths_blog/2010/10/the-business...

Right... Whatever you call yourself, someone is already working on a way to get you fired. The less expenses a corporation has on personnel the better. I don't think fancy job titles are going to save anyone from automation. I hate the arrogant tone of the author.

Also, people have been saying this about programmers longer than 10 years. "Don't go into programming, you will soon be redundant". But the super general purpose code generating AI is still developed yet... Software is everywhere and we need more programmers than ever. I think a lot of other jobs will still be automated away before it's our turn.

And in that case, if computers can make those creative mind-jumps, even doctors are going to feel this, and lawyers. The end of the productive lifetime of humans will be very, very close and we'll have other things to think about such as rethinking the economic paradigm. And please let it be the arrogant MBA types for a change to be jobless. "Masters of the universe". Puke.

>If you work at a place like that, I feel sorry for you.

I came to the comments to express the same sort of opinion. I work at a place that understands and values programmers. I can't imagine working in any other kind of environment unless I was between real jobs and really strapped for cash. If you're at a place run by a bunch of clueless MBAs that don't understand the value of their in-house engineers you just don't have a good (or reliable) job.

Are those MBA's clueless? Programmers are costs, and expensive ones at that. We start off underwater on the value proposition. Saying "I'm a programmer" is saying "I'm a large, fixed cost." The question for the businessman is always: what value do you add, and does it exceed your costs?

Yes, there's value for an in-house engineering team, but with widely varying skill distributions and unevenly matched compensation. Managers know this, and Patrick's point is that "I'm a programmer" is starting off on the wrong foot as it just re-affirms that you are a large, fixed cost, saying nothing about your specific contributions.

The value of programmers tends not be linear with cost though. Paying an extra 25-50% for decent ones gets you at least a 2x improvement, possibly more if they can rewrite large chunks of your corporate code to improve it.

That's precisely my point. The question in the businessman's head is "are you one of the decent ones? are we getting our money's worth?"

Yes, and it should be, but the answer, unfortunately, is that they typically have no idea who is a good programmer and who isn't, so they only end up hiring cheap programmers.

In other words - yes, they are clueless.

> If you're at a place run by a bunch of clueless MBAs that don't understand the value of their in-house engineers you just don't have a good (or reliable) job.

That is exactly Patricks point. If you can explain to those MBAs how you make $N for the company, then your job (as long as your job costs less than $N) is safe because you're now a profit centre. You will then have turned those clueless MBAs into bosses who understands and values programmers.

I'm not too into gatekeepers, so I'd like this to be true:

you might rightfully question whether Published In A Journal is really personally or societally significant as opposed to close approximations like Wrote A Blog Post And Showed It To Smart People

But honestly I have never found a blog post that I could see as replacing journal articles, if your goal is to promote advancement of scientific knowledge. I like blogs, and read them often, but they aren't normally in-depth, with solid scientific evidence for their results, with discussion of how they relate to existing results, etc. The closest is probably in mathematics, where some of the mathematics blogging is quite high-level and results in actual new discoveries--- but those blog posts are mostly written by math professors (e.g. Terence Tao's blog), which doesn't seem to be what this article is proposing.

Where on the internet can I find blog posts of the same scientific standard that one finds in, say, http://jmlr.csail.mit.edu/ ? I read quite a few statistics, data-mining, and machine learning blogs, and while there is a lot of good content, I haven't found anything that I'd say replaces a journal article; it's more along the lines of tutorials and tips and tricks (which are also very valuable, but a different kind of contribution).

I spend a bit too much time on HN, as evidenced by the timing of this post, and one of the dangers I've noticed is that I can become so fascinated with the interesting things other hackers are doing that I lose perspective on how valuable & relatively rare my combination of skills are. I suspect this is true for others here.

Patrick gives insanely valuable advice for hackers who could be both create more value and capture more of it by being aware of the big picture & the motivations of others.

Does anyone else think that this article is in poor form?

On the perils of describing yourself as a programmer: If you're hiring someone to provide a specific skill set (programmer) you want them to be good at programming. Would you hire an accountant if they didn't know accounting? Should lawyers not describe themselves as lawyers? Doctors as doctors?

On the perils of selling yourself as an expert in a certain technology: I spend a fair amount of my time learning about the specific technologies I use. I've been doing this for a while and I don't know everything about sql, postgres, mysql, mongodb, javascript, html, css, ruby, rails, unix, chef, capistrano. But I've put thousands of hours into these things and the tools themselves took thousands of hours to create. Either I'm really bad at learning, or there is a lot to learn there and that information makes me more valuable to potential/current companies. Sure, there is a baseline level of skill you can achieve in programming where you can not suck at most stuff but there is still a lot of valuable information that you don't know if you just half assed your way through a Beginning Ruby on Rails book.

You're letting other people determine your worth using their limited domain vocabulary and their suboptimal pattern matching abilities. A .NET programmer is a highly paid commodity, but a commodity all the same.

A high-tech value creator who thinks and talks in terms of profit drivers and cost sinks is not going to ever be a commodity.

Rather than striving to be the top of your class (e.g. Ruby devops guys, which is something HR can use a standardized pay scale for) you can strive to be unique in a one-person class that is more immediately profitable and scalable than a commodity programmer.

what?

your last: - 'you can strive to be unique in a one-person class that is more immediately profitable and scalable than a commodity programmer.' seriously?

if this guy wants to become an expert in the technologies he mentioned then why is that so wrong? if he enjoys programming and has the drive to get to the top then he should absolutely go for it. smart employers are going to appreciate and see value in someone that has spent thousands of hours coding.

Think back to the now-wealthy Googler who wrote the code that 97% of $BILLIONS in revenue passes through. Do you think that person introduces him/herself as "C++ programmer with 10+ years of industry experience"?

You'll get better work on better terms if you focus on results rather than tools, even if your technical skillset is fundamentally the same as another dev with a poorer sales pitch. You're finding the best mutually beneficial business arrangements out there rather than just pursuing a predefined career track.

Edit: Mastery is its own reward. If you want to become an expert at a particular corner of technology, go ahead. Just remember to explain your work to others in terms that aren't unnecessarily limiting.

Say that person leaves google and spends all his/her money. What jobs do you think that person will be most qualified to apply to next?

Senior C++ Programmer jobs.

And what do you think they'll have to prove to potential employers? That they are capable of writing lots of C++.

You're overlooking the vast network of powerful Xoogler/VC/founder contacts this guy has surely developed in the past decade. He's also likely picked up world class experience in ecommerce, advertising, billing, and infrastructure scaling at Google.

Commodity programming is an inefficient use of this person's time and luckily he will be known and respected by enough business leaders to be able to carve out a more valuable (and again, mutually beneficial) arrangement somewhere in the Valley.

This job may involve C++ but it won't be as generic as you described. Think Paul and Bret at FriendFeed. "Python Programmers" was not their $50 million value proposition.

Reprising a comment of mine from earlier: the actual work performed by most lawyers is letter-writing at $X00 an hour. No lawyer describes themselves as a "professional letter-writer" or "professional letter-writer specializing in Mostly Empty Threats."

When "programmer" starts showing up with lawyer and doctor on "high status occupations used as the canonical examples of professional jobs since you were three years old" then programmers should definitely start describing themselves as programmers to anyone who will listen.

How about a surgeon? Their actual core competency is performing surgery. Should they not describe themselves as Surgeons?

Edit:

Are accountants high status? I'm not sure. They are generally regarded as making a fair bit of money but they are boring. Probably a bit more high status than a programmer, perhaps. But I wouldn't suggest to my accountant friends that they stop selling themselves as experts at accounting.

And anyways, high status = social status, and how is that relevant to any of your points? Social status is mostly useful for when you're trying to get laid (because that's mostly when you are trying to impress people) or prove something to your parents. We, as programmers, still get paid very well and are valued by many many companies.

The lack "high status" thing in comparison to doctors and lawyers is just because:

A) Laywers and doctors generally make more money. A lot of lawyers and doctors make over 200K. Programmers, not so much.

B) Laywers and doctors are almost certainly better educated than programmers. This education is validates a person in lots of ways, in that you are automatically learned about a variety of topics with which to converse with at parties, and that you are smart enough not only to perform as a lawyer/doctor but to achieve the level of education necessary to do so (unlike programming, where you only need to be good at your job and not necessarily good at 6+ years of higher ed).

C) The laywer and doctor professions have been around longer and are therefore safer. Doctors are the most ancient and historically valuable professions. Laywers, not nearly as much so, but for the past few hundred years they have emerged as a staple profession. I like law a lot but I would devalue lawyers over doctors a bunch.

D) It's harder to become a lawyer/doctor than a programmer, so it's a bigger achievement.

E) The jobs generally require more social skills than working with computers.

Programmers will probably never be a high status job because of the above reasons. But that doesn't really affect your argument, which is describing how you should sell yourself to potential employers.

I'd like to reiterate that I'd prefer to well rounded people who are good at programming and specifically good at our tech stack. That's the ideal. Take classic ASP.NET programmer and tell him to write a complex Ruby on Rails project and watch him flounder for months no matter how good he was at ASP.NET. There's just a lot to learn. Now, for someone who is more seasoned, used to unix, used to working with actual HTML+CSS+Javascript (instead of .net controls) used to writing tests, used to dynamic languages, that person will adjust fast, but not everyone will.

Engineering is a older profession that Medicine. Remember it was wheel and before that tools to invent the wheel that got invented.

Software is a sub branch of engineering. Like veterinary doctors. In fact man kind had taken huge leaps in engineering before they took in medicine(Stuff like Pyramids of Giza etc).

Doctors and Lawyers have a nature of work which if done badly or of subjectively low quality a persons quality of life gets very hugely impacted.

Its like high risk, high gain.

Even primitive cultures have medicine men. But they don't have engineers, at least, certainly not full-time ones.

No, they do have.

Not just primitive cultures. Even older than them. There have been huge marvels of engineering for daily lives and occupation. Like Irrigation system in Indus valley civilization(http://en.wikipedia.org/wiki/Indus_Valley_Civilization). That sort of a system can't be built by adhoc work. You will need dedicated people to plan, design and implement it. Its more or less as advanced as any decently large irrigation project today. Except that it was more difficult for them. They didn't have many things at their disposal which most engineers today have(which made their job more difficult than we can imagine)

While biological sciences were still in Infancy then.

That's why "Engineer" actually is a high-status profession. "Programmer", not so much. There is a reason many programmers have tend to refer to themselves as Software Engineers.

This is so true.

I went with my co-worker to talk with a client a few weeks ago. Even though we do the exact same thing, we introduced ourselves differently.

I said I was a programmer, and the response was "oh, that's nice"

He said he was an Engineer, and the response was "Oh, that's so impressive"

Also the fact that here in Japan the average salary for "Software Engineer" is almost twice that for "Programmer" and you can see why you would want to shy away from that nomenclature.

>> ”What is your previous salary?” is employer-speak for “Please give me reasons to pay you less money.” Answer appropriately.

What is the proper approach to answering this question?

"My previous salary is not relevant to the value I would add to your company."

Or just cite an NDA (real or imagined); most employers will back off immediately at that point since (a) they don't want to be accused of inducing you to break a contract, and (b) they probably don't want to hire people who break NDAs lightly.

'It was pretty good.' 'High, Whats your salary?'

What I said is pretty tongue in cheek, but being vague in a way that hints that it compensated well can work.

What the others in this thread said.

If that doesn't work, be prepared to give a range of "total comp" where the low end is base salary and the high end is the total cost of all your benefits + salary + bonus

"You're better situated to judge my worth to your company than I am. What do you think I should be paid?" Counter with better offer.

My other stock answer: "As a matter of professional courtesy, I decline to comment on specific policies of previous employers. You should appreciate this, after all, someday someone will be asking about yours."

EXCELLENT suggestions. I'm 100% positive that being blindsided by the "previous salary" question cost me thousands of dollars when negotiating for a previous job.

Whenever a question on salary negotiation appears on HN, I am reminded of this old comment from mahmud : http://news.ycombinator.com/item?id=1475678

I typically answer with a range where the lower end is the amount of money I'm hoping to make and the high end is $5k to $10k above that. Then I add on, "but I'm getting great benefits, so that would have to be factored in as well." My current salary doesn't really figure into my answer.

One caveat to the replies here, is not to price yourself out of the role. If you're dealing with someone smart, they will want to negotiate benefits early in the process, rather than later - exactly because of the reasons in the article.

If this is early stages of the hiring process, then just move the discussion on, "It's OK, but other things are more important to me than salary..." then ask a question about something you are interested in - vacation days, free lunches, opportunities for travel, whatever.

If you do disclose numbers at early stages, and your number is over budget, to the point where it will need the approval of senior management, then you'd better hope you're #1 on their candidate list by a good margin. No one wants to go to senior management, cap in hand, to ask for a budget extension for someone they've not yet worked with. It's too big a risk unless your reputation precedes you.

90% of programming jobs are in creating Line of Business software: Most software is not sold in boxes, available on the Internet, or downloaded from the App Store. Most software is boring one-off applications in corporations, under-girding every imaginable facet of the global economy. It tracks expenses, it optimizes shipping costs, it assists the accounting department in preparing projections, it helps design new widgets, it prices insurance policies, it flags orders for manual review by the fraud department, etc etc. Software solves business problems. Software often solves business problems despite being soul-crushingly boring and of minimal technical complexity.

Wasn't this precisely the insight of the founders of Infosys in the late 80s? Together, the Indian outsourcing giants, Infosys, TCS and Wipro have amassed huge armies of "programmers" to meet these needs. I stay away from CRUD stuff, because 1. I don't expect to be very successful competing with armies. 2. I don't like being a part of a huge army.

You are not getting the whole point about business. Businesses run on supply-demand scenarios. Only every once in a while something new comes around like iPhone, or Google search or Windows operating system etc etc. And the likeliness of you working on them are as close to negligible. Otherwise what ever you will ever work on, where ever you will ever work at, and its success will often have to often abide by the laws of supply and demand in the market. And the money and long term success flows in the direction where the supply-demand flow is.

When you are talking of big IT bellwethers, they are in a business of supplying services at affordable costs. Aren't you seeing the massive potential in this business? today maintenance and services massively outweighs product development and this is time tested truth. Because once you develop something you have to maintain it all the time. Also this is the only business, where you can retain your technical hands on and still climb the corporate management ladder. Combining both parts of the world. This will give you an edge, to add value in both areas. Also these companies, offer massive infrastructure, training and experimenting grounds which a start up in India can never possibly offer. You also get access to great books, and huge network of good people. If you are lucky you get opportunities to travel around the world, doing business,learning and enjoying various cultures around the world. Also their pay is difficult to match.

The start up scenario in India is really messed up badly. After so many years we get to see only one flipkart and Infibeam. And from what I have been hearing its no honey and milk there. Its your usual 'safest way to production' route that they take. They are generally Java heavy shops. I wonder if all this trouble is worth. If all you want to work is on Java.

After few years if you see you peer in a big IT bellwether(who is/was as good as you) being more successful in terms money and life style. Don't be surprised, he is in a place where there is steady supply of money and opportunities.

Its like you will be average among the best. And he will best among the average.

Another thing that I have noticed is start up's in India and especially founders are extremely stingy. They tend to see developers as tissues(use and throw entities). And chances of large number of people making into start up's are also lesser. And there aren't too many good start ups.

Also these Indian IT companies did a major job of propelling India to global IT forefront. If they were to go away, we will loose massive amounts of employment opportunities, exposure and more importantly confidence to open start ups in the future. Remember they were themselves start up's some time back.

The language stuff is only part true. It's true enough, perhaps, that it's not usually the most important thing to emphasize on a resume, especially if you're doing simple CRUD apps, but nevertheless programming languages and their implementations are varied and complex.

Yes, you can become productive in a new language after 6 months of using it, but most people will still have a long way to go before they can claim a reasonably high level of proficiency, especially if there's significant dissonance between the languages. Going from Java (or most languages, really) to Python isn't going to be too difficult, but a lot of that is because Python is a very easy language to get started with. But even with Python it will probably be a lot longer before you really understand some of its less obvious features, pitfalls, performance profile, and are comfortable writing idiomatic code. For a more complicated language, like Perl, or a more distant language, like Haskell, it'll probably be a lot longer.

Fantastic post. I'd also recommend any "programmers" to invest a couple years in a systems integration engineering role as well. It's generally a great place for picking up some skills many programmers / engineers lack:

* Communicating with internal and external customers

* Understand systems from a broader (higher level) perspective

* Ability to translate wants and needs to technical requirements and specifications that are implementable

* Ability to sell yourself as well as the product / service

* Give constructive criticism as an internal customer to programmers / software engineers (great chance to view the role @ 180 degrees)

I'd also add - meet all the influential people in different teams. From my limited experience, even if you're on a low position you suddenly start talking to team leaders and people who they assign to talk to you (usually the ones who have a clue). Great start for networking.

Honestly, for networking purposes, look no further than participating and volunteering in a national non-profit group. It'll give you access to both depth and breadth.

I agree wholeheartedly. That's how I promote my consulting biz, "More money for your business."

It is amazing how devs think that dollar value should equal effort. It does not. And this doesn't just apply to software. It applies to anything and everything. The value of something is what someone is willing to pay for it in that one split second when they click "charge my card".

It is amazing how devs think that dollar value should equal effort. It does not.

I think most consultants and contractors reach a point where this clicks. At first they think, well this will take me X hours, so it's worth Y dollars. Later they think, this is apparently worth X dollars to the client, so I'll bill Y dollars, where Y is way closer to X than any how-long-it-takes calculation.

It's the difference between "hard work should be rewarded" and "value should be rewarded."

Patrick has some great advice.

I'll add my own anecdote: earlier this year I had an interview which required taking a plane. I decided to wear my suit on the plane, and it was an entirely new experience. I can't put my finger on exactly what it was, but the people simply seemed nicer, more pleasant and accommodating. If you want people to think of you as a professional, dressing the part certainly helps.

I hate the fact that people get treated differently because of what they wear. It's ridiculous and unfair, but that is reality.

And that's one of the biggest things I took from this piece: Yea, it all sucks and is ridiculous most of the time, but it's the way the game is played. Play it or get left behind.

It's definitely a game. One that's rigged (and not in your favor), but you better do your best or you might not get a second chance.

Many asked how to know what programming language or stack to study. It doesn’t matter.

It does matter in so far products come and go and you don't want to accumulate knowledge on a product that's going to disappear from the market.

I worked with SGI IRIX from 1991-1996. The company has since gone bankrupt twice and IRIX has disappeared from the market. All the knowledge I accumulated on IRIX is worth nothing because it's no longer in demand. Practically noone still has IRIX machines in production.

In 1996, I switched to Linux. It had a vibrant community and you could feel it's growing rapidly. Turns out that knowledge is still valuable.

So it's really important for engineers to keep a close eye on the marketplace: If something's getting out of business or out of fashion, stop investing time in it. Instead, be on the lookout for stuff that's growing. In general, open source stuff has a longer lifetime because it can be forked if need be, wheras proprietary stuff is often problematic as companies change their mind on a whim. HP/WebOS is a recent example.

The programming language or stack does not matter to whoever is hiring you.

The fact that you knew IRIX was a good indicator that you'd be able to pick up Linux.

It's also today a good indicator that you'd be able to pick up Windows if you set your mind to it.

Your advice is solid from an engineer to engineer point of view, but Patio's advice takes an egineer to business perspective.

>Many people already successfully employed as senior engineers cannot actually implement FizzBuzz. Just read it and weep. Key takeaway: you probably are good enough to work at that company you think you’re not good enough for. They hire better mortals, but they still hire mortals.

This is one of the most important career lessons I've learned first-hand of late.

71~94: Your equity grant is worth a lump sum of money which makes you about as much money as you gave up working for the startup, instead of working for a megacorp at a higher salary with better benefits.

Or phrased differently, you get to work for a startup you believe in and enjoy instead of a soul-crushing megacorp, with (almost) no cost.

This counts as a win in my book.

You are making the assumption that working in a Start up always compensates for the losses through equity. That is true only if the Start up wins and ends making money or sells for good enough amount to money pay you that chunk.

But if it doesn't you loose time and money. And have to deal with added frustration of that loss and finding a new job.

At the same who is almost as good as you would have never been through all that. Made more money with the same learning experience as yours.

Its not about the positive scenario that's the problem here. Its the negative scenario.

The "positive" (actually breakeven) scenario is what the "71-94 roll" refers to in the OP. The more common negative scenario is if you "roll 1-70", I didn't dispute that. I simply did a half-full glass rephrasing of the 71-94 case instead of the original half-empty version.

This article has tons of gold in it besides the "don't call yourself a programmer" part. I actually thought the paragraphs past that were better, especially for the younger crowd. I want to send this post to every kid that's about to graduate college.

Great read. Probably patio11's best yet (TLDR: A summary of pretty much all his comments here on HN). Thanks.

Not very good advice. It's basically an accountants view of engineering, which can be summarized as follows:

- Only be interested in increasing profit or reducing cost

- Don't care about what you do unless it conflicts with the above

- Treat people you meet as commodities

- Produce cruddy code, because "good enough" is all that matters

- Good engineering is not a "profit center"

- Don't bother keeping up with new programming languages or new techniques

You may disagree with those views, but if they are predominant among the people who have final say in hiring you, and at what salary, then the advice is good.

The whole point of the article is to force a typical engineer to look at how most of the world perceives him, and work with that.

If you have to talk to another engineer as part of a hiring process, talk all the shop you want. If you're talking to business people, try to talk about the business advantages of what you do.

You may disagree with those views, but if they are predominant among the people who have final say in hiring you, and at what salary, then the advice is good.

Are they, though? I can see they might be if you're in consulting (as the author of this post appears to be), but I've never heard of an interview at somewhere like Google or Intel that wants to hear you talk about Providing Value; they want to know your technical skills.

No, the technical interviewers want to know your technical skills, because they advise the people who pull the trigger on your hiring whether you will provide value. Now, it's been a while, but my Google interview involved straight technical interviews and several interviews that were less about technical detail and far more about discerning my longer term value to the company.

To an extent some parts of the article can summarized as: Ok, I don't work on cool stuff like the guys at Google do, but you know what, all that doesn't matter, as I'll make way more money over my CRUD career than those guys will. And by the way, do you know who makes the most at that multinational advertising firm?...well the CRUD guys of course!

"Want to get trained on Ruby at a .NET shop? Implement a one-off project in Ruby. Bam, you are now a professional Ruby programmer — you coded Ruby and you took money for it. (You laugh? I did this at a Java shop. The one-off Ruby project made the company $30,000. My boss was, predictably, quite happy and never even asked what produced the deliverable.)"

Unless an employee actually gets permission to do this, this makes him incredibly selfish, and is a good way to get fired (and deservedly so), no matter how good he is.

Assuming he had a green light on the project itself, and it creates value, I don't see why that would be selfish.

Suppose the OP leaves. It's going to be hard for the his former coworkers to maintain the Ruby app.

If the OP did a proper job documenting his work and his former coworkers are competent, it would only be a tiny bit selfish.

And it is not unlikely that there is somebody else looking for an opportunity to put Ruby experience on her resume, and will gladly take on the maintenance. In that case you have created value for your co-workers, too.

$30,000 hard, or minor annoyance hard?

Depends on how competent his coworkers are.

Maybe "one-off" means something different where you're from, but I read it as meaning this wasn't an issue.

A classic mistake people make is assuming that something isn't an issue, when the other party DOES think it is an issue.

If you think the maintainability of a one-off script that's probably already been deleted because its job is done is that crucial, you're simply nuts. If it needs to be maintained, then by definition it is not a one-off.

Hard for them to maintain, or they wouldn't be as inclined to, if it were written in their language du jour?

Ultimately everybody leaves. Does this mean you should never change your language or technology stack?

Do what gets the job done, within reasonable limits. If the expected maintenance is minimal and you can improve your personal capability and/or produce the deliverable faster using a different technology, by all means go for it. I've had to learn languages far more unpleasant than Ruby (VBA, I'm looking right at you!!) in order to maintain programs that no one expected would ever change. That's life!

If management would like easy-to-maintain software, they are free to start prioritizing it.

Maintenance takes a lot more time than the initial implementation. By using a language nobody else knows, you increase the cost for 90% of the project's lifetime to decrease the cost of the initial 10%.

It's selfish if the numbers are such that maintenance ends up costing more than you saved by using your favorite language for the initial implementation. That depends on a lot of things: your co-workers' experience, your coding style, documentation for the language/libraries used that your co-workers aren't familiar with, etc.

For some projects maintainance cost a lot more than initial development. This is kot the case for a large segment of programs though.

Hint: any kind of problem that need only be solved once (or where it is cheaper to write the code again rather than to make it general enough for everybody) can be written however the original developer believes he will create the most value

He said a "one-off" project. Not all projects have such huge maintenance costs.

Technically, the employee would not be fired right away.

He or she, however, would be red flagged for close observation by being put on a Performance Plan.

Basically, a PP is required to legally fire you. For example, if you had a bad record of coming in at a consistent time, they could put you on a PP. In this PP (which you would have to sign as a condition of further employment), there would be a contract for coming in between 9 and 9:15 for the next thirty days, with a small margin of forgiveness. PP are used to document that you have behaved poorly or acted wrongly in the corporate context. Once you are put on a PP, it is a prelude to a firing. You can successfully get out of a PP, but it is stressful.

For the hypothetical Ruby programmer in the Java shop, the PP would probably involve something insidious like LOC.

Basically, a PP is required to legally fire you.

Where are you talking about? Laws vary, even among the states in the USA.

When I mean legally, I mean to protect the company against being sued for firing you. Yes, there are cases where there are immediate terminations. PP assist in the less egregious cases where there is gray areas. In fact, you can argue that the entire point of an HR department is to protect the company from getting sued.

It depends on the state. You can't (successfully) sue a company in Massachusetts (like California) for any reason besides discrimination. They don't need to give a reason why they fire/lay you off. They just fire you and that's how it goes. Not all states are like this.

> You can't (successfully) sue a company in Massachusetts (like California) for any reason besides discrimination.

Being fired while belonging to an Identified Minority is harassment and discrimination unless done according to a documented failure of a Personal Improvement Plan.

In California at least, employment is at-will. You can be fired for any reason (except discriminatory reasons), or even no reason at all.

PPs (and similar shenanigans) are a great way to turn your company into a smoking crater, programmer-wise. Doubly so for relatively insignificant things like not turning up at 9.00am...

Please note, he got to do this working for a boss who "never even asked what produced the deliverable".

This sounds like a very dysfunctional company in the first place.

So here's another reason not to call yourself a programmer: it suggests that you are a peon who needs micromanagement. At Japanese megacorps, which are not historically known for huge degrees of flexibility, it is assumed that Software Engineers should be able to tie their own shoelaces without needing to be told what kind of knot to use.

The boss asked for me to produce comprehensible and comprehensive documentation of 100,000 lines of Perl and gave me a two month deadline. I produced what he asked for in two weeks. The production of this involved a Ruby script.

Contra many sibling comments, delivering a higher quality product earlier than the deadline does not typically result in one getting fired, particularly when one makes a habit of making your boss look like an effing genius for managing you so well.

My take on what you said in the article was that you were encouraging developers to implement software (that was not tied into other software, but that was still used by end users) in a language that they want to learn. From what you said here, it sounds like you mean something you run just for yourself to get your work done, then toss. I thought you were suggesting doing this for actual software that is used internally or by a client, but that had no other dependencies and you could work on by yourself; as in software that may need to be maintained, have bugs that users discover that need to be fixed, etc. If you mean software for your own purposes as a tool to get a project done, but is not used at all once the project is done, and nobody will need to know or care that it existed, then my comment does not apply to that and I'm mistaken on my interpretation of your original meaning. If you mean software that is used more than once internally or by a client and you're writing it in a language that someone has to support that is NOT supported by the company you work for, then my original opinion stands ;-)

Either way, the parent to your comment has no bearing on my original comment or this one. You replied here, so I'm just replying to you.

A little cynical, but overall mostly rings true. I also have found that focusing on business/product goals and good communications skills dwarfs the ability to hack when it comes to success.

Personally, I think this is an interesting article, and I got two things out of it:

1. Effective communication with people from various backgrounds is important. This is incredibly hard, and it does require practice. Those that succeed typically communicate very well.

2. I mentally replaced the "don't call yourself a programmer" mantra for "tell people why you're doing what you do - what problem do you solve and how is it valuable". If you work for a business, you also need to have some basic understanding of business. Successful organizations probably have more people that really try to find their role in the "big picture" of the company, and they strive to use their place to create value.

I'm going to start reversing my elevator pitch. From now on I help save my company millions of dollars each year by enabling analysts to find and address operational inefficiencies in our national retail operations. Oh, and I do this by leading and implementing a range of business intelligence solutions using a suite of .NET-based BI and data warehousing tools.

I think I used to say something about programming web applications to generate numbers for middle managers to review.

I think this is the best OP has written yet. A lot of people in this thread are fighting with his b/c they make apps or run a small company.

Not living in the bay area I see what he is saying, most programmers are not selling apps, or selling small consumer applications. Most make internal apps, and many of those internal apps are more interesting than mobile apps or web apps.

I'm new to the startup game, and most of my hunches that Ive formed over the past 6+ months are proved true by this post. This is insanely good advice in this post, one of which involves modesty and confidence.

I'm never going to be modest from here on out and will act like a pompous douche when deemed necessary. I see people act this way ALL the time, and I figured people could see right through their bullshit. Apparently not, as it clearly does not matter if they are right - only if their bullshit is passable. Apparently being modest does not work to my advantage. I have no choice but to play the game.

Restrained, professional confidence will work as well or better as "pompous douche", and it won't compromise your principles.

Picture a heart surgeon. Given an opening like "Wow, you save people's lives all by yourself" he doesn't say "Oh, it's nothing", he says something like "My team saves people lives. It is a privilege to work with them."

The opposite of "modest" is not, in fact, "pompous douche". There are alternative ways of showing confidence, many of which actually incorporate substantial amounts of humility.

There are better role models, or better coaches. Keep looking. I realize it is hard, because there are a lot of complete poseurs cluttering the landscape, but keep looking.

The question you have to ask yourself is "am I an exceptional software developer?"[1]. If you are at all unsure about that then the answer is probably no (the fact you are even on here at all worrying about these things indicates the answer is no).

Given that you are not exceptional, the first thing to do is stop listening to the career advice of exceptional people: they base their advice on their own personal experience[2]. They were able to start their own successful companies, or got well rewarded and promoted/hired for top jobs at the large companies, because they are exceptional. 'Restrained confidence' won't get you very far if you don't have extraordinary skills to make you stand out; you will be competing with many others of similar skill level who are quite happy to play the 'pompous douche' character, to lie about their experience and skills and so on. That problem you solved last week that saved the company X$? Your 'pompous douche' colleague has already taken credit for it. You will be annihilated by these competitors every time unless you play the game because bosses and recruiters won't even realise you exist.

Or you could go your own way, if you are happy struggling to pay the rent every month (please don't go this route if you have family/children).

The final 'nuclear' option is to quite the entire industry for one that is less psychopathic, but I've yet to identify such an industry; if you find it please let me know.

[1] as the article points out, if you are referring to yourself as 'programmer' or 'software developer' then you have already gone wrong

[2] this is also why you shouldn't listen to people like Steve Jobs when they give a graduation speech telling you to 'take big risks because it will all work out in the end'. No shit it all works out if you are Steve Jobs, but you aren't Steve Jobs. They don't get people who took huge risks and crashed and burned to give graduation talks.

Having an over-inflated ego can backfire badly in all aspects of life. If you are involved with any aspect of engineering or delivering any good or service then as soon as you start believing that bullshit is more important than reality then you're setting yourself up for a fall of monumental proportions.

Does this cause people to read "The Genius and Tragedy of Patrick McKenzie"

http://www.sebastianmarshall.com/the-genius-and-tragedy-of-p...

(posted last month by an observer of the author of the submitted post here) with a different reaction?

It was posted in 2010 and generated the following discussion: http://apps.ycombinator.com/item?id=1720244

It seems like the author had a really hard time. If you're a software engineer, work at a software company if you want to be happy. Negotiation isn't what's going to get you the job either, programming is.

I agree. Working at a software company makes it more likely you'll enjoy your job as you're around a lot more people that just get it. In an IT dept. you're frequently battling the culture of whatever company you're in to create conditions suitable for building good software. Plus you're a little too close to the customer (the business).

Well now I can honestly reward myself for picking the University of Waterloo. All of the points made by this article are well understood by second+ years of Waterloo Engineering.

How?

The coop program i.e. the four month work then four month study program.

Except maybe for the startup stuff. That said, there are are overarching initiatives being undertaken by uWaterloo to infuse entrepreneurship and student success. The most popular one? http://velocity.uwaterloo.ca/

> Perceptive readers will note that 100 does not actually show up on a d100 or rand(100).

It also jumped out at me that the zero case is not handled (it occurs on the rand(100), if not the die).

He's got a great point about learning negotiation skills, too, but I've read a lot of things and feel that what I lack most is actual live practice. I think this is similar to the point about meeting people and shaking their hand and how different that is from meeting some person online.

>Actual grooming is at least moderately important, too, because people are hilariously easy to hack by expedients such as dressing appropriately for the situation, maintaining a professional appearance, speaking in a confident tone of voice, etc. Your business suit will probably cost about as much as a computer monitor. You only need it once in a blue moon, but when you need it you’ll be really, really, really glad that you have it. Take my word for it, if I wear everyday casual when I visit e.g. City Hall I get treated like a hapless awkward twenty-something, if I wear the suit I get treated like the CEO of a multinational company. I’m actually the awkward twenty-something CEO of a multinational company, but I get to pick which side to emphasize when I want favorable treatment from a bureaucrat.

is it really expected or even appropriate to wear a suit to an interview in the valley? i remember doing that during for my internship interview and i felt silly sitting next to my interviewer at lunch who was wearing shorts and flip flops.

The point is to dress appropriately, not to wear a suit every day. Some companies expect you to show up in a suit and some don't. So figure out which and act accordingly. If your interviewer is wearing flip-flops then you clearly overdressed.

Nowhere in the article did it suggest wearing a suit at an interview at a software company in California. That would go much too far.

And it would appear that suits make you overdressed in the software business even here in relatively staid Boston.

However, when you're going to meet with Japanese bureaucrats, or perhaps even American investment bankers, the suit might be a good idea.

Thanks for this manifesto patio11! I read it a couple of times and thought how I could apply it to my career.

There are 2 parts in it that I have difficulties with, and I'd appreciate clarifications:

-----------------------------

"In the real world, picking up a new language takes a few weeks of effort and after 6 to 12 months nobody will ever notice you haven’t been doing that one for your entire career."

How can you say that? Sure, an experienced and intelligent programmer can learn to program in Language X in a few weeks, but do you think that after a year he will reach the same level of efficiency of a similarly experienced and intelligent programmer who has 8 years of experience programming?

Sure, you'd know most of the important things that the 8-year guy knows, but I was taught that the worth of programmers is exponential to their talents. Say that if you're at the 99% percentile of Language X developers, there are (say) about 1,000 people like you in the world. If you're in the 99.99% percentlie, there are now only 10 people like you worldwide. Wouldn't that result in a much bigger price that you could put on your services?

-----------------------------

"Profit Centers are the part of an organization that bring in the bacon [...] Cost Centers are, well, everybody else. You really want to be attached to Profit Centers."

I don't understand this.

Let me see if I got the terms right: Profit Centers are "where the money comes in from", and Cost Center are "where the money comes out of". But of course, Cost Centers do not exist because CEOs are looking for ways to flush money down the tubes-- it's just that Cost Centers bring in money in indirect ways. For example, let's say that you're a CEO, and you have hired an expensive programmer to write a script that periodically checks that your backups are valid. That would qualify for a "Cost Center", right? And everyone would agree that this is a wise investment.

So what am I supposed to do if I'm hired to do this kind of job? Decline it because it's a Cost Cetner?

You also suggest to "engineer your transfer [from Cost Center to Profit Center] after joining the company". Wouldn't that be kinda douche-y? I mean, I'd be pretty pissed if I hired a guy to do Job X and then he was trying to engineer his way into Job Y because that's where the money is.

-----------------------------

Thanks again for the post!

Cost centres are to be minimised as far as possible. This occasionally means they will be minimised more than is wise and there will be an emergency when this shows up and someone has to fix it.

Nevertheless a Cost Centre is a kind of janitor, an absolutely necessary thing that should be done, at the minimum cost that lends itself to an acceptable standard. Another concept that might enlighten you in this context is Core Competency. Everything that is not this can in theory be outsourced. In practice it may not be worth outsourcing because it would cost too much in time, money or communications overhead but the company exists to charge money to do its Core Competency and everything else is detail.

Don't be detail.

If you are hired to work on a cost centre you attempt to make or save money and either get a raise/bonus for doing so, or move to where you can, whether in the company or in another one.

Finally, being only "kinda douche-y" makes you vastly less douche-y than just about everybody in the executive suite. Your colleagues are mostly not your friends. Your manager is definitely not your friend. Your manager's manger's job is partly to get as much value (work) out of people like you for the least money possible.

If you are ever in a job where you and your (over)manager are directly antagonistic run like hell, but 100% aligned incentives are very, very rare. If you want keywords try "principal agent problem".

You are not a sarariman, you will never have either job security or loyalty from above so don't act loyal from below, it just makes you a chump.

I'm not OP, but I think I can address your concerns a bit:

In the former case, I think OP's point was that being exceptionally familiar with a given language or technology is not what ultimately makes a programmer exceptionally good: that factor is platform-independent, so to speak. Being one of the 10 programmers in the world most familiar with X might be a neat thing to put on your resume (if you could prove it) but probably isn't as important to getting your job done well as the elements of your skills which apply regardless of language.

In the latter case, yes, cost centers are valuable, otherwise they wouldn't exist at all, but they're not the company's primary business, and if something needs to be cut, they'll consider ancillary stuff like this first. This is really just a repeat of the age-old advice to work at a company whose primary business is whatever it is you want to do, as that will usually get you the best treatment.

I'm not patio11, but I'll try to answer them from my perspective:

"I was taught that the worth of programmers is exponential to their talents. Say that if you're at the 99% percentile of Language X developers, there are (say) about 1,000 people like you in the world. If you're in the 99.99% percentlie, there are now only 10 people like you worldwide. Wouldn't that result in a much bigger price that you could put on your services?"

This sounds good in theory, however, there are only so many businesses that actually are in need of 'a programmer in the 99th percentile of language X'. You can find a lot more that are looking for 'a programmer that helps me make more money'.

The problem is that there's a big gap between 'being sufficient in language X' and being in the 99th percentile. If you are in the 90th percentile of language X developers, there's not much people looking for you (they need the 99th percentile guy).

"For example, let's say that you're a CEO, and you have hired an expensive programmer to write a script that periodically checks that your backups are valid. That would qualify for a "Cost Center", right? And everyone would agree that this is a wise investment.

So what am I supposed to do if I'm hired to do this kind of job? Decline it because it's a Cost Cetner?" As far as I understood the article, the point would be to look how you could communicate about the job so it would be attached to the Profit Center. Let me give it a (probably bad) try: _"I make sure company X saves 10K on manual backup verifications, which are in place to make sure they don't lose millions when a backup is required."_

A normal CEO would probably only hire you for $AMOUNT_OF_MONEY if he believes it would save him >$AMOUNT_OF_MONEY on e.g. manual labor.

"You also suggest to "engineer your transfer [from Cost Center to Profit Center] after joining the company". Wouldn't that be kinda douche-y? I mean, I'd be pretty pissed if I hired a guy to do Job X and then he was trying to engineer his way into Job Y because that's where the money is." The trick in 'transferring' to the Profit Center is part communication about your job (to your manager, CEO, clients, etc.) and the other part asking the question _"How does what I'm doing right now makes my boss money?"_ because if it doesn't make him money some how, you're probably messing around.

That said, it's really hard to connect 'bugfixes on other people's applications' to the Profit Center.

Is this article's claim about Google -- that the programmers closest to Adwords revenue have highest status (edit: and/or pay) -- true? It contradicts what I've heard.

I don't think he said they had the highest status...I think he said they were the best paid. I'm not sure if that's true or not, but it's a very different claim.

(I too have heard differently)

This is not true -- pay is not based on project.

But bonus is.

I've updated my question to make it more precise. Either way, it would contradict what I've heard.

Please, let's not play this game- what have you heard?

There's no game. I've simply heard from people who've worked at Google that the revenue-generating groups are far from the highest-respected. So I think the cited example may in fact be a counterexample. (Certainly there are many angel investors among Googlers and former Googlers who worked in all sorts of areas.) Perhaps because Google was started by programmers, programmers don't have to pretend to be something else there.

I'm no Google insider, though, which is why I'd like to hear from people who actually know.

So who, then is the highest respected?

If you go by who HN likes, I'd guess the researchers, who mostly do infrastructure and PLs type stuff-- Peter Norvig, Rob Pike, etc. But that's cheating in a way because they were already famous before Google hired them.

I'm kind of terrified of "At the end of the day, your life happiness will not be dominated by your career." Hopefully he means that primarily for employees, not for startup founders, and even then, I know a lot of people who work in research, engineering, etc. where career is by far #1.

Early in life, or as a means to an end, that's not entirely incompatible. Career success can give you a great leg up in terms of attracting a life partner or supporting a family. But the simple, sad fact is that most work that actually needs to get done is just work. There are aspects of it one can enjoy, and aspects of it one merely tolerates as a means to an end--be it the fulfilling parts of the job itself, or just making a living. It's not necessarily a healthy or fulfilling place to focus one's passions and build one's life around.

Even Steve Jobs said that having kids was more fulfilling than starting companies and creating products. If you're a startup founder, there's a few ways you can go. You can spend a few years working very hard in the hopes that you get rich. Then you have financial independence, which solves a lot of problems and allows you to focus on doing fulfilling but less lucrative things with your life. If you're not going for a huge liquidity event, you can spend a few years working very hard in the hopes that you can create a successful and sustainable business which, hopefully, you can happily spend a good long time working at in a role you created to suit your own skills and interests, like "CEO".

There are always exceptions, and there's a romantic appeal to figures like Erdos, but it's a huge disservice and a huge sense of entitlement to expect a career, of all things, to take a central place in a happy and balanced life.

Hopefully he doesn't mean it just for employees. The Hacker News community has a bent towards "startup = happiness" which I disagree with, but all things considered, is better than the screddit "eSports is important, and it's important to practice Starcraft" bent.

>>The Hacker News community has a bent towards "startup = happiness"

This is something that even I have observed, in some cases I have even seen when people take it like "only startup = happiness".

One of the takeaways I get from this is that if you can't prove value, you can't demand payment for it. Proving usually involves measuring.

How does one go about measuring? They're not about to give a "mere programmer" access to the sales data or whatever.

I recently stumbled across a web-page from the guy whose professional bio is “wrote the backend billing code that 97% of Google’s revenue passes through.” He’s now an angel investor (a polite synonym for “rich”).

Any idea who this person is?

I did appreciate the section about programmer skill and not to underestimate yourself too much, simply because it was a feel-good paragraph. By regularly reading a variety of tech blogs and trying to keep up with software goings-on, I've put myself on a drip feed that constantly reinforces: "Holy crap... every programmer out there is developing mind blowing software in languages you've never heard of in the course of a weekend. Meanwhile, you're dribbling out a few dozen lines of C in a day."

Who knows where the truth lies, but for the next few minutes I'll just enjoy the slight buzz from the article.

My employer calls me a programmer. They print it in on my business cards and hang a sign on my door that reads "Senior Systems Programmer"... so I'm a programmer and I'm not ashamed to be called that.

Seriously, how dense are you to think this article has to do with the title on your business card?

This is about programmers that seem to love to undervalue their skills, and then anonymously bitch in online forums about how stupid everyone else is and underpaid and under appreciated they are.

I only mean to point out that I don't call myself a programmer, but others do.

"Your GPA largely doesn’t matter (modulo one high profile exception: a multinational advertising firm)."

Nice jab at Google.

Enjoyed the post. Do programmers really not know who Peter Drucker is?

What language did he create?

Really.

Allow me to rephrase:

Aside from being a guy who played fast and loose with facts and was awarded a medal by a president who couldn't be bothered with facts, what solid contribution did this Drucker guy make to the art and science of programming?

It would be sort of sad for programmers to not know who Drucker was, since he's the guy who coined the term "knowledge worker" to name the class of job roles that encompasses programmers (and also a large percentage of the people who use computers and software in the business world).

(See http://en.wikipedia.org/wiki/Knowledge_worker.)

I feel like this article takes a very pessimistic view. To be great or have success in any field, doing anything, you are going to be up against "bad odds". If the odds of success were in everyone's favor then it wouldn't be "success" anymore. If anything this is a very discouraging article for people who may be aspiring to accomplish something great which I feel like the HN community is all about.

Perhaps I've misunderstood the authors intentions? The parts about young people in start-ups, and how it becomes a downward spiral if you aren't in the lucky 10% is such a negative view it hurts. Specifically the "odds" of succeeding and the relative unimportance of the connections you make during that time because [paraphrased] "most of the connections you make in the start-up world are with other start-ups who are likely to fail as well". This is just such a losing mindset to have. If the only thing you are concerned about is not failing then you have no chance to do anything of importance. The choice is yours.

I apologize if I've missed the point here as I know there were a lot of other parts in the article about adding value to your career and understanding how corporate structures work. I do believe those are great things to understand but the tone of the whole thing really struck a nerve.

Patio is like a modern day Phillip Greenspun. Trying to turn childish programmer nerds into responsible engineering professionals.

My favorite from this article: Networking: it isn’t just for TCP packets.

Seriously, get out there and grow your network. Do it by getting over being shy and smile more. Ask how you can help others. And ask for nothing in return. You will be shocked (over time) by how much you actually get back.

On the not calling yourself a programmer part: It may be a local thing, but the term engineer was usurped by government to essentially refer to someone who does things by the book. As such, engineer has come to mean someone who has trouble seeing the bigger picture and won't break some rules to deliver something amazing.

Obviously that is not true of many engineers, but the damage to the term is already done (again, perhaps only locally). I find it hard to take programmers who call themselves engineers seriously as a result, even if they are really good at what they do. My advice is not call yourself an engineer if you develop software. You want to use a title that makes people think you do amazing things.

It's a local thing.

To be honest I cringe whenever I hear programmers refer to themselves as "engineers". Maybe it's because here in canada engineering is regulated and you are not allowed to call yourself an engineer by law unless you posses an an engineering degree.

In most domains engineering is not the biggest challenge. The challenge is in a dozen intersecting domains that have little to do with engineering. Calling yourself a programmer is like a guitar make telling people he is a carpenter.

In the real world, picking up a new language takes a few weeks of effort and after 6 to 12 months nobody will ever notice you haven’t been doing that one for your entire career.

I wish more HR/recruiting people understood this.

I have put in at least a few weeks trying to learn Haskell. I certainly never got to the point of being able to solve real world problems with it. Even after 2 years of coding in C most days of the week I wouldn't claim to know it well, and wouldn't be able to keep up with a 'real' C programmer. I've also spent far more than a few weeks (cumulatively) using Javascript and don't really have a solid grasp of the language (although in that case I have made no effort to actually learn the language).

Maybe this just reflects my poor aptitude for programming and I've very much behind the curve, so to speak. In which case it is probably correct that recruiters would do well to avoid recruiting me and to filter out those who are not able to learn new languages in a few weeks.

It depends on the job, I think. I'm not even a C++ wizard myself, and yet it's pretty easy for me to tell apart the people who've been doing it for 6 months versus 6 years. If they're good, both will know the language in some sense; the main difference is that the one who's been doing it for 6 years will have a much bigger mental database of gotchas to be aware of, idioms to use in common situations, interaction between features, etc.

Somewhat true for C also. It's a much smaller language, but there's a fair amount of best-practice and idiom to pick up to be a great C programmer.

At the end of the day, your life happiness will not be dominated by your career.

That said, a crappy career can put a serious chokehold on life happiness. You spend close to half your waking hours at it, after all.

Best quote -- "He’s now an angel investor (a polite synonym for “rich”)."

Strive to help people. It is the right people to do

A heads-up for patio11: There is lots of good stuff here, but it needs to be copyedited. There are a bunch of little errors like the one quoted above.

This could be another little error, or it could be intentional. It's hard to tell:

It is <%= Date.year %>

Seems intentional. I find it slightly funny - about the same level as d100. You need to be min. lvl5 nerd to get it.

For example, consider an internal travel expense reporting form. Across a company with 2,000 employees, that might save 5,000 man-hours a year (at an average fully-loaded cost of $50 an hour) versus handling expenses on paper, for a savings of $250,000 a year.

I should have demanded a bonus for the in-house purchase req system I wrote to replace the antiquated, pen & paper system we had been using for years. I feel better about the salary I was drawing with this in mind.

This post touches on nearly everything. Some interesting snippets - well worth a read if you are a [insert appropriate spin on how you add value as a programmer].

I don't agree with everything he said, but in terms of completeness about working as a software developer vs what you learn in school this is spot on.

>If a Python shop was looking for somebody technical to make them a pile of money, the fact that I’ve never written a line of Python would not get held against me.

>Much of Fog Creek uses the Microsoft Stack. I can’t even spell ASP.NET and they’d still hire me.

A bit presumptuous, perhaps?

You might like to read this too, "Are you a programmer or a coder?" http://brajeshwar.com/2007/are-you-a-programmer-or-a-coder/

Networking, networking, networking... "The classic its not what you know but who you know". Also super confidence (even if your wrong). I wish it was different but then again I'm not smart so maybe I'm glad :)

I agree. However, I have begun modifying it slightly to describe what I think to be the true objective of what networking is: "It is not what you know but who knows you".

Paul Graham, Computer Programmer

http://en.wikipedia.org/wiki/Paul_Graham_%28computer_program...

We must create bacon, not bring it :) Like that pg's rant.

I have a degree in engineering, but when people ask me what I do, I say I'm a computer programmer because that's what I am and I'm proud of that.

"Producing beautiful software is not a goal." Speak for yourself! That is my goal; money is a mere byproduct enabling it.

This is definitely some of the best advice I've heard. Thank you very much for posting this.

Excuse me, but the company decides what the titles for positions are, not the applicants. And I'm sure no one with "Software Engineer" in their title ever got laid off. "But the article is really telling you to pick a job where you'll be considered King Shit!". Thanks for that great advice.

Is it okay with you if I call myself a programmer even if I become CEO?

fantastic article...

I think Patrick is missing a niche segment of Hackers who have been making a lot of money in last few years.They are the independent Mobile App Developer(iOS/Android)

If you choose this path then you dont even have to start a company,all you need to do is make awesome apps.It might be a little hard to start but in a year you should be making good enough money to go independent and then sky is the limit.It is not only possible but probable that you will write better applications (using services like Parse) than entire megacorps.

I'd be interested to see the stats on people making apps on HN vs people actually making a lot of money on them

Search around on HN.You will find a lot threads with Single Founder success stories in recent times.Probably more than Startup Success stories.Two names that come to mind are Instapaper and BigNoggins productions.

I think that a few posts on HN is hardly enough evidence to say that if you make apps you'll probably be making enough money to support yourself within a year of starting.

I'll just say that based only on reading his post, I'm 100% sure that Patrick wouldn't agree with your career advice.

Yes I think so too.I think this option was simply not available to Patrick when he started figuring his way out of his corporate soul-crushing job.The path that he took was probably the best under those circumstances.

But now (thanks to services like Parse,Twilio,Github and so many others) I think a good hacker has a decent chance of making it to financial independence completely on his own.

From the article: "Most software is not sold in boxes, available on the Internet, or downloaded from the App Store."

   all you need to do is make awesome apps.

Oh, is that all? </sarcasm>

The fact is that it's hard to make awesome apps or awesome anything that also makes people enough money to go entirely independent. Especially if you have a family that you need to support.

And even if you do decide to be an independent mobile app developer, parts of this article still apply to you. Your job isn't to make apps.

For example: "Engineers are hired to create business value, not to program things."

Your job is to save people time/money, entertain them, or make their lives easier by making apps.

Yes in fact that is all...when I say awesome I do mean applications that create real value for people.No bullshit...just good products that people will love to use.

You are right.If you have a family and dont really have a million saved,it is not in your best interests to quit your job and jump into the risky world of independent app development.But you can over a period of a year or two (by building up your codebase) get to a point where you are making more money than your corporate job.It is at that point that I recommend you fully jump ship.

Agreed that initially you'll have trouble understanding the market and finding applications that people really want.But once you learn to gauge the market, build awesome apps and then market them effectively to people you will lead a much better life than some 9-5 engineering manager at xyz corp filing TPS reports and sucking up to your boss for a promotion.

Judging by the current growth of smartphone market even a good calculator app is bound to make you a lot of money in the long run if you can market it effectively.

And finally if you know how to search effectively on github you will realize that most of the required classes are already built and open sourced by some hacker out there.And if not maybe you can build it and open source it for your fellow hackers.

I think you're vastly overestimating how easy this is. According to a number of studies I've seen, your odds of even making more than four figures a year are ridiculously low. If you're not in the top 10%, you basically won't make crap.

Everyone knows I pay my rent by making bingo cards for elementary schoolteachers and bear no ill will for small businesses, right?

If you are sufficiently skilled to create a popular iPhone app, you can sleepwalk your way into either $100k+ as a salaried engineer or $200+ an hour doing contracting work. The vast majority of app devs will not reach these numbers.

With all due respect...I think that the factor we are trying to maximize is not money...It is overall life satisfaction and happiness as a hacker.

Personally I would choose 80K a year building my own awesome apps ,making a name for myself,travelling the world ,meeting awesome people than making 200K at xyz corp where I spend my day exchanging bullshit emails with upper management.

I'm very, very sympathetic about those goals. :) Please do more research about the app market. Most people will not achieve $80k or anything close to it as independent app developers. I wish you every success.

I deal with app developers every day. I read a feed of iTunes store rankings regularly in the course of what I do. 80K is not an extremely rare level of success. In fact, even one of my old college buddies with a total MS-stack background has eclipsed it.

I'm not really in a position to share details, but for A-level geeks, there is much, much more than 100-200k to be made. It's true that most people won't achieve that. Much like 90% of sales-people's income are at sub-median levels, it's closer to a power distribution than a gaussian one.

> If you are sufficiently skilled to create a popular iPhone app

How much of this skill set is programming, and how much is design and marketing and the ability to navigate Apple's approval process? (Legitimate question, not rhetorical.)

But the company must be making more than 100K by employing that guy. So what does that mean? That a big company is actually a much better wealth creator than most individuals?

Good read, i totally agree with some of the points made.

How jaded.

Sounds rather like a "Guide to Success in High School" written by the guy that graduated with perfect grades but got his ass kicked every day.

Well, not everybody gets their ass kicked every day.

I absolutely cringe at the idea of a bright-eyed young programmer becoming prematurely jaded based on somebody else's experiences.

"This post aspires to be README.txt for your career as a young engineer."

Definitely failed in that regard for this young engineer and I hope it fails similarly for my cohorts.

Please back up your claims.

I'm sorry to hear that. Well, you can become jaded in the normal course of events if you prefer.

When that happens, remember that this article exists. It's good for tactics later, when you realize you can use it.

I've been programming professionally for 15 years, and programming at all for almost 25 (now I feel old). I'm a fantastically skilled, experienced and versatile programmer, even for that experience level. I am, by any reasonable metric, highly successful. I work on very interesting problems. I work for a cool yet profitable company. I do code and not management, and I otherwise get the computer programmer dream job. I may be jaded by long experience, but I'm not bitter and I have no reason to be bitter.

Patrick is totally, completely, 100% on the money with this article. Everything he says is true. Remember where you saw this so you can come back to it in a few years.

Not only that, but I am printing this article out and saving it to remind myself of how it really is and not to fool myself into ever thinking otherwise.

Whether or not a thing is true is orthogonal to whether or not you want the thing to be true.

I'm a new programmer but not new to business. He hit the nail right on the head for just about any profession (minus to the programming-specific bits).

Saying that the truth of X and the desire that X be true/false are orthogonal is rather like saying that "things just are the way they are".

While this is the case in scientific matters, it's definitely not the case in social matters. There are plenty of things that I and others can do to bring about a business climate that fixes some of the shittiness that the author lays out.

There's not a whole lot you can do about it if you're stuck working 70 hours a week for $35k a year for a boss (or series of bosses) who would very much like to send your job to India. Patrick's guide is just about how to be successful in the culture that exists now. If you manage to completely transform the tech industry, more power to you. But even if you do, that will not be tomorrow, or the day after, or even 10 years after that. Until then, Patrick's guide will continue to be useful.

You can't change other people or how they behave. The only thing you can do is to change yourself, your attitude and/or your habits. Trying to "fix" other people and the environment they've created is a waste of time and energy.

Definitely failed in that regard for this young engineer and I hope it fails similarly for my cohorts.

Counter anecdote: I wish I had read this when I was a young coder starting out. Would have saved me much time and trouble.

In fact, I think it would have spared me some of the jaded moments I've had when felt I wasn't progressing as much as I had expected.

Want to see someone get jaded fast? Keep telling them that they just need to be really good at what they do and work hard and their value will be justly rewarded.

Reply on news.ycombinator.com