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 that I wanted to be a musician, but after a year of studying, I struggled to figure out my 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. certain future 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 I want to do”, and decided to do a master’s in machine in Europe and figure out how I felt after that. know learning 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 enters the name because the agile methodology is all about agility and adaptation. agile 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 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). take into account the inevitability of change 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’, , I might have thought about it in the following way: thinking of myself as a product I use my phone too much and feel overstimulated Bug: 1 week Sprint length: 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 Fix: 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 Acceptance criteria: 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 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 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. 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). That’s okay. I can build that into the process. 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 , 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. do 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: I’ve been lazy about going out and don’t like to commit to things in advance Bug: 2 weeks Sprint length: Say yes to going out whenever someone asks me for these two weeks Fix: 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 Acceptance criteria: 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: I want to have read by Milan Kundera Feature: The Unbearable Lightness of Being 2 weeks Sprint length: Read the book during my free time Fix: Having read the book Acceptance criteria: 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. is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising & sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories

Facebook

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

An Agile Approach to Life

Too Long; Didn't Read

Company Mentioned

Matthew Saltz

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

An Agile Approach to Life

Too Long; Didn't Read

Company Mentioned

Matthew Saltz

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES