[smoyer]

I spent the first twenty years of my career as an embedded systems engineer and there are two specific advantages I gained from that experience:

1) When your writing code for an underpowered microcontroller, you have a plan before you start. This plan includes execution speed and memory usage targets.

2) When you're sending thousands (hundreds of thousands or millions) of non-reprogramable devices into the field, you have a test plan (and comprehensive test suite) that guarantees correctness and performance.

Do you know your "machine"? For instance, if you're working with a language that runs on the JVM have you read the JVM specification? (It's the equivalent of your micorcontroller's data-sheet). The part of this manifesto I agree with is that you should thoroughly understand everything "beneath" your application.

[iamcurious]

>you have a test plan (and comprehensive test suite) that guarantees correctness and performance.

I value the work you do, but please don't imply that tests can guarantee correctness. Tests can never prove the absence of bugs! To guarantee correctness we need to treat programs as mathematical objects.

[logicallee]

>The part of this manifesto I agree with is that you should thoroughly understand everything "beneath" your application.

Say someone (a full-stack developer if you want, or jack-of-all-trades-master-of-none) uses Photoshop and Illustrator but also is coding against Firefox, Chrome, and Safari, and their stack includes node.js, Express, Angular, and PostgreSQL.

At some point, you can't thoroughly understand every cycle of every rendering engine. (Which is what what you've stated implies.)

It is quite literally impossible - as in, a physical impossibilitiy, of "thoroughly understanding everything 'beneath' your application." You just can't - there are not that many hours in the day. You would have no application left.

If you froze technology today you could thoroughly understand all of the mentioned technologies in 10 years. But by then there would be new technologies.

Instead, you just have to abstract it away, code against some framework that compiles down to javascript, and only understand that. You can't thoroughly understand every single thing your databse engine is doing either.

Otherwise you can just never get anything done. The modern world is made up of applications whose combined reference materials total without exaggeration millions of pages of text. You just can't read a million pages of text.

This is completely different from a single microcontroller's architecture. Which is basically a single layer. On the web, even your target is a collection of competing browsers.

Why should someone building a front-end site but also using the basics of a database somehow, take months out of his or her life to gain a deep understanding of every cycle of that database engine or what exactly it's doing?

What does it get them?

Cycles - even billions of cycles - are cheap.

It's like asking a farrier[1] (someone who cares for horse's hooves and then puts shoes on them) to learn all the intricacies of metallurgy, really go back to where metal is mined in ores. Oh, and since, "A farrier combines some blacksmith's skills (fabricating, adapting, and adjusting metal shoes) with some veterinarian's skills (knowledge of the anatomy and physiology of the lower limb)" I suppose this farrier suddenly needs to be a complete veterinarian and really fully understand all layers of the horse?

It just doesn't work that way. At some point the farrier has to work with an abstraction, and not know what is going on at lower layers, and at some point the full stack developer has to just use an interface that compiles down to javascript that will access a database he or she doesn't know. While you may lament this, beautiful and functional sites have been built this way.

It's not fair to ask someone to fully understand everything. Even as a microcontroller coder, you didn't understand the circuitry in the microcontroller at an electrical level - you didn't even get the diagrams. You, too, worked with an abstraction.

[1] https://en.wikipedia.org/wiki/Farrier

[smoyer]

I never said you had to deeply understand your tool-chain ... the use of Photoshop isn't at all relevant (though understanding the produced image format might be). PostgreSQL on the other hand becomes a lot more powerful the more you learn about how it works "beneath the covers". Of course there are limits ... I knew the timing of my microcontroller's signals but ignored details of the physics behind the microcontroller's implementation.

The first computer I built was a COSMAC Elf (based on an RCA 1802 microprocessor) - I didn't have billions of cycles so there was a limit to the work I could do. Now I do have billions of cycles and do my best to make sure there's a linear increase in the amount of work I can do.

<old-guy-voice>In the old days, we spent large amounts of time reading data-sheets, specifications and application notes - probably more than we spent writing software. What you're implying is that you're too impatient to do engineering but you're willing to be a programmer (or hacker).</old-guy-voice>

So I agree with the premise that we should be producing smaller, faster and less buggy software than we are. I don't think we need everything related to our systems - I certainly used ICE when available to avoid the code/burn/test cycle required using EPROMs.

There is (of course) a finite limit to what we can learn, but that doesn't mean we shouldn't want to know everything. One important skill is being able to discern what you need to know, what you need to understand and what you can safely ignore - this is hard. Knowing is also a choice. I can learn more than most because I don't watch TV or spend inordinate amounts of time wasting elsewhere (I have a few vices like HN).

[logicallee]

The distinction you start with between stack and tool-chain is fair, so let's cut out photoshop and illustrator. However, the three mentioned browsers are certainly part of the stack, and the browsers are the ones executing the cycles of anything running in the front end, which these days is a lot. Nearly all projects are literally targeting all of these disparate browsers.

To cut a long story short: when you say "What you're implying is that you're too impatient to do engineering but you're willing to be a programmer (or hacker)" - this is correct. The only way for many people to get projects off the ground is not to engineer them, but just to throw them up.

By the by, I actually in a couple of spare hours toyed with the idea of formalizing this into a project, where we would teach some valuable skill in 15 seconds. (I applied to a YC fellowship with it but wasn't selected.)

Here's my prototype - (it autoplays 15 seconds of sound, you've been warned.) http://iknowkungfu.meteor.com

I didn't write the tutorials up there now, and many of them are too long. But the idea is there: in a few seconds, you can often learn and incorporate something into your stack that you know next to nothing about.

Do this a few times and you have a complete web app serving dynamic, database-backed content - and you've still been able to focus on what you know rather than engineering.

There are 3 billion people out there who deserve to use some of the tools that are available. You, too, deserve to use some of the modern frameworks that are available. Without investing hours, days, weeks of your time into it. I know lots of technologies whose basic usage could be uploaded to someone's brain in 15 seconds of video. Git, to name one.

No, you won't understand how it works or why - but you can commit and roll back (reset), which is all anyone cares about until they start caring more. The advantage to using the git that you can learn in 15 seconds, over copying files and continuously renaming them - is - simply put, astronomical.

Many parts of the toolchain, and many layers of the stack, are quite similar. Who knows what cycles MongoDB is running? Who cares?

[smoyer]

"Learn X in Y minutes" is an awesome concept! Let me know if you ever decide to run with it. I guess I don't fit the CoffeeScript is a hipster language profile very well but I still enjoy writing code in it ;)

I basically agree with everything you've said (in both posts) ... you can be successful while wasting cycles. And if you're working on a low-volume and/or internal only application, you'll probably never face the limits of a modern server.

If you need to operate "at web scale" [1], or run into an uncommon (or common) bug, you'll need to know more about the frameworks and systems you're code relies on (e.g. MongoDB configuration for systems over 2GB [2]). Blog posts like the one referenced are completely unfair to those that developed MongoDB - read the manual and understand how MongoDB works OR use it at your own risk.

So I'll switch arguments and help you make your point. We have an application written in Oracle's Application Express - while we have extensive expertise in Oracle's database software, we have this one system which was completed for expediency's sake. It's kind of horrific but (mostly) works at the scale required. It would be financially foolish to dig into more deeply into ApEx for this one dead-end application. Everyone is happy.

[1] https://www.youtube.com/watch?v=b2F-DItXtZs (audio NSFW)

[2] http://www.sarahmei.com/blog/2013/11/11/why-you-should-never...

[logicallee]

Thanks for the reply! (I didn't actually build those tutorials, i.e. learn x in y is another person's site, like I said I only spent a couple of hours on the concept of a site like this and the current tutorials are external. I did add the time analysis.)

I like your final example - and remember, you guys are Oracle experts: you're the most qualified people on the planet to learn ApEx properly from scratch, even though you haven't.

Now switch gears and imagine a college student who just has an idea for some cool project, but barely codes in any language. This describes the computing needs of 3 billion people. They're not qualified to quickly become experts and engineers at anything. But they still have a computer in front of them that does a trillion operations every few minutes. The gulf between using that to surf facebook or building... anything at all, even very poorly, is immense. (Like git that you can learn in 15 seconds, versus manually copying and renaming files for version control.) Thanks for the encouragement.

[falcolas]

You might be surprised at the depth of knowledge your average Farrier has about both horses and blacksmithing. They might not have a degree in metallurgy, but you can bet they understand the crystalline structures of iron, and how to use that to their advantage. You can also bet on them knowing more about the hooves and related structures of a horse much better than your average vet.

The problem with your hypothetical worker is a lack of depth into any one topic. If they're half artist and half front-end developer and half back-end developer, of course they're not going to be able to get into great depth on any one topic.

I firmly believe in the value of such a Jack-of-all-trades, but I'd be silly to not value the full time artist who can create better works in a third of the time, because they understand their tools and their craft.

[logicallee]

Yes, it takes three times as long for a jack of all trades to draw something that is a tenth as good as what a full-time artist can do in minutes.

A tenth as good isn't good enough. But on the web, for many parts of the stack, a tenth as good really is enough. Even using too many cycles by a factor of three orders of magnitude is still good enough. You just don't need to know.