Hacker News new | past | comments | ask | show | jobs | submit login

The truth of it is that the startup life isn't for every engineer. Startup code is messy. You don't have architects who draw UMLs for you, you don't have the luxury of time to do things right. At a small startup everything is often falling apart at the seams. Morale can rise and crash, repeatedly, like a roller coaster. Small startups often have to visit the iron bank of technical debt and take out a huge loan to put in that feature a very important customer wants right that second. Tests are very important, but spending too much on them can waste precious time. You're always flying low to the ground. You're looking at the short term: days and weeks, not months and years. That said, technical debt sucks and should be avoided at all cost, but priorities aren't the same when you're a three or four person team with about a year's worth of runway.



>At a small startup everything is often falling apart at the seams... >Morale can rise and crash, repeatedly, like a roller coaster... >You're looking at the short term: days and weeks, not months and years...

None of this rings true to me. Not at any startup I've worked at/founded at least(6 in total over the last 12 years). In reality good startups are relatively even keel.

Hell I would argue that startups, almost by definition, think MORE in the long-term than their larger counterparts. In a startup you are always progressing towards a long-term goal, constantly taking in feedback and making adjustments.

It's much like sailing to a small island thousands of miles away. A mistake in navigation in the beginning that goes uncaught will put you farther off course than one farther along on your journey (although sometimes that mistake means you discover North America and then pretend like you meant to do that all along).

The point being, if your startup is constantly in panic mode or is constantly trading long-term stability for short-term satisfaction then you should probably be thinking about leaving. At least from my point of view.


Did you ever work for a “non-startup”? Like, you are a car manufacturer, have to create some telemetrics software that has to work reliably in all kind of conditions, and hopefully not kill people, and has to be supported for the next 12 years minimum?

Compare to the startup that can just “pivot” at will and/or just end it with one of those “it was an amazing ride” blog posts.

Not trying to be smart, just presenting some perspective.


While that is absolutely true, I don't follow how that relates to my post? There is nothing inherent about the flexibility of a startup that means it has to be the frenetic roller-coaster that the thread starter referenced.


"You don't have architects who draw UMLs for you"

You better not, who cares about UML diagrams?

But startup code doesn't have to be messy. I don't write messier code (to be used in a company that pays me), just because I'm in a hurry, and neither should anyone.


This is the antithesis of lean.

If code is particularly messy, unplanned, and untested you might be feature searching as opposed to having a vitamin or medicine feature that a customer will pay for.

Release early, get feedback often. Choose a core competency.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: