Projects as Lost Purposes

  • Understanding what the attribute `action` means in the `<form>` tag.
  • Knowing what a race condition is.
  • Being able to use CSS to underline all links.
  • Knowing how to use `ngBind` to prevent the “flicker problem” in AngularJS.
  • Knowing how to use `ngCloak` to prevent the “flicker problem” in AngularJS.

As a software developer, there are all of these check boxes to check off. The more you’ve checked off, the better you are.

And so if you’re trying to improve as a developer, you should aim to check off the unchecked boxes.

(Perhaps they’re sliders, not check boxes. I see sliders as composed of check boxes, but regardless, the same points apply.)

I see two broad ways of working towards this goal:

  1. Passive: do projects and hope you come across unchecked boxes along the way.
  2. Deliberate: seek out unchecked boxes, get your questions answered, and practice until you fully understand.

Example: I don’t have a great understanding of:

  • What race conditions are.
  • Why they’re so problematic.
  • What some common scenarios that cause them are.
  • What the approaches are for handling them.
  • What the costs and benefits are for each approach.


  • Wait until I come across a race condition in a project I’m working on.
  • Hack together a bad solution.
  • Once the bad solution causes problems, spend some time learning about race conditions and researching a solution.
  • Not deal with race conditions for a while, because I haven’t come across one again.
  • Traverse along the forgetting curve.
  • Later on, come across a new race condition, and start the process all over again.


  • Research and learn about what race conditions are.
  • Set up an exercise for myself that eliminates extraneous stuff and focuses on race conditions. That way I’m focusing on one thing at a time. Along the lines of
  • Repeat the second bullet point a few times. Changing it up and introducing some complexity each time.
  • Perhaps use the Feynman Technique (explain it to someone else/rubber duck) to really reinforce what I’ve learned.
  • Use spaced repetition to make sure I don’t forget what I’ve learned!

Ok, I was a little bit hard on the passive approach. My main points were that:

  1. It’s important to seek out these unchecked boxes.
  2. It’s important to take the time to research and learn.
  3. It’s important to encounter spaced repetition, so you don’t forget what you’ve learned.

These things often happen naturally with the passive approach. You take on hard projects and push you to learn new things. When you encounter things you don’t know, you research them. Because you’re pushing yourself, you happen to encounter these things over and over again, which is a form of spaced repetition, and it allows you to really solidify your understanding.

Personally, I take a very deliberate approach, but I’ve accepted that the passive approach could be effective as well.

I understand that a lot of people find the project-driven nature of the passive approach to be fun, and thus motivating. Motivation is important, so if you’re motivated by the passive approach but not by the deliberate approach, then that’s an important thing to consider.

What scares me about the passive approach is that it has the potential to go wrong. Very wrong.

If your goal is to learn, then you need to find the unchecked boxes and check them off. If you’re not pushing yourself to a) learn new things and b) reinforce things you’ve recently learned, then you aren’t going to make progress towards your goal of learning. With the passive approach, people often get caught up with shiny features and forget to pursue a) and b). That’s where things go wrong.

I think people often forget that learning is their goal and start treating the success of the project itself (ex. shiny features) as their goal. Writing CSS to make your feature shiny might be tempting, but if you’ve already written similar code ten thousand times, then you aren’t really learning from it. When you forget what your goal is and instead end up working towards a different goal, it’s called a Lost Purpose.

To me, this is shortsighted. When you’re a novice, it’s unlikely that you produce something that is actually valuable. Your project is going to get trashed and forgotten about. If your goal is to produce things that are actually valuable, it’s a two step process:

  1. Develop skills.
  2. Build things.

I understand that it’s cool to produce shiny features; it feels awesome. And yeah, it’s ok to indulge in that a bit. But it’s important to keep the big picture in mind. If you want to produce things that are truly valuable, you first need to develop the skills. And if you want to develop the skills, sometimes you have to ignore shinny features and focus on the check boxes.