Hacker News Reader

Comment by svdad | Hacker News Reader

As an old (37) guy with experience in a couple of start-ups, there's another benefit to having older, more experienced people on the team -- if you get the right people, they will have seen the problems and done the work before, and will save you a lot of big mistakes up front.

The start-up I currently work for was founded by a bunch of very smart, very young engineers over four years ago, and we're still dealing with all the bad engineering decisions they made -- decisions that look obvious to an experienced engineer but aren't obvious to someone without the requisite cuts and bruises. Having even one seasoned engineer on the team then would have saved the company a lot of pain over the subsequent years and would have put us in a much better position now.

View on HN

Those bad engineering decisions the founding engineers made may have been what allowed them to move fast enough to build a startup that's still in business 4+ years later.

If you know exactly what your customers want, you should take the time to build it correctly the first time. But if you're innovating and creating a new product, you'll need to perform a lot of experiments before you figure out what your customers really want.

Experiments shouldn't be engineered perfectly. It's better to have a creaky product that customers want than a bullet-proof system that nobody wants.

Not all engineering is over-engineering. You can use your years of past experience to build something both quickly and better. Should not the experiment part should be experimenting with the function of the application, rather than experimenting with how to design code or architect systems?

It's absolutely true that, sometimes, you need a quick and dirty solution to move quickly. For instance, on a project that I worked on when I was younger, I was running data through an O(n^6) algorithm when there was an O(n) algorithm available. However, getting something up and running at O(n^6) was far more valuable than waiting two weeks to work all the bugs out of the more complicated O(n).

On the other hand, that same project also had an object responsible for both displaying bitmaps on the screen and also for calculating statistical uncertainties. This unholy mash-up of two completely unrelated concepts was a constant impediment to development. If I'd had an experienced developer on the project, she'd have caught it in half a second. Splitting the class would have been trivial and wouldn't have delayed the project longer than a bathroom break. However, since the other developers were just as green as I was, the class stayed in and grew into a nightmare that prevented us from doing further experiments toward customer satisfaction. I think this is the kind of advantage that svdad was talking about.

Reply on news.ycombinator.com