I love how Google's response is akin to "well, if the password is compromised...anything is possible" logic and tagged as won't fix. Facebook and Linkedin of all people immediately triaged and started fixing the issue.

Unacceptable response from a company promoting its services as identity and communication platforms.

I also wish that programming were a lot different today than it was when I started learning it. That being said, a lot of this article's points are things I've heard before. They led to the development of Visual Basic & co., mostly by people who had no contact with the Smalltalk and Lisp environment in the 80s, while people who did were shrugging and throwing tantrums like WHY THE FUCK DIDN'T YOU FUCKING LIKE IT TEN YEARS AGO?

IMHO, all these things went down to the bottom of history because things like these:

> Anon the intern needs to be able to open up Programmingâ„¢ and click 'New Web Form'

are adequate for people who usually don't program, and extremely inadequate for people who usually do. Generally, and for good reasons, programmers will dislike a tool that hides implementation details for ease of operation. Past a certain level of complexity, the time spent manually doing the right cruft becomes significantly smaller than the time spent manually cleaning up after a smart tool.

I sympathize with Anon the intern, but perhaps he should rethink his expectations about complexity; if discoverability is a problem, perhaps he could switch to something that's better documented?

And at the risk of sounding like an elitist schmuck who rants about how things were back in his day, maybe he ought to start with something other than web programming. The size and complexity of that tech stack is humongous, to the extent that a large proportion of those who use it don't understand it more than two layers of abstraction down. Programs are also hard to pack and the environment that runs them is hard to setup. Because it involves at least two servers, possibly with several add-ons in order to allow the server-side languages to run, learning at least three languages (assuming server-side JS is an option), two of which (HTML and CSS) aren't quite being used for their original purpose. This is a beginner's nightmare and it has exactly nothing to do with the development tools.

And then there are things that are far harder to solve than they originally seem:

> I want to just type 'email' and see a list of functions and libraries relating to email.

Related how :-)? Should MIME-related functions, needed to reason about attachments, also come up here? HTML parsing/converting, in case you need to deal with HTML email? Information cluttering does nothing to alleviate the opposite problem of information breadth: if Anon the intern's problem is he doesn't know how to Google for libraries or how to make efficient use of documentation, an IDE that presents him with a gazillion of possibly related things won't help him. Especially when, like all beginning programmers, one of his main difficulties is correctly defining the problem he's working on which, in turn, makes it likely for the solutions presented by the IDE to be nowhere even close to the one he needs, because the IDE (like Anon himself) thinks Anon is trying to solve another problem.

There is, on the other hand, a lot more truth in this:

> Tightening the feedback loop between writing code and seeing the results reduces the damage caused by wrong assumptions, lightens the cognitive load of tracking what should be happening and helps build accurate mental models of the system.

I do think that the real resolution to this problem is writing simpler programs whose state is easier to track. On the other hand, programming tools today suck considerably at presenting program meaning. Things like evaluating what an expression comprising entirely of constants, or at least evaluating it based on the default values of the variables involved, are well within reach for today's tools, and yet programmers' calculators are still employed because 99% of the available IDEs couldn't evaluate ADDR_MASK & IO_SEGMENT if the life of every kid in Africa depended on it.

This is wicked cool: http://repository.cmu.edu/cgi/viewcontent.cgi?article=1165&c... . However, I also find myself thinking that the very fact that we need debuggers that are this smart is proof enough that we don't reason about our programs well enough. Except for the fringe case of having to quickly debug a (possibly horrible) codebase I haven't written, I'd much rather prefer being good enough a programmer to avoid the need for a debugger that can tell me why foo is not 8 despite the fact that I fucking said foo = 8 ten lines above, than being a programmer with good enough tools to help me when I'm stupid.

The article is technically well written, but somewhat uninformed which stems from the author's limited experience and what he sees in popular media.

I thought the top comment below reflected what I have seen in my 10 years in the industry, much better:

" This is a very well written piece, but it's only covering the frothy tip of a very deep phenomenon. I too am a Rails developer, have been coding professionally for 15 some odd years, and I too find what VCs are chasing nowadays to be mostly time wasting crap. But that's not what software, even web software, is really about right now. It's just the glam side of the game.

The real folks making real things happen are building tools and technologies that literally could not have existed 10 years ago. In my personal experience, I've built integrated web portals that show real-time electricity usage for factories, saving them 10-50 grand a month by lowering usage during peak hours. I've built sales management tools that allowed a 2 man company to scale to a distributed team of dozens. Online rental advertising systems to cut out costly newspapers. Medical order management systems.

It's not glamorous, it doesn't get on TechCrunch or Hacker News, but it's real value, delivered by real professionals. And that, more than the stupid photo sharing cruft, is what's really driving developer salaries.

During the late 90's, the joke/threat was "go away or I will replace you with a very small shell script" - the point being that lots of human work could be automated by a savvy developer. That threat has become a promise, and we (costly) web developers are the ones fulfilling that promise across a huge range of industries." - Rob Morris