We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

How to Start a Solo Project that You'll Stick With

00:00

Formal Metadata

Title
How to Start a Solo Project that You'll Stick With
Title of Series
Number of Parts
10
Author
License
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Have you ever started a solo project that never really came together? Been able to write something up in a weekend but dropped it soon after? Me too! In this talk I go over how I was able to break from that and build my first CLI tool, written in Rust. Drawing from an understanding of habit formation, we’ll examine how to plan projects in a way that keeps you fulfilled and stops you from veering off track.
RhombusComputer fontMusical ensembleJSONXMLComputer animation
Musical ensembleTwitterSoftwareSoftware engineeringMeeting/Interview
DemosceneFrame problemGeneric programmingStreaming mediaMeeting/Interview
Multiplication signException handlingPoint (geometry)Computer programmingQuicksortRight angleMeeting/Interview
Perfect groupTerm (mathematics)Computer networkLine (geometry)SoftwareOnline helpMetropolitan area networkRootSingle-precision floating-point formatFamilyNetwork topologyQuicksortDirectory serviceWeb applicationoutputMultiplication signPoint (geometry)Software testingType theoryWeb 2.0Server (computing)Computer programmingSoftware developerState of matterOcean currentDiagramCartesian coordinate systemPhysical systemFormal languageFluid staticsBitPower (physics)Data miningInheritance (object-oriented programming)Musical ensembleHome pageSheaf (mathematics)WebsiteFront and back endsGUI widgetMessage passingMeeting/Interview
Image resolutionGUI widgetActive contour modelRevision controlImage resolutionGame controllerOnline helpDisk read-and-write headReflection (mathematics)Inheritance (object-oriented programming)BitSoftware engineeringTranslation (relic)Hecke operatorFile formatMobile appRootSoftwareMoment (mathematics)Meeting/Interview
Event horizonPlanningGroup actionObservational studyWater vaporForm (programming)Order (biology)Inheritance (object-oriented programming)MathematicsImplementationInformation technology consultingType theoryData managementFrequencyContext awarenessMultiplication signBuildingTable (information)Sound effectBitFigurate numberIntegrated development environmentEvent horizonCodeGroup actionDecision theoryText editorFrustrationTask (computing)SoftwareObservational studyFile formatAdditionPerspective (visual)Online helpReliefComputer programmingPlastikkarteNeuroinformatikSoftware testingDistanceBuffer overflowNumberMusical ensembleTraverse (surveying)Stack (abstract data type)Interactive televisionNetwork topologyRight angleSet (mathematics)Latent heatComputer animationMeeting/Interview
Latent heatPlastikkarteIntegrated development environmentComputer programmingMultiplication signLevel (video gaming)AuthenticationLimit (category theory)TrailQuicksortAdditionArithmetic meanLaptopAttribute grammarSoftware bugFrustrationPhysical systemNumberType theoryElectronic mailing listServer (computing)INTEGRALWeb applicationTask (computing)Data structureRun time (program lifecycle phase)MeasurementArithmetic progressionNetwork topologyoutputRootLatent heatPrototypeFormal languageProduct (business)Numbering schemePlastikkarteFluid staticsParsingCASE <Informatik>NP-hardDomain nameStress (mechanics)DampingCodeRoutingPrice indexMeeting/Interview
Broadcast programmingFreewareBuildingProcess (computing)Presentation of a groupComputer programmingSoftwareObservational studyTwitterWebsiteInheritance (object-oriented programming)Multiplication signScheduling (computing)Level (video gaming)ResultantComputer animationMeeting/Interview
Transcript: English(auto-generated)
Hi, I'm Harrison Bachrach. I typically say I'm a software engineer during introductions,
but chances are high that you're a software engineer, too. So I guess I bake, but I guess everyone is baking right now. So to clarify, I bake challah. Here's some challah before it's edible, and here's some challah while it's edible. If you haven't heard of challah, it's like that scene at the end of Tangled where all the kids get together
and braid Rapunzel's hair so it's not dragging everywhere, but unlike hair, it's not gluten-free. I actually had a frame from Tangled in here, but I was worried about the stream being taken down, so that's why you have some generic stock footage. So if you're like me, you've probably gotten really passionate
about programming at some point for some reason and wanted to do a side project. Cool, me too. Happens to me all the time. And things always kind of fall apart, right? First, you have an idea. A lot of us are spending a lot of time indoors all of a sudden. So what if you were to start an indoor plant collection?
Except if you're like me, you forget to water these things or forget which plant needs what sort of light, and all of a sudden you go from this to this. Don't think anyone needs this kind of vibe in their home right now. So can software help? I mean, let's be real, probably not.
Software can be pretty bad, but hey, maybe. You know, I've been looking to make something in my spare time. I'm primarily a front-end developer, but I've been hearing about Rust web server projects like Actix and Rocket. Maybe I can make a web app or something. Yeah, yeah. You'll be able to upload pictures of your plants over time. You'll be able to give them names.
It'll tell you when they need to be watered, which soil type they need and where to find that soil. Tons of features, great. So you get started and work on it until 3 a.m. and you get us to the point where you can create a plant and you deploy it to Heroku and the automated tests run on push and some time passes.
And now that thing that was so much fun for an evening is a stub of a program and you've lost all interest or enthusiasm. So I feel like this is probably a familiar experience for a lot of you. It's a very familiar experience for me. So what happened? We're gonna come back to that at the end of this talk,
but first let's talk a little bit about Rust. I forget how I found out about Rust, but I was intrigued as soon as I got the pitch. I really like powerful static type systems, which is funny because all of the languages I use daily are dynamically typed. Though maybe I've just been burned too many times by my own silly mistakes, who knows?
So I'd read the Rust book a few times before off and on, but I had never really made anything with it, partly because I didn't know how to start and partly because I was intimidated. But eventually I saw how easy it was to make command line applications and that got me working in my first Rust program, Root. Side note, thanks to all the people
who made this section of the site about what to make with Rust. I went to the homepage for the first time about a year after initially being introduced to Rust, not knowing what to actually build. And I found this information super useful getting up and running on my first project. Right, so this is about solo projects.
So let's talk about the solo project of mine that actually worked. Root, or if you wanna call it RUT, is a pretty straightforward program. Think of it like tree, but instead of directories and files, it works on data. For example, you can input some JSON that you might be using to represent a tree of some sort.
Here we have a root node with the name cool, a single child node with the name beans, and a single grandchild node with the name man. But that's kind of hard to see. So root takes that JSON and converts it into a diagram like this. Cool beans man. The reason I'm talking about root
is that it took almost two months to get it into its current state. If you're thinking, that's a long time to make a program to do that, I think you're right. I'm very much a beginner when it comes to Rust, and it's very possible that many of you could get this done in a single evening. Now I've done small one night projects before.
I made a widget for making digital flowers to send to people. I made a dumb two headed version of snake with terrible controls. And while both were fun, they fall into the same issues that come with their gardening app from earlier. I never came back to them. So after working on root for weeks and weeks, I started asking myself,
why did this project turn out differently? What was different? Well, it became a habit. For a lot of us, side projects are something that we want to do in the abstract, but have trouble doing in the moment. If you've ever come up with new year's resolutions and almost inevitably failed those resolutions, that concept might be familiar to you.
And that's probably most of you assuming you had any. So what goes into a successful habit? Firstly, you have to do it. Of course, that's a lot easier said than done. Now we're about to step into a big vat of psychology research. And I want to give a huge disclaimer that I'm a software engineer,
not a psychologist or a mental health professional. I'm also not a doctor nor a lawyer. And it's kind of a bummer because both of those careers are much easier to explain to your parents. So in prepping for this talk, I read this paper called Promoting Habit Formation. And in it, I found this super academic sounding quote,
intentions to act are significant precursors of initiation of behavior, but intention translation is imperfect. What the heck does that mean? Well, just because you want to do something and you know that that thing that, and you know that you want that thing to be done, doesn't mean that you'll actually do it
when the opportunity arrives. There are a lot of reasons why people abandon projects, but a major one is not feeling satisfied. Now, this may seem silly to say out loud, but how satisfied you feel by working on a project is a big factor in whether or not you'll stick with it. If building your project isn't satisfying,
you might want to reflect on that for a bit. Why did you think it would be satisfying? If it was satisfying before, what changed? Not every minute is going to be super fun, of course, but if it feels really dull for a while, it may make sense to step back and consider how to address that, or how to move on to something that might be more satisfying for you.
One thing to note here is that you can encourage your satisfaction. You may not think about how much you improve on a skill while working on a project, but that reflection can be super uplifting and help you see value in the work that you've already done. Now, it all starts with a good goal. What do you want to do? You'll often come up with a simple goal at first
when starting a new project. You might write it down or just have it in your head, but the work between you and your goal may grow. This is often how things get unsatisfying. No longer feels like the work that you're doing is actually progressing you towards that goal, which is the thing that got you into this into the first place.
Coming up with unrealistic goals is really easy. For example, aiming to catch all Pokemon is a ludicrous goal to start out with. Now, I feel bad for making fun of a child, but Ash Ketchum is an absolute fool. Do you know how many kinds of Pokemon there are?
Almost 900. So let's say we have some realistic goal. How do we make sure we actually do the work? One common idea in habit formation is something called automaticity, which is basically the act of doing something automatically without meaning to do it or even being aware of it. For example, for some of you,
flossing your teeth is often an automatic action that you don't actively plan out or think about. Now, you probably can't write code as unconsciously as you can floss your teeth, but you can start that way. That is, you can't write a test without thinking about it, but you can sit down in front of your computer and open up your editor pretty automatically.
So when should you work on your project? It's very common to pick a fixed time to start working on something. For example, I will go to the computer at 7 p.m. But fixed times aren't really how we structure a lot of our day. Instead, our day is broken up by events into periods of activity. You take a shower, you clean up the table, you finish eating dinner.
The gaps between these periods are really significant and tend to stick in your mind much better. These are the times to schedule working on your project. But when those events happen, what do you do? Even when you remember to work on a project, starting can be daunting. In order to make a habit, having a plan helps a lot. The research is pretty clear here.
There's one type of plan that's super helpful called implementation intentions. However, that name is a pain to say, so I'm just gonna call them if-then plans. They have a form like this. If I encounter X, then I will do Y in order to reach goal Z. Let's say you want to start a habit of drinking more water.
An if-then plan that might help is if I get out of bed in the morning, then I will fill my water bottle and put it on my desk. The idea is to get simple tasks into your routine so that the harder tasks, like remembering to drink throughout the day, get easier. For software projects, getting your environment set up, like opening up your editor and project tracker,
can make starting work a lot less scary. Now, in working on your habit, there are likely going to be some struggles, whether it's difficulty in building the habit in the first place, frustration when writing code, or uncertainty on how to make important architectural decisions. You can create what are called coping plans on how to deal with these issues when they crop up.
Research has found that coping plans, when applied to physical exercise, had a dramatic effect on the endurance of those habits. Of those in the study that made specific plans on when, where, and how to exercise, two months later, around 44% were still performing at least an hour and a half of exercise per week.
However, for those who had made coping plans, 71% were still working out that much. Forming concrete plans on how to deal with these roadblocks is super valuable for success, but also for mental health. There very well may be times when working on your project where you feel really useless or stupid, but these are neither accurate nor helpful thoughts.
Programming can be a really demoralizing hobby. Imposter syndrome is rife within our industry, and those feelings are often compounded for underrepresented engineers. I wasn't able to find much research on coping plans that might apply to side projects, but in my experience, these were super helpful. First, talk with people.
Talking with people, engineers, and non-engineers alike can be a huge relief and put things in perspective. And of course, it's fun. I think we could all use a little bit of fun right now. Secondly, find some nice communities online. In addition to being a great place to ask questions, people working on similar things can often understand your frustrations
in a deeply validating way. I've had a bunch of super great interactions on the Rust Discord, for example. That said, there are a lot of not nice communities online. I remember I asked a question on tree traversal on Stack Overflow, and the first comment was, stop doing this in Rust. Number three, just step away from the computer.
Oftentimes, all you need is a bit of distance from what you're working on to help clear your mind and relax you. Not only that, but I found that most of the time, I figure out a tricky problem when I'm washing dishes or about to fall asleep. Now, with all these suggestions, there's one thing that I'll advise against, and that is setting external rewards for yourself. Say, for a little extra dessert,
if you work a bit, a little bit longer. These have actually been shown to reduce intrinsic motivation. The risk is that the rewards can often become the goal in and of themselves, or that the rewards mean less and less over time. The rewards also tend to have less of an effect
if you have very high awareness of them, and we're talking about solo projects here, so that seems very likely. Now, there's a very common acronym, SMART, that is referenced a lot in articles on successful habit building and goal setting. It was initially introduced by this guy named George T. Doran, a consultant and director at the Washington Water Power Company,
in an article intended for managers on how to set corporate objectives, but since its introduction, the ideas have gone through a few changes that better align with personal goal setting for individuals. While they weren't derived from academic research, they are still a very useful tool that aligned with many of the conclusions from various studies on habit formation.
Anyway, what are SMART goals? A SMART goal is specific. It's very clear what the problem is, and if your project is intended to solve a problem. It's very clear what needs to get done or what you need to build. A SMART goal is measurable, meaning it should be clear what's required for it to be workable,
or how close it is to becoming workable. Notice I didn't say done, more on that later. A SMART goal is achievable. It's something that isn't too far outside the realm of possibility. I'd love to build a laptop from scratch, for example, but for me, that's not exactly realistic.
A SMART goal is relevant to you. It needs to be something that you care about, something that motivates you. It's something that's hard. It's really hard to put a lot of time into something that is not directly meaningful to you. Lastly, a SMART goal is time-bound. Now, in most invocations of SMART, this refers to a sort of due date, but that often doesn't apply to side projects.
It may never be truly done. Additionally, due dates often create unnecessary stress, and this is something that should be enjoyable. Instead, I'd like to think of time-bound as referring to your engagement with the project on a day-to-day level. Limit your habitual time instead of your total time.
So let's see how SMART connects to root. First, the initial goal was just to write a program that made drawing those tree diagrams from an easy-to-type input. The project expanded beyond that afterwards, of course, but the initial idea was very focused. As I went through adding features to root, I really only thought about everything
one small step at a time. This meant that as I wrote more code, the progress felt really real and was directly measurable. I could literally count the number of things that I had added. This sort of measurement elegantly translates to filing issues, creating tickets, or however you like to do task tracking. This can be as simple as a list of a piece of paper,
which is what I used, or it can be as sophisticated as an integration with GitHub issues or a Clubhouse project. Another natural way to measure progress is with semantic versioning, or whatever versioning scheme you might elect to use. Each release is a concrete indication of progress, whether it is a feature edition, a bug fix, or something else entirely.
Both ticket tracking and semantic versioning serve as reminders to recognize achievements that you made along the way, which is very easy to forget, especially when the intermediate product of your project doesn't feel very impressive. When I started planning root, I kept scope small. I wasn't gonna have any command line options.
It would do one thing and only one thing, and even that was too hard. Starting in Rust was so difficult that I had to make an initial prototype in Ruby, my primary language. Root as a project felt very useful to me. It came out of the very real issue that communicating the specifics of tree data structures is super hard.
I deal with trees a lot at work and talking about various corner cases with specific tree structures was always super challenging. In addition to the problem domain, root gave me the opportunity to learn about parsers as well as Rust, both of which I had been partially exposed to, but hadn't really been able to sink my teeth into. That prototype from earlier also aided the motivation
on continuing with Rust, as it showed that switching to Rust dropped the execution time from 200 milliseconds to five milliseconds. The static type system also caught a number of bugs that would have been a real pain later on. So when working on root, I would really only spend a few hours a night and only two to three nights a week. When I got stuck or frustrated on a problem,
I would give it a solid attempt, but if that wasn't enough, I would take a break or stop on it for the day. Typically I would continue thinking about the problem in the back of my mind and when I came back to it, my frustration was replaced with excitement and I would end up solving it very quickly, most of the time anyway. In addition to the smart attributes I just mentioned,
I found a few other things really, really helpful. Showing what I was working on to other people was very encouraging, even when they weren't super impressed. It still made what I had made more real to me. Celebrating victory has also made the work more fun. For example, I tracked downloads on crates.io and I still very vividly remember passing 50 downloads
and being wowed that anyone else might find what I had made useful. So we're equipped to look at what happened earlier now with our gardening project. Firstly, the scope of the project just ballooned. What started as a way to track caring for plants became something much bigger.
Learning Rust is also a big challenge and creating a web application is no small feat. In addition to learning Rust, we also needed to create an authentication system. We needed to set up how to handle assets. We needed to deploy to some server. All of that takes time before we can get up and running. Working for all this hours sure was fun,
but it's not sustainable. You end up exhausted the next day and associating all of that exhaustion with all the work that kept you up. Also, one thing missing from the story is anyone else. No talking with friends to bounce ideas off of, no chatting online when running into roadblocks. Working alone is certainly possible, but it's a tough path to follow.
All of this is well and good, but I do need to point out a bunch of things because, well, I don't want people to yell at me. I fear being yelled at so much I even named my now abandoned, ultra depressing comic series Please Stop Yelling Online. Really? Anyway, asterisks.
Firstly, don't feel like after watching this talk that you ought to do a programming side project. It's not for everyone. It's not even for me a lot of the time. That's okay. You can have other hobbies. I imagine a good deal of you write software for your job. If you don't want to bring that home, then don't. Another thing, right now we're living through a historic global pandemic
that has dramatically impacted most of our lives. Not only that, but people are becoming even more aware of the very present problem of police brutality against black people in America. As a result, you might feel demotivated to work on a side project right now. Even if you have tons and tons of free time, that's okay. Side projects are optional.
Also, you might follow this advice, start a project and abandon it. That's okay. This stuff isn't a silver bullet. No study about any of this stuff has 100% written anywhere. That doesn't say anything about you. Stuff happens. Lastly, again, please don't yell at me. I am very weak and I will be super sad.
So in conclusion, make a plan, not a schedule. Build something that you care about. Think small and be kind to yourself. I wanna thank everyone that was involved in setting up RustConf. I also wanna thank my parents as well as my partner, Anne-Marie. Everyone has been super helpful in getting this talk to this stage.
If you wanna follow me online, my website is holoscript.com. That's with a C-H. And my Twitter is harryb. So thank you. Thank you.