18 ms·

Finish your projects

513 points by aarondf 3y ago

wiihack 3y ago
As I started my studies, I tried to develop a little Android game. It took way longer than expected, being also very frustrating from start to finish. I kept working on it for a couple of months, set up a Google Play account, created some images for the Play Store, and then released it. As expected, it didn't get much traction, but I felt very proud and happy about it. Would recommend! :)
sproketboy 3y ago
[dead]
mijustin 3y ago
I often say this to my teenagers: "You don't get any credit for the homework you thought about handing in. Even if it's not perfect, the only way to get a mark is if you hand it in." So true for work and side-projects as well. (I needed this reminder myself as I have a blog post I've been noodling on for 12+ months. I just need to publish the damned thing!)
- hacknewslogin 3y ago
  This reminds me of two quotes that really helped me with perfection anxiety: "If it's worth doing, it's worth doing badly." "Within acceptable tolerances."
  - whartung 3y ago
    The corollary of which is "It's not just good, it's good enough" (which I think is a Simpsons reference). I actually have a project on the shelf that's ][ far from being releasable. It's waiting on two things. One, is since it's a Java GUI, getting it built into a form for the MacOS/Window/Linux platforms, rather than just "here's a jar file". There's ways around this, but it's not quite drag and drop, and I haven't got a Windows box to test anything on, so its stalled. (I tried installing one of MS's VM images that they offered, but that's didn't work, so...back to the shelf). Two, is documentation. I could probably just let it go, and explain it to the 3 people who might actually download it and use because simply launching it, "Neat!", and letting it bit rot forever more. But, I think it needs some documentation, so...it sits. If I could satisfactorily drag and drop the installers, I'd probably press on with it, but it could still use some docs. Meanwhile, I continue on my meta project which this project would inevitably be folded into, so it's not all lost.
    - marcosdumay 3y ago
      Personally, I have lost count of the times I've got a jar from some place, and had to look at the source to discover how to use, and still used the software. It is really not a good experience, but totally beats not having the software.
- dotnet00 3y ago
  To latch onto that analogy, the point of homework is to make sure you learn the topic. So, if it weren't mandatory, handing it in isn't all that important as long as you're doing it. Indeed, in grad school, there was very little graded homework and most was just assigned with solutions given for anyone who wanted to do it. So, to bring the overly stretched analogy back to projects, I think you shouldn't feel like you need to "finish" something if it meets enough of the goals you set for yourself. Eg I spent months working on projects like custom OS's and game engines. But as the nature of those kinds of projects is to have endless room for growth, I just drew the line at some point that I had learned and done enough and could just drop them in whatever potentially buggy state they were in.
mjwhansen 3y ago
> Finishing requires courage Oh man, I feel this. I’ve been doing a lot of furniture refinishing lately as a hobby. One piece is 90% done and another is 80% done. I was working on the 90% done one today, and was planning to lacquer it today so I can put the hardware on tomorrow and be done… but instead I found a few places where I should really touch up the paint. That pushes back completing it at least one more day as the lacquer needs to sit for a day and… I just need to “ship” the darn thing. I realized it’ll probably never be 100% perfect, and that’s okay - done is better than perfect, as they say. Having the courage to create something that isn’t perfect is a skill.
mkoubaa 3y ago
Except software is never finished. If you publish something, there's a tacit expectation that you'll return to it, and it'll never be truly behind you. Rest assured, the only way that returning to a finished project takes more mental bandwidth than the guilt of never finishing it is if it's wildly successful. And that's a good problem to have
- aarondf 3y ago
  Totally! I referenced that near the end: > Sometimes finishing is just the beginning: You release the library, the package, the SaaS product, and your work is really just beginning. Users have issues, customers have feedback, and dependencies need upgrading. In some sense, there is no finished software; there is only released software.
phoe-krk 3y ago
The main problem with finishing projects is that the fun 90% of the project takes 90% of the time spent on it, and the un-fun 10% required to actually polish and release it takes at least the other 90% of the time spent on it. And then come the issues and PRs and people requesting your attention and time that they're entitled to because they found a project on GitHub that seems to fulfill 90% of their needs, and they only require you to implement or review the other 90%. Keeping stuff unfinished is actually not a bad idea.
- Hamuko 3y ago
  Eh. The vast majority of the time that you ship something, the end result is that literally nothing happens.
  - codazoda 3y ago
    I can relate to this. I actually finish a lot of stuff. I mean, it’s not all polished, it’s just simple, documented, and released. Then, crickets. I either suck at marketing my stuff or I’m scratching itches that only I care about. Examples: https://ponder.joeldare.com/ https://ponder.joeldare.com/ https://www.nolific.com/ https://www.nolific.com/ https://github.com/codazoda/https-basic-auth-go https://github.com/codazoda/https-basic-auth-go https://calories.joeldare.com/ https://calories.joeldare.com/ https://neat.joeldare.com https://neat.joeldare.com Okay, a few of them have some GitHub stars, and I slipped in my most popular project, but still. It’s not like my inbox is overflowing or anything. There are about a gazillion others too. ;)
    - blakewatson 3y ago
      I think Ponder is cool! I made something similar for myself, but never got around to supporting more than one text. https://blakewatson.com/scratchpad/ https://blakewatson.com/scratchpad/
    - bbkane 3y ago
      Oh, you're the Neat CSS guy! One of these days I plan to use that for my blog- thank you for making it!
SCUSKU 3y ago
I always remind myself that "Done Is Better Than Perfect" whenever I think I should add some new feature to a project rather than ship it. I think the scariest thing is accepting that if you ship something people probably won't care. It's easier to continue working and not ship it under the assumption that just adding that one more thing will then make everyone love it. I don't know how it happened, but at some point I stopped caring about outcomes and have accepted that most ideas I have are stupid, most projects bad, but the only way to find good ones is to just put it out in the world. Worst case scenario everyone ignores it.
- damethos 3y ago
  "Perfect is the enemy of good" is another similar one you might like ;)
mrcwinn 3y ago
In the middle of this as we speak, so thanks for the post. I'm absolutely in that rough 10% phase. XD
- aarondf 3y ago
  Rooting for you. You can do it.
interroboink 3y ago
In general, I like the empathetic tone of the article, and I appreciate that it addresses an emotional facet of software development. But nevertheless it triggers some little part of me w/regard to telling people what they should or should not do, or what they may be proud of. I worry for someone who reads "You also have a duty to your future self to release the project" and "...you tell yourself that you are the kind of person who ships" and takes that to mean "if you don't release it, you're failing yourself" and "you're the wrong kind of person if you don't ship." On an emotional level, I think it's better to start from a place of (unconditional!) self-love, and go from there, rather than beating yourself up because you're not meeting some blogger's expectations of how you should act. And just to be clear: I don't think the author means it that way, but that's one way it can come across, to some people, in some states-of-mind. I've generally found it more useful to phrase things like this in terms of "I" rather than "you". As in: "I had X experience when I did Y" rather than "you should do Y, so that you will feel X." It's a common mis-step in giving well-meaning advice, I find. EDIT: Also, I'm sure there are plenty of people who really do benefit from advice being given in this more pointed way, and I realize it's a bit onerous to always write and phrase things for a "safest common denominator," but I think it's worth keeping in mind, at least.
- aarondf 3y ago
  Nuanced and valuable feedback, that I receive. Thank you! I think your edit was basically going to be my reply, haha. It is hard to address every side of every potential topic in an article. I actually needed help softening the tone to end up with the final version you're reading today. I'm empathetic by nature so it's easy for me to write with empathy, but I'm still prone to generalizing my personal experiences!
  - BeetleB 3y ago
    > You have a duty to your past self to release the project. It’s a way to honor your work and sacrifice. All the time spent on the project is time you could have spent on something else. That time was not without cost. Ouch! I strongly encourage you to read up and understand the sunk cost fallacy. In general, do not let past efforts be the guide for future decisions. I've quit a lot of projects in my life. And it was the right thing to do. Put another way, many of the valuable projects I've completed would not have been accomplished had I stuck to the projects I had sunk time into. > You also have a duty to your future self to release the project. Every time you don't release a project, you're telling yourself that you’re the kind of person who doesn't ship. If you tell yourself that every time you don't release a project, the fix is not to release the project, but to stop telling yourself these lies. Despite the strong complaints, the article isn't that bad and does have some merits.
bartq 3y ago
I think this is important: finish your project in bigger context where your project is a piece needed in higher level picture. Don't finish project just to finish it. This attitude solves problem of motivation, because you naturally finish the project without forcing yourself. Masons don't lay bricks to have bricks laid down, they want to build a house. Of course it much more complex than that, some people are just not types of makers and "finishing projects" is not their cup of tea.
Lammy 3y ago
> Sometimes finishing is just the beginning: You release the library, the package, the SaaS product, and your work is really just beginning. Users have issues, customers have feedback, and dependencies need upgrading. In some sense, there is no finished software; there is only released software. Translation: "Please get locked in to using GitHub"
- aarondf 3y ago
  Ha. I don't work for GitHub tho! I'm just a guy writing about my feelings
  - Lammy 3y ago
    I didn't claim you did. Why would GitHub (read: Microsoft) "amplify your voice" in a way that doesn't benefit them? They want people locked into GH via their non-Git offerings.
  - pvaldes 3y ago
    > Ha. I don't work for GitHub tho! I'm just a guy writing about my feelings And this is exactly the problem. GitHub uses you as a free writer to promote its making money goals, instead to pay somebody. You are just another case of "working for the exposure". You in fact were working for Github, you just not realized it, and weren't paid. Open source in late 90's was not about making a personal brand -> to make merits -> so the companies will hire you -> so you don't need to do open source anymore. Some people maybe, but the majority were driven by personal hobbies and "I'll fix it because I can, in a context of mutual benefit, and feels good helping somebody like me somewhere". Now the mutual benefit in both parts feel much more unbalanced.
deleted 3y ago
[deleted]
ge96 3y ago
lol (monkey eyes, looks away)
stuckkeys 3y ago
I also listen to the same song on repeat. How do you think Despacito got all those views.
- aarondf 3y ago
  The thought of listening to Despacito for a week straight is making me sweat
rozenmd 3y ago
My "hack" is to release work early (while you're still embarrassed by it), and iterate ruthlessly: https://onlineornot.com/unreasonable-effectiveness-shipping-daily https://onlineornot.com/unreasonable-effectiveness-shipping-....
- forgotmypw17 3y ago
  I try to make at least one commit a day. Some days I fail, but often I have weeks-long streaks.
- aarondf 3y ago
  Love this framing! Good article. Followed you on Twitter!
agumonkey 3y ago
I heard that Shannon was a mess hyper multitasker. He just went wherever his mind wanted to, and moved accordingly. Made me try to accept my scrapyard of project shelf and just keep iterating hard.
ezekg 3y ago
Totally agree. And even after the big finish^Wlaunch, too many people give up on good projects because they don't know how to get traction yet. The truth is that sometimes that's your fault, not the project's fault. New founders especially quit good ideas way too often, way too early because they've been conditioned to want to drop things if they fail to reach hockey-stick growth within a certain time threshold. It takes time. All of it. I briefly wrote about this awhile back as well: https://keygen.sh/blog/5-things-ive-learned-in-5-years/ https://keygen.sh/blog/5-things-ive-learned-in-5-years/
jhp123 3y ago
To take the contrary position: give up. Your project will take far longer than you think, and you will get much less from it than you hope (at least in terms of external validation and rewards). You may feel a horrible pressure to finish it, but you are a free person and can simply choose not to. You can free yourself from this pain without lifting a finger. Go take a walk or bake some cookies instead. If you have the intrinsic motivation to continue with your project, then your interest will return at some point and you'll get back to it with the wind at your back. If you don't have that intrinsic motivation any more then you will only make yourself miserable by trying to whip yourself forward.
- aarondf 3y ago
  I've lashed myself to the mast (so to speak) and forced myself to finish projects that I would've otherwise walked away from, and I'm so so glad I did. > You can free yourself from this pain without lifting a finger. Sometimes the cost of doing things is pain. I was going to say the cost of doing _great_ things is pain, but honestly, the cost of doing anything is usually some level of pain.
  - bob1029 3y ago
    It isn't always the case, but I have found that pain is the #1 litmus test for "is what you are doing valuable". Some times this turns out to be a "you worked hard instead of smart" problem, but game theory wise one can assume that painful things are generally avoided or not fully explored. There is a really good reason you are spammed to death with GPT chat bot clones, but have to go around like a beggar to find things that actually matter.
  - waboremo 3y ago
    What happened as a result of finishing those projects?
    - aarondf 3y ago
      One thing: internal satisfaction. External success, too! The biggest one recently was releasing a course on MySQL at https://planetscale.com/mysql-for-developers https://planetscale.com/mysql-for-developers. It was painful to push that over the finish line, but giving up on it would have been a huge disservice.
cmrdporcupine 3y ago
Unfortunately I don't get paid to finish personal projects on GitHub, and I need to get paid to feed my family. (And I don't have other devs, product managers, QA, etc. to help, either, like I do at work). And judging from the nature of the vast majority of stuff on GitHub, most people are in the same boat. Someday I'll retire and then I can get some real work done.
doctor_eval 3y ago
I have two projects on the shelf right now. I’ve been dragged away (read: need money) to work on non-code projects. To the point where I don’t feel confident about opening my IDE! So, this article is really timely. Thanks.
- aarondf 3y ago
  Go get em. Thanks for the kind words
carb 3y ago
I love this article and the premise. Further similar reading/watching in some of my favorite Zack Freedman videos! - "Here's What's Preventing You From Finishing Projects": https://www.youtube.com/watch?v=L1j93RnIxEo https://www.youtube.com/watch?v=L1j93RnIxEo - "How to Finish Your Weekend Projects in One Weekend": https://www.youtube.com/watch?v=72a85tWOJVY https://www.youtube.com/watch?v=72a85tWOJVY "Finishing" more projects (even if that means changing the scope and announcing it "finished") has been amazing for my internal willingness to start new projects or tell friends about them. I have much less anxiety that I'll leave another half-finished project sitting around with lost motivation.
- bgoldste 3y ago
  Thanks for sharing these. Though I mostly do software I found his take very helpful. Also nice to be reminded how fungible things are when no actual wires get involved.
enos_feedler 3y ago
Is it bad I can’t even finish reading the article?
Ilasky 3y ago
I really like the analogies of SLC (simple, lovable, and complete)[0] and “I’m the only user”[1] to motivate how I finish my projects. Often times I have a project I’m working on and my imaginary perception of what a user needs is steering the development. Whereas, in reality, I just need the thing to work for myself and I can pretty it up how I like. [0] https://herman.bearblog.dev/mvp-vs-slc/ https://herman.bearblog.dev/mvp-vs-slc/ [1] https://blubsblog.bearblog.dev/i-am-the-only-user/ https://blubsblog.bearblog.dev/i-am-the-only-user/
turnsout 3y ago
Counterpoint: do what actually matters to you. You may constantly start projects and never finish them, but that may actually be serving your need for experimentation and learning. For someone else, that same behavior might be unhealthy avoidance. If "finishing" a project (software is never done) is something that matters to you, find ways to work towards that goal. I've shipped plenty of things, but also walked away from 10X more projects that were "90%" done, because I got what I needed out of them.
- xwowsersx 3y ago
  I agree with your idea, but I don't see at as a counterpoint. I don't read this post as making an axiological statement about the would-be reader's work (I may have read it wrong though!). To me, the article assumes that "finishing" the thing is something the reader already values, or at least does in many cases. And the author is offering some advice for how to stick to it and power through even when there are painful stages along the route to what the reader already wants. I see this as trivially or obviously true too, namely the idea that not every moment or every ounce of work on the way to something you yourself really deeply desire will feel like elation and fun.
  - aarondf 3y ago
    Author here: you are reading it as I intended! Not "you have to finish everything" but rather "you want to finish something but it's hard, now what"
    - xwowsersx 3y ago
      Glad I read it as intended. I enjoyed your writing!
bodge5000 3y ago
I used to have this problem and then maybe ~8 years ago, I solved it, and word of warning, it can go the opposite way. When I finished my last project I started work on a new one, which I predicted would only take a few months. Common mistake I know, but even looking back, technically speaking I wasn't wrong by much. It is a simple project on a technical level, but not so much on a design level (by that I mean game design, its a game I was working on). 3 years later, I realised it was a fundamentally flawed idea. 6 years later, now, I'm still working on it, despite knowing that. Very recently, for the first time in that 6 years, I've been successful at pulling myself away onto other projects, but that main one still sits there and I will get back to it, whether I want to or not. All thats not to say that finishing things isn't important, just that it can go both ways. Sadly I don't have any advice to stop others from falling into the same trap as I did other than maybe being aware of that. EDIT: To be clear, this isn't a "just ship it" situation. I don't have anything to ship other than mismatched ill-formed prototypes, and I do mean prototypes. Maybe one day I'll just polish up one of those prototypes and ship it, that's been my thought process lately
pengaru 3y ago
Commercial software vendors don't even finish their products before shipping what's often aspirational vaporware in the form of a skinned update mechanism. Don't get me wrong; I'm totally in favor of finishing things in the sense of doing the un-fun work of finishing instead of distracting yourself with a fresh set of problems every time you reach the un-fun finishing phase of resolving existing messes. But it's worth noting that what qualifies as "finished" seems vastly different from what it was back in the days of shipping software on CDs and floppy disks. You don't even get a finished automobile anymore in some cases, and we're not talking kit car prices. Tesla, I'm looking at you.
- paxys 3y ago
  Commercial software vendors may not finish their products (what even is "finished" when it comes to software?) but they do ship them. How many unfinished hobby projects meet the same fate?
c7DJTLrn 3y ago
I tried forcing myself to finish a personal project before moving on to the next one. I've just ended up procrastinating and getting nothing done for the past 6 months. In turn, that has created a cycle of guilt and anxiety making me not want to touch any of my projects at all.
sheepishly 3y ago
[flagged]
seabass-labrax 3y ago
I tend to have the opposite experience from the author's: I know enough about the domain to know that choices I make at the beginning could cause massive problems later on (in performance-critical software, for instance), yet not enough to know exactly where the traps are. Once the project is underway and empirical data can be collected, it's much easier to direct attention to known issues and opportunities. By nature I enjoy the 'boring' stuff, to use the author's term, and often find a clean code-to-package CI pipeline and an up-to-date wiki more satisfying than the software itself! I wonder what the ratio of 'non-finishers' to 'non-starters' is. I suspect I'm in the minority, but maybe someone here knows of a reliable study of this.
doingmaths 3y ago
I'm definitely guilty of not finishing projects, but I don't know that the "Just do the thing and don't NOT do the thing" is a particularly useful piece of advice. I know I should "fight for the time on the project" but willpower to do so isn't always something that's available. And that's not a personal failing -- I might decide that tonight I want to work on my game, but then have a long day at work that leaves me emotionally and physically exhausted. It's important not to burn out on your projects too, and forcing labor on them when you do not have the spare capacity can lead to long term failure to complete the projects as well. I think the much more valuable lens is to consider -- "Why do I work on this project? Is the joy of finishing it important to me?" If you want to finish it, and cannot, then start looking into pushing yourself to finish. If the joy is in just tinkering because tinkering is fun, then allow yourself that pleasure and don't beat yourself up for finding something you enjoy and partaking in it.
doingmaths 3y ago
I'm an anarchist --- wait hold on! --- not like "The Purge" kind, but the "mutual aid and share what you can" kind. I genuinely believe that if we operated more on a "people will produce the tools, food, and art they want to produce, and will improve their working conditions if given the opportunity" mindset, and less on a "hit this deadline so your boss makes a buck" mindset we'd be able to finish more of our 'side projects'. I think we all naturally have these projects in mind, things we would pursue if we had the time. And I think we could move towards a world where we optimize a little less for maximizing profit, and a little more for maximizing our leisure time. It will take some structural reforms, some trust, and a whole lot of learning by doing, but I'd much rather live in a world when I had less stuff but more freedom to pursue things I enjoyed.
- eternityforest 3y ago
  I'm all for mutual aid and sharing, and I am definitely not an endless growth capitalist, I want people to have time and resources to make art and tend their gardens. But I sure couldn't produce the tools I want without making use of the work of profit driven people, simply because advanced tech is a lot of work, takes hundreds of people, is too big for anyone to understand and thus is almost never made if idea-exploring is the main motive, and generally seems pretty tied to profit. Lots of places in Europe seem to have mostly figured the balance out. I don't think I'd prefer to live in a world without Intel and Microsoft, maybe I'd have free time, but I'm not sure it would be leisure time, I might be hand-washing laundry instead. We definitely need changes, and there are some amazing side projects out there.... but also, I want to eradicate the last few guinea worms, have every roof covered in solar panels that can last 70 years, and have my Google Keep notes keep working or be replaced with an even more advanced and feature rich version. To do that, I think we would either need to start doing really big polished side projects, or we'd need to manage and reform, but not eliminate the deadlines and meetings kind of stuff. I'm not sure we know how to run a chip fab with any other social structure. Maybe a co-op with elected leaders, or unionization, or better inspectors to be sure there's no child labor sourced parts... but we would have a lot of learning to do to make Intel open source, half the people would just say "We should ditch out of order execution, it's a security risk" and the other half would say "This defect tolerance routing that improves yield 20% is really complicated, stuff is getting too hard to understand, we can toss a few wafers if it means the tech stays human-level, and in 5 years we can probably just get rid of the defects".....
eclectic29 3y ago
Personally for me the biggest hurdle is starting a project, not finishing it.
deleted 3y ago
[deleted]
satisfice 3y ago
I have no duty to be a slave to my past self. I proudly liberate myself from finishing anything.
shit_game 3y ago
As "inspirational" as this comes across, I can't help but feel a bit cynical in that this is _Github_ publishing this. You know, the company that famously built an AI product using the projects hosted on Github... Personal development and growth and feel-good-iness aside, there is a tremendous conflict of interest present when Github is encouraging its userbase to create working software projects when those software projects constitute a treasure trove of machine learning data that can be monetized (and even more effectively so if they work/are completed).
- slicktux 3y ago
  I agree, very much so, with your reasoning; so much so that I never trusted my code in any online code hosting platform…but never did I imagine it would be used for machine learning!
- jahewson 3y ago
  Is this not an alignment of interests?
  - shit_game 3y ago
    I suppose that depends on ones opinion regarding the Copilot situation.
- aarondf 3y ago
  GitHub did publish it, but they didn't write it! I (the author) don't work at GitHub, and they don't tell me what to write. The brief they give me is basically "write something a developer would like" and off I go. Not sure if that changes your mind, but at least now you know how it worked behind the scenes!
  - shit_game 3y ago
    I'd say it does influence my opinion to be more positive knowing that you're not necessarily in the palm of Githubs hands, though my underlying cynicism still remains - I think part of that is that I've grown significantly more cynical of written pieces over the years having watched online content succumb more and more fervently to the game of monetization and opinion influence. Additionally, I think this article strikes a bit at my person as I struggle immensely with finishing anything I start, to the point where I've began projects (plural!) meant to act as tooling to create project boilerplates, and I still haven't finished even those. Regardless, I do feel the message shared is a positive one that does come from a place of benevolence. Tangentially, I'm curious if you could speak to what it's like creating content as a third party author? Are you given prompts regarding the tone or content of your work? Have you ever had work you've produced be rejected by a publisher? I'm not at all familiar with this aspect of online content (despite being stuck to a screen reading it all day), so I'd appreciate some insight on the matter if you're willing and able to share any.
blueblimp 3y ago
This brought to mind another blog post I liked on the topic of finishing, by Derek Yu (of Spelunky fame): https://makegames.tumblr.com/post/1136623767/finishing-a-game https://makegames.tumblr.com/post/1136623767/finishing-a-gam....
codersfocus 3y ago
I read a very boring but useful paper on curiosity by Lowenstein. He frames curiosity as a drive (similar to eg hunger.) If you’re starting but not finishing projects, maybe it’s due to curiosity about a sub problem that you hack a solution for. But once your curiosity is satisfied and you have no other drive eg money, stars on Github, you finish without releasing it
- shepherdjerred 3y ago
  That's an interesting take, and certainly one I empathize with. Did Lowenstein argue that not finishing projects is a negative trait as it's often portrayed as?
- v7n 3y ago
  In my native Finnish tongue we do use, interchangably, expressions "tiedonjano" and "tiedonnälkä" which directly translate to thirst/hunger for knowledge. Even "tiedonmuru" is a crumb of knowledge or data, as in bread crumb.
kazinator 3y ago
I don't agree with the part about starting a new project with no legacy code being easy; starting a new project with no old code at all can be paralyzing. The best is a project that is never finished, with great legacy code that makes it easy to do new things all the time, such that you're relieved you have it there. :)
steve76 3y ago
[dead]
MichaelMoser123 3y ago
what happened? Is GitHub concerned about the quality of the training data that is fed to GitHub copilot?
- aarondf 3y ago
  If they are they didn't tell me. I explained this more fully in a few other threads!
temporallobe 3y ago
I’d love to. I actually have 2 games I started and never finished, mostly because I developed the primary gameplay mechanics and design, but I’m too lazy to make them into a finished product. The chasm between developing a POC and finishing things is surprisingly wide. It’s the same for the literally hundreds of songs I’ve written and recorded over the past 20ish years - I’ll record a demo or a 90% finished mix, but again, the level of effort between that 90% finished mix and a fully polished and mastered release-ready song is far more than it took for the 90% version.
jftuga 3y ago
I feel like I finish most of my projects. Granted, most of them are small, command-line tools. When they're done they're done. What are your thoughts I projects that haven't had any updates in a few years? https://github.com/jftuga?tab=repositories&q=&type=source&language=&sort=stargazers https://github.com/jftuga?tab=repositories&q=&type=source&la...
nixpulvis 3y ago
Define “finished”. Oh cool (read FUUUUUCK), I forgot I don’t know how to disable smart quotes on iOS.
- aarondf 3y ago
  That's the neat part, you get to define it for yourself.
langsoul-com 3y ago
Should be finish your project* Sometimes there's just more interesting stuff to do, or the easy project turned out to be a near impossible slog. Letting go and moving on is a valuable decision instead of digging a deeper hole. That is sunk cost fallacy. Ie, I tried making a instagram + discord fusion. Instagram image feeds, but to a server of people instead. Turns out it's a ton of work and is worthless unless others adopt it. So it got scrapped after month+ of work.
_proofs 3y ago
"the things that you love should be the things that you do, and the things that you do should be the things that you love." -r. b.
ramity 3y ago
I don't really subscribe to the idea of "finishing" or "completing" a project; I'm sure my personal github can attest to that. I think "real" software is never done. The only things in software that are completed are the fractions of software we abstractly define (tasks, features, sprints, deliverables, etc). Much like us, real software lives until it doesn't. It changes through time sometimes regressing and expanding. Software whose goalposts remain static becomes deadware. Outside of commercial projects, I program for the joy of creation and commonly, and paradoxically, automating for the sake of "not automating." I jump from project to project, sure, but I've found the largest source of not wanting to go back to a project is the difficulty of doing so. Having to pick things back up to juggle and going through the motions of learning what my software did and what needs to be done was always a pain. My real breakthrough was "optimizing being able to leave." Comments like I'd be picking up the software months/years later, READMEs detailing build steps and rationale and planned features, automating dev environment setups with docker, break features/work into pieces so it isn't overwhelming, etc. These are just some of the many ways to make it easier. Sometimes you don't want to go back because all you can think of is the known (or unknown) work that lies ahead of you. The fewer the reasons to not go back, the easier it is, and if it's easy to pick back up, you'll find yourself picking things back up when the time is right. Sometimes inspiration hits while working on other stuff, and I say that's fine. Embrace that. Commercial software is a bit more narrow in the selection of how one can start and stop on work (I call this "task shopping"), but being in tune with yourself and vocalizing that during standups/meetings/whatever can help. Can't seem to finish a task? Maybe the task was too big to begin with, scope/feature creep set in, or whatever. Create tasks for what you've gotten done and what needs to be done. Lay out some groundwork to explain how someone might pick up the new tasks. Do that and you'll find yourself "optimizing being able to leave." "You must become comfortable with the grind-it-out nature of the last 10% of a project." I really don't align with this statement. Software can and should be a joy to do. Sure, there are aspects that can make it feel like a grind, but this is a question of framing. After all software development is technically data entry (don't think about this too much).
moomoo11 3y ago
Really nice read! I too play the same songs on repeat. I love death metal so I just listen the songs that make me want to wage intergalactic war on other planetary systems and play them on repeat lol. Once I’m in the zone there’s no coming back unless it’s with the spoils of victory!
rocho 3y ago
I found this paragraph so relatable: > Personally, I like to put a single song on repeat for hours and hours, days even. It helps me zone in. Why does this admittedly strange behavior help me? I'm not sure exactly, but I've known it to be helpful for more than half my life. I like to get up early before the family is awake, close Slack, put my phone in Do Not Disturb mode, and work. I even put a Post-it note on my monitor with the task I'm focusing on to help keep me on track. Sometimes I can accomplish more in that quiet hour and a half than I can in the rest of the day. Except for the post-it note, I do those exact things. These seem to be the essential pre-requisites to being very productive (for me): 1. Set aside some time to work on something specific (with clear goals and intentions). 2. Block all interruptions (messages and calls of any kind and other distractions). 3. Focus and get in the zone. I find that music helps a lot here, and generally for me it's electric music or songs with very subtle lyrics (almost dream-like). If the lyrics are too noticeable, they become a distraction. The above works both for my personal projects and work. I work remotely and sometimes there are so many interruptions during the work day that I simply abandon everything and go do something else (a walk, groceries, work out, etc.). Then I catch up in the evening or during the weekend, when interruptions are at a minimum or completely absent for hours on end. Almost always I'm more productive in a couple hours like this than for entire days. Finally, while I liked the article a lot, I disagree with the premise that projects _must_ be finished. It's fine not to finish a project, it's not failure at all. On the other hand, yes, there is a certain feeling of accomplishment that comes with reaching a level of "completeness" of a project.
- mach1ne 3y ago
  Interesting that music works for you. I’ve noticed that besides just white noise, music significantly degrades my work results. I might produce similar amounts of content line-wise, but the solutions are of much lower quality when I listen to music. As a result, I only listen when work feels too painful and I’m okay with decreasing my output.
  - rmuratov 3y ago
    For me it is listening music without any words. I have one special track that enables "productivity mode" for me. If there any lyrics I can't concentrate and listen to words instead,
deleted 3y ago
[deleted]
uoaei 3y ago
This reads like a thinly veiled plea to improve Copilot's training data.
kissgyorgy 3y ago
No thank you. The whole point of my project is that I don't have to finish it!
rconti 3y ago
Funny, I have the exact opposite reaction. Solving for edge cases, for optimization, for bugs, is all so much easier. The "infinite possibilities" means infinite wrong decisions. Infinite ways that the decision you just made will prove to be a colossal fuckup in 2 months' time.
Joel_Mckay 3y ago
Rule #1: Quickly identify a failure to resolve critical paths to completion. Some projects are simply doomed without the right people, resources, and market conditions. See "Law of holes" corollary: "Nor would a wise man, seeing that he was in a hole, go to work and blindly dig it deeper..." ( The Washington Post dated 25 October 1911 )
kaba0 3y ago
What helped me finish some of my projects was also choosing a realistically achievable goal. I have made the mistake of being overly ambitious many times, like how cool would it be to rewrite this and that as well from scratch, my version will be so much better, etc.. But it is sometimes simply not feasible, and we would be much better off with a less ambitious solution to the problem we have. Last time I successfully applied this was a personal finance tracker, where instead of going at it reinventing the wheel I built my smaller project on top of the Plain Text Accounting ecosystem (beancount specifically).
joeig 3y ago
Regarding > Decide upfront what you're going to work on. and > Behind the fear of releasing is often the fear of exposing your work, and yourself, to criticism. When I plan to release my project's source code, it has helped me to release parts of the project up front as single-purpose libraries. This helps me think in smaller chunks of work, and makes me feel like I'm finishing more often. It also shortens the feedback cycle.
rpastuszak 3y ago
For those looking for more practical advice on the subject: https://sonnet.io/posts/sit/ https://sonnet.io/posts/sit/ > Finishing requires work > Finishing requires courage and > "Just Work" Hard to disagree with that, IMHO Sitzfleisch is akin to exposure therapy. But, in practice both items require having a deeper understanding of where the difficulty comes from. Instead of brute-forcing the problem (and sometimes setting up yourself for failure), it might better to develop tools that work you as an individual. For instance, sometimes for me procrastination or avoidance can be a signal that I haven't been taking care of myself outside of work OR that deep down I just don't give shit about the project, but can't admit that to myself so just end up more frustrated. In this case leaving the house for 15 minutes or petting my dog works better than Sitzfleisch (cliche I know). Again, that's not always the case, but I think spotting those signals and making the appropriate choices is a muscle we develop through practice. More on the subject in the article above and here: https://sonnet.io/posts/hummingbirds/ https://sonnet.io/posts/hummingbirds/
ly3xqhl8g9 3y ago
One way to make sure (some) projects get finished is to not use semantic versioning, 1.0.0, 27.8.3, and so on, since integers can be incremented longer than the average lifespan, and instead use something like alpha-versioning which starts at 0.0.0-0 and ends at 1.0.0-0, that is, reaching 1.0 is actually the death of the project, its tombstone saying non perfectus sed perfectibilis non amplius (Latin for gravitas: not perfect, but perfectible no more). At the other end, having goals which extend well beyond the average lifespan is what could be considered as the root of wisdom.
marc 3y ago
I still struggle with this, but I’ve become better at it. What I learned is that “the last 10%” really is about half of the work. The solution is to reduce the scope. A lot. Not only will it make it easier to finish the project. It also allows you to get real-world feedback a lot earlier. Which is both rewarding and informing. Two things that will help you push your project forward if you choose to do so.
drawkbox 3y ago
Finishing is hard so it needs to be the strongest point of the project. When you got started you were in the open mode, playing, prototyping, dreaming and iterating. When you finish you have to move to the closed mode and have an internal editor that says "ship" and "cut that" or "move to an update" and that is a difficult ride. Sometimes people don't finish simply because it is too painful for a labor of love to be trimmed, but it is the skill you need to ship. It sucks but is. What you have to do there is revisit the love/play that initially got you to the idea and project. See your project in the world/market and feel the original feelings of when you started it. Don't focus on what you had to cut or didn't meet your expectations, focus on what did and head to post-production and ship. Ultimately we are only what we ship to the world, no matter how much you have in development or your adventures. If it isn't where you want to be improve it, but also learn to love each ship as that is a major step. It is a joy when what you envisioned comes out as you wanted or better, when it isn't, make changes and updates. Both "work with a high degree of quality" and "finish strong" are good areas to strive for, but "finish strong" is where it is at.
outsomnia 3y ago
"Finish your projects", finger wags cheerful guy full of certainties, paid by large American corporation that makes money from your finished projects and doesn't care what happens to you before, during or afterwards.
- q1w2 3y ago
  This is a Reddit-level comment. Cynical and teenage-anger-esuque
  - outsomnia 3y ago
    Good job you're there to lift the tone!
- vaylian 3y ago
  It makes sense to add this context. But I still think the advice and explanations in the blog post are more generally applicable than just to GitHub projects.
- aarondf 3y ago
  I do work for an American corporation, but we're not large! Less than 100 people I think. I do care about what happens to you, but I assume you're saying GitHub doesn't. I don't work for GitHub. I'm working incredibly hard to provide a better life for my family. For my two-year-old twins. Finishing projects is part of that work. It's not easy but I think it's worth it. If you're curious about my story of working, side-hustling, and spending time with my family here's an hour of me talking about it: https://saas.transistor.fm/episodes/bootstrapping-with-kids https://saas.transistor.fm/episodes/bootstrapping-with-kids. It's full of nuance that you might be wishing was in the article.
jpswade 3y ago
"perfection is the enemy of progress"
ultranano1 3y ago
Interesting idea but sometimes your projects aren't just a mess of errors and cryptic code. Sometimes they are clean enough, but mainly are just there to learn something, and spending all of the time finishing everything off to try to make it shippable is just a waste of the time that you could be spending on something worth shipping using your new found knowledge. Although if projects are getting abandoned just because of the mess they are in, that's definitely something to work on.
heikkilevanto 3y ago
Although I agree with some of the advice, I also remind myself to the exact opposite: Kill your projects. If during a project you learn that it will not work, will not be as good as you hoped it would, or if the circumstances have changed, put it out of its misery. Do not let it hang around nagging for you to finish it. Declare it dead, maybe archive it somewhere far away, clean it out of your sight, and move on. Do not consider a killed project to be a failure. Rather, it was an experiment with a negative result. You learned at least one thing that didn't work, and probably you learned a lot more. It is better to start exciting and ambitious projects, of which some may succeed, than to play it safe and only start working on something simple and boring that you already know will get released.
guzik 3y ago
About a decade ago, I was working on a mobile RPG game. I invested six industrious months, building it up to the brink of completion—just 3% short of its final version. The unpredictability of life, however, has its own plans. An unforeseen circumstance led the company I was collaborating with to dissolve, and simultaneously, a tech startup I had founded began to show the sprouts of success. Faced with this duality, I found myself contemplating the choice between my creation and an entrepreneurial opportunity. With a heavy heart, I paused the game project to build my startup, which turned out to be an arduous, albeit rewarding journey. Yet, that unfinished 3% kept lingering on the edges of my consciousness. So, I set aside three months to complete the remaining portion of the game (1% takes the same amount of time as 99% of development?) and finally released it on Steam. The joy I felt was amazing, not because the game was extraordinary, but because I had finished what I started. From this experience, I took away two key lessons: - We only have the bandwidth to complete a few significant projects in our lives (2 or 3 on average). It's crucial to know when to say 'no' and choose our commitments wisely. - Leaving a project incomplete can lead to long-term regret, more so than the effort it would take to finish it.
- plewd 3y ago
  I'm curious, does the 3% number for how (relatively) close you were to finishing the game come from hindsight, or did you know that number while in the process of making the game (and if so, how?)
  - guzik 3y ago
    The 3% completion figure initially came from my estimate that only the outro was left to be done, which could feasibly be considered as around 3% of the overall game. However, I hadn't taken several factors into account: - Releasing on platforms and setting up a Steam account. - Marketing and creating promotional graphics. - Bug fixes that were discovered by hardcore gamers, who we didn't have access to for testing a decade ago. - After 10 years, some Unity plugins needed to be updated and adapted. - Also important to consider is that I ultimately decided against a mobile version and had to rework the game for desktops. These factors ended up extending the process much more than I initially thought, but the figure of 3% had stuck with me from the beginning, illustrating how finishing touches often require a lot more time and effort than we might initially anticipate.
pvaldes 3y ago
Could be this a sign of a shortage of open source programmers willing to work for free anymore, so a big company can mix and sell their code ignoring the license? It seems that the early times of open source were much more idealistic and less corporative. This zeigeist will not return, I'm afraid.
iandanforth 3y ago
"Those few people—the ones that actually finish—know the deep satisfaction of seeing something through to the end. It’s a satisfaction much deeper than the euphoric high of starting." For me, this is false. I see other people who jump for joy at winning, who seem to really really like overcoming obstacles, who do get some deep satisfaction from accomplishment. I don't. Winning and completion feel ok, but at their most powerful they feel like a relief from the stress of effort or the shame of not getting something done. I look at people who get a natural internal reward for doing hard things like they have a super power. It's like they get paid millions for their work while I'm over here getting pennies. Over the years I've had to actively work to focus on intellectual pride rather than any feelings of satisfaction or accomplishment. If there's no rush then at least I can objectively say "I've done X to an acceptable level of quality" and have confidence that others will react positively. To some degree I get that feeling of reward from external praise, which I'm very thankful for, as I'd hate to be totally missing out on feelings of satisfaction, but I imagine there are people who don't even have that. So ultimately I feel like the author has failed to conceive of a world where people are wired differently and is saying "You'd like it if you tried it" without considering the possibility that, no, not everyone will like it enough to try it a second time.
- shrimp_emoji 3y ago
  Yep. This is totally me. It's as if my brain isn't wired to process "good news" or "triumph". The closest thing to that is rather final relief from some huge pain in the ass, and even that's fleeting. I think I could be told I just won a billion dollars, and I'd focus on whatever my next problem is in like 15 minutes. And the things I do are usually not huge pains in the ass since I usually only do stuff when I enjoy the journey. The destination can be nice, but not just because I'm stoked about reaching it.
hathym 3y ago
I need advice on how to finish your article :)
- aarondf 3y ago
  You'll finish it when the time is right :)
m463 3y ago
stop starting and start finishing.

513 points by aarondf 3y ago

As I started my studies, I tried to develop a little Android game. It took way longer than expected, being also very frustrating from start to finish. I kept working on it for a couple of months, set up a Google Play account, created some images for the Play Store, and then released it. As expected, it didn't get much traction, but I felt very proud and happy about it. Would recommend! :)

sproketboy 3y ago

[dead]

mijustin 3y ago

I often say this to my teenagers: "You don't get any credit for the homework you thought about handing in. Even if it's not perfect, the only way to get a mark is if you hand it in." So true for work and side-projects as well. (I needed this reminder myself as I have a blog post I've been noodling on for 12+ months. I just need to publish the damned thing!)

hacknewslogin 3y ago
This reminds me of two quotes that really helped me with perfection anxiety: "If it's worth doing, it's worth doing badly." "Within acceptable tolerances."
- whartung 3y ago
  The corollary of which is "It's not just good, it's good enough" (which I think is a Simpsons reference). I actually have a project on the shelf that's ][ far from being releasable. It's waiting on two things. One, is since it's a Java GUI, getting it built into a form for the MacOS/Window/Linux platforms, rather than just "here's a jar file". There's ways around this, but it's not quite drag and drop, and I haven't got a Windows box to test anything on, so its stalled. (I tried installing one of MS's VM images that they offered, but that's didn't work, so...back to the shelf). Two, is documentation. I could probably just let it go, and explain it to the 3 people who might actually download it and use because simply launching it, "Neat!", and letting it bit rot forever more. But, I think it needs some documentation, so...it sits. If I could satisfactorily drag and drop the installers, I'd probably press on with it, but it could still use some docs. Meanwhile, I continue on my meta project which this project would inevitably be folded into, so it's not all lost.
  - marcosdumay 3y ago
    Personally, I have lost count of the times I've got a jar from some place, and had to look at the source to discover how to use, and still used the software. It is really not a good experience, but totally beats not having the software.
dotnet00 3y ago
To latch onto that analogy, the point of homework is to make sure you learn the topic. So, if it weren't mandatory, handing it in isn't all that important as long as you're doing it. Indeed, in grad school, there was very little graded homework and most was just assigned with solutions given for anyone who wanted to do it. So, to bring the overly stretched analogy back to projects, I think you shouldn't feel like you need to "finish" something if it meets enough of the goals you set for yourself. Eg I spent months working on projects like custom OS's and game engines. But as the nature of those kinds of projects is to have endless room for growth, I just drew the line at some point that I had learned and done enough and could just drop them in whatever potentially buggy state they were in.

mjwhansen 3y ago

> Finishing requires courage Oh man, I feel this. I’ve been doing a lot of furniture refinishing lately as a hobby. One piece is 90% done and another is 80% done. I was working on the 90% done one today, and was planning to lacquer it today so I can put the hardware on tomorrow and be done… but instead I found a few places where I should really touch up the paint. That pushes back completing it at least one more day as the lacquer needs to sit for a day and… I just need to “ship” the darn thing. I realized it’ll probably never be 100% perfect, and that’s okay - done is better than perfect, as they say. Having the courage to create something that isn’t perfect is a skill.

mkoubaa 3y ago

Except software is never finished. If you publish something, there's a tacit expectation that you'll return to it, and it'll never be truly behind you. Rest assured, the only way that returning to a finished project takes more mental bandwidth than the guilt of never finishing it is if it's wildly successful. And that's a good problem to have

aarondf 3y ago
Totally! I referenced that near the end: > Sometimes finishing is just the beginning: You release the library, the package, the SaaS product, and your work is really just beginning. Users have issues, customers have feedback, and dependencies need upgrading. In some sense, there is no finished software; there is only released software.

phoe-krk 3y ago

The main problem with finishing projects is that the fun 90% of the project takes 90% of the time spent on it, and the un-fun 10% required to actually polish and release it takes at least the other 90% of the time spent on it. And then come the issues and PRs and people requesting your attention and time that they're entitled to because they found a project on GitHub that seems to fulfill 90% of their needs, and they only require you to implement or review the other 90%. Keeping stuff unfinished is actually not a bad idea.

Hamuko 3y ago
Eh. The vast majority of the time that you ship something, the end result is that literally nothing happens.
- codazoda 3y ago
  I can relate to this. I actually finish a lot of stuff. I mean, it’s not all polished, it’s just simple, documented, and released. Then, crickets. I either suck at marketing my stuff or I’m scratching itches that only I care about. Examples: https://ponder.joeldare.com/ https://ponder.joeldare.com/ https://www.nolific.com/ https://www.nolific.com/ https://github.com/codazoda/https-basic-auth-go https://github.com/codazoda/https-basic-auth-go https://calories.joeldare.com/ https://calories.joeldare.com/ https://neat.joeldare.com https://neat.joeldare.com Okay, a few of them have some GitHub stars, and I slipped in my most popular project, but still. It’s not like my inbox is overflowing or anything. There are about a gazillion others too. ;)
  - blakewatson 3y ago
    I think Ponder is cool! I made something similar for myself, but never got around to supporting more than one text. https://blakewatson.com/scratchpad/ https://blakewatson.com/scratchpad/
  - bbkane 3y ago
    Oh, you're the Neat CSS guy! One of these days I plan to use that for my blog- thank you for making it!

SCUSKU 3y ago

I always remind myself that "Done Is Better Than Perfect" whenever I think I should add some new feature to a project rather than ship it. I think the scariest thing is accepting that if you ship something people probably won't care. It's easier to continue working and not ship it under the assumption that just adding that one more thing will then make everyone love it. I don't know how it happened, but at some point I stopped caring about outcomes and have accepted that most ideas I have are stupid, most projects bad, but the only way to find good ones is to just put it out in the world. Worst case scenario everyone ignores it.

damethos 3y ago
"Perfect is the enemy of good" is another similar one you might like ;)

mrcwinn 3y ago

In the middle of this as we speak, so thanks for the post. I'm absolutely in that rough 10% phase. XD

aarondf 3y ago
Rooting for you. You can do it.

interroboink 3y ago

In general, I like the empathetic tone of the article, and I appreciate that it addresses an emotional facet of software development. But nevertheless it triggers some little part of me w/regard to telling people what they should or should not do, or what they may be proud of. I worry for someone who reads "You also have a duty to your future self to release the project" and "...you tell yourself that you are the kind of person who ships" and takes that to mean "if you don't release it, you're failing yourself" and "you're the wrong kind of person if you don't ship." On an emotional level, I think it's better to start from a place of (unconditional!) self-love, and go from there, rather than beating yourself up because you're not meeting some blogger's expectations of how you should act. And just to be clear: I don't think the author means it that way, but that's one way it can come across, to some people, in some states-of-mind. I've generally found it more useful to phrase things like this in terms of "I" rather than "you". As in: "I had X experience when I did Y" rather than "you should do Y, so that you will feel X." It's a common mis-step in giving well-meaning advice, I find. EDIT: Also, I'm sure there are plenty of people who really do benefit from advice being given in this more pointed way, and I realize it's a bit onerous to always write and phrase things for a "safest common denominator," but I think it's worth keeping in mind, at least.

aarondf 3y ago
Nuanced and valuable feedback, that I receive. Thank you! I think your edit was basically going to be my reply, haha. It is hard to address every side of every potential topic in an article. I actually needed help softening the tone to end up with the final version you're reading today. I'm empathetic by nature so it's easy for me to write with empathy, but I'm still prone to generalizing my personal experiences!
- BeetleB 3y ago
  > You have a duty to your past self to release the project. It’s a way to honor your work and sacrifice. All the time spent on the project is time you could have spent on something else. That time was not without cost. Ouch! I strongly encourage you to read up and understand the sunk cost fallacy. In general, do not let past efforts be the guide for future decisions. I've quit a lot of projects in my life. And it was the right thing to do. Put another way, many of the valuable projects I've completed would not have been accomplished had I stuck to the projects I had sunk time into. > You also have a duty to your future self to release the project. Every time you don't release a project, you're telling yourself that you’re the kind of person who doesn't ship. If you tell yourself that every time you don't release a project, the fix is not to release the project, but to stop telling yourself these lies. Despite the strong complaints, the article isn't that bad and does have some merits.

bartq 3y ago

I think this is important: finish your project in bigger context where your project is a piece needed in higher level picture. Don't finish project just to finish it. This attitude solves problem of motivation, because you naturally finish the project without forcing yourself. Masons don't lay bricks to have bricks laid down, they want to build a house. Of course it much more complex than that, some people are just not types of makers and "finishing projects" is not their cup of tea.

Lammy 3y ago

> Sometimes finishing is just the beginning: You release the library, the package, the SaaS product, and your work is really just beginning. Users have issues, customers have feedback, and dependencies need upgrading. In some sense, there is no finished software; there is only released software. Translation: "Please get locked in to using GitHub"

aarondf 3y ago
Ha. I don't work for GitHub tho! I'm just a guy writing about my feelings
- Lammy 3y ago
  I didn't claim you did. Why would GitHub (read: Microsoft) "amplify your voice" in a way that doesn't benefit them? They want people locked into GH via their non-Git offerings.
- pvaldes 3y ago
  > Ha. I don't work for GitHub tho! I'm just a guy writing about my feelings And this is exactly the problem. GitHub uses you as a free writer to promote its making money goals, instead to pay somebody. You are just another case of "working for the exposure". You in fact were working for Github, you just not realized it, and weren't paid. Open source in late 90's was not about making a personal brand -> to make merits -> so the companies will hire you -> so you don't need to do open source anymore. Some people maybe, but the majority were driven by personal hobbies and "I'll fix it because I can, in a context of mutual benefit, and feels good helping somebody like me somewhere". Now the mutual benefit in both parts feel much more unbalanced.

deleted 3y ago

[deleted]

ge96 3y ago

lol (monkey eyes, looks away)

stuckkeys 3y ago

I also listen to the same song on repeat. How do you think Despacito got all those views.

aarondf 3y ago
The thought of listening to Despacito for a week straight is making me sweat

rozenmd 3y ago

My "hack" is to release work early (while you're still embarrassed by it), and iterate ruthlessly: https://onlineornot.com/unreasonable-effectiveness-shipping-daily https://onlineornot.com/unreasonable-effectiveness-shipping-....

forgotmypw17 3y ago
I try to make at least one commit a day. Some days I fail, but often I have weeks-long streaks.
aarondf 3y ago
Love this framing! Good article. Followed you on Twitter!

agumonkey 3y ago

I heard that Shannon was a mess hyper multitasker. He just went wherever his mind wanted to, and moved accordingly. Made me try to accept my scrapyard of project shelf and just keep iterating hard.

ezekg 3y ago

Totally agree. And even after the big finish^Wlaunch, too many people give up on good projects because they don't know how to get traction yet. The truth is that sometimes that's your fault, not the project's fault. New founders especially quit good ideas way too often, way too early because they've been conditioned to want to drop things if they fail to reach hockey-stick growth within a certain time threshold. It takes time. All of it. I briefly wrote about this awhile back as well: https://keygen.sh/blog/5-things-ive-learned-in-5-years/ https://keygen.sh/blog/5-things-ive-learned-in-5-years/

jhp123 3y ago

To take the contrary position: give up. Your project will take far longer than you think, and you will get much less from it than you hope (at least in terms of external validation and rewards). You may feel a horrible pressure to finish it, but you are a free person and can simply choose not to. You can free yourself from this pain without lifting a finger. Go take a walk or bake some cookies instead. If you have the intrinsic motivation to continue with your project, then your interest will return at some point and you'll get back to it with the wind at your back. If you don't have that intrinsic motivation any more then you will only make yourself miserable by trying to whip yourself forward.

aarondf 3y ago
I've lashed myself to the mast (so to speak) and forced myself to finish projects that I would've otherwise walked away from, and I'm so so glad I did. > You can free yourself from this pain without lifting a finger. Sometimes the cost of doing things is pain. I was going to say the cost of doing _great_ things is pain, but honestly, the cost of doing anything is usually some level of pain.
- bob1029 3y ago
  It isn't always the case, but I have found that pain is the #1 litmus test for "is what you are doing valuable". Some times this turns out to be a "you worked hard instead of smart" problem, but game theory wise one can assume that painful things are generally avoided or not fully explored. There is a really good reason you are spammed to death with GPT chat bot clones, but have to go around like a beggar to find things that actually matter.
- waboremo 3y ago
  What happened as a result of finishing those projects?
  - aarondf 3y ago
    One thing: internal satisfaction. External success, too! The biggest one recently was releasing a course on MySQL at https://planetscale.com/mysql-for-developers https://planetscale.com/mysql-for-developers. It was painful to push that over the finish line, but giving up on it would have been a huge disservice.

cmrdporcupine 3y ago

Unfortunately I don't get paid to finish personal projects on GitHub, and I need to get paid to feed my family. (And I don't have other devs, product managers, QA, etc. to help, either, like I do at work). And judging from the nature of the vast majority of stuff on GitHub, most people are in the same boat. Someday I'll retire and then I can get some real work done.

doctor_eval 3y ago

I have two projects on the shelf right now. I’ve been dragged away (read: need money) to work on non-code projects. To the point where I don’t feel confident about opening my IDE! So, this article is really timely. Thanks.

aarondf 3y ago
Go get em. Thanks for the kind words

carb 3y ago

I love this article and the premise. Further similar reading/watching in some of my favorite Zack Freedman videos! - "Here's What's Preventing You From Finishing Projects": https://www.youtube.com/watch?v=L1j93RnIxEo https://www.youtube.com/watch?v=L1j93RnIxEo - "How to Finish Your Weekend Projects in One Weekend": https://www.youtube.com/watch?v=72a85tWOJVY https://www.youtube.com/watch?v=72a85tWOJVY "Finishing" more projects (even if that means changing the scope and announcing it "finished") has been amazing for my internal willingness to start new projects or tell friends about them. I have much less anxiety that I'll leave another half-finished project sitting around with lost motivation.

bgoldste 3y ago
Thanks for sharing these. Though I mostly do software I found his take very helpful. Also nice to be reminded how fungible things are when no actual wires get involved.

enos_feedler 3y ago

Is it bad I can’t even finish reading the article?

Ilasky 3y ago

I really like the analogies of SLC (simple, lovable, and complete)[0] and “I’m the only user”[1] to motivate how I finish my projects. Often times I have a project I’m working on and my imaginary perception of what a user needs is steering the development. Whereas, in reality, I just need the thing to work for myself and I can pretty it up how I like. [0] https://herman.bearblog.dev/mvp-vs-slc/ https://herman.bearblog.dev/mvp-vs-slc/ [1] https://blubsblog.bearblog.dev/i-am-the-only-user/ https://blubsblog.bearblog.dev/i-am-the-only-user/

turnsout 3y ago

Counterpoint: do what actually matters to you. You may constantly start projects and never finish them, but that may actually be serving your need for experimentation and learning. For someone else, that same behavior might be unhealthy avoidance. If "finishing" a project (software is never done) is something that matters to you, find ways to work towards that goal. I've shipped plenty of things, but also walked away from 10X more projects that were "90%" done, because I got what I needed out of them.

xwowsersx 3y ago
I agree with your idea, but I don't see at as a counterpoint. I don't read this post as making an axiological statement about the would-be reader's work (I may have read it wrong though!). To me, the article assumes that "finishing" the thing is something the reader already values, or at least does in many cases. And the author is offering some advice for how to stick to it and power through even when there are painful stages along the route to what the reader already wants. I see this as trivially or obviously true too, namely the idea that not every moment or every ounce of work on the way to something you yourself really deeply desire will feel like elation and fun.
- aarondf 3y ago
  Author here: you are reading it as I intended! Not "you have to finish everything" but rather "you want to finish something but it's hard, now what"
  - xwowsersx 3y ago
    Glad I read it as intended. I enjoyed your writing!

bodge5000 3y ago

I used to have this problem and then maybe ~8 years ago, I solved it, and word of warning, it can go the opposite way. When I finished my last project I started work on a new one, which I predicted would only take a few months. Common mistake I know, but even looking back, technically speaking I wasn't wrong by much. It is a simple project on a technical level, but not so much on a design level (by that I mean game design, its a game I was working on). 3 years later, I realised it was a fundamentally flawed idea. 6 years later, now, I'm still working on it, despite knowing that. Very recently, for the first time in that 6 years, I've been successful at pulling myself away onto other projects, but that main one still sits there and I will get back to it, whether I want to or not. All thats not to say that finishing things isn't important, just that it can go both ways. Sadly I don't have any advice to stop others from falling into the same trap as I did other than maybe being aware of that. EDIT: To be clear, this isn't a "just ship it" situation. I don't have anything to ship other than mismatched ill-formed prototypes, and I do mean prototypes. Maybe one day I'll just polish up one of those prototypes and ship it, that's been my thought process lately

pengaru 3y ago

Commercial software vendors don't even finish their products before shipping what's often aspirational vaporware in the form of a skinned update mechanism. Don't get me wrong; I'm totally in favor of finishing things in the sense of doing the un-fun work of finishing instead of distracting yourself with a fresh set of problems every time you reach the un-fun finishing phase of resolving existing messes. But it's worth noting that what qualifies as "finished" seems vastly different from what it was back in the days of shipping software on CDs and floppy disks. You don't even get a finished automobile anymore in some cases, and we're not talking kit car prices. Tesla, I'm looking at you.

paxys 3y ago
Commercial software vendors may not finish their products (what even is "finished" when it comes to software?) but they do ship them. How many unfinished hobby projects meet the same fate?

c7DJTLrn 3y ago

I tried forcing myself to finish a personal project before moving on to the next one. I've just ended up procrastinating and getting nothing done for the past 6 months. In turn, that has created a cycle of guilt and anxiety making me not want to touch any of my projects at all.

sheepishly 3y ago

[flagged]

seabass-labrax 3y ago

I tend to have the opposite experience from the author's: I know enough about the domain to know that choices I make at the beginning could cause massive problems later on (in performance-critical software, for instance), yet not enough to know exactly where the traps are. Once the project is underway and empirical data can be collected, it's much easier to direct attention to known issues and opportunities. By nature I enjoy the 'boring' stuff, to use the author's term, and often find a clean code-to-package CI pipeline and an up-to-date wiki more satisfying than the software itself! I wonder what the ratio of 'non-finishers' to 'non-starters' is. I suspect I'm in the minority, but maybe someone here knows of a reliable study of this.

doingmaths 3y ago

I'm definitely guilty of not finishing projects, but I don't know that the "Just do the thing and don't NOT do the thing" is a particularly useful piece of advice. I know I should "fight for the time on the project" but willpower to do so isn't always something that's available. And that's not a personal failing -- I might decide that tonight I want to work on my game, but then have a long day at work that leaves me emotionally and physically exhausted. It's important not to burn out on your projects too, and forcing labor on them when you do not have the spare capacity can lead to long term failure to complete the projects as well. I think the much more valuable lens is to consider -- "Why do I work on this project? Is the joy of finishing it important to me?" If you want to finish it, and cannot, then start looking into pushing yourself to finish. If the joy is in just tinkering because tinkering is fun, then allow yourself that pleasure and don't beat yourself up for finding something you enjoy and partaking in it.

doingmaths 3y ago

I'm an anarchist --- wait hold on! --- not like "The Purge" kind, but the "mutual aid and share what you can" kind. I genuinely believe that if we operated more on a "people will produce the tools, food, and art they want to produce, and will improve their working conditions if given the opportunity" mindset, and less on a "hit this deadline so your boss makes a buck" mindset we'd be able to finish more of our 'side projects'. I think we all naturally have these projects in mind, things we would pursue if we had the time. And I think we could move towards a world where we optimize a little less for maximizing profit, and a little more for maximizing our leisure time. It will take some structural reforms, some trust, and a whole lot of learning by doing, but I'd much rather live in a world when I had less stuff but more freedom to pursue things I enjoyed.

eternityforest 3y ago
I'm all for mutual aid and sharing, and I am definitely not an endless growth capitalist, I want people to have time and resources to make art and tend their gardens. But I sure couldn't produce the tools I want without making use of the work of profit driven people, simply because advanced tech is a lot of work, takes hundreds of people, is too big for anyone to understand and thus is almost never made if idea-exploring is the main motive, and generally seems pretty tied to profit. Lots of places in Europe seem to have mostly figured the balance out. I don't think I'd prefer to live in a world without Intel and Microsoft, maybe I'd have free time, but I'm not sure it would be leisure time, I might be hand-washing laundry instead. We definitely need changes, and there are some amazing side projects out there.... but also, I want to eradicate the last few guinea worms, have every roof covered in solar panels that can last 70 years, and have my Google Keep notes keep working or be replaced with an even more advanced and feature rich version. To do that, I think we would either need to start doing really big polished side projects, or we'd need to manage and reform, but not eliminate the deadlines and meetings kind of stuff. I'm not sure we know how to run a chip fab with any other social structure. Maybe a co-op with elected leaders, or unionization, or better inspectors to be sure there's no child labor sourced parts... but we would have a lot of learning to do to make Intel open source, half the people would just say "We should ditch out of order execution, it's a security risk" and the other half would say "This defect tolerance routing that improves yield 20% is really complicated, stuff is getting too hard to understand, we can toss a few wafers if it means the tech stays human-level, and in 5 years we can probably just get rid of the defects".....

eclectic29 3y ago

Personally for me the biggest hurdle is starting a project, not finishing it.

deleted 3y ago

[deleted]

satisfice 3y ago

I have no duty to be a slave to my past self. I proudly liberate myself from finishing anything.

shit_game 3y ago

As "inspirational" as this comes across, I can't help but feel a bit cynical in that this is _Github_ publishing this. You know, the company that famously built an AI product using the projects hosted on Github... Personal development and growth and feel-good-iness aside, there is a tremendous conflict of interest present when Github is encouraging its userbase to create working software projects when those software projects constitute a treasure trove of machine learning data that can be monetized (and even more effectively so if they work/are completed).

slicktux 3y ago
I agree, very much so, with your reasoning; so much so that I never trusted my code in any online code hosting platform…but never did I imagine it would be used for machine learning!
jahewson 3y ago
Is this not an alignment of interests?
- shit_game 3y ago
  I suppose that depends on ones opinion regarding the Copilot situation.
aarondf 3y ago
GitHub did publish it, but they didn't write it! I (the author) don't work at GitHub, and they don't tell me what to write. The brief they give me is basically "write something a developer would like" and off I go. Not sure if that changes your mind, but at least now you know how it worked behind the scenes!
- shit_game 3y ago
  I'd say it does influence my opinion to be more positive knowing that you're not necessarily in the palm of Githubs hands, though my underlying cynicism still remains - I think part of that is that I've grown significantly more cynical of written pieces over the years having watched online content succumb more and more fervently to the game of monetization and opinion influence. Additionally, I think this article strikes a bit at my person as I struggle immensely with finishing anything I start, to the point where I've began projects (plural!) meant to act as tooling to create project boilerplates, and I still haven't finished even those. Regardless, I do feel the message shared is a positive one that does come from a place of benevolence. Tangentially, I'm curious if you could speak to what it's like creating content as a third party author? Are you given prompts regarding the tone or content of your work? Have you ever had work you've produced be rejected by a publisher? I'm not at all familiar with this aspect of online content (despite being stuck to a screen reading it all day), so I'd appreciate some insight on the matter if you're willing and able to share any.

blueblimp 3y ago

This brought to mind another blog post I liked on the topic of finishing, by Derek Yu (of Spelunky fame): https://makegames.tumblr.com/post/1136623767/finishing-a-game https://makegames.tumblr.com/post/1136623767/finishing-a-gam....

codersfocus 3y ago

I read a very boring but useful paper on curiosity by Lowenstein. He frames curiosity as a drive (similar to eg hunger.) If you’re starting but not finishing projects, maybe it’s due to curiosity about a sub problem that you hack a solution for. But once your curiosity is satisfied and you have no other drive eg money, stars on Github, you finish without releasing it

shepherdjerred 3y ago
That's an interesting take, and certainly one I empathize with. Did Lowenstein argue that not finishing projects is a negative trait as it's often portrayed as?
v7n 3y ago
In my native Finnish tongue we do use, interchangably, expressions "tiedonjano" and "tiedonnälkä" which directly translate to thirst/hunger for knowledge. Even "tiedonmuru" is a crumb of knowledge or data, as in bread crumb.

kazinator 3y ago

I don't agree with the part about starting a new project with no legacy code being easy; starting a new project with no old code at all can be paralyzing. The best is a project that is never finished, with great legacy code that makes it easy to do new things all the time, such that you're relieved you have it there. :)

steve76 3y ago

[dead]

MichaelMoser123 3y ago

what happened? Is GitHub concerned about the quality of the training data that is fed to GitHub copilot?

aarondf 3y ago
If they are they didn't tell me. I explained this more fully in a few other threads!

temporallobe 3y ago

I’d love to. I actually have 2 games I started and never finished, mostly because I developed the primary gameplay mechanics and design, but I’m too lazy to make them into a finished product. The chasm between developing a POC and finishing things is surprisingly wide. It’s the same for the literally hundreds of songs I’ve written and recorded over the past 20ish years - I’ll record a demo or a 90% finished mix, but again, the level of effort between that 90% finished mix and a fully polished and mastered release-ready song is far more than it took for the 90% version.

jftuga 3y ago

I feel like I finish most of my projects. Granted, most of them are small, command-line tools. When they're done they're done. What are your thoughts I projects that haven't had any updates in a few years? https://github.com/jftuga?tab=repositories&q=&type=source&language=&sort=stargazers https://github.com/jftuga?tab=repositories&q=&type=source&la...

nixpulvis 3y ago

Define “finished”. Oh cool (read FUUUUUCK), I forgot I don’t know how to disable smart quotes on iOS.

aarondf 3y ago
That's the neat part, you get to define it for yourself.

langsoul-com 3y ago

Should be finish your project* Sometimes there's just more interesting stuff to do, or the easy project turned out to be a near impossible slog. Letting go and moving on is a valuable decision instead of digging a deeper hole. That is sunk cost fallacy. Ie, I tried making a instagram + discord fusion. Instagram image feeds, but to a server of people instead. Turns out it's a ton of work and is worthless unless others adopt it. So it got scrapped after month+ of work.

_proofs 3y ago

"the things that you love should be the things that you do, and the things that you do should be the things that you love." -r. b.

ramity 3y ago

I don't really subscribe to the idea of "finishing" or "completing" a project; I'm sure my personal github can attest to that. I think "real" software is never done. The only things in software that are completed are the fractions of software we abstractly define (tasks, features, sprints, deliverables, etc). Much like us, real software lives until it doesn't. It changes through time sometimes regressing and expanding. Software whose goalposts remain static becomes deadware. Outside of commercial projects, I program for the joy of creation and commonly, and paradoxically, automating for the sake of "not automating." I jump from project to project, sure, but I've found the largest source of not wanting to go back to a project is the difficulty of doing so. Having to pick things back up to juggle and going through the motions of learning what my software did and what needs to be done was always a pain. My real breakthrough was "optimizing being able to leave." Comments like I'd be picking up the software months/years later, READMEs detailing build steps and rationale and planned features, automating dev environment setups with docker, break features/work into pieces so it isn't overwhelming, etc. These are just some of the many ways to make it easier. Sometimes you don't want to go back because all you can think of is the known (or unknown) work that lies ahead of you. The fewer the reasons to not go back, the easier it is, and if it's easy to pick back up, you'll find yourself picking things back up when the time is right. Sometimes inspiration hits while working on other stuff, and I say that's fine. Embrace that. Commercial software is a bit more narrow in the selection of how one can start and stop on work (I call this "task shopping"), but being in tune with yourself and vocalizing that during standups/meetings/whatever can help. Can't seem to finish a task? Maybe the task was too big to begin with, scope/feature creep set in, or whatever. Create tasks for what you've gotten done and what needs to be done. Lay out some groundwork to explain how someone might pick up the new tasks. Do that and you'll find yourself "optimizing being able to leave." "You must become comfortable with the grind-it-out nature of the last 10% of a project." I really don't align with this statement. Software can and should be a joy to do. Sure, there are aspects that can make it feel like a grind, but this is a question of framing. After all software development is technically data entry (don't think about this too much).

moomoo11 3y ago

Really nice read! I too play the same songs on repeat. I love death metal so I just listen the songs that make me want to wage intergalactic war on other planetary systems and play them on repeat lol. Once I’m in the zone there’s no coming back unless it’s with the spoils of victory!

rocho 3y ago

I found this paragraph so relatable: > Personally, I like to put a single song on repeat for hours and hours, days even. It helps me zone in. Why does this admittedly strange behavior help me? I'm not sure exactly, but I've known it to be helpful for more than half my life. I like to get up early before the family is awake, close Slack, put my phone in Do Not Disturb mode, and work. I even put a Post-it note on my monitor with the task I'm focusing on to help keep me on track. Sometimes I can accomplish more in that quiet hour and a half than I can in the rest of the day. Except for the post-it note, I do those exact things. These seem to be the essential pre-requisites to being very productive (for me): 1. Set aside some time to work on something specific (with clear goals and intentions). 2. Block all interruptions (messages and calls of any kind and other distractions). 3. Focus and get in the zone. I find that music helps a lot here, and generally for me it's electric music or songs with very subtle lyrics (almost dream-like). If the lyrics are too noticeable, they become a distraction. The above works both for my personal projects and work. I work remotely and sometimes there are so many interruptions during the work day that I simply abandon everything and go do something else (a walk, groceries, work out, etc.). Then I catch up in the evening or during the weekend, when interruptions are at a minimum or completely absent for hours on end. Almost always I'm more productive in a couple hours like this than for entire days. Finally, while I liked the article a lot, I disagree with the premise that projects _must_ be finished. It's fine not to finish a project, it's not failure at all. On the other hand, yes, there is a certain feeling of accomplishment that comes with reaching a level of "completeness" of a project.

mach1ne 3y ago
Interesting that music works for you. I’ve noticed that besides just white noise, music significantly degrades my work results. I might produce similar amounts of content line-wise, but the solutions are of much lower quality when I listen to music. As a result, I only listen when work feels too painful and I’m okay with decreasing my output.
- rmuratov 3y ago
  For me it is listening music without any words. I have one special track that enables "productivity mode" for me. If there any lyrics I can't concentrate and listen to words instead,

deleted 3y ago

[deleted]

uoaei 3y ago

This reads like a thinly veiled plea to improve Copilot's training data.

kissgyorgy 3y ago

No thank you. The whole point of my project is that I don't have to finish it!

rconti 3y ago

Funny, I have the exact opposite reaction. Solving for edge cases, for optimization, for bugs, is all so much easier. The "infinite possibilities" means infinite wrong decisions. Infinite ways that the decision you just made will prove to be a colossal fuckup in 2 months' time.

Joel_Mckay 3y ago

Rule #1: Quickly identify a failure to resolve critical paths to completion. Some projects are simply doomed without the right people, resources, and market conditions. See "Law of holes" corollary: "Nor would a wise man, seeing that he was in a hole, go to work and blindly dig it deeper..." ( The Washington Post dated 25 October 1911 )

kaba0 3y ago

What helped me finish some of my projects was also choosing a realistically achievable goal. I have made the mistake of being overly ambitious many times, like how cool would it be to rewrite this and that as well from scratch, my version will be so much better, etc.. But it is sometimes simply not feasible, and we would be much better off with a less ambitious solution to the problem we have. Last time I successfully applied this was a personal finance tracker, where instead of going at it reinventing the wheel I built my smaller project on top of the Plain Text Accounting ecosystem (beancount specifically).

joeig 3y ago

Regarding > Decide upfront what you're going to work on. and > Behind the fear of releasing is often the fear of exposing your work, and yourself, to criticism. When I plan to release my project's source code, it has helped me to release parts of the project up front as single-purpose libraries. This helps me think in smaller chunks of work, and makes me feel like I'm finishing more often. It also shortens the feedback cycle.

rpastuszak 3y ago

For those looking for more practical advice on the subject: https://sonnet.io/posts/sit/ https://sonnet.io/posts/sit/ > Finishing requires work > Finishing requires courage and > "Just Work" Hard to disagree with that, IMHO Sitzfleisch is akin to exposure therapy. But, in practice both items require having a deeper understanding of where the difficulty comes from. Instead of brute-forcing the problem (and sometimes setting up yourself for failure), it might better to develop tools that work you as an individual. For instance, sometimes for me procrastination or avoidance can be a signal that I haven't been taking care of myself outside of work OR that deep down I just don't give shit about the project, but can't admit that to myself so just end up more frustrated. In this case leaving the house for 15 minutes or petting my dog works better than Sitzfleisch (cliche I know). Again, that's not always the case, but I think spotting those signals and making the appropriate choices is a muscle we develop through practice. More on the subject in the article above and here: https://sonnet.io/posts/hummingbirds/ https://sonnet.io/posts/hummingbirds/

ly3xqhl8g9 3y ago

One way to make sure (some) projects get finished is to not use semantic versioning, 1.0.0, 27.8.3, and so on, since integers can be incremented longer than the average lifespan, and instead use something like alpha-versioning which starts at 0.0.0-0 and ends at 1.0.0-0, that is, reaching 1.0 is actually the death of the project, its tombstone saying non perfectus sed perfectibilis non amplius (Latin for gravitas: not perfect, but perfectible no more). At the other end, having goals which extend well beyond the average lifespan is what could be considered as the root of wisdom.

marc 3y ago

I still struggle with this, but I’ve become better at it. What I learned is that “the last 10%” really is about half of the work. The solution is to reduce the scope. A lot. Not only will it make it easier to finish the project. It also allows you to get real-world feedback a lot earlier. Which is both rewarding and informing. Two things that will help you push your project forward if you choose to do so.

drawkbox 3y ago

Finishing is hard so it needs to be the strongest point of the project. When you got started you were in the open mode, playing, prototyping, dreaming and iterating. When you finish you have to move to the closed mode and have an internal editor that says "ship" and "cut that" or "move to an update" and that is a difficult ride. Sometimes people don't finish simply because it is too painful for a labor of love to be trimmed, but it is the skill you need to ship. It sucks but is. What you have to do there is revisit the love/play that initially got you to the idea and project. See your project in the world/market and feel the original feelings of when you started it. Don't focus on what you had to cut or didn't meet your expectations, focus on what did and head to post-production and ship. Ultimately we are only what we ship to the world, no matter how much you have in development or your adventures. If it isn't where you want to be improve it, but also learn to love each ship as that is a major step. It is a joy when what you envisioned comes out as you wanted or better, when it isn't, make changes and updates. Both "work with a high degree of quality" and "finish strong" are good areas to strive for, but "finish strong" is where it is at.

outsomnia 3y ago

"Finish your projects", finger wags cheerful guy full of certainties, paid by large American corporation that makes money from your finished projects and doesn't care what happens to you before, during or afterwards.

q1w2 3y ago
This is a Reddit-level comment. Cynical and teenage-anger-esuque
- outsomnia 3y ago
  Good job you're there to lift the tone!
vaylian 3y ago
It makes sense to add this context. But I still think the advice and explanations in the blog post are more generally applicable than just to GitHub projects.
aarondf 3y ago
I do work for an American corporation, but we're not large! Less than 100 people I think. I do care about what happens to you, but I assume you're saying GitHub doesn't. I don't work for GitHub. I'm working incredibly hard to provide a better life for my family. For my two-year-old twins. Finishing projects is part of that work. It's not easy but I think it's worth it. If you're curious about my story of working, side-hustling, and spending time with my family here's an hour of me talking about it: https://saas.transistor.fm/episodes/bootstrapping-with-kids https://saas.transistor.fm/episodes/bootstrapping-with-kids. It's full of nuance that you might be wishing was in the article.

jpswade 3y ago

"perfection is the enemy of progress"

ultranano1 3y ago

Interesting idea but sometimes your projects aren't just a mess of errors and cryptic code. Sometimes they are clean enough, but mainly are just there to learn something, and spending all of the time finishing everything off to try to make it shippable is just a waste of the time that you could be spending on something worth shipping using your new found knowledge. Although if projects are getting abandoned just because of the mess they are in, that's definitely something to work on.

heikkilevanto 3y ago

Although I agree with some of the advice, I also remind myself to the exact opposite: Kill your projects. If during a project you learn that it will not work, will not be as good as you hoped it would, or if the circumstances have changed, put it out of its misery. Do not let it hang around nagging for you to finish it. Declare it dead, maybe archive it somewhere far away, clean it out of your sight, and move on. Do not consider a killed project to be a failure. Rather, it was an experiment with a negative result. You learned at least one thing that didn't work, and probably you learned a lot more. It is better to start exciting and ambitious projects, of which some may succeed, than to play it safe and only start working on something simple and boring that you already know will get released.

guzik 3y ago

About a decade ago, I was working on a mobile RPG game. I invested six industrious months, building it up to the brink of completion—just 3% short of its final version. The unpredictability of life, however, has its own plans. An unforeseen circumstance led the company I was collaborating with to dissolve, and simultaneously, a tech startup I had founded began to show the sprouts of success. Faced with this duality, I found myself contemplating the choice between my creation and an entrepreneurial opportunity. With a heavy heart, I paused the game project to build my startup, which turned out to be an arduous, albeit rewarding journey. Yet, that unfinished 3% kept lingering on the edges of my consciousness. So, I set aside three months to complete the remaining portion of the game (1% takes the same amount of time as 99% of development?) and finally released it on Steam. The joy I felt was amazing, not because the game was extraordinary, but because I had finished what I started. From this experience, I took away two key lessons: - We only have the bandwidth to complete a few significant projects in our lives (2 or 3 on average). It's crucial to know when to say 'no' and choose our commitments wisely. - Leaving a project incomplete can lead to long-term regret, more so than the effort it would take to finish it.

plewd 3y ago
I'm curious, does the 3% number for how (relatively) close you were to finishing the game come from hindsight, or did you know that number while in the process of making the game (and if so, how?)
- guzik 3y ago
  The 3% completion figure initially came from my estimate that only the outro was left to be done, which could feasibly be considered as around 3% of the overall game. However, I hadn't taken several factors into account: - Releasing on platforms and setting up a Steam account. - Marketing and creating promotional graphics. - Bug fixes that were discovered by hardcore gamers, who we didn't have access to for testing a decade ago. - After 10 years, some Unity plugins needed to be updated and adapted. - Also important to consider is that I ultimately decided against a mobile version and had to rework the game for desktops. These factors ended up extending the process much more than I initially thought, but the figure of 3% had stuck with me from the beginning, illustrating how finishing touches often require a lot more time and effort than we might initially anticipate.

pvaldes 3y ago

Could be this a sign of a shortage of open source programmers willing to work for free anymore, so a big company can mix and sell their code ignoring the license? It seems that the early times of open source were much more idealistic and less corporative. This zeigeist will not return, I'm afraid.

iandanforth 3y ago

"Those few people—the ones that actually finish—know the deep satisfaction of seeing something through to the end. It’s a satisfaction much deeper than the euphoric high of starting." For me, this is false. I see other people who jump for joy at winning, who seem to really really like overcoming obstacles, who do get some deep satisfaction from accomplishment. I don't. Winning and completion feel ok, but at their most powerful they feel like a relief from the stress of effort or the shame of not getting something done. I look at people who get a natural internal reward for doing hard things like they have a super power. It's like they get paid millions for their work while I'm over here getting pennies. Over the years I've had to actively work to focus on intellectual pride rather than any feelings of satisfaction or accomplishment. If there's no rush then at least I can objectively say "I've done X to an acceptable level of quality" and have confidence that others will react positively. To some degree I get that feeling of reward from external praise, which I'm very thankful for, as I'd hate to be totally missing out on feelings of satisfaction, but I imagine there are people who don't even have that. So ultimately I feel like the author has failed to conceive of a world where people are wired differently and is saying "You'd like it if you tried it" without considering the possibility that, no, not everyone will like it enough to try it a second time.

shrimp_emoji 3y ago
Yep. This is totally me. It's as if my brain isn't wired to process "good news" or "triumph". The closest thing to that is rather final relief from some huge pain in the ass, and even that's fleeting. I think I could be told I just won a billion dollars, and I'd focus on whatever my next problem is in like 15 minutes. And the things I do are usually not huge pains in the ass since I usually only do stuff when I enjoy the journey. The destination can be nice, but not just because I'm stoked about reaching it.

hathym 3y ago

I need advice on how to finish your article :)

aarondf 3y ago
You'll finish it when the time is right :)

m463 3y ago

stop starting and start finishing.