Surely you must realize how ridiculous that sounds. You can build basically anything (including a kernel) by working from tutorials and starter projects, then hacking through it. Someone's solution may be extremely sub-optimal, but I've yet to see a programming task that wouldn't to googling and persistence.

Inventing Calculus was hard, but virtually anyone can learn to pass a Calculus test given enough time and incentives.

Tutorials don't cover things like corner cases, and they neglect nearly every aspect of designing and integrating a large system, particularly scaling it. Some of the worst code I've ever seen was "tutorial code."

I've encountered concurrency challenges in my day-to-day work that have no cookie cutter solutions, are specific to my application (particularly in constraints and requirements), and I haven't even been able to fully convince myself of the correctness of my own solution, let alone contrive a way of systematically proving or even testing it.

On the other hand, programmers faced with solving technical challenges such as optimizing and approximating in the face of limited resource, where heuristics and intuition only discovered and learned through experience and trial-and-error (pattern building and "finding" at its best). These meta "design patterns" aren't found in any books yet, especially because they are pretty hard to articulate using the English language.

There is an inventive element to the sort of problem solving that good programmers perform that goes well beyond pasting solutions from StackOverflow. This is why duct tape and bubble gum cobbling of out-of-the-box solutions rarely works in practice (and why good engineers are paid so well). Clever hacks are actually pretty damn clever.

It's scary how many "best practices" I've only learned through building my own production systems and having actual users test what I've coded -- having already done a fair deal of sitting in classrooms being inundated with CS theory from the very minds who conceived it -- even years of building pet projects of my own haven't prepped me for the challenges I am encountering now.

I might add that the difference between a hacked together kernel and the Linux kernel is HUGE. "Hacked together" projects are full of weird bugs, incorrect concurrent code that still works 99+% of the time but then rarely crashes and burns when that ill-anticipated failure case execution interleaving randomly strikes -- to say nothing of problematic and unrefined UX. Well-designed projects are a work of beauty.

> full of weird bugs, incorrect concurrent code that still works 99+% of the time but then rarely crashes and burns when that ill-anticipated failure case execution interleaving randomly strikes -- to say nothing of problematic and unrefined UX.

That sounds like an accurate description of 95% of existent software in the world.

Closer to 99.99999999%, i would estimate.

100% agree, but this is an epoch where even the most mediocre dev is capable of having a long and fairly successful career. I've worked with some huge systems filled with garbage code, and I've never seen a comment anywhere in there that said "the people who wrote this have all been fired."

If the end user experience is anything better than catastrophic and it's making a profit, it's very hard to make anyone care. At best, there will be a big cleanup project that takes it from being totally incoherent and inefficient to being merely very stupid, but in a fairly consistent way.

Most programming tasks don't have tutorials. Programming tasks in general are more like inventing then passing a test on some book material.

Also like you say, everyone won't pass calculus. Not even programmers.

Imagine you're given a problem that is completely novel in its description yet is actually reducible in some non-trivial way to a well-known NP-complete problem that has great probabilistic algorithms available for it.

Googling the original problem description will (for a novel formulation of the problem) not result in any advantage and implementing a standard algorithm will not work if you need n to be large for your application.

I will admit that it's a slightly contrived example ;)

you just described what maybe 0.001% devs will face, so not really... that's not how studies are done nor intended

0.001% of devs would be around a few hundred in the whole world, there are way more CS grad students than that...

I'd guess that at you get to at least a few percent if you count grad students, researchers, people working on performance critical stuff like GPU drivers, people working on state of the art tooling like Google internals or large OS libraries etc.

I read somewhere that people who don't know calculus somehow invent it by themself when faced with a problem that requires it.

Here's one: Take a complex system and make it as simple as possible but no simpler. The complexity may be essential or accidental (as introduced by previous 'fast' programmers). When you need someone with this ability, you really need them because the system is falling over under its own weight.

Worse than infinite.

The truly bad programmers destroy more than they create, making extra cleanup work for competent and productive programmers like me and everyone reading this.

Can you give an example of an "IQ requiring task"? I'd buy that there are programs you can't write without the proper background knowledge, but I don't understand what IQ has to do with any of this.

On one hand IQ is pretty much a measure of general problem solving ability. The higher your IQ, the better you will solve most kind of problems.

On the other hand, that's an average. Most anyone can solve any individual problem once.

Write a sensible search engine for the web with 1995 knowledge.

First you have to prove that the relationship between IQ and performance on writing "hello world" is continuous, otherwise IVT doesn't apply.

I think what you call it is more complex. As I can see there are three important capacitities: attention to details, working memory and iq (capacity to see patterns, what is tested in iq tests). In my experience they are all important, I'm pretty bad at the first two, and this makes me miserable in my job.

attention to detail correlates with interest in the topic. Maybe find something to work on that you care about a lot of that excites you. If not cultivate your interest. Pretend it's your child then love it unconditionally.

Working memory: Memorize things that surprise you. Then Try to understand why you were surprised. You don't have to memorize things you understand.