Programming is Terrible

This guy gets it wrong in his last post on reliability (but the other posts seem reasonable).

Reliability is hard because we continue to move the goalpost. I can write a pretty reliable program to compute sin/cos tables or to sort a phonebook or to do some basic projectile trajectory. But those aren't even table stakes anymore. Today a first year undergrad student might be expected to write a program that in 1970 the most advanced programmer in the world couldn't do with a large team and millions in funding.

I hate the analogy to other fields of engineering (and this author doesn't fall down that trap, but plenty do). Bridges haven't changed in the past 10 years the way programs have (in terms of functionality or complexity).

And lastly, this is IMO, a corollary for why ageism is so persistent in our field. Experience means very little. Why? Because I can capture 70% of your experience in your code -- in your library -- and build directly on top of it. I don't actually need you. There are few other fields where as much of your experience can be captured in something so reusable (despite our constant protests that code isn't reusable -- it's more reusable than any output from my plumber).

Programming is terrible because we obsolete ourselves by moving technology out of our own grasp. The fact that newer programmers don't understand the foundation they build on is irrelevant, since few need to look behind the current. Unfortunately, I think it is simply the nature of the beast. It's why we love it and do it -- and probably why we'll all eventually stop (or at least move into management).

Programming is honestly a very tricky sector of work to understand how to make progress in the practice of it from here on out.

You have essentially an almost infinite number of ways to get to an endpoint with very few real constraints... this is good and bad.

We have lots of creative freedom within the constraints of code to achieve a certain piece of functionality. For example, authentication - Ive seen it done somewhat differently on every product Ive worked on not to mention the different languages and coding styles used. Most programmers enjoy the mental process of crafting their own implementation and there is usually a real reason for custom development - every product is a little bit different.

The bad... we seem to have to continually be rewriting custom implementations of very similar things which equals cost and usually mediocre reliability. We barely even have adhered to guides for something as common as authentication (at least that anyone pays attention to). This is quite vastly different than other professions. Take for example plumbing - while not every job will be done the same by every plumber, there are a set of standards that all plumbers leverage - specs on pipes, fittings, etc. Or take for example healthcare, most doctors have at most a few different treatments that are agreed upon as effective.

But its not like certain sections of the programming community haven't tried... we have open source libraries, plugins, published recommendations, etc but the problem is that the landscape is a mess not to the fault of any individual... programming languages, technologies, business requirements come and go every day effectively erasing much of the work/libraries/best practices/etc that were just starting to get established.

Its as if we need to only have one universal unchanging language and a set of universal devices we all agree on with an unbiased committee that organizes open source modules - I also live in the real world so realize this is a bad idea that will never come to fruition for a 1000 and 1 reasons but I have to agree with the author and dont have much hope in short term "real" advances in how software development gets done.

TLDR:

Don't bother making anything - there's no chance it will be successful, no matter what. Life sucks, then you die.

> Experience means very little

Perhaps. But I believe that good engineers have a number of cool failures in their past.

> Because I can capture 70% of your experience in your code -- in your library -- and build directly on top of it

You can capture /some/ of someone's experience this way. But don't confused the ability to _use_ the novel Moby Dick with the ability to _write_ Moby Dick. These are two very different things.

Let's talk about this hypothetical library for a minute.

1. It's a finished product. You didn't experience the design process. You didn't see the things that were tried and which failed. All you see is the shiny object. Could you make another like it?

2. Since you missed out on the design interaction, you're missing out on the stuff that was left out for the next version. You weren't there for the discussions about alternatives (maybe better ones).

3. If you treat the library as a black box, you're going to be at the author's mercy for bug fixes, making improvements, or doing integration in environments where it doesn't exactly fit.

4. Ultimately, abstractions are lies. The best ones are white lies, the worst ones paper-over or ignore fundamental problems. (My favorite example is putting a database on top of a Unix file system: How do you know when data is stable on disk? What /is/ a commit, anyway?) How much of that library do you really believe?

I've seen some really interesting product failures resulting from "unthinking isolation" -- perhaps a better term would be "false abstraction" -- of what was happening in the system at the hardware level. We're talking bricks and user data loss because someone thought that transactions weren't important. Performance is another area where it's hard to abstract (and some platforms, such as video game consoles, are all about performance).

Good, reliable systems should be designed with all layers in mind. That's where experience starts to matter.

> A bad programmer would be someone who didn't care about the next guy.

Unfortunately I wish this was true to non-programmers. But a "successful" programmer ships without worrying about how difficult it is to add a feature or to debug a problem when they're gone.

At least that's my experience in my current job where I'm mostly maintaining shitty code. And I know it's a culture problem too.