Ask HN: Your Favourite HN Comment?

My advice is to lower the value of ideas. A lot of time people think, "If only I had a good idea I would be successful". You will see other people saying things like, "Buy my good idea!". But really, good ideas are a dime a dozen. Good ideas, bad ideas... it actually doesn't make much difference. What makes the difference is execution and timing.

For things that take a long time, timing is essentially random. The world is chaotic. Had I known everyone and their dog would be locked down in their houses for months on end, I would have built something to cater to them. But of course, there is no way to know. I find it amusing that just before the pandemic there was a thread on HN talking about overvalued unicorns and Zoom was up near the top of the list. What would need to happen to make Zoom a household name, people asked?

To be successful, really what you need is execution and to have the patience to wait until what you are doing is relevant. Of course there is the fear that it will never be relevant. However, if you accept the thesis that the good idea is not valuable in itself, then you realise that it is not really valuable to pivot without a really good reason. A good idea that is never relevant is just as worthless as a bad idea that is never relevant. However, even a bad idea that is executed very well and ready when the opportunity arises can be successful.

Also I don't think most people can really tell when an idea is good. Seemingly good ideas fail all the time and if it was easy to determine which ideas are good everyone would be successful.

> Dependencies (coupling) is an important concern to address, but it's only 1 of 4 criteria that I consider and it's not the most important one. I try to optimize my code around reducing state, coupling, complexity and code, in that order. I'm willing to add increased coupling if it makes my code more stateless. I'm willing to make it more complex if it reduces coupling. And I'm willing to duplicate code if it makes the code less complex. Only if it doesn't increase state, coupling or complexity do I dedup code.

>The reason I put stateless code as the highest priority is it's the easiest to reason about. Stateless logic functions the same whether run normally, in parallel or distributed. It's the easiest to test, since it requires very little setup code. And it's the easiest to scale up, since you just run another copy of it. Once you introduce state, your life gets significantly harder.

> I think the reason that novice programmers optimize around code reduction is that it's the easiest of the 4 to spot. The other 3 are much more subtle and subjective and so will require greater experience to spot. But learning those priorities, in that order, has made me a significantly better developer.

https://news.ycombinator.com/favorites?id=jakelazaroff&comme...