Hacker News Reader

Comment by deeg | Hacker News Reader

I find that the best way for me to finish a side project (for some definition of "finish") is to work on something that I want to use. Sometimes my motivation will flag for a few months until I want to use it; then the motivation kicks in and I'm productive while I improve/fix the project to make it work better for me.

View on HN

Relatedly, it’s about working on something that will be useful quickly and you can polish after you’re already using it every day.

E.g. I got really fed up with how clunky the AWS assume-role workflow was at work with multiple AWS accounts so I wrote a little tool using Lispworks’s CAPI for a GUI that would handle authentication and embed a webkit browser so I could control the cookies more precisely. I got an MVP that improved my workflow working in a weekend and I’ve been iterating on it over the last several months. I find this sort of process works much better than spending months working on something that I may eventually use.

I’ve also just decided that it’s ok to have a dozen incomplete projects I work on occasionally over the course of several years.

I'm in the same boat but the problem with that approach is the technology stack and/or the problem the project solves become obsolete in the meantime.

It’s a matter of picking slow-changing technologies: so, not the latest JS framework or whatever, but something like Clojure or Common Lisp that has a track record of maintaining backwards compatibility. And then learn to solve problems in ways that can easily be adapted to solve related problems.

I would absolutely love a browser extension version of that. Current using Last Pass and searching for the accounts to switch to.

Are you signing in with AWS users or STS AssumeRole? My company does the latter: there’s a user management account and then each project gets their own account. To access a particular account, we have to use a user in the user-management account to assume a role in the account we want to access. This makes the AWS CLI tooling annoying and it also makes the AWS console annoying to access: you have to generate a sign-in link programmatically and use that link in the browser to sign in. However, if you’re already signed into an account, this pops up a page that says “you’re already signed in, please click here to log out before switching accounts”. Then you have to logout and regenerate the link before you can access the account you want.

My solution was an app with a minimal embedded webkit browser, so that I can programmatically clear the cookies every time I login to a new account: that way, the sign-in link works first try. Since then, it’s grown the ability to list Cloudformation stacks and their parameters and outputs.

Yes, this a thousand times. I couldn't find the right way to articulate but you did the job.

I'm sure many of us want beauty, conciseness, and every other quality in our writings but it's 99% of the time a neverending rabbithole.

On side projects a little bit of quick'n'dirty is extremely valuable to progress in assembling the bits of a system and see it operate for real.

It's a hard balance because no one wants to come back and fix things later but the fact that you walked forward into building the system means you have more concrete knowledge of what is required and this will make it a lot more clearer and motivating to adjust and fix the previous modules.

There's also a different kind of pleasure involved. I can be proud of super clean code in a project that is never done.. but the feeling of having finished a tool that is actually useful is so much nicer. And it makes you want to keep doing it this way.

This is probably the best way to keep "motivation" up... and why I don't even start side projects. All of my "itches" can be scratched with existing products.

Wow, you are lucky!

So many products I use only get me 80% of the way there and I find myself wanting to make my own version.

The problem with this, for me, is that almost anything I want to do can either be accomplished with existing tools or is too complex for a doable side project.

I used to feel the same but in the last year I got sick of saying, "that sounds too big" and just started hacking. By focusing on small bits at a time I've been surprised at how far I've gotten. I'd encourage you reevaluate what's too complex. You might surprise yourself.

Funny, I usually go in the other direction. I'll find something to automate and I'll think, "That sounds buildable in a weekend," before realizing after the weekend that it would actually be a multi-week, sometimes multi-month effort.

I concur.

It especially helps motivate learning new tools. I find that if I want to learn a new tool, I look for something I'd want to do with it and use that to drive the project.

This comment really speaks to me as someone who just got a software project into a minimum-viable state after two years of this exact kind of off-and-on burst programming. I threw away several prototype approaches in that time and am left with something that should serve my needs for a long time without significant maintenance investment. It's nowhere near the most complicated thing I've ever written but is easily the thing I'm proudest of. I used to feel a lot more like the OP author, have only recently experienced what you describe, and really hope I can channel and maintain this as a way to avoid burnout and demotivation.

Yeah! This is also the same advice I discovered for open source contributions. Browsing for a cool-looking project on GitHub is nowhere near as motivating as a breaking bug as you start working with a library, haha.

That's a great call.

I often get into side projects that start from "it would be cool if this exists", but, if I actually think about it, I have no interest in them beyond yeeting them off into this vague coolness.

Reply on news.ycombinator.com