Friday, November 25, 2011

Programming and Problem Solving

We all know someone who sort of freaks out when presented with a large problem.

Me, I tend to get frazzled by the small stuff. Today I spent an hour and a half trying to figure out what towel rack to get for my bathroom. In one of my four (yes, four) trips to Home Depot today I returned two different towel racks. I haven't installed the last one yet - so there may be another trip around the corner.

On the big stuff I don't tend to fret as much. As long as I can remember it's been this way. It wasn't until this last year as I started Aunt Bertha did I start thinking about why that is.

Before developing our website I hadn't written code for almost seven years. I stopped after my first year of graduate school. I even gave away my Java books to a friend, thinking I'd never need them again.

When I realized it would be up to me to build the site, I was in for a rude awakening. Time has a way of making us forget about the tough stuff. We remember when things work but we forget about the long nights, cross-browser frustrations and the bugs we just can't figure out. We think we were the Harlem Globetrotters when in reality, 80% of the time, we felt like the Washington Generals.

Having written code for several months this year I started thinking about the relationship between programming and solving real-life problems. I think there's a relationship. In fact, I think it's the same mental process if we're doing it right.

Why didn't my code work? Why didn't I get that promotion?

Let's dig into what goes through my mind when my code doesn't work (this happens a lot).

---

"Why am I such a loser?" - Erine asks.

"It has to work. This doesn't make any sense. When did it stop working?" - Erine's Alter-Ego (EAE) responded.

"Hmmm. It did work through this point,"  Erine responded.

"Okay. Well, let's dig in a bit further. What is the next thing that the code tried to do right after the last time it worked," said EAE.

"The code tried to look something up," Erine said.

"Okay, where did you look that up? Specifically," responded EAE.

"It was a web service that will return the data that I need to get," said Erine.

"Well, let's see if it got the data back," EAE then investigated a bit further. "Hmm, turns out that there's nothing being returned from the web service. Let's see why."

"Oh, okay. That service should be really simple. Maybe it's down for some reason," Erine said. "Maybe I'm not such a loser after all."

(repeat 10 minutes later)

---
You get the idea. I don't think I'm going too far out on a limb by saying that 20% of a programmer's time is spent creating and 80% is spent debugging. That means that a full-time programmer will spend at least 30 hours a week fixing things (assuming they only work 40, but we all know they tend to work much more than that).

That's a lot of practice solving problems. I wonder if programmers, because they do it all the time, are generally good problem solvers.

We may not be writing code, but we can get better at solving problems. Sometimes asking why a few more times is all it takes to better understand what broke down. What was working before things went wrong? Then think about it. Break it down. There may just be some small thing you missed and at least you'll know what to fix next time.

Now, if you'll excuse me, I have to go try and install that towel rack. Wish me luck.



No comments:

Post a Comment