3 ms·
> What worries me is that certain developers, especially > developers early in their career, may get the idea that a > startup engineer is not a problem s
by jt2190 11y ago
> What worries me is that certain developers, especially
> developers early in their career, may get the idea that a
> startup engineer is not a problem solver or computer
> scientist, but... their task is [instead] to memorize a
> new... language, framework, or library - in many cases to
> get limited benefits.
While I agree that it's possible that an early stage startup (and I mean _early_, like building their first version) might flounder around rewriting their app using different tech stacks and never actually ship anything, I suspect that it's more common to see companies delay releasing their first version due to reworking things that are perfectly acceptable for a rough first version.
(edit: Also, I think the idea of a "sacrificial architecture" is useful when starting out. If you're lucky enough to need to massively scale, you're going to have to replace everything eventually anyway, so don't get too hung up on trying to make things scalable from day one.)
- angersock 11y agoI suspect that it's more common to see companies delay releasing their first version due to reworking things that are perfectly acceptable for a rough first version My observation has been that this gets a project into what I call the "done-but" category. "It's done, but could you change this?". "It's done, but can we make it responsive?". This is especially rough if the company uses pretty mockups to sell products--the cultural focus on design/UI/UX can drag out development, burn out developers, and generally just slow everything down.