This is exactly correct. The difference is in how you approach problem solving, not how fast you write the code. Can you clearly articulate the important conce

This is exactly correct. The difference is in how you approach problem solving, not how fast you write the code. Can you clearly articulate the important concepts and how they inter-relate? Define the problem boundaries (and later, as a consequence, boundaries of functions, data structures, objects)? Separate which component is responsible for what, in a way that makes sense to the business need? Choose the right algorithms? Focus on optimizing what matters, know your tools to get standard parts done in a standard way? Like all true craftsmen, the final output will make everything seem so easy, so concise and obvious. But it's anything but. The same problem solved by an army of mediocre engineers will just end up a huge convoluted mess. And it doesn't matter how many of them you unleash during the initial architectural stages of a project — arguably the more, the worse the result. Being able to handle uncertainty (as opposed to an unrealistic list of minute specs), ask the right questions and make the right technical choices is what makes 1000x engineers. The value chain of software is long, and the higher up the chain you can empathize with and code to, the better for you.