> Programmers have to remember a vast amount of domain knowledge. Consider the basic task of choosing where you are going to store some data, well first you need to know which options exist and there's dozens of them (do you want Postgres, SQLite, Redis, LevelDB, ..?). Then you need to know the strengths and weaknesses of each. And I hope you have been keeping your knowledge up-to-date because the answer in 2018 is very different to the answer in 2008.
I'm pretty sure 90% of us would just look for a Stack Exchange question describing a bunch of popular database platforms and choose whichever looked best after thinking about it for a few minutes, and that outside of extreme circumstances (>terabytes of data, distributed over an actually unreliable network, other exotica) almost any option would work well enough.
Which is to say, programming is complicated but it's not very precise. Compare to mechanical engineering, where if you use the wrong steel your bridge will fall down; or to medicine, where if you prescribe the wrong drug someone might just die. So while there's lots that's useful for a programmer to know, if they don't know it they can get by alright almost all the time, and it's really hard for their managers to tell the difference. (Which is also why we can get away with not having a "programming school" beyond a handful of required courses for a CS degree.) So it's hard for this to seem like a very effective barrier to entry.
> Compare to mechanical engineering, where if you use the wrong steel your bridge will fall down; or to medicine, where if you prescribe the wrong drug someone might just die.
Dereference the wrong pointer and the rocket blows up. Forget a memory barrier and the robot brain gets corrupted memory and sees human life as an impediment to paper clip maximization. Forget to zero out some memory in a goto: cleanup section and suddenly there's a back door in a popular security library leaving machines to the whim of any curious script kiddie.
I know a lot of people aren't working on real time systems or encryption libraries that have the same level of significant consequences as what you're describing, but some are.
For software developers (and in fact, for the general public), the smart play is to rely on real engineers to provide mechanical, electric, or electronic failsafes in their designs.
> I'm pretty sure 90% of us would just look for a Stack Exchange question
When you're starting from scratch, I think the bigger barrier isn't "where do I store this data", it's "what the hell is data"? Try to explain to a computer illiterate person that the latest Mariah Carey CD is just a really big number and you'll get a glimpse of this. The person who knows they can jump on Stack Exchange is already past the worst part of the learning curve.
And other times. I've been working in software for almost two decades. I ran into a particular data problem that I could describe but didn't know the name of (a la wizard of earthsea). So I couldn't search to see how others had tackled this.
Google and blogs and YouTube and stackoverflow have pushed the boundaries of knowledge. You don't need to know exactly how to do something (for many kinds of tasks) but you do need to know what it is called, and how to adapt what you find on the net to your situation.
> I'm pretty sure 90% of us would just look for a Stack Exchange question describing a bunch of popular database platforms and choose whichever looked best after thinking about it for a few minutes, and that outside of extreme circumstances (>terabytes of data, distributed over an actually unreliable network, other exotica) almost any option would work well enough.
And you're the reason why I have to mop up poor performance because someone decided to use MongoDB for highly-relational data.
Oh, yes[1]. I was arguing why there isn't a knowledge barrier to entry into programming, not why there shouldn't be one. :)
[1] Well, not me in particular! I know the important things and only use SE for looking up trivial details, of course. But maybe not everyone agrees with me which is which...
I'd argue the reverse: that in software, very small errors can have vast consequences, but it's virtually impossible in many cases to tell what those consequences may be or where they'll fall.
The reason is that software systems are at another level of complexity.
The Space Shuttle is often given as an example of the most complex machine every built, with more than 2.5 million parts. The Airbus A380 has about 4 million parts.
The Linux Kernel, not necessarily the most complex software ever written, has nearly 10 million lines of executable code, over 12 million with comments, scattered over 36,000+ files.
Google's back-end cluster and services are frequently given as the most complex software existing.
The full LoC in Debian GNU/Linux has been estimated as 324 million as of 2009. This is the stable archive, which includes somewhere between about 30k to 70k individual software packages (I'd have to do some digging to see what the count was for the stable release as of 2009).
>I'm pretty sure 90% of us would just look for a Stack Exchange question describing a bunch of popular database platforms and choose whichever looked best after thinking about it for a few minutes
I used to do that but I got burned more than a few times.
These days I do a bunch of research - sometimes days, including tracking down obscure blog posts about obscure issues, reading issue trackers and spiking code. Can feel like a waste to begin with but it's saved me from some very dark places.
I would not trust stack exchange or stack overflow for a technology recommendation ever.
I don't think the problem with programming is that it is complex or has wast domain knowledge, it is true, but this is not a unique problem.
I think the biggest barrier in programming is just how abstract and alien it is, cognitive load can be enormous. Try to teach engineer about materials or steel liquation or semiconductors - it might be abstract or complex but at least it is dealing with real life physical processes.
With programming it is whole different galaxy. Like explaining pointer arithmetic to someone who just started learning CS. Or recursion, or asking someone to rotate tree in their head - there is a huge chance it will simply BSOD them. Programming is much more close to theoretical physics or maths than engineering.
It's a good thought, but I agree with madengr. Other disciplines are faced with abstract challenges, and even those in plain sight are very difficult to reason about. Magnetic fields. Rotational moment of inertia. RMoI--still so confusing. Even simple to explain, easy to observe concepts can still be abstract and difficult to understand.
I'm pretty sure 90% of us would just look for a Stack Exchange question describing a bunch of popular database platforms and choose whichever looked best after thinking about it for a few minutes, and that outside of extreme circumstances (>terabytes of data, distributed over an actually unreliable network, other exotica) almost any option would work well enough.
Which is to say, programming is complicated but it's not very precise. Compare to mechanical engineering, where if you use the wrong steel your bridge will fall down; or to medicine, where if you prescribe the wrong drug someone might just die. So while there's lots that's useful for a programmer to know, if they don't know it they can get by alright almost all the time, and it's really hard for their managers to tell the difference. (Which is also why we can get away with not having a "programming school" beyond a handful of required courses for a CS degree.) So it's hard for this to seem like a very effective barrier to entry.