[Ace17]

> Programming today 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.

This is vague and insulting.

Many of us programmers spend a lot of energy to keep systems simple, to a point that one could mistakenly conclude that they were easy to write.

We don't dream of having to maintain complex machineries reminding us of Rubik's cubes. We consider maintainance nightmares and hard-to-understand systems as failures, not goals. We don't love complexity, we hate it (but the less experienced of us haven't got the chance to fully develop this hatred).

[stcredzero]

> Programming today 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.

This is vague and insulting.

As someone who can solve a Rubik's cube and has programmed and played D&D since the version predating the "Advanced" ones, I think it's spot on!

Many of us programmers spend a lot of energy to keep systems simple, to a point that one could mistakenly conclude that they were easy to write.

I've seen code like that. It's the exception, not the rule!

We don't dream of having to maintain complex machineries reminding us of Rubik's cubes

Really? Because I've seen lots of 20-something programmers trot out a bit of code because it's "neat" without regard to cost/benefit within the project and within the current codebase.

We consider maintainance nightmares and hard-to-understand systems as failures, not goals.

I see lots of programmers who blame the skill and intelligence of their fellows while not demonstrating self-awareness by examining how everyone's participation in the system creates the mess in an emergent fashion -- then go on to fail to solve it.

We don't love complexity, we hate it (but the less experienced of us haven't got the chance to fully develop this hatred).

Plenty of the younguns just straight out fetishize complexity. Overtly. Enthusiastically!

[BlackFly]

I too, don't understand why people think anyone could be a programmer if it wasn't for the existing programmers. What is considered a good grade in school? I think most parents would be happy with their children coming home with 90% grades. That's 1 error in 10 attempts. That is a pretty abysmal fault rate in an actual computer program. Even most experienced programmers fail to consider everything that can go wrong with a system, but that is what is required to make fault tolerant systems. There is no silver bullet[1], and I wish people that wrote articles like this would go out and read that essay and actually attempt to tackle the thesis of that essay instead of just asserting the opposite.

[1] https://en.wikipedia.org/wiki/No_Silver_Bullet

[AstralStorm]

You do this by involving mathematical proofs at every stage. That is expensive, but sometimes done.

Strict functional languages are a step in the right direction. As are verifiers as done in Rust.

[BlackFly]

Some use cases and bugs are not amenable to proof. For example, how do you mathematically prove that your rendering engine is cutting off the bottom of the g of your new font?

Not all requirements of a system can be expressed a priori. I think proofs will never be enough to make a bug free system. Working as intended is a very frustrating response to a perceived bug for a user.

[tluyben2]

I do not think that is his point though; it is not that you dream or like making that complexity, it is that you are forced to make it by current tooling and languages. You are and people you know probably fall into the group of exceptions that can handle that kind of complexity (to some extent) and try to simplify it. In the non HN, corporate world of a lot of companies, this is not the case. Many large corporates do not do version management, code reviews, refactoring or anything you consider standard. You are the exception. And that is mostly because of the tooling; for most beginners React/Node simply is far more challenging than Visual Basic or HTML/PHP. For people who just want to solve a small problem and share that solution they made, learning 3-4 languages and installing bucketloads of tooling and libraries is just not a step forward.

By using that kind of tooling you are already acknowledging what the article says in some ways. By using programming languages and editors that let you figure out what the computer can do much faster (like figuring out, at edit time, the result of a bunch of if then else statements for instance), you are getting further away from simple.

And yet this is our normal and it hardly changes over time. So yeah, as someone who has programmed for over 30 years I see the D&D and Rubiks Cube comparison. We do not like it but that does not make it less true; it was easier to solve simple problems ‘fullstack’ when fullstack was 1 language and 1 simple install that had everything; in my opinion we did not evolve well here. It was easier to create most (No I am not talking about a Facebook; that is far from most) things when you did not have to worry about libraries or packaging for deployment. It always was a Rubiks Cube, but we are getting more D&D by the week imho.

And then there are the sort of things Edwards likes to experiment with; relevant live feedback during coding with enforceable prompts to repair simple things that your brain is just not (by far) as good or as fast at as a computer is.

[david927]

This is vague and insulting.

Good. It should be. Get mad about that. Get so mad that you devote time and effort to fixing it.

Programming compared to other disciplines is what might arise from a Lord of the Flies situation. Like the end of that novel, we should stop, fall at the feet of a comparison of programming to other disciplinnes, and weep tears of shame.

[Vinnl]

> Get so mad that you devote time and effort to fixing it.

Interestingly, I feel that insulting people is one of the worst possible ways to get them to change their behaviour.

[stcredzero]

But if you're so cynical you just want to help people more quickly seek their own doom...then pass the popcorn! This should be good!

[david927]

He's not actively insulting anyone; he's calling a spade a spade, he's telling the truth, and if you find that insulting then change that reality.

[Vinnl]

The person you replied to called it insulting. It's not really about what you think they should do; all I'm saying is what I think it's likely people will do. Formulating criticism in a way that the people it applies to are not insulted is, I think, the best way to actually get them to fix it.

It's hard, I know. But all I'd do when someone refers to Rubik's Cubes and DnD is shrug it off and think it doesn't apply to me.

[AstralStorm]

The easiest fix is to debunk the article. Which reflects the author not spending enough time writing kidding critical software and too much with cool startup kids.

There is no technical solution to a social problem caused by hiring cheap young and naive programmers.

[ofrzeta]

While I agree that it's a social problem I think it's more of an industry problem than a hiring problem. The industry generates sales by putting new tech first over solving business problems. So you have customers like big companies and consulting companies that hire "cheap young and naive programmers" with little experience who are willing to jump any hype train. After all it is easier to just learn the latest bunch of technologies opposed to recap decades of computing history. Then the young programmers implement proof of concepts in, say, cloud, containers, serverless and BigCo execs are satisfied because they can proof they are trying out new stuff. It doesn't matter that it's not maintainable or sustainable because it's thrown away after one year anyway, when the cycle starts over.

Obviously I am exaggerating but it's still a huge part of reality.

[david927]

The author is Jonathan Edwards who was a fellow at MIT and is an eminent Computer Scientist.

The article stands true on its own, and is not a simple indictment of a class of programmers.

[AstralStorm]

Well, if anything, MIT actually is the startup and cool stuff mine lately in addition to strong CS.

Programming can be made as accessible as spreadsheets to common people when they become as good at baseline logic as good programmers. (This is not that high of a bar actually for your average cheap coder.)

Designing CRUD apps has been automated before, as have been macro systems like iMacros or AutoIt or the venerable Windows Recorder. RAD tools still exist but common people don't want them. Graphical junk like LabVIEW also still exists.

Automating modifying applications runs counter to job security and would enforce a specific architectural decisions forever... Too expensive unless it is for mission critical software.

[vanderZwan]

By the way, claiming a statement is vague is quite disingenuous if you take the quote out of context. Especially when the author explains what they mean in the next four sentences:

> Programming today 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. I’m serious: Dungeons & Dragons requires mastery of an encyclopedia of minutiae; Rubik’s Cube is a puzzle requiring abstract mathematical thinking. That is programming in a nutshell. As a bonus you also get a toxic culture of intellectual one-up.

[mockingbirdy]

I've streamlined all my processes to the point that I can build a reasonably scalable system (including user management, app, ACLs, file management, custom queries, REST API points, websocket integration) in a couple of hours.

It's boring for a developer. I don't understand many of the problems described here (e.g. people complain about the complexity of server management, complexity of web frameworks and web in general). Actually it has become more simple than ever to create an app, a backend and scale the system.

With more servers (I use systems that can be scaled horizontally) thrown at it, good caching and some load balancing, it will work for 99% of businesses. Here [1] is a good description of a service that uses this thinking.

I believe there are many who celebrate complexity. Otherwise I can't understand most codebases - I've seen terrible codebases with big LoC's where I was able to reimplement the whole feature set in a couple of days. I believe many programmers don't want to see that their jobs become increasingly easy to do and the boilerplate can be reduced by 90%.

> We don't dream of having to maintain complex machineries reminding us of Rubik's cubes.

Many people do because their jobs depend on it. If businesses would adopt those fast, clean and scalable engineering techniques, 70% of the work force is no longer needed. It's basically the principal-agent problem [2] in action.

[1]: https://medium.com/unboxd/how-i-built-an-app-with-500-000-us...

[2]: https://en.wikipedia.org/wiki/Principal%E2%80%93agent_proble...

edit: in terms of "No Silver Bullet" - I think if we decrease accidental complexity (using good techniques and automated and tested systems) to a record low, we won't need as many people to manage the essential complexity.

In my experience the problem of complexity is another one: big enterprise makes a lot of money using their terrible code. They will keep throwing money at it to avoid major rewrites. Programmers will complain about unnecessary complexity, but complexity is not what's important for the bottom line most of time. The system just works and prints money, so there's no need to correct (until it explodes in complexity, but a major rewrite is also a risky decision for managers and can result in huge investment losses).

[vanderZwan]

When someone points out a painful truth, it's better to take a good look at oneself, be honest about our flaws, and accept their advice, than to just reject it and consider the other person as mean-spirited.

> Many of us programmers spend a lot of energy to keep systems simple

"Many" is not good enough (and makes me think of the cringy and problematic #notallmen thing on twitter). Ask yourself: who introduces the complexity to those systems again?