These quotes really show the paradox: within the weird definition used in the article of "amazing engineers" which is not defined but seems to imply those who c

These quotes really show the paradox: within the weird definition used in the article of "amazing engineers" which is not defined but seems to imply those who can talk a big game about architecture or score well on the HackerRank, the "quality" of the engineer has no relation to business success. That's because the engineer's quality is being assessed for being able to bullshit about architecture or score points for writing "clean code." The idea that "even great engineers" might take on technical debt is insane. In a startup situation, great engineers take on technical debt with the greatest of glee and at every opportunity, as the primary goal is to find product market fit. Bullshitting about scalability, maintainability and frameworks is counterproductive and maturely, one understands that any software will be almost totally rewritten whatever happens: take this example by John Carmack to start a prototype environment for rapid iteration, explicitly laying out ways in which it should be rewritten if successful https://groups.google.com/forum/#!msg/racket-users/RFlh0o6l3Ls/8InN7uz-Mv4J https://groups.google.com/forum/#!msg/racket-users/RFlh0o6l3... Many good engineers stay in their comfort zone of some part of the software lifecycle. Seems like the author was trying to assess people imagining their situation was that of big company software project going in for a third generation rewrite with little uncertainty about what it should do. This is not the situation startups are generally in, and great engineers in this situation adapt; they pivot without getting stuck on old conceits, and have a knack of understanding which signals to heed to get to that glorious market fit where suddenly reliability is valuable. Definitely they can be assessed on ability.