Hacker News Reader

Comment by doki_pen | Hacker News Reader

How do mere mortals become wizards to their peers? They take the time to read documentation and code and really understand the tools that they are working on. What software projects have stood the test of time? The ones that were painstakingly thought out and progressed slowly. Of course there's a balance, and our current system of financing software projects rewards fast and loose, and there will always be a place for fast prototyping to help understand the problem, but to create something truly amazing takes a lot of time.

View on HN

"What software projects have stood the test of time? The ones that were painstakingly thought out and progressed slowly."

I kinda think that the opposite is true, or at least as true as your statement (meaning that at least as much half-baked stuff rushed out the door 'stood the test of time' as did stuff that took a lot of time to ship.) Unix, C, Windows, PHP, JavaScript...

To offer an example of a project that has stood the test of time far longer than the ones you mentioned, consider Fortran. The first compiler was released in 1957, several years after it was first proposed. The specification took a couple of years to complete. This was over 60 years ago, and even now they are releasing an update to Fortran (Fortran 2015).

Even in the examples you mentioned, Unix, C, and Javascript are all run through standards bodies now. It took years for C11 to be finalized. It's been years since ES6 has started development. PHP7 has taken a few years (and a version update before even being released).

Windows, depending on who you're talking to, can be a good example of half-baked, or an example of why half-baked is terrible, with regards to Windows 8 and Windows 10 releases.

This feels like a classic example of survivorship bias. Based on the nature of computing resources in the 1950's and academic culture in general, it's likely that all language/compiler projects of the era were planned deliberately and slowly. One of them survived.

So all projects that have "stood the test of time" for that length of time have that attribute. Also having that attribute are all the projects of that era that failed miserably.

May be you and your parent comment are both right? Release the first few versions very fast (even if it is not good) and if it is successful, then slow down, redesign etc? Examples include PHP and JS

You can totally screw the pooch with this approach and squander all your momentum, as well. See Perl 6, OpenGL Longs Peak

I think there's a big difference between working quickly and working rushing a project. Doing things thoroughly and correctly is of course well worth it; you can complete this work as efficiently as possible without cutting corners and building half-baked products.

In addition to that, I like to try to answer every question I can at work, even if I have to just go Google it myself. Telling someone you don't know and they should just Google it is robbing yourself of an opportunity to 1) learn it yourself, and 2) explain it to someone else (which is a GREAT way of making sure you really understand it).

Plus, people seem to like it when they ask something, and you help research through it with them. They come back to you again, which gives you another free opportunity to share someone else's learning, and you quickly turn into that person who either knows everything, or knows where to find out.

I agree with you completely here, but you definitely have to be careful, particularly as you become more knowledgeable. Some developers get into the habit of simply asking every time they can't find an answer, or giving up after only a few minutes trying, without realizing that the searching builds a better foundation than the answer many times.

My general rule has been - always ask what they've tried first. If it seems a sincere effort has been put into it so far, by all means help out. It may be something you know immediately, but there is value in teaching people to learn for themselves.

For sure. If I'm dealing with a junior engineer, I take a much more hands-off approach. It ends up taking longer, but that's ok, because usually, the net long-term benefit of that engineer getting practice at self-directed research is much higher than the output of the task itself.

On the other hand, if I'm dealing with a "senior" engineer who's doing that, I'm actually less worried about whether there's been sincere effort. It's just the other side of the same coin: They've offered their learning opportunity to me, and I'm happy to take advantage of it.

Conversely, there's an easy-to-fall-into bad habit of googling up an answer every time somebody on IRC asks a question, rather than waiting to see if somebody else is actually knowledgeable about the area, or doing the questioner the courtesy of assuming they're capable of googling for themselves...

"create something truly amazing takes a lot of time" Reminds of a front t-short slogan from Games People Play by Eric Berne.

Go slow so you can be fast :)

Reply on news.ycombinator.com