5 ms·
... until reality catches up with a software engineer's inability to see outside of the narrow engineering field of view, neglecting most things that the end-us
by malthaus 11mo ago
... until reality catches up with a software engineer's inability to see outside of the narrow engineering field of view, neglecting most things that the end-users will care about, millions if not billions are wasted and leadership sees that checks and balances for the engineering team might be warranted after all because while velocity was there, you now have an overengineered product nobody wants to pay for.
- varjag 11mo agoThere's little evidence that this is a common problem.
- KaiserPro 11mo agothere is in meta. Userneed is very much second to company priority metrics.
- tru3_power 11mo agoI wouldn’t say this lends to a bias of over-engineering but more so psc optimizing
- tomnipotent 11mo agoBesides the graveyard of failed start-ups? There's plenty of evidence, just no strong conclusions.
- varjag 11mo agoDid you look at the graveyard of failed start-ups and conclude they would of lived if they had enough non-coding overhead?
- tomnipotent 11mo agoI look at it and see just as many failed start-ups from engineer-founders as a do from non-engineer founders. The idea that being a programmer makes you better to run a business has nothing to back it up.
- varjag 11mo agoI'm not sure where this idea comes from though, it's not something I argued. The post I replied to claims engineers can't see the big picture and deal with end user requirements, and your own testimony above contradicts that.
- himeexcelanta 11mo agoYou’re on the mark - this is the real challenge in software development. Not building software, but building software that actually accomplished the business objective. Unless of course you’re just coding for other reasons besides profit.
- sp4rki 11mo agoI agree... but not at the engineering level. This is, IMO, a leadership-level problem. You'll always (hopefully) have an engineering manager or staff-level engineer capable of keeping the dev team in check. I say it's a leadership problem because "partnering with X", "getting Y to market first", and "Z fits our current... strategy" seem to take precedence over what customers really ask for and what engineering is suggesting actually works.