5 ms·

Perseverance and conditioning yourself to be comfortable with (or even excited/inspired by) long periods of unfinished-ness are core competencies in practically

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.

deleted 4y ago
[deleted]
fitnessrunner 4y ago
These are very wise words that I needed to hear today; thank you.
dieselgate 4y ago
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
- Aperocky 4y ago
  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.
  - Nemrod67 4y ago
    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).
- q-big 4y ago
  > 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.
  - dieselgate 4y ago
    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
scoofy 4y ago
I've been working on my site: https://golfcourse.wiki 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.
- bruce511 4y ago
  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 :)
- darepublic 4y ago
TylerGlaiel 4y ago
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.
- ivars 4y ago
  "No prototypes. Just make the game. Polish as you go. Don't depend on polish happening later. Always maintain constantly shippable code." - John Romero
  - c0mptonFP 4y ago
    > Polish as you go Best way to end up bikeshedding.
    - meheleventyone 4y ago
      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.
      - c0mptonFP 4y ago
        > 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.
djitz 4y ago
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.
- silok 4y ago
  On the same topic, I would recommend Seth Godin - The Practice: Shipping Creative Work
ssss11 4y ago
You go to hell and back thinking you have a broken disaster and come out beautifully the other side.

deleted 4y ago

[deleted]

fitnessrunner 4y ago

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

dieselgate 4y ago

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

Aperocky 4y ago
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.
- Nemrod67 4y ago
  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).
q-big 4y ago
> 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.
- dieselgate 4y ago
  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

scoofy 4y ago

I've been working on my site: https://golfcourse.wiki 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.

bruce511 4y ago
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 :)
darepublic 4y ago

TylerGlaiel 4y ago

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.

ivars 4y ago
"No prototypes. Just make the game. Polish as you go. Don't depend on polish happening later. Always maintain constantly shippable code." - John Romero
- c0mptonFP 4y ago
  > Polish as you go Best way to end up bikeshedding.
  - meheleventyone 4y ago
    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.
    - c0mptonFP 4y ago
      > 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.

djitz 4y ago

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.

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

ssss11 4y ago

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