[The E]

So this article recently entered my newsfeeds. It's really long, but reading it is very much recommended if you ever wanted to know just what it is that software developers do all day, why we do things the way we do them, and why there are sometimes decades-long flamewars over the correct way to position opening and closing braces.

To quote the introduction:

Software has been around since the 1940s. Which means that people have been faking their way through meetings about software, and the code that builds it, for generations. Now that software lives in our pockets, runs our cars and homes, and dominates our waking lives, ignorance is no longer acceptable. The world belongs to people who code. Those who don’t understand will be left behind.

This issue comprises a single story devoted to ­demystifying code and the culture of the people who make it. There’s some technical language along with a few pretty basic mathematical concepts. There are also lots of solid jokes and lasting insights. It may take a few hours to read, but that’s a small price to pay for adding decades to your career.

[Fury]

I disagree. Knowing code is no more necessary than knowing how your freezer, washing machine or car works.

[Achillion]

I'd argue that drivers should know how a car works, at least at a level where they can tell what's potentially broken from the sound the car makes or the way in which it's "behaving".

EDIT: And ESPECIALLY so if it's a central part of their working environment.

[NGTM-1R]

The world belongs to people who understand RF transmitters, and the rest of you will be left behind!

Or not.

[Flaser]

The world belongs to people who understand RF transmitters, and the rest of you will be left behind!

Or not.

Actually, if you asked people about what radio is, while most won't give you a scientifically accurate answer they'll give you a description that will cover some of its basic properties well. I'm afraid that same can't be said for software while its use is increasingly as common as breathing air.

[Dragon]

I'd argue that drivers should know how a car works, at least at a level where they can tell what's potentially broken from the sound the car makes or the way in which it's "behaving".

EDIT: And ESPECIALLY so if it's a central part of their working environment.

One very much can drive a car with only rudimentary knowledge of its workings, but you'll pay through the nose for every little failure. A loose nut once set me back 50 zloty (granted, 30 was for replacing the hydraulics oil that leaked through it, but still). And don't even think about buying a used car without a good idea of how it's supposed to work.

I'd say, it's similar with code (and computers in general). You don't have to bother with how the code actually works. But if you don't, you'll be stuck with what you're given. If you do know what you're doing, you can improve performance and usability of many programs by a large margin. Not to mention you're not helpless when something fails. Assembling a PC out of components is also cheaper (for the same performance) as buying a prebulit one (not to mention infinitely more fun ). You don't actually have to know any programming languages, mind you, but rather the underlying principles that all of them work upon.

[Klaustrophobia]

Speaking as one who knows far more about code than cars, you get FAR less benefit out of knowing how code works than how your car works as an everyday user.  There's almost nothing in day-to-day computer use that knowledge of code will improve.  You can't bust open the hood of your broken program and use your knowledge of programming to fix it.

[Phantom Hoover]

Yeah, you're much better served by knowing how to use your OS and applications than knowing how they work inside.

[AdmiralRalwood]

Speaking as one who knows far more about code than cars, you get FAR less benefit out of knowing how code works than how your car works as an everyday user.  There's almost nothing in day-to-day computer use that knowledge of code will improve.  You can't bust open the hood of your broken program and use your knowledge of programming to fix it.

...I do this all the time.

[Klaustrophobia]

By 'your' program I meant one you bought and installed, not one you made yourself.  I realize that wasn't clear. 

[karajorma]

If you mainly use open source software, the dividing line becomes less clear. I assume that is the joke Ralwood was making.

[AdmiralRalwood]

By 'your' program I meant one you bought and installed, not one you made yourself.  I realize that wasn't clear. 

I didn't mean one I made myself, either.

I also wasn't making a joke; I have literally decompiled a closed-source program to fix a bug that was pissing me off.

[qwadtep]

Existing code aside, there's a pretty big gap in productivity between someone who knows how to set up a macro or batch file and someone who doesn't.