As a computer scientist, I tend to think of everything in terms of computer science. It was only a matter of time before I tried to apply a software development methodology to my life.
When I was in college, one of my favorite pastimes was to sit on the porch and stare up at the trees, looking at the leaves and trying to figure out the point of life. I had left high school certain that I wanted to be a musician, but after a year of studying, I struggled to figure out my future plans. I felt that though I was capable of much, I was achieving little. Not shockingly, I ended up feeling pretty down at times. I would write poetry about the colorless existence out there, and how we’re swirling around in the darkness, and so on.
Throughout this, I was trying to figure out “what I wanted to do with my life”. By the time I made it to the end of senior year, I had decided that this was a stupid question. Things probably wouldn’t go as expected anyways, I’d say, so no use in planning further ahead than a few years, right?
I’m starting to think I was onto something — but in a way that was not yet formalized, and easier said than done. I managed to follow my own advice for the time being — I asked myself “what do I know I want to do”, and decided to do a master’s in machine learning in Europe and figure out how I felt after that.
That worked pretty well for me. I enjoyed my time in Europe, learned that I wanted to work at the crossroads of machine learning and distributed systems, and found myself a nice job doing almost exactly what I wanted to do in Cambridge, MA.
After a year and a half of working, here we are. Though I still enjoy work, I’m considering that I might enjoy a more sustained structure to my free time. Thus far I’ve managed to fill it with a variety of pleasant activities — hanging out with friends, taking improv classes, and so on. But still, beginning a few weeks ago, I started to feel that I was lacking direction. I needed some better system for self-improvement and deciding what to do with my time.
So, I called my good friend Ryan, a fellow software engineer and musician. After catching up for a bit on life in general, I explained how I was feeling.
I mentioned that I wanted a better way to decide what to do in my free time, and that I missed having a long-term life goal like I did when I first started college. I explained my current approach to life: that I should simply exist, do, enjoy things, and that eventually if something good and productive comes of that (as I think that it will), so be it. If not, it’s not a huge deal. I said that I think it’s good to plan in advance a little bit, and to consider what skills I should improve on if I want to be well-prepared for my next endeavor, but that I don’t really know what’s beyond that — but that in spite of these beliefs, I still feel a desire to work towards something specific, something greater, something long-term that I can pursue with passion and direction.
In the back of my mind, an analogy was forming, but Ryan fortunately beat me to the punch. “It kind of reminds me of the difference between agile and waterfall development, actually”, he said, followed by a “Eureka!” of sorts on my end.
For the non-software-y people out there, waterfall and agile are different styles of project management that evolved for software projects (though they can certainly be applied to other kinds of projects as well). The waterfall approach is a more standard, old school approach — create a plan for the development of the project many months or even years out, spend a long time developing the product, then once an initial version is ready, test it, then go back and fix issues, repeat, and finally ship the project.
The agile methodology was born out of the realization that the waterfall approach was overly rigid, and not particularly well suited to the development of software. Things would rarely go exactly as planned; issues were discovered way too far into the process; too much time was spent on things that users might never want or need. Some smart people declared in the usual manner, “There must be a better way!” The word agile enters the name because the agile methodology is all about agility and adaptation.
There are many flavors of agile development, but the main ideas are these:
- Software evolves organically and with constant feedback from the user or customer
- Features are developed in one week to one month periods known as sprints
- Long-term planning is relatively loose and open-ended
- Testing is done throughout development
The overall goal of a piece of software must be known to some degree before starting its development, obviously; but the idea of agile is to take into account the inevitability of change in the process. This approach has been shown to be quite effective in software development. It deals better with change; timelines are more realistic; poor lines of development are stopped in their tracks before too much time is wasted; it produces a result that people actually want (with some degree of confidence, anyways).
And, I think, this might not be such a bad approach to life. Consider the following example:
A month or so ago, I realized that I was constantly rushing to fill the gaps in my day with stimulation; in particular, by looking at my phone whenever there was an opportunity to do so. With all this overstimulation, I started to feel fed up and burnt out. I came to the conclusion that I was frying my brain and that I needed to allow some small gaps for myself and relieve myself of the iPhone for a few days. I decided I’d try leaving my phone at home during the day for a few days. I warned my parents and a friend or two not to expect immediate responses from me.
At first, I felt like an addict going through withdrawals, reaching for my pocket only to realize my phone was missing; but after a few days, though I’d still check for my phone often, I found myself winding down. When I’d go home I’d look at it briefly and proceed to do other things. I felt the humanity in me returning, and felt relaxed. I was already less addicted, more focused, and more present with my surroundings.
With the ‘agile approach to life’, thinking of myself as a product, I might have thought about it in the following way:
- Bug: I use my phone too much and feel overstimulated
- Sprint length: 1 week
- Fix: Leave my phone at home for two days while I go out. Then, keep my phone turned off entirely while at work, and don’t use it until after I get home
- Acceptance criteria: Feeling more relaxed and focused and less overstimulated, looking at my phone less often when it is on, and being more aware of my phone usage
If, when the sprint ends, my acceptance criteria are met, I can consider how I might integrate that habit or ‘fix’ into my life in general. In this case, I’ve continued to leave my phone off during work, and I essentially turn it on only when I need to make plans. I check it first thing in the morning and at night I browse Facebook, the news, etc., but don’t spend much time on it. This example was formulated as an agile sprint in retrospect, but since the first draft of this essay I’ve completed several sprints successfully. These are described in more detail after the end of the essay.
We could consider a similar process with ‘features’ as well, like “Reads fiction on a regular basis” or “Completes a side project”, or other bugs like “Doesn’t wake up at the same time to go to work every day”. These could each involve multiple sprints with subtasks as well, but I think it’s best to start with things that can fit into 1–2 week sprints. This encourages me to focus on one goal at a time. At work, I’d never say “I think these 10 features would be good, I’ll do them all at once.” In life, however, I tend to have bursts of motivation where I think, “Okay, this week I can achieve my perfect schedule, doing x, y, z, p, q, and r every single day,” which isn’t really feasible. With 1–2 week sprints, I can prioritize and focus on one thing at a time, which is much more reasonable. And if I really wanted to be cheesy, I could have a policy for self-versioning… but I don’t know if I could take myself seriously as “Matthew v2.0”.
It’s natural to desire the waterfall approach to things. You set up a goal at the beginning. You make a plan, that in theory you’ll steadily execute until completion, which is, of course, comforting. It’s nice to have a plan. In the end, you’ll have a product, be happy, and make millions and millions of dollars and people will call you a unicorn, and give you the Nobel Peace Prize and the Turing award while you’re at it. In theory.
The problem, in software as in life, is that this approach sets you up for disappointment. Things don’t go as planned. External factors intervene. You take longer than expected to do something you thought was simple. The goal you started with turns out to be something that nobody wanted. At the end you arrive, having learned a lot (hopefully), and having produced something (hopefully), but with a lot of pain, stress, and uncertainty in the middle, and when the product pops out, it may not be what you wanted it to be.
So, finally, we end up with a formalization of the ideas I’ve developed over the years, with which I intend to experiment for the foreseeable future — the agile approach to life. Change is inevitable — I know that — in myself, in my beliefs, in the job market, and so on. That’s okay. I can build that into the process. If I read a book for a week and then decide to ditch it — so be it. It turned out not to be so well aligned with the purpose of the end product (that is, me).
I don’t have to have a plan now. I can take it one or two weeks, or even a month, at a time. And there we have it: a freedom to do, within the comfort and the structure of a framework that accounts for change. And if the agile approach to life doesn’t work out? So what? That’s part of the process.
Additional Examples
The phone example I gave before was applied in retrospect, but since the first draft of my essay, I’ve also used this process successfully in two other endeavors.
Example 1:
- Bug: I’ve been lazy about going out and don’t like to commit to things in advance
- Sprint length: 2 weeks
- Fix: Say yes to going out whenever someone asks me for these two weeks
- Acceptance criteria: Feeling less hesitation when someone asks me to do something or commit to something in advance. Realizing that it usually isn’t a big deal and is worth doing even if I might be tired at the time
This sprint was a success. I participated in several things that I didn’t feel like doing at the time or when accepting the invitation, that ended up being valuable experiences. I won’t continue accepting every invitation I’m offered, but I’m finding it easier to say yes, and I’ll be less likely to refuse unless I have a good reason.
Example 2:
- Feature: I want to have read The Unbearable Lightness of Being by Milan Kundera
- Sprint length: 2 weeks
- Fix: Read the book during my free time
- Acceptance criteria: Having read the book
I finished the book in a week and a half. Being a simple task, this one is very easy to formulate. But still, just thinking of it in terms of a sprint with a short timeline made it easy for me to stay on track. Since this was my only task-based sprint at the time, I used it as a guide for what to do during my free time. I didn’t necessarily set aside specific time to read, but whenever I had time that I wasn’t doing anything, I would read the book instead of doing whatever I might normally do, like watch TV or skip from article to article online. Each week I’ve been thinking “What sprints am I on this week? What do I need to have done by the end of this week?” and I’ve managed to stick to only doing two sprints at a time. Only doing two at a time has helped the goals seem realistic and has kept me from exhausting my willpower trying to do too many new things at once. I’m also beginning to like the pattern of having one personal, behavior-based goal (like accepting all invitations I’m offered), and one task-based goal. Behavior-based goals take up willpower but not necessarily time, whereas task-based goals give me something specific to do when I’m alone with free time.
Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.
To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!
