Comment by pengaru | Hacker News Reader

Comment by pengaru | Hacker News Reader

Parent Full thread

Perseverance and conditioning yourself to be comfortable with (or even excited/inspired by) long periods of unfinished-ness are core competencies in practically every demanding project I've embarked upon - not just software, literally anything that can't be started and finished over a weekend.

A WIP is often largely indistinguishable from a complete and utter broken disaster. When the project necessarily takes a long time, that work-in-progress state can start convincing you (and your peers/family/friends/onlookers) that it's not a work-in-progress but a total failure. The only difference between those two realities is abandoning it vs. finishing it.

Some (most?) people lack the grit to get through that trough of "unfinished-or-failed?" ambiguity.

That's a lot of text trying to describe what I've found is the real substance behind "real developers ship".

And somewhere in all this, you still have to have maintain enough perspective to know when to cut your losses.

As a developer, and builder of things in general, I have hella respect for anyone who does such projects.

I've been working on my site: https://golfcourse.wiki for some time, and this is exactly how I feel all the time. Thank you for the encouragement.

I know this is a good idea. I know it will help people. I know I can either monetize it long term or even have it function as a non-profit. I also know it will take many years to slowly build to the functionality and content quality that I'm aiming for. Holding onto that long term view is extremely challenging.

Most days are just watching nothing happen, or slowly, slowly adding a single course (aggregated sites litter the golf internet, I want the opposite). One day I'll post on the golf subreddit and have 1000 users, get positive feedback, and the next two weeks just 5 users per day from google. And the kicker is, I'm genuinely embarrassed by some of the sub-optimal code and real lack of functionality I haven't addressed, even though I'm honestly very regularly working on it.

The best advice i got from a friend: only look at one-month or two-month increments as far as users. Day-to-day can get depressing, but on a bi-monthly basis, I've had slow-and-steady growth. At the same time, while I'm only up to 700 commits so far (vs 2000 in the article), I do have serious anxiety that I'm wasting years of my free time building something that won't amount to anything but a couple hundred upvotes on reddit, so I look at it as my unique hobby. I like mapping courses and making course books. It's my site and my hobby, and I'm fine if it's just me doing the work alone for the rest of my life. I believe that much in the project.

As a hobby I dabble in ceramics. I've recently been working on a large animal sculpture which has taken a few months of (weekly class) work.

It has probably a 50% chance of surviving a firing. Naturally the class instructor is concerned that "all this work will be for nothing".

But unlike him, I'm at peace. Creating the sculpture was its own reward. After the firing it maybe a big bag of bits, but that won't remove the pleasure of creating it.

In the same way I applaud your enjoyment of your hobby. Whether it is financially successful or not, your pleasure needs to be in the journey, not just the destination. If you keep it that way you'll have more fun than if you're only working for a future payday. And if you do monetize it, you may find it robs you of your joy.

If someone was going to pay me for my sculpture, I'd be a lot more worried around about now :)

Just wanted to say that I have only ever played golf once and have no real interest in it, but I still clicked on your site and went down a rabbit hole. This was fascinating: https://www.latimes.com/archives/la-xpm-2004-jun-11-me-peren...

Thanks :)

This is very relevant!

Personally the map with little icons always turns me off of sites. Maybe just a random course with quality photos where the map is, and some way to navigate to the next one? Maybe you don't fully aggregate the courses but you can scrape behind the scenes, automatically compile a bunch of content, and then edit it down. So you've proofread vetted all the content but doesn't have to be done manually.

>Personally the map with little icons always turns me off of sites.

I actually agree with you, but I really don’t know how else to get people to physically see courses they’ve never noticed before. Also I suck at Leaflet so it’s ugly.

>Maybe you don't fully aggregate the courses but you can scrape behind the scenes, automatically compile a bunch of content, and then edit it down.

I thought long and hard about this, but when I realized that the USGA, itself, has incorrect data more often than not, I realized that letting the people who love the course add the data is going to be better in the long run.

I'm surprised you think it's ugly, my immediate impression was the opposite.

I personally don't mind the icons on the map, they give a good overview and, above all, immediately explained to me what the website is about.

I've been making video games for a long time and while it's true they can feel unfinished for a long time, they shouldn't ever feel completely broken/disasterous/failed. One of the key things when making a video game is to make sure that it is fun and playable as early as possible into development, and when someone is grinding away working on something that isn't fun that's a pretty huge red flag to me.

"No prototypes. Just make the game. Polish as you go. Don't depend on polish happening later. Always maintain constantly shippable code." - John Romero

For one project, John Carmack hacked out a beta in two weeks in a cabin retreat and then spent ages polishing it up.

The first 90% of the effort is getting it working and then the next 90% is the polishing the result.

I think one of the biggest problems indie game devs have is putting a lot of focus into art and polish without actually working out whether the game is fun to play. The dev gets to make enjoyable incremental progress without having to confront the difficult questions about whether the game is actually workable. Some games can get by purely on story and art, but in the vast majority of cases I think solo devs would be best served by making an absolutely minimal gameplay prototype and making it fun before thinking at all about polish.

> Polish as you go

Best way to end up bikeshedding.

This is why it’s good to intentionally go between the micro and macro and define some design goals or pillars. The latter give you a razor by which to judge the game and the former stops you getting stuck in the weeds.

I broadly agree with the Romero quote, getting the game playable as quickly as possible and keeping it playable is easily the most effective way of crafting a game because it enables you to routinely playtest and understand your progress. A key element of that is making the game legible and for that you do need to spend some time on “polish” because it’s an intractable element of the whole.

> keeping it playable is easily the most effective way of crafting a game because it enables you to routinely playtest and understand your progress.

Obviously.

> A key element of that is making the game legible and for that you do need to spend some time on “polish” because it’s an intractable element of the whole.

What does "legible" mean? Polishing means making something production-ready. A polished feature contains (ideally) no known bugs, has been thoroughly tested, gone through several UX iterations and brought up to a release standard.

That's not necessary for playtesting and improving the game. Unless you're done with all core game mechanics, you shouldn't be polishing.

Legible means clear enough to be understandable and polish can be a clear part of that including selling the game feel. It’s a pretty classic move to under-appreciate how much feedback from a game players need to understand it.

Your definition of polish is much narrower than mine and I fundamentally disagree with you on the value of polishing during development through bitter experience.

sounds believable, i'm not sure its helpful.

i think that also sums up John Romero tbh...

The most difficult part about software engineering and IRL engineering is the feeling of “everything’s broken always” and just constantly needing to fix or tweak things. I understand that’s the job description basically but nice to hear it articulated by someone else

This is why TDD exist, it doesn't necessarily improve the product or delivery speed, but it keeps you sane while the project is half baked.

I've found incorporating tests on my personal projects allow me to pick it up after even a year or two, but if I don't have tests, they inevitably become so jumbled that they cannot be salvaged once the initial effort is over.

tests mostly work for technical code, it would be harder to pick up gameplay stuff.

Though that's why open betas exist I suppose, but for most studios that want to keep things under wraps, paying a lot of testers is extremely costly (and thus buggy releases).

> The most difficult part about software engineering and IRL engineering is the feeling of “everything’s broken always” and just constantly needing to fix or tweak things.

Who says that this feeling is not entirely correct and most of software development is insanely broken, i.e. software development as of today actually mostly means working around these insane problems such that not already a monkey that was conditioned using electrical shocks realizes how broken everything is.

Not sure I understand this comment very well but should have added it’s “the thing I personally find most difficult”. I was referring to “putting out fires” at work mostly, even with tests and other checks there are often regressions in a “large codebase” when working with a team of devs

Real developers ship = real writers write = real painters paint, etc.

If you want to create things — anything, you put your ass in that chair every day regardless of whether you feel you are accomplishing anything. Eventually, you will start to make progress towards your goal. It gets better as you become better at staying the course.

Highly recommend The War of Art by Steven Pressfield, which is a short, but important read on this very topic.

On the same topic, I would recommend Seth Godin - The Practice: Shipping Creative Work

These are very wise words that I needed to hear today; thank you.

You go to hell and back thinking you have a broken disaster and come out beautifully the other side.

Reply on news.ycombinator.com