Your Progress As A Programmer Is All Up To You

I agree and disagree. It's a moral responsibility of the employer. Work takes up such a large portion of a person's time and energy that if the company isn't invested in the employee's progress, he owes that company nothing. My work ethic is strong as hell, but if I get the sense that management isn't interested in my progress, I slack as a matter of principle. If your manager isn't looking out for your career and you put more than about 10-15 hours per week in on your assigned work, you're just a chump. (In the MacLeod analysis, a Clueless.)

That said, expecting your employer to manage your progress and education is unreasonable, because no company can possibly account for the variations in peoples' abilities and desires. Even if your employer is genuinely well-intended and wants you to advance-- let's ignore the 80% of companies that aren't this way-- your company will figure out where you should go much later than you will. That's why open allocation is the best solution: the workers can figure out what's worth working on faster than central/upper management.

So, yes, it's a moral responsibility to the employer to give the employee time and resources to look out for her career (and, if it doesn't, engineers should slack). However, for the employee to put the self-executive responsibility of picking out what to learn on the company is, in practice, an irresponsibly bad idea.

By my third year I saw the microcomputers were going to be the future and wiggled my way into the group that worked with them.

The problem is that most modern companies have such mean-spirited, insane policies regarding performance reviews and internal transfer that internal mobility is pretty much impossible in them. At a closed-allocation tech company, the only time you can realistically get a transfer is when your performance history is in the top-10%-- in which case, lateral transfer is a terrible idea anyway, because you should wait for the promotion instead of restarting the clock. Closed allocation and Enron-style performance reviews are all about inhibiting mobility, i.e. keeping the poors in their place.

But once you discover you are obsolete it's too late. Assuming your employer will retrain you is a fool's pipe dream. These days employers may drop you, your job, your projects, or even the whole company without much notice, and then you have to find a new job. Expecting them instead to retrain you is not going to happen.

This is why I hope to see a French Revolution-style uprising. Silicon Valley looked like a way out, a "middle path" between serfdom and violent revolt. Now that that middle path is closed due to the VC good-ol'-boy network, I think that a (probably global) class war is just an eventual necessity. It may come next year, and it may come in 50 or 100, but I hope that it's the last major war humanity has to endure.

In programming you need to look forward because the only thing behind you is that nasty steamroller.

Honestly, I get the feeling that this guy was very lucky. He had the autonomy to pick new technologies and he picked winning horses. Imagine what he'd be writing if, instead, he'd learned Blackberry app development. Or, what he'd be writing if his manager, long ago, had fired him for attempting the transfer to the microcomputer team (possibly forcing him to take a suboptimal job due to financial pressure, with long-term effects on his career). He should at least attribute some of his success to having been luckier than most engineers.

Specifically:

I gave examples of the need to control memory layout and memory allocation.

I gave examples of Rust's features leading to reliability and security -- memory safety and absence of data races.

You seem remarkably uninformed as to what Rust's goals are. Allow me to enlighten: reliability is a big, big deal to the Rust developers. Security is a big, big deal to the Rust developers. Speed is a big, big deal to the Rust developers. Memory efficiency is a big, big deal to the Rust developers.

As for your mistaken assertion that such efforts at memory safety are unnecessary in real-world code:

https://groups.google.com/forum/#!msg/mozilla.dev.servo/ufJM...

  >>> * Do we have data showing how many security bugs we could be avoiding in
  >>> Servo in comparison to Gecko? Is the security benefit truly as valuable
  >>> if expected performance benefits don't pan out?
  >>
  >> We've been talking to some members of the security team (Jesse, Brian). In
  >> general the main class of security vulnerabilities that Rust offers a layer
  >> of defense against is memory safety problems in layout, rendering, and
  >> compositing code. Use-after-free is the big one here, but there are others.
  >> I'm not in the sg so I can't run the numbers myself, but I am told this
  >> constitutes a large class of security vulnerabilities.
  >>
  >
  >A quick scan suggests that all 34 sec-critical bugs filed against Web Audio
  >so far are either buffer overflows (array-access-out-of-bounds, basically)
  >or use-after-free. In many cases the underlying bug is something quite
  >different, sometimes integer overflows.
  >
  There are 4 sec-high bugs --- DOS with a null-pointer-deref, and a few bugs
  reading uninitialized memory. The latter would be prevented by Rust, and
  the former would be mitigated to the extent Servo uses the fine-grained
  isolation Rust offers.
  
  There are no sec-low bugs.
  
  Web Audio is an example of a feature which has very little security impact
  of its own. Its security impact is entirely due to bugs where violation of
  language rules can trigger arbitrary behavior. Rust prevents such bugs. A
  lot of Web features are in this category. 

"If you don't keep learning, keep reading, keep improving your skills eventually that nasty steamroller behind you will flatten you permanently. Then your career is likely over."

and

"And that clanky monster breathing down your neck has an endless supply of fuel."

Egads. Not blaming the messenger here, he's right. It's a tough field. So the pay is extraordinary, right?

http://money.usnews.com/careers/best-jobs/rankings/the-100-b...

Take a look at these jobs, and in particular, look at the pay in higher salary regions. The best job, software developer, earns 116k a year on average in San Jose.

The average registered nurse earns 122k a year in San Jose. The average dental hygenist in SF earns about 106K a year. Nurse practitioners clock in at 125K a year.

There are all kinds of ways to interpret this data, and in the end, I'm talking about the greenness of the grass somewhere else. Not that I wouldn't welcome comments about these comparisons, I just want to make it clear that I acknowledge these other fields come with their own stresses and challenges and barriers to entry (and I don't object to good salaries in these fields at all). And everyone has to keep learning...

But is there a steamroller that threatens to make dentists obsolete, and do dentists have to bet the farm, so to speak, on whether to learn "enterprise java beans". It does seem particularly relentless (and difficult to predict) in software, and the career stakes are very, very high.

I think programming can be a wonderful career for some people. I think the main reason I pay so much attention to this sort of thing is that I often think about pay and work conditions for software developers within the context of claimed "shortage", as this is frequently discussed (and until recently, often accepted without question) in the mainstream media.

Judging from this informative blog post, it takes a very unique wiring to really thrive for a career as a software developer. Can we really say there's a shortage of people willing to put themselves in the path of a steamroller? (The author of the blog post in no way made this claim, this is just a question I'm turning around in my own mind).