This post really resonated with me, as I have between a dozen and a hundred abandoned projects, mostly games, since I started programming around 1989. Most of them written for the Mac Plus or Mac LC. And many of them following a similar mechanic or art style to the ones in the post.

I think of the few shipped projects I've released or been part of as a shadow of who I am. Same with my resume and work experience. They're a fingerprint of a whole being living a dream life that never manifested, because I never had an early win to build upon. That's why I think UBI might magnify human potential by 10 or 100 fold, to get us from the service economy to agency and self-actualization, producing our own residual incomes.

Oh and I played Pararena a ton!

Many companies I have worked for operate like this. Engineers get to work on shiny new features, they get released, everyone is happy. Months later tons of bugs accumulate. The original authors are already part of another team (because “breaking silos”, but actually because “make everyone replaceable”). The engineers that inherit the project need to maintain it and fix the bugs until another team takes over.

It’s awful.

I’ve been going back and working on retro development. These days, making software for the 68K Macintosh, which is where I learned to program in the first place. I dug a lot through old books, comp.sys.mac.programmer posts, and the source code from Soft Dorothy and others (like the GliderPro source).

It’s a trip seeing this old code through new eyes. I can see why the old Macs crashed so much (beyond the basic “they had no memory protection” explanation). I’m also fond of the 1-bit art, like the author mentions, and I curate a list of accounts on Twitter which post 1-but artwork (if you know anybody who’s missing from the list, let me know): https://twitter.com/i/lists/1578111923324944397

The nice thing about programming for a limited system is that it limits your options. It’s a nice break from the more modern experience where you can do anything by pulling in the right library. I sometimes imagine a world where computational power is frozen, and we simple get better and better software for systems that are well-understood. The thing about these old systems like the Mac 68K machines is that the pace of hardware development was so fast it made you dizzy. If a new processor came out like the 68020 or 80386, then you had maybe a couple years at most to make something that really used it to its full potential. If you waited too long, you’d be competing against a new generation of software written for a new generation of hardware.

That's a neat blog all around. Lots of interesting stuff to poke around in.

I think it's okay to abandon things, and you can certainly learn things and reuse parts from abandoned projects. For me, a breakthrough moment was when I decided to make things so small that I could finish them. It helped me develop the skill of finishing things, which is a separate skill that's hard to learn, because it only happens at the end of a process so long and hard you almost never make it there. All my friends who are making video games start by writing their own engine, and get burnt out somewhere around the point where they're making a level editor. They learn a lot about things like tooling (which, coincidentally, is a lot like what they already knew how to do), but never actually make the game. It'd be like learning stone masonry by building a cathedral—you won't live to see the end. Start so small that you can't fail, then work your way up to bigger and bigger projects.

John, your games were an inspiration to me when I was a kid first learning my way around programming on the Mac. I spent a lot of time playing Glider and even more playing Pararena. I still have the echo-y startup sample of that lodged in my head.

I probably spent even more time poking around in the resource forks of your games in ResEdit.

I didn't finish much, but I did complete a couple of little shareware games and uploaded them to AOL. I was beyond surprised when a check from far away California appeared in my mailbox many months later.

Those early Mac days really did feel like a special time where anything was possible a solo developer could make a thing and put it out into the world without needing more than creativity and time.

Thank you for writing these posts and sending me down memory lane. I hope you're enjoying your retirement.

If the goal of this article is to normalize abandoning your projects then I'm not so sure it's a good idea. All else aside it can be a horrendous waste of time and no amount of "at least I've learned something" can justify that. Learn by also finishing stuff, right?

Some of the pixel art in those screenshots is seriously awesome!

Personally I've learned (and earned) way more by shipping small things and THEN iterating on them. Or abandoning them.

I like this and find it interesting, but at an organizational level, it strikes me as trickier to do. A lot of the things we discover about projects and technologies have to do with its feasibility at whatever scale our real projects operate on, and don't necessarily pop-up in smaller experiments. (And sometimes they aren't really technical issues at all, but issues of "can we get most developers here to understand doing it this way.)

None of which means we shouldn't do more of this. You can learn things by trying smaller projects. It's just not a guarantee it will work in the large.

Mines just time. I get home from work, the last thing I want to do is sit in front of my computer.

With two days off a week to fulfil with chores, I still don't want to sit in front of a computer screen.

When I read articles like this, I feel nostalgia and envy. Why was I not born 10 years earlier? I see other people in my industry who are 10 years older than me and they not only had a way more fulfilling career, they are much better off financially too. It's like everything fell on their lap.

I love this but I approach it a bit differently. I don't think this is a good excuse to write bad or unmaintainable code. Sure some shortcuts are fine but it should be useful for the next person.

Personally I try to use free hosting services so that I don't have to pay to keep it running when I abandon it. (That could be AWS free tier or blockchain or IPFS etc). Use a public repository so someone else can find it when it's inevitable dropped. I always make sure to have good documentation so that once it's found anyone can get it running.

Some of the worst advice I read comes from some of the smartest people out there.

The car prototype reminded me of Spy Hunter graphics, but I couldn't remember that NES game's name at first. Sent me on a nice nostalgia dive!

Move Fast and Abandon Things: The Google Story

this seems like a fantastic way to look back on a career where the author started as a prolific solo developer and later became an effective, fast, and contributing part of an effective development team. it was also just really fun to read, about the code reuse, the scrapping of ideas, the rewrites, etc.

It’s interesting to consider how your guerrilla programming techniques could integrate with contemporary development tools and practices.

For instance, leveraging version control systems more extensively or utilizing collaborative platforms might enhance the efficiency and scalability of your projects.

Somewhat related, I think, I am always surprised at how often we don't have non-critical paths in jobs. Half the reason stress is so high, it seems, is we have backed ourselves into a situation where things have to succeed.

Engineer Sneed Art

Great to see this do numbers. I posted it last week but it didn't gain any traction

The new Google motto?

That's exactly the playbook how they destroyed Perl6 then. They had the very same outspoken motto "Move fast and destroy things". They indeed do so very successfully, instead of fixing just the few outstanding bugs.

Dad??

this is the way

Abandoning things is essential to development. If we didn't let things go, we'd be stuck with all of our weaker ideas. That doesn't mean they are bad or a waste of time, but rather you reach a point at which you realize there is something better you could be doing and move on. This can be painful but it's necessary.

I keep beating this drum but I believe there is a significant amount of pain in software because people shipped first drafts and got stuck with foundational design issues. Once this has gone on long enough, even a greenfield rewrite is hard because both the programmers and the users have internalized the flawed design.

I'm not sure I am all for abandoning all projects, but I do remember reading a comment on this very website that really resonated with me.

Someone was complaining about always starting projects, but never finishing said projects.

To paraphrase another user's response, it was something like, "Not all projects need to be finished in order for value to be gained. To borrow a concept from Buddhism, perhaps you found what you were looking for all along?"

The irony of the #3 thing on HN today being this, and the #5 thing being 'Finish Your Projects' haha. Good points all around.

[flagged]

[flagged]