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.
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.
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).
>>"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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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)."
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.
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.
> 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.
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].
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.
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.
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.
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.
"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.
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.
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.
>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.
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.
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.
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?
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".
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.
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."
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.
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.
"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.
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.
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.
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!
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
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.
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.
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...
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.
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).
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."
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.
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.
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.
273 comments
[ 3.7 ms ] story [ 157 ms ] threadPatrick 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.
* 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)
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?
(See http://en.wikipedia.org/wiki/Knowledge_worker.)
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.
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.
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.
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
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.
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.
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...
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?
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.
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.
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.
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.
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.
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.
What you call a code monkey is what the rest of the world considers a programmer.
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.
"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...
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.
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.
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.
In other words - yes, they are clueless.
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.
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.
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.
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.
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. ;)
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.
Many are driven to stick with it because if they don't, they'll get deported.
What is the proper approach to answering this question?
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.
What I said is pretty tongue in cheek, but being vague in a way that hints that it compensated well can work.
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
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."
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.)
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.
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.
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).
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.
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.
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".
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."
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.
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.
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!
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.
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 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.
Where are you talking about? Laws vary, even among the states in the USA.
Being fired while belonging to an Identified Minority is harassment and discrimination unless done according to a documented failure of a Personal Improvement Plan.
This sounds like a very dysfunctional company in the first place.
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.
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.
'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.
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.
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 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.
>>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.
"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
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.
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 think I used to say something about programming web applications to generate numbers for middle managers to review.