Making goals and achieving them - overcoming adversity to gain something you want - is tremendously motivating and often rewarding in life. Still, there are often times you extend so much effort in focusing on the goal that you don't notice the journey, or worse: you make the journey downright unpleasant.
That's the discussion in this week's chapter from
Chad Fowler's MJWTI.
The point revolves around the fact that hitting the goal is short-lived, while the process of getting there takes up the bulk of the time. Therefore, wouldn't it be better to view the process as the goal itself, and make that the enjoyable part?
My view diverges from Chad's here. Whereas he implies that this observation is a better way to live generally, I tend to think it applies to particular people doing particular things. For instance, I might agree that, in general, the US is "a nation of people who are always focused on the
outcome of a process," I wouldn't agree that it's "one of America's biggest problems" (Quoting Chad Fowler, pg. 156). Still, I might be more inclined to think that people's choice of goals doesn't line up with my own.
Regardless of the small divergence of our beliefs about the theory
in general, I
do agree that it works for software development. I'm not talking about doing software development as a means to achieve fame, fortune, girls, and cars (or just as a means to do something else with your life). For the production of software as a means to reach goals (including some where the path is the goal), I agree with
Zed Shaw:
I've been saying for years that you can live a life involving code and hacking as a cultural phenomenon, but you can't live a life that only has code. You can work and make money doing web programming, but you can't make a life out if it. I try fill my mind and experiences with other shit, and then use code as one of many ways to express myself.
Those kinds of goals are rewarding long after you've achieved them. Memories last until you forget them, and you can drive that Ferrari convertible up and down the Pacific Coast Highway until it falls apart.
But if you're talking about finishing a project as the goal, then you're likely to put yourself in a lot of pain during the journey.
Back to the software development example, it's easy to get wrapped up
in the delivery of the code you are creating. Your customer needs a web
application up, and you focus on finishing that application. But, a living
application is never "done." One release leads to the next. Too much focus
on the end product distracts us from the real deliverable: the sustainable
development of a new entity.
Focusing on the ending makes you forget to
make the process good. And, bad processes
create bad products. The product might meet
its minimum requirements, but its insides will
be ugly. You've optimized for the short-term end goal -- not for the
inevitable, ongoing, future of the product's development.
Not only do bad processes make bad products, but bad products make bad
processes. Once you have one of these products that is messy inside, your
processes adapt around it. Your product's broken windows lead to broken
windows in your process. It's a vicious cycle.
Sound familiar?
It does to me. A focus on a ridiculously short promised delivery date leads to no tests leads to coupled code modules and "quick and dirty" hacks in the code. That leads to an inability to test and more hacks in maintenance. And the cycle continues.
Wouldn't it be better to treat the process of making applications as the goal to be enjoyed, rather than masochistically torturing yourself?
What's your experience like? Are you more likely to treat the end as the goal or the path? Which works better for you?
Hey! Why don't you make your life easier and subscribe to the full post
or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate
wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!
Leave a comment
There are no comments for this entry yet.
Leave a comment
