Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The person who told me about this was the person who counted up the code at the end of the project. And, yes, it was 250 from each, not 500 from each parent company. (Memory is funny that way.)

I do not doubt that the numbers were rounded for simplicity. It is meaningless to talk about a 499x engineer.

As was explained to me, this engineer assigned two-week work units. If the work was not ready at the end of two weeks, he wrote it himself over the weekend. So, a fair bit of code was written that did not make it into the final product.



That's a ridiculously wasteful way of managing work. I too can be a 10000000x engineer if I never let others actually merge their code and just write it myself instead.


If you hired engineers like they hired them before coding interviews combined with a decade of the dead sea effect I can easily see a team of 500 barely getting anything done at all. Big organizations are often grossly mismanaged like this which is why smaller organizations can beat them.


mismanaged, yes. But also risk-adverse and encumbered with process. At a big corp you may need 5 or more sign offs on a single merge. I probably spend a good 40% of my time herding cats and babysitting the merge pipeline. There is a lot of overhead you simply won't find in a startup.


It was a way that delivered product on deadline, for exactly that project. Every project has specific needs. If you code to some other project's needs, you do the wrong thing.


> If the work was not ready at the end of two weeks, he wrote it himself over the weekend.

Using no code or knowledge from the past 2 weeks?


That would have taken longer.


Using it or not using it would have taken longer?


Trying to use somebody else's code that does not solve the problem generally takes longer than writing it yourself.


Solving a problem isn't all or nothing.


For it to matter, it is.


Nonsense. A house without electric outlets and switches isn't ready. It's much closer to ready than empty land.


But looking at someone elses code first generally makes you faster even if you end up not using any of it.




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

Search: