Do you really want to be making this much money when you're 50? - <AUTHOR> http://www.yosefk.com/blog/do-you-really-want-to-be-making-this-much-money-when-youre-50.html <comment><USER3> The author is a bit naive in his cheerleading, extrapolating his situation in his location to a nation-wide situation. That is just simply not the case.

As a business-owner in my mid-40's, I travel around quite a bit. There are locations where the employment picture is similar to what the author describes. But what he describes is far from the norm in the places I travel to, or from what I hear from friends and old coworkers during lunches. Ageism, low-salaries, "sweatshop"-like/highly-political work environments, lack of diversity in companies/economic sectors, lack of interesting problems to solve. All are observations of mine, as well as old friends' concerns voiced softly after looking over their shoulder during lunches over the past year or two.

Very good IT people (programmers/developers, DBAs, infrastructure, the whole gamut) wanting to leave their current job, but wondering where to go, because their friends in other "just as bad" companies are looking too. Discovering they can still get interviews--but maybe not the job--after age 35; and discovering the difficulty in even getting interviews after age 40. Watching their companies hire either H-1Bs for 40-50% of what they're paid, or college interns (or even recent grads for intern salaries) for even less.

Yeah, people would like to be making this much money in technology when their 50. But in most places, it's a pipe-dream.

<comment><USER4> The ageism I saw is why I decided I didn't want to be in software development for the long term and left the field.

I personally think the mentality is stupid and probably quite inefficient. In my field, law, they don't even let you into the courtroom until you're 5+ years in. Practicing law is an art and people with 20 years of experience are just better at it than people starting out. I never understood why so many people think software development is any different. Companies don't lay off their lawyers and hire fresh graduates when some new major new law goes into effect, so why do people lay off their software developers and hire fresh graduates when some major new technology becomes popular?

<comment><USER5> I wouldn't argue for ageism, but I would say programming is different from law because technology changes much faster than law. There aren't giant paradigm shifts in law every 10 years.

A new technology may in fact be much more productive to work with than an old one. Does someone with COBOL experience have an advantage or a disadvantage in learning Python vs someone who is just starting? Which is larger, the amount of useful knowledge they bring along, or the amount they have to discard?

There are sage old programmers that I look up to. But there are also a lot who just burned out and quit, tired of the new technology treadmill. I'm not sure which I'll become.

<comment><USER4> The volume of small, incremental, changes in law is higher. Let me put it this way. The Dodd-Frank regulations that have come out so far in the last two years is probably the same number of pages, printed 50 lines per page, as the C++ source for Oracle's Hotspot JVM. And it's only 30% done. And there is no ChangeLog.

The pace of paradigm shifts is indeed much faster in technology, but I disagree there are major paradigm shifts in technology every 10 years. There are major developments within specific scientific domains like AI, image recognition, etc, but in software engineering itself there is little new under the sun. There is nothing in Javascript that wasn't done better in Smalltalk 30 years ago. CoffeeScript, C#, Lua, Ruby, etc? Derivative stuff that any Lisp-er plucked out of 1985 could pick up in a week or two.

<comment><USER6> I feel like a lot of what you're talking about is applicable to languages and technologies in general. Advantageous technological knowledge seems to be more about frameworks and domain-specific experience more than anything else; something that a Lisp-er from the 1980's will have quite a steep learning curve ahead for.

Not disagreeing with your point. Just pointing out something that has been bothering me a bit about the fragmented platform market.

</comment></comment></comment></comment></comment><comment><USER7> Money is about being good at something. I know of lawyers that barely scrape by on insurance law suits because all they know how to do is prey on the fear and pain of injured people. Such lawyers have to buy $500 suits and drive BMWs and belong to country clubs to stay presentable, and thus have to scrape by on 80-100k a year.

Similarly, I know carpenters and plumbers who will get the job done - and make a lot more than the aforementioned lawyers. These pros can demand hourly rates of anywhere from $60-$80, but more often will make $250-$500/hr by quoting a job price and doing it quickly. And it's no problem for them to drive to all their appointments in their 1997 Ford E series wearing flannel and jeans.

I could also introduce you to janitors that make six figures a year because they know how to penetrate insurance bureaucracies and get black mold cleanup jobs.

If money is your aim, pick a job out of a hat and be excellent at it - and not just the actual execution, but the promotion, estimation, and pricing of your talent too. If you can get into the 25th percentile of solving problems in your expertise, you'll be well compensated for it no matter what it is.

<comment><USER8> Hogwash. For every skilled craftsman you can find, I can find ten other idiots making ten times as much money thanks to being born in the right family. Skilled developers recognize that rockstar developers can be ten times as productive as average ones. I haven't ever heard of any developers making ten times the average salary or even double the average.

Stock brokers are regularly getting beaten by monkeys when it comes to betting on the stock market, yet they are among the top earners in society. It's just insane to suggest that salaries are fair or that skill is in any way correlated to income.

Unless you believe that making lots of money proves that you are good at what you are doing, which makes the whole argument a tautology.

Edit: Also, the best work I've done is all open source. It isn't all very good stuff (far from it!), but it certainly is both more valuable and better than the corporate code I write for a living. Then there is <http://www.ohloh.net/> that tries to estimate the labour costs of various open source projects. People have plowed thousands of hours of unpaid work into some of the highest regarded software projects on earth just for fun. They will never get properly compensated for their work. "From each according to his ability, to each according to his work." is the famous slogan of Socialism, but it certainly isn't how the world currently operates.

<comment><USER4> To be fair, compensation in banking is very related to performance. Investment bankers get paid on the size of their deals, traders get paid based on how much they make, money managers get paid based on how much they bring in. The majority of people get pushed out within a few years if they aren't top performers.

The key thing to realize is that value to the customer isn't part of the performance equation. It doesn't matter if a hedge fund manager is beating the market. His performance involves how many people he brings in the door willing to pay the fund's management fees. That's the metric he's judged on.

Which brings me to your point--it's not that pay isn't correlated with skill. It's that the skill it's universally correlated with is salesmanship.

<comment><USER9>
        compensation in banking is very related to performance

The last four or five are conclusive proof that this is not even remotely true.

<comment><USER4> Those bankers that helped caused the collapse were making money hand over first for their companies, and even with the reduced profitability during the recession the banks came out way ahead.

</comment></comment></comment></comment></comment><comment><USER10> > _"The fact is that your material well-being is rarely in jeopardy because of > a missed deadline, so your reaction is fully up to you._ "

Much of what the author says is true, currently. This is a fantastic market for programmers, and anyone being born into this era is lucky.

But the forces of supply and demand will sort this market out in the future, to which the author seems ignorant. Name another profession that requires "Little or no education", and "no physical effort" (not to mention the ease of globalizing coding) that has sustained the kind of market pressure where agents are required to fend off recruiters, or kids right out of school can demand six figure salaries and four weeks of holidays right off the bat.

America (and the world) will churn out programmers until being a programmer is a marginal decision, equal among many occupations. It will lose its luster; it has already happened to lawyers. So planning on having a blase attitude towards deadlines and stress-free work in this field at 50 (assuming you're ~30 now) is a tad naive. I believe this will be an _extremely_ competitive field in 20 years.

<comment><USER11> Why isn't the field extremely competitive now? The demand has been strong for a decade and a half; it seems like a lot of time.

(I'm not sure I have an explanation myself, really; perhaps it's something innate in people and perhaps it's something about education, but the fact remains that the world still hasn't churned out enough programmers even though the incentives have been there for a long time. One possible explanation is that much of the software implements bureaucratic processes and there's always more demand for this sort of processes - so demand will outstrip supply no matter what happens at the supply side.)

<comment><USER12> "Why isn't the field extremely competitive now? "

Visas.

Most programming work (of the type talked about in the OP) originates in the USA, and most companies, even startups, need employees to come in the door everyday. (not taking on the question of whether this is ideal or not, that is the just the way it is, right now) .

Imagine (as a thought experiment) a scenario where a smart kid who lives in India or Ukraine or Africa is just able to get on a plane and land in SF for an interview or a job irrespective of whether he has the right degree, paperwork etc and without jumping through hoops at the consulate and rolling the dice.

The (edit: thanks @daladd for correction) supply would go way up and hence average salary would go down (which is why large companies are trying for more H1 Bs - they like easier availability of devs and lower salaries)

Or imagine the border with Mexico being completely officially open. See what happens to the dishwasher/fruit picker payment structure.

<comment><USER13>
      > The demand (and hence average salary) in SF for
      > programmers would go way down

Wouldn't this be detrimental to the SF area, considering as the high cost of living? I realize that cost of living will probably lower to meet what people can afford, but not without growing (or shrinking) pains, I imagine.

<comment><USER14> Detrimental for whom?

The changes to the cost of living are primarily a function of the now thousands of google and apple commuters. Not that that is stopping them from complaining when they wonder why moving up to a 2BR costs $4k/month now.

<comment><USER13> The growing pains associated with pay not meeting (or barely meeting) the cost of living.

</comment></comment></comment></comment></comment></comment><comment><USER15> I'm one of those guys programming in my 50s. Technically my jobs involve project management and consulting as well but I still love programming the most.

Saying that programming "requires little or no education" is from the perspective of either a naturally smart person or the Dunning–Kruger effect. Like any profession, there are some self-motivated people who can do the job effectively without formal education. Yet it saves time to have everyone on the same page with knowledge of basic algorithms, terminology, and problem- solving methods.

If money is your motivator for programming in your 20s, the odds are that you will find some other way to make more money and not last until you're 50. At least I hope so.

<comment><USER16> One piece of the puzzle is that programming education is not very effective. Most computer science programs teach you almost nothing about software engineering, partially because many CS profs know almost nothing about it.

<comment><USER17> I think one of the problems with software engineering is that [almost] no one knows anything about it.

I've been a working programmer [or software engineer if I've just met you at a party and I think you're cute] for long enough to work on >5 multi-billion dollar projects. Of these, one was delivered on time and according to spec. That company went down the toilet within four years.

I've read fairly widely in the software engineering literature starting with Weinberg and Brooks in university, and chasing my share of papers, 'blogs and web pages since then. One of the most positive things that has happened to the field is the recent discovery that the only thing at the end of the methodology rainbow would appear to be consultants [wearing suits with slits for the dorsal fins [h.t. Mr Stross]] and stacks of unread Learn Florble- Oriented Development in 21 days.

I know I can build complex systems. I know I can sometimes build simple systems [much much harder.] I don't know how to reliably schedule a project to build a new thing. I think anyone who thinks they do know this is delusional or lying.

And in the end, I think it probably doesn't matter. The truth of the software engineering crisis, is that it never existed. And it's possible that software engineering never existed either. We program. We do it because we like it and it pays. The folks who do it only because it pays usually end up in management fucking things up by assuming they can motivate people always and only with money.

[oh, on a tangent I've also been a manager. I wasn't all that good at it. The team I managed delivered good stuff, some of it on schedule, but the company still went belly-up. And I learned that I don't enjoy management, and would rather have less money and more fun - take from that what you will]

<comment><USER18> A multi-billion dollar project.

I can't really imagine that. Are those ever executed by a single company all on its own? Are they software-only? Do they exist outside NASA?

<comment><USER19> I think timescale may be applicable here. Some key programs for large companies will spend several million a year for several years - <USER2> if you are taking your Mainframe applications and trying to restructure them to have more easily changed business rules and a new infrastructure.

That said, I also suspect he may have been exaggerating for effect :-)

<comment><USER20> I have a friend who works for Northrop Grumman, and he just completed a $500 million project he described as "relatively small".

</comment></comment></comment></comment></comment></comment><comment><USER21> "Programmers who can program at all - as in, print out a binary tree correctly"

Strikingly succinct and useful benchmark, just sort of thrown in there like it was jam on toast.

There are some tidbits of wisdom in this article, but overall it boils down to a life that has lost all meaning and passion and has succumbed to the lowest common denominator: money. True, maybe, but sad, really.

<comment><USER22> Many people spend years or decades moving from job to job and from career to career looking for happiness. Most of them don't find it until they learn that your job just isn't what makes you happy. "Do something you love" is a myth.

Jobs are jobs because they involve a lot of crap people don't want to do. No one's going to find personal meaning by writing specs, or by cutting a beautiful design down to an ugly minimum to fit into time constraints, or by maintaining some poorly-written internal tool. But these are all things programmers will do, at some of the best jobs in the industry. Every job has a large chunk of "this sucks" work. If it's kept to a minimum, you're doing far better than most people.

<comment><USER23> >"Do something you love" is a myth.

As someone who is currently working his dream job, this statement couldn't be further from the truth.

<comment><USER22> A dream job is still a _job_. There are still parts that are tedious, and frustrating (if you're not encountering anything frustrating, you're not doing anything important), and annoying. That's why they pay you. And that's why "do what you love" is a myth. You can't always do what you love. Sometimes you have to do things you do not love, and just be happy that part of the time you get to do what you enjoy.

Far too many people chase a "dream job" not understanding that every job will have parts they simply will not love. And instead of accepting that this is reality, they fixate on the problems and fall prey to "the grass is greener" thinking. I'm sure Elon Musk loves his job (indeed he has many people's "dream job"), but I bet 90% of it is tedious bullshit.

<comment><USER24> Your argument is so weird to me. Not because I think you're wrong about every job having a bunch of tasks that are tedious and annoying, but because the same thing is true of every single thing we do in life. Jobs aren't unique in this manner, the same thing is true of any creative hobby, relationships, etc.

"Far too many people chase a "dream job" not understanding that every job will have parts they simply will not love."

I don't think that is true, I think most people realize any jobs just like anything at all in life, won't be 100% fun stuff. It is just such an obvious common sense thing that they don't bother talking about it.

<comment><USER22> > _I don't think that is true, I think most people realize any jobs just like > anything at all in life, won't be 100% fun stuff. It is just such an obvious > common sense thing that they don't bother talking about it._

I disagree. People who are _happy_ with their jobs realize this. People who switch aimlessly between jobs and careers definitely do _not_ seem to realize it. They get fed up with dealing with people, or a crappy co-worker, or whatever else they don't like about their current job and leave, assuming that somewhere is a job that doesn't have to deal shitty thing "X", not admitting that most jobs will have shitty thing "X", and the ones that don't will have shitty thing "Y" instead.

On top of this, we get sentiments like the one from calinet6, telling people that if they simply accept that they need to work for a living, then their lives must sad. "Oh, you work as a programmer for money; how sad for you." Yes, how sad that someone can make a good living in a good industry.

How sad instead that so many people look for their life's meaning at work and never find it.

</comment></comment></comment></comment></comment></comment><comment><USER25> I'm a software developer (MS Comp. Sci.) in my late thirties. I've always had the impression that software development was really well paid. But lately many of my friends (doctors, lawyers, MBAs) has started to make way more than I can get as a regular employee. And for the doctors it's all part of their standard salaries. They don't need to demonstrate any particular high level of competence. And from here on their salary will increase until retirement, while I expect mine to flatten or decrease. I love programming and didn't choose it for the money, but my view on software as a high paying job has changed. Of course everything is relative.

<comment><USER26> This is interesting. I've heard mentions of very large numbers for bankers, lawyers, doctors as they move up the career ladder, but normally involving starting their own businesses or being made partner. Do they really outearn developers significantly, even as employees? Maybe I should've stuck to trying to get into finance...although once the entrepreneurship bug bites, it isn't quite so easy.

I'm in a country where the wage difference between the protected professions and the rest is pretty large, and programmers are pretty much commodity employees with little advancement opportunities. The only way to break out seems to be entrepreneurship, but the local market isn't big enough to support big or even medium exits. I guess that's why so many people try to get into medical and law school or into i-banks.

</comment></comment><comment><USER27> I agree with many of the things written in the original post. But I definitely disagree with the notion that the barrier to entry in this profession is low and that any Joe Sixpack can start programming for a living because it's supposedly easy.

I can vividly remember my days in back in college where a lot of fellow students in my CS classes had substantial problems writing even the simplest of programs and understanding basic statements and data structures. A lot of them couldn't even write simple programs which would take user input, do something with it and give some output, let alone come up with more complicated solutions and architectures for real world problems.

This field is not for everyone and I believe that is often not obvious to many of us because we take our ability to turn mental constructs into code for granted. A lot of people just don't have the mental facilities to do it. I'm not saying this to sound elitist, but it's the way it is.

<comment><USER28> I think it's getting progressively easier. I think that back in the day before the Internet, perhaps in the mainframe days, you had to be a true wizard and know your domain extremely well to make anything happen. Think K&R kind of attitude and skill level.

Nowadays anybody with sufficiently good Googling skills can put something together by stitching pieces of Stack Overflow code. You don't need a specialist to make it happen, just about anybody will do. Perhaps you shouldn't leave mission-critical aspects of development to those people, but you can get away with most of the other work.

Was it Mark Suster who said that most companies out there do not fail because of bad technology?

</comment></comment><comment><USER29> To the pedant brigade: ease up. It's "little to now education" compared to medicine or law, where you have to toil in years in a very rigid pipeline of exams, internships and certifications. There's plenty of _learning_ in programming, but you can do with little _education_.

</comment><comment><USER30> Best quote I've read/heard all month "...but passion burns out, whereas greed is sustainable." I identified with the author and it's one of the major reasons I didn't pursue other career paths even though I could have (Lawyer, Doctor etc.) Thanks for this article.

<comment><USER31> I came here to say that this is the _most misleading_ quote I've read recently. If you're avaricious, of course you think that passion burns out, because _your passion is for money_. All of your other interests have been fleeting fancies, but you mistook them for "passions."

At the risk of introducing a Scotsman to the discussion, I suggest that passion is the only sustainable thing. If you sustain an interest in money for your whole life but not an interest in programming, or art, or writing, or Ultimate Frisbee, those other things aren't passions, they're interests or hobbies.

Greed is pretty much the definition of a passion for money. If you identify with this quote, I suggest that you modify it slightly to read, "For the greedy, a passion for making money is the only sustainable thing, all other interests burn out."

</comment></comment><comment><USER32> I think this is a bit cynical (and dangerous) but agree with the premise that currently the number of programming opportunities continues to exceed the number of programmers. However there are signs that this is changing.

I do know a programmer who became an IP attorney (doing well at it too) and a couple of programmers who have gone off to do entirely different things (one is a guide in Africa, another drives a tugboat around Puget Sound for fun and profit). I also know some who are not working at their first choice of job, rather they are working at jobs they would not have taken if they had a choice.

It is this last bit that suggests we are at the beginning of the end for the programming shortage.

NB: I think it is hilarious that the first comment is from a user named Bogdan but I suspect that is just me.

<comment><USER33> _However there are signs that this is changing._

I've been hearing this for fifteen years now, which is about as long as I've been paying attention. For the first five years I was maybe even a little concerned. (In the nineties programmers were going to become obsolete because OOP worked and all code was about to become highly reusable so there wouldn't be any need to write new code. Yes, people were saying this in earnest.)

<comment><USER32> I hear you, I don't think the change is being wrought by any magic bullet where programs write themselves, what I'm seeing is that more folks are going into programming than durable programming jobs are being created. (I use the word durable because there are lots of short term requirements.)

So this is how I look at the health of the market:

1) Does any programmer have their choice of jobs? (which is to say bargaining power when changing jobs)

2) What is the median unemployment time for programmers?

3) How are the first two mediated by contract vs full time work?

4) What are the median salaries?

What I've been seeing since the more recent depression is that unemployment median is staying fairly low but that is being achieved by an increase in the number of folks doing contracting work. Full time work (and that includes health benefits which become significantly more expensive for the 'over 50' programmer as a contractor) is getting harder to find.

As with most markets it is more clear on the 'mediocre' programmers (where mediocre is a function of code productivity) Another thing I'm seeing is salary erosion, which is to say that engineers taking lower salaries at large companies to stay employed. That also indicates a switch in the 'bargaining power' of companies looking for programmers vs the available programmers.

The sequence I've seen a number of times now with acquaintances are flat to negative salary growth when leaving one job and moving to the next. Some folks spent a year or two consulting looking for that position that would be a net gain on their salary growth.

From an economist's point of view if prices are flat to trending down it signals a shift in power from the seller to the buyer.

Those are the signs I'm seeing, would love to hear other's experiences on whether or not they think the market is saturating or not.

</comment></comment></comment><comment><USER34> I've seen all kind of different programmers. The ones that are not in it for the money and the ones that hate their job but won't switch because it has a good pay. It reminded me of this animated movie about 'what motivates us' <http://www.youtube.com/watch?v=u6XAPnuFjJc> The essence: don't underpay and don't overpay.

More and more programmers are looking for good company cultures with a good (but not highest pay). Money will make your life easier but won't make you happy.

<comment><USER35> Hooray. That is exactly what drives me too. The culture, the people, the actual work is more important.

Working for a huge amount of money in a corporate machinery is a brain killer.

<comment><USER34> Yes! But make enough money so you don't have to worry leaving the lifestyle you'd want.

</comment></comment></comment><comment><USER36> I know a programmer who became a lawyer (in Netherlands). It lifted his hourly rate 10x (50->500 EUR/hour), and while not all time is paid, and he isn't working full time having a lot of time to spare, he's getting like 2x than before.

<comment><USER11> That's rather nice indeed; I think the mean earnings for lawyers aren't that high and there's quite a lot of variance, not?

(Unfortunately, this is a theoretical discussion for me, since I'd make a lousy lawyer.)

<comment><USER33> The starting salary distribution for a lawyer is an interesting graph: <http://www.nalp.org/salarydistrib>

Basically, after graduating from a law school you either get hired by a good law firm or not. In the former case, which happens to some 20% of graduates, your starting salary will be $160k. In the latter case your salary will be dictated by an unexciting distribution with the peak around $50k.

</comment></comment></comment><comment><USER37> Just a few comments on a well-written article that makes some good points:

> No health or legal risks

On the contrary -- the health risk arises primarily because of the sedentary lifestyle. It's hard to imagine anything so hard on one's health and longevity prospects as sitting and typing all day.

As to legal risks, they're certainly on the upswing, as people who can't program try to steal the work of those who can, and as people try to take generic methods, known to all, and turn them into private property.

Apart from those quibbles, a nice article.

<comment><USER11> I think programming and exercising is healthier than, say, moving.

As to legal risks - it's not the programmer who's facing them, it's his employer (which is the same thing for the self-employed programmers, but they're few). A programmer will not be personally sued for any sort of "IP infringement".

<comment><USER37> > As to legal risks - it's not the programmer who's facing them, it's his > employer

I didn't consider this angle, because I've always been my own boss. I've never written programs for anyone else, which means I took home the money, not the grief.

<http://en.wikipedia.org/wiki/Paul_Lutus>

But as time passes, I see more and more cases where someone tries to patent something that should never be patented, which might eventually prevent people from writing programs at all.

</comment></comment></comment><comment><USER38> It's posts like these that get me as a programmer worried. Arrogance tends to lead to bad things and the world can change at a pace greater than one can imagine (a good way for me to understand how swiftly things change is to ask myself: Could I have foreseen x years ago what I am be doing today? for me, using the relatively low value of x=5 the answer is a definitive no. And I think that's a good thing).

Be humble if people are willing to pay you more money than others for what you do - it might change incredibly fast. The more generic assumption of the post is that people are willing to pay good money for skills that are relatively rare... well, make sure to keep your skill set up to date.

<comment><USER11> Don't get me wrong - I'm rather paranoid, and I'm not sure at all that this will last. All I'm saying is, the alternatives I know about aren't necessarily better, and if one talks about quitting the field because it's not enjoyable (without mentioning money), then my question - from an angle not unlike yours, I think - my question is, so what's your alternative way to make money.

</comment></comment><comment><USER39> Also, in what other job can you build your own little slaves to do some of your work for you? You don't even have to tell anyone.

<comment><USER40> Farming :-)

<comment><USER41> Farming is undergoing a similar talent crunch right now. If you are in the right parts of the world and have a little skill behind your name, you can easily make $50/hr as a farmhand.

Food and tech is where investors are piling all their money right now. As both a software developer and farmer, I do fear what will happen when investments start going elsewhere.

<comment><USER42> I don't know what to make of this. In New Zealand, a farm hand will probably earn a bit more than someone working at McDonalds, and they'll work a lot more too.

<comment><USER41> I cannot speak to the economics of New Zealand specifically, but there is a huge difference between a skilled farmhand and a farmhand. I referred to the former in my earlier post.

A skilled farmhand is someone who has, well, skills. They probably have a commercial drivers licence, background in mechanical work or dealing with animals, and have spent a lot of time operating heavy equipment. Those kind of people are rare, but can be paid well when you find them.

Someone without skills on the farm will probably be paid as you describe no matter where the location.

</comment></comment></comment></comment></comment><comment><USER43> I am grateful that I am able to make a lot of money doing something that is fun for me anyways, programming computers. However, a fool and his gold are soon parted. There are some programs best left unwritten, for any amount of money. And some programs worth no money, yet most valuable.

The freedom from work as we know it, is the dream that technology is meant to bring... to _everyone_. When I am 50, I hope that how much money I am making will be largely irrelevant due to advances in technology and society.

</comment><comment><USER44> >" _No health (...) risks_ "

I'd like to see some research to back up this claim, but I'm not aware of any studies into occupational health for programmers. Does anyone know of any?

<comment><USER45> Can't think of any offhand, but I anecdotally, tendonitis is a huge risk for programmers.

While you can't claim "no health risks", they are pretty low as far as jobs are concerned.

</comment></comment><comment><USER46> If what's described is true:

a) Tons of money to be made b) Tons of unmet demand

Why the outsourcing market isn't growing as much as it should? There are plenty of places with more than capable programmers which are usually paid in peanuts not only when compared with SV, but when compared to people in the same country.

That smells like a niche waiting to be disrupted. He who solves the trust and quality perception and control issues, will become very rich.

<comment><USER47> The problem with outsourcing is not 'quality perception,' it's the actual quality.

The good programmers around the world command good salaries, whether out- sourced or not.

In the end it doesn't matter whether you're in India or the the US; there are just not that many great programmers around.

<comment><USER46> That's why I said quality perception _and control_. This is, making sure you are producing what's needed.

As to the rest, I'm baffled. How can you even think it doesn't matter where you are?

Different cultures value differently different jobs. For example, I know of places where programmers are not valued much and it doesn't matter how good you are, you'll not earn more than a corporate salesman.

Maybe it doesn't matter for the top 0.5% who end up going to work for Google or Facebook anyway. But there are lots of jobs for merely above average programmers, which are very well compensated in the US, but not at all well elsewhere.

<comment><USER48> disrupting culture sounds hard. Software isn't a field students in china work towards because there just isn't as many jobs there as other fields. The pay is fairly mediocre so top students from universities aren't exactly dying to get into that field. It may take at least a generation or two to convince the masses that software engineering is just a good of a job as chemical engineering.

<comment><USER46> The point is you don't need to disrupt that culture. That culture is in fact what would permit the idea to work. There are badly paid good programmers already in China and elsewhere.

If you can manage to produce quality work and convince people to hire you consistently (big if, I know) in the high paying market, you can leverage the existing programming population oferring wages a lot higher.

</comment></comment></comment></comment></comment><comment><USER49> One of the biggest reason there aren't that many 50-year-old programmers is that a lot of programmers move to other roles in the same company, like line manager, project manager, product manager or various sales roles.

<comment><USER50> Agreed - the emergence of career progression (ie monetary progression) based on technical qualities rather than managerial ones is only a fairly recent phenomenon... at least, in all the companies I have worked for (large enterprise).

It's not surprising many former programmers of that vintage are in the managerial ranks now. Whether that is a good or bad thing, I'm not sure.

<comment><USER49> I think it's mostly a good thing. Having worked yourself as a programmer makes you a better manager of programmers in my experience.

</comment></comment></comment><comment><USER35> If you're into programmer and not in it for the passion there is a high chance that you're a mediocre programmer.

But indeed that doesnt matter. Because the demand is high.

But for me, this is what drives me: working with an excellent team on a product/service that is heavily used and comes with technical challenges.

If managers, business and bad programmers interfere with this, i'd rather stop and get a decent job.

The money is not the main driver.

<comment><USER51> Judging by OP's blog, I'd say he's passionate. Look at his other articles.

He says he's "in it for the money" because he's honest. No one working to earn a living is _not_ in it for the money, and if they tell you otherwise they're delusional. I think the measure should be "Would you still program if this wasn't your job?" and if the answer is yes, then the passion is there.

I really hate it when people decry the importance of money, because money is basically our unit of human sustenance. It is what we trade for food, shelter, and clothing.

<comment><USER35> Off course everybody needs money to survive. But when choosing a profession, some people choose to be an attorney because they can get a big salery.

However I choose computer science because of the passion. I also had a passion for making music. But the passion and the money are the drivers. But the _main_ driver is not the money.

<comment><USER48> I guess that could still depend -- suppose the individual in question made lots of money by selling a software product, and develops a passion for it due to the payout. Does it matter if he was initially passionate, or only after making the money?

A friend of mine hated piano as a child, only after many forced hours of practice (from his tiger mom) he became really good and started to win state championships for his ability. After a few more years, he developed a passion for it and played piano for fun. He never liked piano to begin with, but when he became good at it, he developed that passion.

So I'd argue that a bad programmer, after making some decent money, can become passionate at it when the initial driver started as money.

<comment><USER52> Do you by chance read Cal Newport's blog? or have read his recent book "So Good They Can't Ignore You: Why Skills Trump Passion in the Quest for Work You Love"

<comment><USER48> nope, did he form the same opinion as mine?

<comment><USER52> yup

</comment></comment></comment></comment></comment></comment></comment><comment><USER53> "Little or no required education" really? Sitting at the cashier requires little or no education, but doing programming requires much more education (either on your own or someone has to teach you). From my perspective a lot people I know aren't capable of programming just as they are unable to solve mathematical problems (and a lot of people can't even do basic math when buying at grocery store).

Not to mention that here where I work you are tested for your knowledge and problem solving skills - so although there is a high demand there are still very few that are hired.

BTW. About 15 years ago I heard that it's not a good choice to go and study computer science because there are a lot of others that do it and the market will be saturated. And we know how it is saturated right now (it isn't). There are more and more "places" where software wasn't needed before (e.g. cars, TVs) and now it is required - demand for programmers increases.

</comment><comment><USER54> You dont necessarily need FORMAL education, but you have to learn alot to be a good programmer. Its alot about training, experience and talent...

</comment><comment> UK-AL Basic Economics states that with a low barrier to entry and large salary means it won't be for very long. Wish we would professionalise. In the UK now there are software dev jobs being advertised for minimum wage.

<comment><USER55> I think the barrier to entry to be "good" is fairly high, it just isn't artificial, like most barriers. There is no certification, money, or time barrier artificially constraining supply.

You need persistence, logical (not magical) thinking, willingness to learn a tremendous amount of material, and the ability to envision abstraction in order to become a programmer. These skills co-occur in only a limited portion of the population and of that, only a subset would be willing to live the programmer lifestyle (indoor, bad for extroverts, sedentary, not so high- status as being a Dr.)

</comment></comment><comment><USER56> I've often times felt guilty that this is almost exactly the reason why I program. I like programming but I also like the salary and benefits. I can then use my 5-9 time to do all the other things I like: cooking, working-out, hiking.

That said, I recently founded a startup, where the work is more stressful and the pay is less and I'm hoping for it all to be worth it financially in a few years. This is often not the traditional "Why I founded a company" story you read about hear on HN, but I wonder how common (or misguided) it is.

<comment><USER57> If financial independence is your only goal, you've stared a startup for the wrong reason.

</comment></comment><comment><USER58> One reason I'm not confident that the supply problem will be solved anytime soon:

[http://marginalrevolution.com/marginalrevolution/2011/11/col...](http://marginalrevolution.com/marginalrevolution/2011/11/college- has-been-oversold.html)

Given that college has been incredibly (over)promoted over the past 20 years and that CS jobs have become more lucrative if anything, the conclusion I drew from this is that there just aren't very many engineers on the margin.

</comment><comment><USER59> Nice to hear such an optimistic viewpoint. I find some comfortable truths in this essay, but he kind of glosses over some major things.

The moving targets that are the latest fads in languages (every six years a new "generation" does the same old thing their way) and shifts in market demand certainly create an environment requiring constant learning. Unless you're in business for yourself and taking on more risk and stress, your earnings will top out in the low six-figures so you have to value daily comfort and health insurance over any grand ambition or ability to disappear for months at a time. Outsourcing and immigrants willing to work longer hours for less money are a constant macro threat to this comfort zone too.

To say that it requires almost no education isn't true. An engineering or computer science degree surely makes it easier to get a job. Whether that training makes a difference at work if you started coding at age 9 anyway is debatable but a degree gets you recognition as a professional and shows that you have deep cross-training in math and physics.

I do agree coding non-mission critical applications is pretty low stress and for the most part you have a chance at a decent quality of life.

</comment><comment><USER60> I have a suspicion (albeit a light one), that programming in itself will become a commodity skill, like "good writing" (something you _have_ to know to score well on the SAT/GRE).

It would become a necessary skill that simply everyone in a wide variety of fields (doctors, accountants, etc) where programming is the slightest bit helpful would have.

In such an age and era, will programmers get paid anything close to what they get paid today?

<comment><USER61> You seem to have "good writing". Could you write a novel, with a captivating, nonobvious plot, interesting characters and a twist ending?

You probably can score ok in a math SAT. Can you visualize the mathematics of a quaternion, or formulate the equation for an n-sided betzier patch?

The work a linguistic/novelist/journalist or a mathematican is not on the highscool level. Neither is the work of a programmer.

I do believe basic programming should be taught, just like basic math and writing skills. But that has absolutely nothing to do with proffessional programming.

</comment></comment><comment><USER62> _passion burns out, whereas greed is sustainable_

This blog entry seems to have been written so that it can end up with this sentence and not read cynical.

</comment><comment><USER63> Either the system is broken, or some people are just _gasp_ not motivated as much by money. There are quite a few internships in programming (just check out glassdoor) that pay about as much as a tenure-track professor, and these days with all the shenanigans in academia I would be hesitant to make a judgement on which will provide better job security...

So the economy rewards someone building facebook or groupon more than someone with a PHD and multiple post-docs doing basic research, and while the developers for said companies do add a tremendous amount of value, which is reflected in their sallary -- IMO it is more likely that DARPA or a similar government body is more likely to develop the next step in innovation. Siri was originally a government project, that was then commercialized from CALO. <http://en.wikipedia.org/wiki/CALO> Same goes for the internet.

</comment><comment><USER64> Good post. I've been doing this for many years now though and I've been burnt out after maybe the first 4-5 on coding, but that is still what I do. It really is about the money though. Early on I had the idea that I would become an architect get all of the certifications (back when that meant something), work my way up management and have a house at the beach, at the lake, and in the mountains. Ha. Yeah, I should have known. Right now I'm hoping that telecommuting becomes the norm. I love working from home, but I don't think I could make what I'm making now as a contractor doing Rails development, which is now primarily what I do. As long as I continue to be employed, I guess that is the main thing. And I guess that is the point of the post.

</comment><comment><USER65> This is a nice response to the other blog post. It is amazing how privileged your life gets when you can do black magic with code that most people don't even dream of ever being able to understand.

However, I disagree with this statement: "So I'm not planning to quit programming, not because it's such a great source of joy by itself, but because it looks so good compared to just about anything else."

Well, I wouldn't want to miss the high I get from being in the zone for four hours straight either. I wonder if the author implies that programming is no longer fun to him or if its just not the deciding factor. To me, the fun in coding is really a big part of my overall happiness and so contributes a large part of the decision to stay in the field.

<comment><USER11> It's a lot of fun, but not the deciding factor. I have a great gig now, but it won't necessarily last, and I won't necessarily be able to get a similar job (it's in hardware architecture and software tools and there are likely to be less jobs in these things over time, though not necessarily). I'm not sure the typical programming job is that much fun for me, but it's decent enough and the question always is what you'd do if you decided to leave the field.

</comment></comment><comment><USER66> I did not even get past the first 100 lines before I want to give this blog post a score off the charts. We need more people programming, lots more, with the honesty and humility of the author. Thank you for saying what you said.

yosefk.com +10000

</comment><comment><USER67> Perhaps I can add my experience in this. I was very good at programming in college. I was one of those guys that left the labs under the hatefull gaze of the entire lab section having finished his assignment early. And boy I loved it too. I was so happy having finished a large programming project or a large engineering design assignment. After getting an interesting assignment I would literally skip on the way back home daydreaming about how I will write it. I was not at the best university, mostly because I was an immigrant so I was not able to get good grades/sat scores, but it was a very decent state school.

But while in college I saw that most powerful people in america were lawyers of some kind. These were the days of the Clintons, btw. Then I got into my stupid head that perhaps I should go to law school. You know in order to join the power elite and make a difference and all that.

By that time my english was very good, and being naturally intelligent (I will not bore you with false modesty), I got into some of the very best law schools in America. I chose one and did very well there and got jobs at some very prestigous top law firms. Basically, for a while I had the promise of a career that most lawyers would dream of.

But now this is all in shambles and I am thinking of getting back into engineering or something more closely related to technology.

Oscar Wilde said something very wise (paraphrasing): "I used to have the life of my dreams and I was happy; now I have the life of everybody else's dreams and it is incredibly tiresome"

So my advice is if you are one of those natural programmers by all means do it, and do not ever think about what other people say about "what would you be doing when you are 50." Yosef (the author of this article) is one of those people, and to him the answer is very simple and very happy: "programming".

You see this question of "can you see yourself as a programmer when you are 50" does not have much to do with ageism or the labor market but about people's inner feelings and desires. Some people are horrified to see themselves as programmers when they are 50, not because of the market but because they secretly loathe it. And to see themselves doing it when they are 50 seems like a life sentence. For others, it is the most natural thing in the world.

I remember when I was a lawyer I once had an especially good stretch. Some of our top clients complimented my work. This is a big deal because those clients spent crazy money on fees and it is very rare for anyone to complement a lawyer's work. I thought to myself "wow keep going and you will be a partner in no time". Then I thought about life as a lawyer, doing the same thing over and over again, for the rest of my life and it was the most depressing thing ever. It was horrifying and the thought about multi-million dollar salaries did not help (although now in my much more perilous situation those salaries sure seem nice). I got into a serious depression and that badly affected my work thereafter.

So my advice is, if you are good at programming, if you are one of those few for whom this stuff just clicks, go for it and do not listen what anyone says about markets, or ageism etc. Note that those that are really good at programming are very few. Even among programmers, I would say that those to whom programming is annoying and a little scary greatly outnumber the ones that have real talent for it.

So people will generally give you many reasons to move away from it, but those are their reasons, not yours. If you are part of this select group just count your blessings. And here are some of these blessings:

1\. You know how rare it is to have a passion and talent for something, and at the same time have that something be valuable and useful. Think of all the brilliant and passionate people that are into disciplines where only a few thousand people in the world get a decent income. Think of all dancers, screenwrights, directors, painters, poets, chess players, etc.

2\. You have a wonderful differentiator of skill and ability: things either work or not. When I was a lawyer I had to compete with so many hacks. When I would stay up nights writing complex documents, trying to phrase every single word just the right way, when I would stress out for hours about a particular phrasing or argument, they would slap something together quickly and with no second thought. And their work would look like mine to the client. The consequences of bad legal work are uncertain and tend to be much delayed.

3\. Your craft requires very little investment. Again, you have no idea how lucky that is. Even startups that require capital, get it mostly for salaries. There is no expensive equipment to purchase, etc. Marx thought so much about how to connect workers to their means of production, and in the end came up with a theory that turned out into a complete disaster and caused untold tradegy. If he only knew that some day there would be a sub $500 means of production that can create wealth worth millions he would not go into silly plans about dictatorship of the proletariat.

There is more but I have rambled enough. Heed my advice. If you are one of the lucky ones, ignore what the less lucky ones are saying and do not squander your good fortune.

<comment><USER68> This sort of intelligent reflection on personal experience makes for valuable comments.

Particularly good: "You see this question of 'can you see yourself as a programmer when you are 50' does not have much to do with ageism or the labor market but about people's inner feelings and desires. Some people are horrified to see themselves as programmers when they are 50, not because of the market but because they secretly loathe it."

I hope you do get back into engineering, and write about it.

<comment><USER67> Thanks for the encouragement.

</comment></comment></comment><comment><USER69> Why are all these posts talking about 50?

Retirement in Canada just got pushed to 67, and I think most people expect it will go out to 69 before we actually get to retire (I'm 30 now).

All these titles should say " _Do you really want to be doing this at 66_ "

<comment><USER41> Given the article, the additional income over of a programmer over the average income earner should be, if saved carefully, enough money to cover the years between 50 and 69 to retire, if you so desire.

</comment></comment><comment><USER70> You don't get what you deserve, you get what you negotiate. Being good at the job or the market demand or the right size of a company are small variables against your ability to negotiate the rate you want.

</comment><comment><USER71> If this fellow truly has no passion for his craft, I hope he can find the energy to constantly update his skills when he's 50.

I started in FORTRAN in 1968. Today I'm working in Java and MongoDB and studying Scala and Go.

<comment><USER72> If you have followed his blog posts for a long time. He is very crafty in all low level programming that most of us are incapable of. And he also wrote his reflection on C++ programming language in C++ Frequently Questioned Answers.

Also I like this post from him a lot. He just likes to say things more frankly.

<http://www.yosefk.com/blog/work-on-unimportant-problems.html>

</comment></comment><comment><USER73> Pretty much.

There's also tremendous scope for working from home, or from wherever you want. I can imagine it getting to the stage where job ads for developers will advertise perks like 'work from the beach!'

I'm not a full-time developer (though my work involves programming), but I know what I want to be doing in my 30s, 40s... Not just because I like it but because it gives you so much freedom in terms of lifestyle.

<comment><USER74> I've done programming, functional management and product management. Today, I'm back to programming for exactly this reason. I work remotely, can take 20 minutes to run my kids somewhere or just to sit and listen to the latest problem at school that day. Given how little time I have left with my kids as kids (and how much I wasted chasing a "career"), this alone is worth as much as my salary.

</comment></comment><comment><USER75> Is anyone concerned that over the next 10+ years after many people realize how lucrative the work is that supply will catch up with demand?

<comment><USER76> It's happening already - a lot of my liberal-arts friends are retraining as programmers - but the thing is that it takes 10 years to develop expertise in a skill. So the market for _good_ programmers will remain untouched for the foreseeable future, and that should give the alert ones plenty of time to skate to a different point in the value chain if market conditions start changing.

</comment></comment><comment><USER77> _> Give me a profession remotely close to programming in the following ways: Little or no required education..._

 _> Programming is money for nothing._

This is not called programming. It's called monkey job. Programming requires education (i.e. being a knowledgeable professional in computing, software engineering and so on) and it's not money for nothing by any means.

<comment><USER28> Agreed. You can do a lot in programming without much knowledge, but a lot of the really good opportunities and interesting work are reserved to those who have superior domain expertise.

</comment></comment><comment><USER78> Passion only burns out if you consistently fail to pace yourself, or if it wasn't really innate passion in the first place.

</comment><comment><USER79> > I haven't met programmers who became lawyers.

For what it's worth, I'm a programmer in the middle of law school.

<comment><USER40> Many do, such as Google's Dan Berlin and huge chunks of the IP law field.

<comment><USER80> And in constitutional law, Eugene Volokh of the Volokh Conspiracy (<http://www.volokh.com/>).

</comment></comment></comment><comment><USER81> If money is your primary motivation for any long term choices, you are doing something wrong.

</comment><comment><USER82> Honestly, I don't want to read articles about "doing x when you're 50" when I'm 50.

</comment><comment><USER83> You won't have to worry about that. They'll be hiring 23 year old Stanford kids who don't have a family and who can pull all nighters. They won't be hiring you.

</comment><comment><USER84> Computer programming jobs in the USA have been in decline since 1990.

Stats from the Bureau of Labor Statistics (USA):

[http://www.bls.gov/ooh/computer-and-information- technology/c...](http://www.bls.gov/ooh/computer-and-information- technology/computer-programmers.htm)

2010 Median Pay $71,380 per year $34.32 per hour

Number of Jobs, 2010 363,100

Job Outlook, 2010-20 12% (About as fast as average)

Especially worth a look:

<http://americawhatwentwrong.org/story/programming-jobs-fall/>

"Over and over, Americans are told that education is the key to their job future. The more education you have, the better your shot at getting a job that pays middle-income wages to take care of your family. If we as a nation are better educated, the theory goes, we'll be able to compete more effectively in the global economy, which in turn will generate more good jobs for everyone.

But some major flaws in this theory are playing out today in a field that was once thought to have the brightest future — information technology...

...In its 1990 Occupational Outlook Handbook, the U.S. Department of Labor was especially bullish: "The need for programmers will increase as businesses, government, schools and scientific organizations seek new applications for computers and improvements to the software already in use [and] further automation . . . will drive the growth of programmer employment." The report predicted that the greatest demand would be for programmers with four years of college who would earn above-average salaries.

In 2000, the Labor Department predicted America would have 839,000 computer programming jobs by 2008. The department warned of competition from "programming businesses overseas where much routine work can be outsourced at a lower cost," but was nonetheless confident that "jobs for both systems and applications programmers should be plentiful." Things didn't quite work out that way. The number of programming jobs has fallen steadily, in part because of outsourcing.

When Labor made these projections in 1990, there were 565,000 computer programmers. With computer usage expanding, the department predicted that "employment of programmers is expected to grow much faster than the average for all occupations through the year 2005 . . ."

It didn't. Employment fluctuated in the years following the report, then settled into a slow downward pattern after 2000. By 2002, the number of programmers had slipped to 499,000. That was down 12 percent–not up–from 1990. Nonetheless, the Labor Department was still optimistic that the field would create jobs–not at the robust rate the agency had predicted, but at least at the same rate as the economy as a whole.

Wrong again. By 2006, with the actual number of programming jobs continuing to decline, even that illusion couldn't be maintained. With the number of jobs falling to 435,000, or 130,000 fewer than in 1990, Labor finally acknowledged that jobs in computer programming were "expected to decline slowly." "

<comment><USER85> Programmer is a distinct job from software developer.

[http://www.bls.gov/ooh/computer-and-information- technology/s...](http://www.bls.gov/ooh/computer-and-information- technology/software-developers.htm)

2010 Median Pay $90,530 per year $43.52 per hour

Number of Jobs, 2010 913,100

Job Outlook, 2010-20 30% (Much faster than average)

Employment Change, 2010-20 270,900</comment></comment>


Ill-Advised C++ Rant, Part 2 - <AUTHOR> http://www.codersnotes.com/notes/cpp-rant-2/ <comment><USER2> Just to note, the proposal the author lists as "so complicated" is actually just fixing an inconsistency in the grammar where "class" and "typename" are not always synonymous in the context of template declarations. Specifically:

        template<class T> class Foo;
        template<typename T> class Foo;

Are the same. But, not when declaring a template with a parameter that is itself a template:

        template<template<typename> class T> struct Foo;    // Compiles
        template<template<typename> typename T> struct Foo; // Does not compile

The proposal allows the second form to compile, fixing this inconsistency.

</comment><comment><USER3> > Calculating the size of a static array.

std::size is in C++17: [http://en.cppreference.com/w/cpp/iterator/size](http://en.cppreference.com/w/cpp/iterator/size)

</comment><comment><USER4> I mean, finally getting standard networking and filesystem libraries is a really nice thing...

<comment><USER5> It depends on your definition of "standard." POSIX is a standard, and it's the standard nearly everybody has used for networking and filesystem access.

<comment><USER4> Yeah, writing C++ code that works on both Windows and *Nix means I can't use straight POSIX, and usually wind up with Boost ASIO and Filesystem. Putting them into the standard library means I've got two fewer libraries I need to worry about in autoconf.

</comment></comment></comment><comment><USER6> I tend to agree, but gave up on fixing C++ a decade ago.

I hope Rust is the future; it deals with all these issues. But Rust seems to be starting out at the complexity level it took C++ two decades to achieve.

<comment><USER7>
      > Rust seems to be starting out at the complexity level it
      > took C++ two decades to achieve.

You say this every time that Rust is compared to C++ (which is a lot!), but I have yet to see an elaboration. What in particular are you talking about?

<comment><USER6> Rust encourages writing imperative code in a functional style, like this:

        fn run_query() -> Result<PgResultSetOrWhatever, String> {
            PostgresConnection::connect("postgres://localhost:5432/postgres", &NoSsl)
                .and_then(|conn| conn.prepare("SELECT ir FROM x"))
                .and_then(|stmt| stmt.query([]))
                .map_err(|e| format!("{}", e))
        }

This is a strange way to write control structures. Each object gets to define its own control structure syntax. Then there's the "try!" macro, which generates an invisible return on error. Cargo has their own "try!" macro, and it's slightly different. All this puts a layer of macros on top of control flow. There's a rationale for that, but it doesn't help readability.

Exceptions were such a mess in C++ that they've scared people away from the concept. But they work well in Python, especially in conjunction with "with" clauses. The machinery in Rust to avoid exceptions is more complex than exceptions. It took C++ years, and Boost, to get to this level of wallpapering over a mess.

<comment><USER8> The try macro is going to be replaced by cleaner syntax soon (along with control flow based catch syntax). It's not "a layer of macros", its one macro, which everyone knows about, so it's not invisible. No different from a return or throw statement -- the control flow escape hatch is "invisible" there, too, but everyone knows what a return/throw are, so it's perfectly visible. It's the same situation with try -- everyone knows what it does; so it's not invisible.

Rust doesn't _encourage_ writing things monadically. You can write them as nested if lets if you want; indeed; many people do exactly that (I prefer doing this too, or using try).

Where's the wallpapering? There's try!, and a couple of monadic methods on Result, and that's about it? Monadic error handling is not a new idea, and it's not really complicated either (well, if you force people to understand monads first, it is, but that's totally unnecessary and nobody does that). This is no more complicated than vanilla C++ exceptions. It's _different_ , and different from what people are used to, but not new.

Also, this isn't even part of the language, it's part of the stdlib. If anything that is a point for Rust, since C++ needs language integration for exception handling, Rust doesn't (and thus the language is simpler in this axis). It will soon become a part of the language; but only as some sugar.

And this is a very specific example. Overall, where does "Rust start at C++s complexity level"?

> Each object gets to define its own control structure syntax.

Technically only Result and Option do, the objects above are just Results. While you can create your own enums for error handling, most people don't, so there's no repetition of control flow syntax.

This is true anywhere, each object always gets to define its own utility methods. You have the same on the std::exception types in C++.

> The machinery in Rust to avoid exceptions

This is not "to avoid exceptions", it shouldn't be viewed that way. Sure, the Rust designers don't want exceptions in the language, but monadic error handling is a proper, tried-and-tested solution for error handling, not a "last resort".

<comment><USER9> For what it's worth, I agree with Animats that Rust's error handling is too complicated.

My dream language would have catchable, unchecked, untyped exceptions. I.e. you can throw and catch strings anywhere without declaring that upfront. You can even throw from a destructor while unwinding, whereupon the new string gets appended to the old string and life goes on. It's a pretty sweet design:

1) Easy to read code with standard control constructs.

2) No performance overhead in the common case.

3) No dispatching on error types, therefore less temptation to use errors for control flow.

4) No distinction between recoverable errors (option) and unrecoverable errors (panic). I feel that distinction is in the eye of the beholder, especially if you need to catch errors from code you don't control.

5) No distinction between code that can cause errors and code that cannot, thus higher-order functions become easier to write.

I'm hard pressed to name any advantages of Rust's model compared to the above. Rust can't even claim to be transparently callable from languages that don't support exceptions, because panics exist :-(

<comment><USER8> > It's a pretty sweet design

Yeah, it is, but it wouldn't interact well with Rust's safety guarantees :)

(You're analysing this feature in a vacuum, but that's not how language design is done.)

> Easy to read code with standard control constructs.

I think this is in the eye of the beholder, `try!` or `?` or `catch` are (would be -- for the latter two) easy to read for Rust folks. It's just _different_. do-notation in Haskell is similarly "standard" for functional types, but it's totally alien to C++ folks. The main reason folks find try/catch/throw easier to understand is because they're used to it. Once I learned how enums worked in Rust, `Result` was a very straightforward and simple thing. I actually personally find `try!` easier to read, since I know _exactly_ where a return can happen, unlike C++ where the control flow is totally obscured.

This leads to the rug getting pulled out from underneath you, which can be bad for safety. In fact, Rust's `recover()` needs to be careful about types allowed to cross a recover boundary so that it can be 100% memory safe.

So the code might be easy to read, but not easy to reason about.

> No dispatching on error types, therefore less temptation to use errors for > control flow.

I don't get what you mean here. Rust doesn't dispatch on error types, though it does dispatch on Result (which may contain an error). I don't see what's wrong with this. This lets you program in a functional way (and like I mentioned, you don't _have_ to), which isn't a bad thing.

Errors _are_ a control flow thing, you can't escape that. C++ handles the control flow around errors with try, throw, and catch, Rust does it with Result and its methods (and the try macro).

> especially if you need to catch errors from code you don't control.

`recover()` exists. Use it sparingly; it's basically only for cases when you want to catch panics in code you don't control (even then, try other solutions), or stop panics from crossing FFI boundaries.

Panics are supposed to be for irrecoverable or impossible things, where "irrecoverable" is usually a statement that only makes sense in an application, not a library. So this problem in theory shouldn't come up (I haven't seen it happen much in practice).

I think the problem of forgetting to catch an exception from code you don't control because you don't know it's there is a much more pressing problem than having stray panics (since panics are relatively rare).

> No distinction between code that can cause errors and code that cannot, thus > higher-order functions become easier to write.

Result<T,E> is also a type. Treat it as any other return type in a higher order function and it works. In `Fn(...) -> T`, `T` can be a Result type, no problem.

> Rust can't even claim to be transparently callable from languages that don't > support exceptions, because panics exist

and so does `recover()`.

> No performance overhead in the common case.

IIRC it doesn't turn out to be much, but ICBW. I think someone looked into this.

<comment><USER9> About higher order functions: putting effects in the type forces you to make a distinction between map and mapM. You can't unify them because one takes a -> b and the other takes a -> m b. Same for any other higher order function, you have to write two versions (or more if you don't have HKT).

About memory safety: can you give an example where a naive implementation of catchable exceptions would break memory safety? I know about RecoverSafe but it seems to be solving a different problem (marking types whose logical invariants are preserved in case of panic).

<comment><USER8> > forces you to make a distinction between map and mapM. You can't unify them > because one takes a -> b and the other takes a -> m b.

You have the same distinction in exceptions? One map would bubble the exception, the other would internally catch and exclude. You don't _have_ to write two versions, map still works for cases with and without Result, but it will not have the additional behavior of excluding errors. You want that additional behavior, hence you write mapM; just like you would in C++.

> About memory safety: can you give an example where a "naive" implementation > of catchable exceptions would compromise memory safety? I know about > RecoverSafe but it seems to be solving a different problem (marking types > whose logical invariants are preserved in case of panic).

There's an example in the rfc: [https://github.com/rust- lang/rfcs/blob/master/text/1236-stab...](https://github.com/rust- lang/rfcs/blob/master/text/1236-stabilize-catch-panic.md#background-what-is- exception-safety-in-rust)

In Rust logical invariants are used to enforce memory safety. If the destructor of something within a vector panics, that might result in an invalid vector. There's a pattern colloquially called "pre pooping your pants" which would help in this specific case ([http://cglab.ca/~abeinges/blah/everyone- poops/](http://cglab.ca/~abeinges/blah/everyone-poops/)), but not in general. Writing unsafe code in Rust involves careful bookkeeping if you want to be sure the code is safe; and that goes out the window when the rug can be pulled out from underneath you any time.

<comment><USER9> Well, that example doesn't use catch, so it doesn't really tip the scales on catchable vs uncatchable exceptions. It does show that you have to be extra careful when making function calls from unsafe blocks, and that destructors are especially error prone. I agree with all that :-)

<comment><USER8> Recover is basically catch, it shows how a panic can leave something in a invalid and unsafe state, which can be accessed after recovery (without recover you wouldn't be able to access it). :)

<comment><USER9> You can see the invalid state even without catch/recover, e.g. from destructors that are called during unwinding.

<comment><USER8> Ah, I see. Right, that works in this case, but it doesn't work in all -- you can come up with a situation where the destructor is fine but the recovery can lead to arbitrary unsafe things.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> A bunch of those are of the form 'you know there are better ways to go about doing that sort of thing' (like 'maybe consider using a std::vector instead of that static array' and 'just make a minimal ctor for initialization, you'll save typing in the long run' and 'when do you need to know the largest value in an enum, and why can't you just toss in a dummy last element, also why aren't you using enum class') if not outright 'jesus, don't put yourself in a position where you'd want to do that' (like the 'iterate over members of a struct' or the type stuff). And I had never heard of those 'fourcc' codes and have no idea why anybody would want them in a language standard.

That said, there are some reasonable points, like '#pragma once' and 'enum-to- string' (extreme disagreeage on the 'string-to-enum' direction tho).

<comment><USER11> What possible use is there for being able to convert the name of an enum as a string that isn't totally bug-ridden the minute you write it?

<comment><USER12> Serialization. And don't tell me that it falls under "bug-ridden the minute you write it" because more defensive programmers than you and I have been using it responsibly in a dozen other languages for more than a dozen years.

</comment></comment></comment><comment><USER13> He has a some good points, but the "switch" statement needs an integer for a reason... a switch can be converted a jump table in assembly language, so that the "case" can be arithmetically determined and instantly jumped to. The reason being: MOAR SPEED! A jump table is a lot faster than a sequence of else-if statments.

<comment><USER14> The compiler knows the type of the value it switched upon and generates code accordingly (efficient code on int values, dumb if-chain on other values), doesn't it? Sure it may become hard to tell if the code is efficient or not, but that property has already long been lost with operator overloading.

</comment></comment><comment><USER15> Who forgets to break in switch statements? I mean yea, there was a time when I started programming I did this once or twice but not for a quite long time. Seems to me more like a request for sloppy programmers than anything else.

Also don't forget [Duff's device]([https://en.wikipedia.org/wiki/Duff's_device](https://en.wikipedia.org/wiki/Duff's_device)) for how it could actually be expressive.

</comment><comment><USER5> I found it funny how many of the complaints were really about the preprocessor. Many of them have already been addressed. If you don't like defining a macro as "do { ... } while (0)", try using an inline function. Even C has inline functions nowadays, and that's been true for more than a decade.

<comment><USER16> If you could write it as a function why would you be writing a macro in the first place?

<comment><USER5> That's an obvious question. A lot of macros should be functions.

The most common case I'm aware of are functions like toupper(), islower(), ispunct(), etc. that the C Standard allows to be macros for performance (the actual work in the function is testing or setting a single bit, and the overhead of a function call really matters in that case).

Inline functions would have the same performance, and you can get a pointer to them without doing the #undef rigamarole you see when a macro definition might muck things up.

<comment><USER17> Inline functions aren't guaranteed to be inlined. There are compiler specifics that add stronger hints to the optimizer to inline but behavior isn't always consistent from one compiler to the next. The only portable way to force something to be inlined is to use a macro.

<comment><USER16> Why is it essential that anything is inlined? Maybe if the compiler isn't inlining it had a good reason for that? Maybe it has some understanding of the trade off between specialisation and code size for these particular functions which you don't.

<comment><USER17> In most cases I would wager I have a better idea of where I want the optimizations to be applied in code than the compiler does.

Macros, unlike inline functions, will always give you the result you are looking for. You don't have to worry about things like regressed performance because a new compiler versions has tweaked inlining heuristics.

The use of "inline" is diminished in much real world C++ too. Because it's used liberally in user code and added implicitly to member functions defined in a class definition there already is much code that is inline-worthy. There is no way in C++ to say "I explicitly want THIS code to be inlined HERE", unless you use a macro.

In theory you can get benefits out of using PGO but PGO is also non-standard, not available on all compilers, and a pain to setup.

Inline functions will also never be able to replace the diagnostics available with the preprocessor; being able to extract the line and file for things like assertions is something you can't do with inline functions.

Inline functions have their use, but so do preprocessor pseudo-function macros, and saying that there isn't a valid use for these macros is claptrap that I'd attribute to someone who hasn't shipped performance sensitive code in C or C++ before.

<comment><USER5> I recognize that there is some use for macros, but the valid cases have been getting smaller over time.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> 1\. Be more precise. You want the cardinality of the set of items of the array. When you say you want the "size", you sound like you want to know the physical size in bytes of the array.

But yes, it would be good. But if you want to know why that macro is so problematic, have a read of the following:

[http://blog.natekohl.net/making-countof-suck- less/](http://blog.natekohl.net/making-countof-suck-less/)

Of course, knowing how many elements are in an array is probably not a bad feature. (just noticed that porges points out that it's coming in C++17)

2\. Completely agree with you on enums. There is a proposal in C++17 to allow for this, see:

[http://www.open- std.org/jtc1/sc22/wg21/docs/papers/2015/n442...](http://www.open- std.org/jtc1/sc22/wg21/docs/papers/2015/n4428.pdf)

      std::enum_traits<E>::enumerators::size
      The number of enumerators in the enumerator list of E.

3\. Same deal, see in the same proposal:

      std::enum_traits<E>::enumerators::get<I>::identifier
      A std::string_literal(N4121) holding the identifier of the enumerator.
      The identifier is encoded in UTF8 format, with any UCNs decoded.

3\. #pragma once... the entire way of including headers into code is kind of broken. Having to implement a compilation firewall (aka pImpl) just to ensure that when you change a private member definition you need to recompile all other classes that rely on it seems so incredibly broken to me.

The LibreOffice code is littered with pImpls. It doesn't make it easier to read or understand the code, or even maintain it, at least in IMO. And without them, the compilation time is huge, every time I touch VCL code in anger I fear I'm wasting some other poor devs time in compilation time.

4\. C99 designators - no opinion on this.

5\. Binary - only if you can specify endianness.

6\. FourCC doesn't seem like something for a standard... maybe that's just me though.

7\. All macro criticisms - someone just please implement another macro processor in the standard already!

8\. Iterating fields - back to that C++17 proposal again:

      std::class_traits<C>::class_members::get<I>
      Requires: I >= 0 && I < size

      Provides information about the I'th (zeroindexed) public member
      of C that satisfies the above criteria, in declared order.

9\. Breaking by default in switch statements... ugh. Lots may disagree with me though. That .. gcc extension is pretty cool though! Add that to the standard, by all means!

10\. Agreed on strongly typed typedefs

11\. See that C++17 proposal I linked to previously - I think that has everything you'd want! High time too.

<comment><USER19> Yep that sure looks like a fine C++17 proposal (although I didn't understand a word of how it would actually be implemented).

How much do you want to bet that it won't be accepted? :). Like a lot of the other good proposals (std::optional anyone...?) I wouldn't be surprised if it never sees the light of day.

</comment></comment><comment><USER20> do you realize this would crash with empty array: #define countof(X) (sizeof(X) / sizeof((X)[0]))

<comment><USER21> No, because the expression is not evaluated at any time. Only the type of the expression is used.

A much better implementation would be

        using std::begin, std::end;
        #define countof(x) (end(x) - begin(x))

(except for the double evaluation, but this is better as a template function instead of a macro anyway) because it'll work on any type that supports random-access iterators which include arrays but also std::array and vector.

<comment><USER22> Corrected below, leaving here for posterity and to make sure this conversation isn't confusing in the future. The only thing I'll note is that you get a compile error on a zero length array, so the OP of this chain turns out right in a way heh.

Start ignoring here: _Are you suggesting end() and begin() can be called on an array? As far as I know they can 't. Apparently you can deduce array length in a constexpr function now in C++11 (which I only learned just now but also couldn't get working quickly, so have some salt with that), but before that arrays always degrade to pointers when passed as function arguments so there's (afaik) no way to extract their length from their type..._

<comment><USER23> Before the array decays to a pointer, you can get its length.

Here is the implementation of std::begin for arrays in libc++: [https://github.com/llvm- mirror/libcxx/blob/60d223df071f6e3d4...](https://github.com/llvm- mirror/libcxx/blob/60d223df071f6e3d4ffa29331ed466fff563096f/include/iterator#L1430-L1436)

<comment><USER22> Quite right, I'm apparently rusty on my stdlib knowledge. Didn't know about the reference trick.</comment></comment></comment></comment></comment>


Two basic ways how to work on computer - <AUTHOR> http://www.baum.com.au/petr/blog/01194140580

<comment><USER2> I really can't agree with the hypothesis that this guy is putting forward. Why would anyone work directly with the filesystem for storing large amounts of data in this day? Examples from MacOSX include email, photos, or music. I have two ways of getting at this: 1) Use the program that manages the library - Mail, iPhoto or iTunes - these have very friendly interfaces for most of the common tasks that you may want to do with these document types. Of important note, they _have_ special use cases - I want mail from this week, or from this person, or that mention a certain subject. I want photos taken on a certain date, or during a certain event, or I want to create an album which shows photos of my niece from any event. I want to organise a playlist for tonight's party, or for listening to on my iPhone, or I want to find all of my Pink Floyd albums. Application-centric access is great for this.

2) Spotlight. But what if I want to do something else. Say I want to put a copy of all my Battlestar Galactica episodes on my Media Centre. Not a problem, Spotlight will grab all of those files for me in less than a second in the Finder. Or if I don't want to make copies, I could do something a bit more geeky, and create a smart folder containing everything Battlestar Galactica, and then iterate through that folder using a script to create alias to each item. I could then share the aliases, without having to make copies of those large files.

The days of handling the filesystem details of how one stores data are over. The computer can add so much more semantic information for us these days, allowing complex queries to retrieve the data that it would be silly to do the job manually. I don't try to read raw files out of an SQL database, I use queries - a userspace filesystem these days is much the same - don't worrying about ordering the data, just worry about being able to craft the right query to retrieve it...</comment>


Understanding Asymmetric Numeral Systems - <AUTHOR> https://ro-che.info/articles/2017-08-20-understanding-ans <comment><USER3> zstd uses ANS [1][2] to encode its (literal length, match length, offset) triples.

[1] [https://github.com/Cyan4973/FiniteStateEntropy](https://github.com/Cyan4973/FiniteStateEntropy)

[2] [https://github.com/facebook/zstd/blob/dev/doc/zstd_compressi...](https://github.com/facebook/zstd/blob/dev/doc/zstd_compression_format.md#sequences- section)

</comment><comment><USER4> > The algorithm tries to assign each list a unique integer so that the more > probable lists get smaller integers.

This sounds like basic Huffman encoding. What am I not understanding?

<comment><USER5> > This sounds like basic Huffman encoding. What am I not understanding?

The smallest item in a Huffman encoded tree is a single bit.

You can end up with fractional bits with ANS.

And this puzzled me too, till I ran into a fractional bit-shift problem in some of my work.

We encounter fractional bits very often when dealing with number systems which don't encode very well into binary.

When encoding a (yes, no, maybe) into a binary structure, it uses up all 2 bits, while we do know that it doesn't cover the entire range properly - because we can pack 4 values into 2 bits, while this loses a single value.

Basically to encode tristate data into booleans, you need to be able to shift the input by Log2(3) bits - or 1.58 bits, so that you can use the other 0.42 bits into the next one etc, until you get to a point where you end up with a whole bit in real "bits".

Shifting by 1.58 bits sounds rather odd, but that's what a CPU does when you do a * = 3 (and the other one was really * 4).

So instead of being able to store 8 (yes, no, maybe) into 16 bits by using boolean logic, instead you can store 10 (yes, no, maybe) by using *3 as a multiplier instead of 4. Because 3^10 is 59049, the maximum encoding still comes in way under 65536.

Anyway, I'm currently juggling with a fractional bit problem of my own - <USER2> with a more familiar numbering system, Decimal.

I need to represent 38 digits and a sign within two 64 bit registers, however splitting those two across Decimal values wastes fractional bits.

To represent all positive 19 digits in binary, you end up using 63.1166338029 bits.

So if you store 38 digits in binary as 2 independent 19 digits, you end up consuming 128 bits, because you round up the 2 representations to 64 bits each.

But if you store 38 digits in straight binary, you only end up needing 126.233267606 bits = 127 bits rounded up, which leaves a bit available to do a sign bit.

Decimal(38,0) doesn't encode very well into 2 Longs in decimal, but it encodes nearly perfectly by straddling the sign bit across the two values if you're careful to encode it, so that you can squeeze in a sign bit into the higher value.

Anyway, fractional bits are super interesting because it jumps from engineering, all the way through computer science to end up with pure information theory in mathematics.

PS: Genetics data is probably the next place where I'd look at this - ATGCU, for instance

</comment></comment><comment><USER6> Anyone else just stare at this stuff hoping to understand it someday?

<comment><USER7> For me at least, the barrier to understanding this was all the Haskell. I'm familiar with functional programming (Scheme), but I couldn't understand enough of the code to really grasp what was going on after the first section.</comment></comment>


Ask HN: Do US tech companies ignore quality applicants because of visa hassles? - <AUTHOR> I just graduated with a PhD in computer science from a top university in Germany. I've sent out a dozen applications to well-known start-ups and bigger tech companies in California but my applications are being ignored. My LinkedIn profile is definitely being viewed but I hear nothing after. I'm wondering is there something glaringly wrong with my CV or is it just because they don't want the hassle of finding visas. <comment><USER2> They don't need to find visas. They need to apply. And afaik the wait period of H1B visas over a year because the quotas are reached so fast. That makes planning ahead hard.

The US company also has the burden to prove it wasn't able to find an equivalent US citizen (resident?) to do the same job. That means to write job ads and document the replies and interviews to those.

I'd say the companies don't want the hassle.

</comment><comment><USER3> As a foreigner who got hired by a US company, I'd recommend going to the US & holding interviews in-person.

My experience is that a lot of people apply from overseas - if you're already physically in the US, it seems you're more likely to be serious about committing to it.

</comment><comment><USER4> You can send you resume to me at konstantin dot solomatov at jetbrains. We have 2 positions which are currently open is USA:

* [https://www.jetbrains.com/company/jobs/#software-engineer-ne...](https://www.jetbrains.com/company/jobs/#software-engineer-newpr)

* [https://www.jetbrains.com/company/jobs/#software-engineer-ne...](https://www.jetbrains.com/company/jobs/#software-engineer-newpr2)

</comment><comment> bro-stick Applying to jobs (outbound): it's far harder to sell yourself and build sustained interest compared to people deliberately discovering you (inbound). Outbound is also a lot more work vs. return. Make a killer LinkedIn, Github or whatever appropriate portfolio to make the conversation higher signal and remove their uncertainties/likely objections. Odds are they have a pressing need (challenge to address)... get talking about it and discard pointless hazing rituals that don't address moving the business forward. If they persist, indicate they're wasting your valuable time and theirs on non-value- add business theater that doesn't remotely pertain to doing real work or getting along with the culture.

</comment><comment><USER5> It's probably because you're in Germany (physically). If you were applying within the US (and within the Bay Area) you'd have better luck. Visas are an issue but larger companies are more comfortable with it because they have mobility staff in-house.

</comment><comment><USER6> Of course they do, but if you're not getting interviews as a fresh CS PhD from a top (or even non top) school, it's something else.

</comment><comment><USER7> I guess this proves that there is no real shortage of tech workers.</comment>


Robot SmartBird Flaps and Flies Like the Real Thing [video] - <AUTHOR> http://www.wired.com/gadgetlab/2011/03/smartbird-flaps-and-flies-like-the-real-thing/

<comment><USER2> Even _better_ than the real thing — the video clearly demonstrates the robot bird _not_ flying into all those glass windows like its avian counterpart has been known to do.

</comment><comment><USER3> Does anyone know how this compares to fixed-wing aircrafts in terms of energy efficiency?

</comment><comment><USER4> So, is that were we are? We have robot birds now? I'm convinced that pretty soon all privacy will end, because we'll have self-controlled fly (as in the animal) robot drones that will be able to record their journeys. I'm not so much afraid of governments dping this, but of creepy guys.

That said, it looks like this bird can't really fly very well. It doesn't stop flapping its wings to glide, and it looks like it can't control its angle of ascent very well.

However, I'm sure it'll look and fly exactly like a real bird (even flocking, perhaps) within a few years.

<comment><USER5> Actually, it does glide. Check out from 0:16.

<comment><USER4> It doesn't show it alternating flapping and gliding, though, the gliding footage is just of it gliding. Look at the rest of the footage, it keeps flapping its wings until it stalls. It doesn't seem to be able to control its flight path.

<comment><USER6> Yes, but it physically can flap to fly, and it physically can glide. Making it do so alternately is just a matter of software.

Not that I'm underestimating the difficulty of bird-control software (especially in wind), but I think the most difficult part of this invention is the physical mechanism and getting it to fly at all.

<comment><USER4> Oh, I agree, that's why I think they'll be indistinguishable from real birds in a couple of years.

</comment></comment></comment></comment></comment><comment><USER7> I had one of those when I was a kid, <http://www.youtube.com/watch?v=J0UK4mTTRsw>

</comment><comment><USER8> Here is a longer (~half hour) making-of video. Really interesting.

<http://www.festo.com/cms/en_corp/11369_11468.htm#id_11468>

</comment><comment><USER9> This is slightly less spooky than BigDog:

<http://www.youtube.com/watch?v=W1czBcnX1Ww>

<comment><USER10> big dog uses RL while this bird robot do not have any learning abilities (at least nothing is said about it) and is just a remote controlled unit.

</comment></comment><comment><USER11> Be sure to check out the animation. Also its Bionic Handling Assistant & Bionic Tripod is amazing as well, reminds me of Dr. Octopus ;)</comment>