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!