This doesn't pass the sniff test. The demand for high-quality software continues to outstrip supply. Bad software is an imperfect-but-better-than-nothing subs

This doesn't pass the sniff test. The demand for high-quality software continues to outstrip supply. Bad software is an imperfect-but-better-than-nothing substitute for good software, which is why so much of it gets written. The problem here is that there's a sort of Gresham's law effect - bad software drives out good software by infection. Your technology stack is only as good as the worst component, and if you're operating at the level of indirection that Sam Gerstenzang suggests, that's a lot of software that you need to depend on, and your software can only be better than the software it depends at the cost of a lot of effort. Some component in your stack doesn't work the way you need it to? Well, suddenly you're either three layers down the stack trying to fix it, or you're writing a non-trivial piece of software higher up the stack to make up for the deficiencies of the lower level. I'd also dispute Gerstenzang's basic premise that modern engineers need to know less than yesteryear's. 20 years ago, you could write an entire app in Visual Basic. It could integrate with a database, had a drag-and-drop GUI builder, was scriptable using a language that, for all of its many idiosyncrasies, was fairly easy to learn (and you could write plug-in components in C++ if you wanted to). A statically-compiled binary could be put in a floppy disk and would work on any computer running Windows, where it would look basically the same. Modern front-end web code needs to navigate a Rube Goldberg machine of preprocessors and build pipelines that would have embarrassed a C developer from 1988, and incompatibilities with particular browsers, operating systems or form factors frequently cause simple tasks to take longer than expected. Because nearly every modern application is a distributed application in some sense, you need to understand concurrency and network protocols, and if you want to work on both the client and server components of your application, you probably need to know more than one programming language, or the subtle differences in the runtimes that your language has on client and server. And that's just fairly simple web applications! WhatsApp was created by a small team, but that team needed to include skills in everything from Erlang to J2ME. That breadth of knowledge was what gave WhatsApp the key competitive advantage of being able to support almost every mobile device on the market, not just the latest generation of smartphones. You might be able to get a startup off the ground without engineering, but you won't be able to grow it much.