joshclarkson.net

The tedious tasks are not always the low hanging fruit. The reason tedious tasks persist is that the water is muddy. Our vision is blurry. Our view is cloudy. However the underlying truths in solving all tasks still remain. Namely that seeing the real problems, finding discreet steps, exploring unconventional options, and persistence in breaking your own mental barriers is required.

Many problems that you will face in trying to bring efficiency to the world through web technologies will be issues of vision. That old proverb: “Where there is no vision, the people perish” holds truth for our everyday lives. If you do not take the time to see the problem, no matter how hard you try to spin your wheels, the result is epic fail.

I’m reminded of a story I read about Taiichi Ohno, the famous Toyota exec, where he would draw a circle on the shop floor and ask his employees to stand in the circle and watch the process for hours with an eye for improvement. When was the last time you watched a user of your applications in the wild? Just sit and watch them use it. Take more time than you normally would to observe each action. Try not to interfere — just observe. Catch a vision of the frustrations, the problems, the effects of the application in it’s current state. Before you even start thinking about solutions, make sure you fully understand the problem.

How many horrible UI implementations were because some designer didn’t ask if his improvement would be beneficial to a process, but just added it because it was another bell or whistle? For all your work you could be making things worse! Now once you have sufficiently observed (and have you really?). Let’s think about solving problems.

Another key to tedium-busting programming is the ability to find workable discreet steps. A summary of the problem you are trying to solve that is divided into actionable steps. If you cannot act, you are paralyzed. When you eat a steak you cannot merely absorb the entire steak, but must first cut the steak into manageable bite-sized pieces that may then be chewed and swallowed. Follow the old adage; “Don’t bite off more than you can chew”. If you wish to accomplish great things with your programs you must continually divide your work into bite-sized pieces. Segments that are within your ability. Actions like: “search google”, call a friend”, “read some of my old code”, “write a unit test”, “solve this error message”, etc., are the kind of pieces of work you need to isolate.

Exploring the unconventional approaches are how great leaps forward are found, and where in programming your creative side may be unleashed. When I say to explore these ideas I mean an inner mental exploration as well as a physical fleshed out exploration. Imagine your fantasy solution, how it would work, how it would behave. And the ways in which the world might be changed forever by your unique approach to a problem. I find using a whiteboard and running my ideas past the Rubber Ducky are great ways to reflect on these ideas when you are working solo.

With all of this we still tend to get bound up in the old ways we’ve always done things. The status quo gets us, especially when the direction that is necessary to take can be much more difficult. That’s why sometimes breaking your own rules about how you work, in a deep and meaningful way, is the only way to have a breakthrough. Do you always write things out on a legal pad while you’re sitting at your desk? Take it outside. Get a big sheet of butcher paper. Do you ever just write some throwaway code that no one will ever see? Are you caught up in syntax? Whip up some pseudo-code. Breaking your own rules can be an excellent way to say “NO!” to mediocrity.

I’ll finish this by exhorting you to challenge your own willingness to innovate. Is it enough?