4 ms·
I don’t think this dichotomy is helpful. I’m presently working at a startup that’s trying to dig itself out of a hole created by the first CTO, who in doing thi
by wk_end 5y ago
I don’t think this dichotomy is helpful. I’m presently working at a startup that’s trying to dig itself out of a hole created by the first CTO, who in doing things “quickly” created an MVP so buggy, inefficient, crash-prone, and unmaintainable that we can’t retain customers or engineers. As always, there’s a balance to be struck, and ways to operate quickly that don’t sacrifice quality too much.
- notreallyserio 5y agoI'm kind of surprised that you can't find engineers interested in creating a new implementation of an existing application that is actually used by people. I think that might be my dream role.
- 88913527 5y agoAt the risk of crushing your dream role, re-implementations can be long slogs. I'm in the middle of one right now. The Product owners don't know what the thing does. The engineers who originally wrote it are gone, and their replacements are relatively new to the codebase. The bright side is customers are hugely interested in our progress to date and we've received positive feedback. The business wishes we could move faster.
- Aeolun 5y ago> The Product owners don't know what the thing does. This is the dumbest part. You’d think that someone documented something when they originally built it, but nooo. Don’t even know the requirements, just that it has to be the same as the previous one.
- wk_end 5y agoBusiness doesn’t want us to stop the bus to change the tires - or spend so much time changing tires that the bus never reaches the destination.
- jimbokun 5y agoMakes me think of Lightning McQueen losing the first race in Cars because he refuses to pit to change his tires, then blows them out on the last lap.
- arealaccount 5y agoIf your dream job could be in Charleston SC lets chat :)
- cupofpython 5y agoThat type of role typically requires senior engineers at a junior salary
- cupofpython 5y agoI think something that is lost in this conversation is that "quickly" maps to wildly different results in code quality depending on the programmer. It sounds like your CTO did not just operate quickly, but also sloppy and chaotic. From what I am gathering from this thread, the best practice is to move quickly AND organized such that refactoring is reasonable.