Hacker News Reader

Comment by dharmon | Hacker News Reader

I remember as a 14 year old reading André Lamothe's Windows Game Programming for Dummies. I think in one of the Appendices he has a tip, something like:

"Your first 10 games are going to suck, so get those out of the way as quickly as possible."

That advice has stuck with me through the years when learning new things. Don't freak out about perfection, just get something "finished". Repeat N times and watch yourself improve.

I guess this guy went for N=100. It would be cool to see an analysis, even by a friend, of his games to see at various points where he goes from derivative games to sparks of creativity to ruts and so on.

View on HN

It is very common to suggest to people new to the game of go to lose the first 100 games as quickly as possible [1]. Not "play", "lose". The fact is you will lose a vast majority of the first 100 games you play because the initial learning curve is so steep. It's hard to even imagine what moves might be reasonable when you start playing. So the idea is to not focus on trying to win or thinking through what your best moves might be, but to just get accustomed to some basic patterns, common positions, etc first. You have to build up a certain body of knowledge before you can really think about what moves you might want to play. So just play a lot of quick games and accept that you will lose and come out better on the other side.

[1] http://agfgo.org/pages/learn2.php

I am a perfectionist, and so far this has been holding me back massively. To the point where it's getting frustrating. I am trying to enter the Open Source world and that's only making it worse. Showing off things you aren't entirely proud of.

I never considered quantity a worthwhile alternative goal, but maybe I should reconsider that. Thank you.

The Engineering mindset is to make the best possible thing while minimizing cost, time, and complexity. I find that somewhat freeing as perfection off the table.

https://www.youtube.com/watch?v=4j4Q_YBRJEI

It works for a huge number of things two. Hmm I wonder if I can do this in 15 minutes, or I wonder how compact I can get this, or whatever as long as it's not abstract like make it pretty.

Another way to state the problem is "you have to do it badly before you do it well". Not strictly true in every case, but software is in a broken state for most of its development and then suddenly works at the end, which is really weird and off-putting to human intuition. When the code just barely works then it works forever(given the same environment and inputs), while with most other processes it would be a improvement in success percentages or yield rates or other measures.

It also leads to an issue with never really knowing what good code looks like, because we have to consider both the "it's still in development and therefore expected to be broken but easily debugged" state and the "it's in production and should be fast, reliable, practical" state. It can be great at one and not the other if the stakeholders aren't approaching it in a balanced way.

Sometimes it never gets to a "working" state and plods along in a "mostly not prone to errors."

This works for games but when you get to payment systems, autopilot cars, and operating systems... Well it's not a good enough way of thinking. You need tools to help you think at a certain level of difficulty. Even for programmers we shamelessly glorify that level isn't very high... Yet hubris sometimes pushes us to make silly claims.

I cannot disagree that "practice makes perfect." That applies at so many levels. One has to be comfortable with throwing things away and trying again. Practice dutifully and intentionally. Then realize what you don't know and where your limits are and have the humility and boldness to find ways to reach beyond them.

Don't know how you write code, but I typically fix all visible bugs before moving on.

If I want to complete a project, I make sure to scope a minimal set of features.

This is a good video. Helps you frame your goals and focus on your goals and stop thrashing.

https://vimeo.com/5895898

I found this excerpt useful: https://blog.codinghorror.com/quantity-always-trumps-quality...

Motivate your inner perfectionist by telling it that the perfect way of learning is trying a lot of different approaches and not one perfected approach. That way you can satisfy the meta-perfectionist while violating perfectionism on the day to day level (as long as you assume life is a learning process).

One way to beat perfectionism is to try to pursue it to absurdity. If you are a painter, try to make the perfect painting. But recognize that, in order to do this, you will have to mix the perfect paint first. So now put your focus on the mixing paint. Recognize that each of the constituent base colors have to be perfect. Focus now on one color. Et cetera.

Quickly, you notice that perfectionism really doesn't work. Everything is about making compromises. And the "perfect" painter is the one making the best compromises.

"How to make a pencil from scratch"

https://news.ycombinator.com/item?id=10631115

I recall a tale from a pottery teacher, half the classes work would be judged on quality, the other just the weight of the finished pieces, those who threw lots of pots aiming for weight consistently produced better quality by the end of the process, some things you can only learn by doing!

A lot of people say the same thing about drawing ("draw a lot of random sketches, don't obsess over single drawings for hours/days trying to get it right"). It's too bad that obsessing is just so much more pleasant than spewing out tons of ugly crap :)

I disagree, if you can become comfortable with imperfection in your work you'll derive more satisfaction from the process of creation -- or at least that has been my experience. It requires a concerted and conscious effort but pays dividends both in terms of quality of work (eventually) and peace of mind.

Walking the walk is easy. The hard part is abandoning a goal.

Reply on news.ycombinator.com