4 ms·

My experience is that the type of day-to-day work shifts pretty significantly as a company gets bigger, generally from "build new things" to "maintain existing

My experience is that the type of day-to-day work shifts pretty significantly as a company gets bigger, generally from "build new things" to "maintain existing things". At a big company, my view of "good engineering" was writing well-factored code and making systems robust and scalable. At a small company, my view of "good engineering" is intelligently taking shortcuts for faster prototypes when the final product is uncertain, or recognizing clever product solutions that can be built quickly to satisfy a user need. If you want space to find a perfect solution for a well-defined technical problem, you probably want to work at a big company, and if you want messy open-ended problems where you get significant ownership over the product direction, you probably want to work at a small company.

marcc 8y ago
This is well said. Writing well-factored, robust, scalable and easily-maintainable code takes more time than shortcuts. It produces a much better result also, and that time is a worthwhile (and needed) investment only after you've figured out what the final product is. Iterate quickly, knowing you are building some some technical debt. When you figure out the product, chances are that significant portions of code have been thrown out, and now you should focus on upgrading the quality of that early code. The engineers I've seen that struggle at early stage startups are the ones who want to go from 0 to 1 on a prototype but want to write well-factored, robust, scalable code because they are worried about how it will be maintained. I can't stress enough, to be successful at most early stage startups, the goal has to be to create a product that people love, and then figure out how to get it maintainable.
- redisman 8y ago
  It's a tough switch both ways. The ideal experience IMHO is starting at a small company with prototyping and fast delivery that then transitions to a more established business and makes you clean up all your messes.
jiveturkey 8y ago
best differentiation i’ve ever seen

marcc 8y ago

This is well said. Writing well-factored, robust, scalable and easily-maintainable code takes more time than shortcuts. It produces a much better result also, and that time is a worthwhile (and needed) investment only after you've figured out what the final product is. Iterate quickly, knowing you are building some some technical debt. When you figure out the product, chances are that significant portions of code have been thrown out, and now you should focus on upgrading the quality of that early code. The engineers I've seen that struggle at early stage startups are the ones who want to go from 0 to 1 on a prototype but want to write well-factored, robust, scalable code because they are worried about how it will be maintained. I can't stress enough, to be successful at most early stage startups, the goal has to be to create a product that people love, and then figure out how to get it maintainable.

redisman 8y ago
It's a tough switch both ways. The ideal experience IMHO is starting at a small company with prototyping and fast delivery that then transitions to a more established business and makes you clean up all your messes.

jiveturkey 8y ago

best differentiation i’ve ever seen