[josephg]

Sure; well rounded engineers care about architecture as well. But in the same way some “code first” programmers are myopic and only really care about the code, plenty of product first engineers only really care how the product looks. I’ve met and worked with plenty of people who don’t have the skill to be creative with architecture, or don’t know how to structure the code to avoid certain bugs showing up over and over again. Or have no idea how to make their code run fast. - So their software becomes a beautiful, laggy mess.

One “product first” engineer I worked with years ago made a database indexing system, syncing our data into elasticsearch so we could add text search to our product. For about 6 months after the feature launched we kept running into indexing bugs - where data was missing from the index and things like that. I (naturally code first) ended up helping rearchitect it. After we relaunched the feature we never had another indexing data bug as long as I was at the company.

Sometimes it’s faster to take more time to do it right rather than do it wrong and spend your life playing whackamole with bugs. It all depends on your context. (Is this a MVP to throw away? Or are you working on code that will probably still be around in a few years?). The best engineers know how to adapt their own personal process to the needs of the project. Sometimes that means quick and dirty. Sometimes it means thinking it through and building it to last.

[noway421]

We're arguing about semantics. What you define as "well rounded" I define as "product-first". What you define as "product-first" I would define as "inexperienced".

[josephg]

Yes, and what you’re describing as “code first” I define as myopic / inexperienced / single minded engineers.

Maybe the broader frame is to say there’s two perspectives to hold: the perspective of the user and the perspective of the code. Each orientation has its own set of supporting skills. Good developers are strong in one of those perspectives, but need other people on the team to balance them out. Excellent developers are strong in both, and can switch between them based on the immediate needs of the company and project.