'The Problem With Programming and How To Fix It' (alarmingdevelopment.org)
Jonathan Edwards has been programming since 1969 (starting on a PDP-11/20). "Programming today," he writes, "is exactly what you'd expect to get by paying an isolated subculture of nerdy young men to entertain themselves for fifty years. You get a cross between Dungeons & Dragons and Rubik's Cube, elaborated a thousand-fold."
theodp summarizes the rest: To be a 'full stack' developer, Edwards laments, one must master the content of something like a hundred thousand pages of documentation. "Isn't the solution to design technology that doesn't require a PhD...?" he asks. "What of the #CSForAll movement? I have mixed feelings. The name itself betrays confusion -- what we really want is #ProgrammingForAll. Computer science is not a prerequisite for most programming, and may in fact be more of a barrier to many. The confusion of computer science with programming is actually part of the problem, which seems invisible to this movement."
It wasn't always this way, Edwards notes, citing spreadsheets, HyperCard, and the many incarnations of Basic as examples of how programming technology can be vastly easier and more accessible. "Unfortunately application programming got trampled in the internet gold rush," Edwards explains. "Suddenly all that mattered was building large-scale systems as fast as possible, and money was no object, so the focus shifted to 'rock star' programmers and the sophisticated high-powered tools they preferred. As a result the internet age has seen an exponential increase in the complexity of programming, as well as its exclusivity."
"It is long past time to return to designing tools not just for rock stars at Google but the vast majority of programmers and laypeople with simple small-scale problems," the essay concludes, arguing we need new institutions to fund changes in both the technology and culture of programming.
"We've done it before so we can do it again, even better this time."
theodp summarizes the rest: To be a 'full stack' developer, Edwards laments, one must master the content of something like a hundred thousand pages of documentation. "Isn't the solution to design technology that doesn't require a PhD...?" he asks. "What of the #CSForAll movement? I have mixed feelings. The name itself betrays confusion -- what we really want is #ProgrammingForAll. Computer science is not a prerequisite for most programming, and may in fact be more of a barrier to many. The confusion of computer science with programming is actually part of the problem, which seems invisible to this movement."
It wasn't always this way, Edwards notes, citing spreadsheets, HyperCard, and the many incarnations of Basic as examples of how programming technology can be vastly easier and more accessible. "Unfortunately application programming got trampled in the internet gold rush," Edwards explains. "Suddenly all that mattered was building large-scale systems as fast as possible, and money was no object, so the focus shifted to 'rock star' programmers and the sophisticated high-powered tools they preferred. As a result the internet age has seen an exponential increase in the complexity of programming, as well as its exclusivity."
"It is long past time to return to designing tools not just for rock stars at Google but the vast majority of programmers and laypeople with simple small-scale problems," the essay concludes, arguing we need new institutions to fund changes in both the technology and culture of programming.
"We've done it before so we can do it again, even better this time."
It's not the 80s anymore. Useful systems are complex, have many layers, and tend to grow new layers over time.
In the 90s, a web page was a static .html file. Some minimum understanding was enough to make one.
Later, CGIs were added. Now you need some understanding of HTTP.
Add a database. Now you need to understand SQL, and related matters, like SQL injection.
Add JavaScript. A whole new language to deal with.
Add dynamic content. Suddenly, the page isn't a static thing, there's a DOM that's being modified in real time.
Add a growing internet, with many users of your page. Now you need to know how to make a scalable system, and how to design a proper database.
Add cloud computing, where the underlying infrastructure itself can be scaled in real time, and where you can get extra database servers if you need them for a couple hours.
Add internationalization, and now the programmer has to be aware of Unicode, different date formats and so on.
With each added feature and with each added layer the complexity grows. And you can't just throw your hands up and say "fuck this, let's do it like we did in the 90s", because all those things were added for a reason. Without Unicode, you have problems with your international clients. Without dynamic content your page is clunky and slow compared to the competition. Without planning for scalability, your infrastructure falls down right when your business is on the front page of Reddit.
I get the nostalgia for the good old and simple times, but that never lasts. As soon as a new tech emerges, people build on top of it, and then on top of that, and so on, and things escalate until it's hard for a single person to deal with all of it anymore.
You might as well suggest that people could master painting or mechanical engineering or something without putting in a time investment.
I'm all for getting more people to code. I'm all for an introductory language for new coders.
But when it comes to the big league heavy lifting coding, it is going to be complicated because it is complicated.
It isn't complicated because some "nerds" made it complicated. It was complicated before anyone coded at all. It is inherently complicated.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
I don't get why the notion of "full stack developer" is such a big deal. I mean, do people go to build a home and say, "I want an 'all trades craftsman'."? Or do people go looking for a doctor and say, "I want an 'all specialties surgeon'."?
I want someone to be in charge of building my house that understand enough about wood, concrete and plumbing to safely fuse the different work, without it falling apart next year.
And when I have surgery on my foot, and the surgeon spots a rupturing blood vessel, I want him to be able to deal and not have to put me on ice while attempting to find someone who knows something about veins.
A strong base with branching out into special areas is what I want to see. Not specialists who have no fundamental knowledge, unskilled labor who fall apart when instructions don't match reality, nor generalists that are so general that they can't actually do anything.
The problem is that it's impossible. The complexity of software comes from the complexity of the underlying problem. No matter where you move the complexity, whether it's from the frontend to the backend, or from an application to a library or to the OS, it still exists. Someone needs to understand that complexity to create working software for it.
Lay people, especially managers, like to think "if we just used library X" that could take care of all the hard stuff. The reality is, using library X now becomes the hard part. It could be bugs, performance problems, bad behavior for certain edge cases, incompatible API changes or security problems. In many cases it could be worse to work across an abstraction layer like that, since the business-destroying bug you're running into is just one of thousands that the upstream developer has to deal with.