4 ms·
> The startup pace is fast, and you need to be creative, think on your feet, and come up with solutions as quickly as possible. A more accurate description is:
by tensor 9y ago
> The startup pace is fast, and you need to be creative, think on your feet, and come up with solutions as quickly as possible.
A more accurate description is: The startup risk tolerance is extremely high, thus it rewards quick and dirty over well thought out and solid.
This is often opposite to academic work, which needs to be well thought out and rigorous to an extent, though not necessarily in code quality. The code just needs to work for the experiment and be correct. It doesn't need to be maintained, extended, and debatably, communicated. This is also probably why startups tend to hire younger people, rather than older developers who've worked for places where the risk tolerance is very low and thus they take the time to make sure things are very solid.
- hedora 9y agoWhat? A decent PhD needs to have a payback horizon (time between start to commercialization) of over 5 years. Startups cannot afford that level of risk. PhDs should be much riskier than startup pitches. Maybe it is an artifact of the fact that I work on computer systems research (where the focus is on finding the simplest solution that works) but the comments here make me wonder where you (collectively) are finding your PhD candidates! I do agree that is often OK for PhD code to be terrible ("least publishable unit"), but that is also true of non-core production code at startups! ("Minimum viable product")
- noobermin 9y agoFurthermore, the article under consideration speaks to that: >Many PhD students can be perfectionists. But they need to remember that there’s an important compromise that needs to be made between the best solution and a good solution that can be used in practice. Code quality doesn't seem to be a concern for Dr. O at least.
- WalterSear 9y ago> This is also probably why startups tend to hire younger people, rather than older developers who've worked for places where the risk tolerance is very low and thus they take the time to make sure things are very solid. Appropriate older developers should have an even better handle on when (and how) to write good code and when (and how) to write bad code. Moreover, their bad code will be better, and produced faster. Young coders are hired mostly because they are cheap and don't understand stock options.
- solatic 9y ago> quick and dirty over well thought out and solid Perhaps you misunderstand the agile process? Quality isn't something you ever actually achieve through the Feynman Algorithm (write down the problem -> think real hard -> write down the solution) regardless of whether you spend two hours thinking real hard or two years. Quality is achieved through iterative, continual improvement and polish. Otherwise, waterfall software would be the pinnacle of quality.
- dasmoth 9y agoSoftware quality isn't the easiest thing to define. In some cases, it means "no bugs", and it certainly looks to me as though the places turning out really-low-defect-rate code for, e.g., aerospace applications are doing a fair amount of up front planning (plus other things -- reviews, dedicated QA groups, etc.) In other contexts "nice to use" is a better measure of quality, and I definitely agree that some iteration can help there. Even so, I'd caution that iterative development and a planned overall architecture aren't necessarily incompatible. And when following an iterative approach you have to be pretty careful to optimise for something that most users like, rather than a just bolting on everyone's pet feature.