[Dr_tldr]

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.

[Hydraulix989]

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.

[Hydraulix989]

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.

[ForHackernews]

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

[smaddox]

Closer to 99.99999999%, i would estimate.

[Dr_tldr]

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.

[naveen99]

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.

[laksjd]

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 ;)

[saiya-jin]

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

[Klockan]

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.

[k__]

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

[discreteevent]

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.