My Pumpkin Can See

Since my kids are pretty young, when it comes to carving the pumpkin, they do the "drawing" and I do the "carving." I think it has to do with all that "gunk" inside...that, or the sharp knife thing.

Well, I was working on one of them while my daughter looked on, making sure that I "did it right." Of course, I wasn't, because she told me so. You see, carving circles in a pumpkin, especially small ones, is *really* hard. I didn't have a professional pumpkin cutter (you know, those cute little orange-handled things that work like a saw), so all I could do was carve straight lines, and then "adjust" things to make it look more like a circle.

Of course, my daughter noticed that my cuts weren't going to work, since they were "straight" and she wanted "round." I had to explain to her that I was getting there, that they would look like circles when I was done. She didn't believe me, because she couldn't "see" it.

It reminded me of sculptures. You know, those artists who can take a rough piece of wood, whittle it down into a masterpiece, and you've no clue what they're working on until they're nearly done. You just can't see what it is that they see.

I feel like that happens with programming. Sometimes, it's difficult for others to "see" what it is that you're trying to accomplish. It's hard to describe, but you know what you're trying to do. You just have to show them the end results and hope they appreciate what it took to get there. The perception is that it shouldn't be that hard, because it's just a simple web site, or a simple GUI, or something like that. They could probably do it in a couple of days, while you're claiming it'll take weeks, if not months. They just don't appreciate what they can't see.

It's a good thing my pumpkin can now see, 'cause otherwise, my daughter would have made me buy her a new pumpkin and start all over. I don't like the "gunk," either.

It's All About the Fundamentals

I was out shooting around at the basketball hoop in my driveway and noticed how poor my shooting had become. I used to play quite a bit of basketball, and though I never considered myself all that great, I certainly kept up. However, I've not played seriously for many years (kids'll do that to you), and it was obviously showing in my performance that day (luckily, no one was watching).

So, what did I do? Other than lament for the "good old days," I stopped and paid attention to what I was doing. I remembered learning all those fundamentals when I was a kid...how to hold the ball, how to release and follow through, etc. I'd not forgotten them, though my hands had.

And to my surprise, after some concentration, I was making noticeable improvement. Hey, I'm not so bad, after all! Of course, it wasn't like I was hitting every shot or anything, but my focus and concentration on the fundamentals had obviously helped.

And so I'm reminded of my own programming experience...those times when I've "walked away" from it, forgetting and losing my touch, only to return and, luckily, remembering the fundamentals and picking things back up. I'm reminded of watching struggling programmers who never learned the fundamentals, and how they struggled over issues that they would not have, had they stuck to the fundamentals. It's all about the fundamentals.

Solitary Sport, Team Play

Programming is typically viewed as a solitary sport. That is, programmers are sent off into a cube, given their tasks, and emerge when the work is done. Obviously, a team exists, and get-togethers are common (sometimes too common). In some of the more agile environments, programmers are teamed together in pairs.

Recently, I spent some time "away from home," starting a new job (with the family to follow). I found myself, alone, in a apartment, with my evenings unadorned of family things: dinner, play, or any of the typical family-related evening activities. Did I mention that I was alone?

Great, I thought, I'll have plenty of uninterrupted time to work on some projects. I had plenty to do, lots of time to do it, and absolutely no motivation to get started. I found out something very interesting: it's hard to get motivated when you're the only one in the room (or whole apartment, in this case). I've not worked as a sole programmer on a project, so I'm not sure how they get motivated. However, I realized how important it is to put a team together and keep them together. They play off each other; they require each other to be "near" (even though they may not constantly communicate); we are a social animal, even when we work.

Watching the World Go By

I typically work while I eat my lunch. So, there I was, sitting at the restaurant eating lunch, working on something or another for work. As I like to do while I'm eating lunch in this way, I look up and watch...I watch people, things, and generally let my mind wander a little. I've discovered that this is an amazing thing.

You see, I remember watching Dead Poet's Society with Robin Williams. He was an English teacher, and one day, he had the entire class climb up on his desk (one at a time, of course), take a quick look around, and then jump down. The idea was to give them a different perspective on life. It's about taking the time to see what's going on around us. It's also about seeing things from a different perspective.

That's why I like to move around while I do my work. Since much of my work requires considerable thinking, it's important that I give my subconscious mind the time it needs to sort things out. And I've found that when I "wander," I'm able to see things differently. Sometimes, that makes all the difference.

Programming is a thinking-man's game. It requires deep and focused thought. And, I believe, it also requires variation, perspective, and time.

The Snowfort

This past winter, I was out in the snow playing with my kids. We were building a snowfort. My wife had come up with a great idea on how to go about it: use some small tubs to pack the snow into and up-end them as "snow bricks." So, there we were, up-ending our tubs of snow and stacking our "bricks" to make a snowfort.

Then I realized a problem: the brick idea was great, but there wasn't anything holding the bricks together. Not being a mason, I hadn't put a whole lot of thought into our structure. However, it became fairly obvious to me after we'd put up several rows of bricks that we needed some mortar. So, I switched everyone to stuffing snow in the cracks.

Once caught up with mortar, I went back to bricks. However, a couple of my kids kept at the mortar work. With so many on the mortar, the brick building was going slowly (I'm getting old). Hence, I asked my "mortar" kids to help with the bricks. They refused: it was too hard of work and they kept at the mortar work.

I got to thinking about this impasse: they didn't want to help with the bricks, but that was the whole point of the exercise, to build bricks and build the snow fort. The mortar was certainly necessary, but didn't require all the extra time they were putting into it (though the snowfort was definitely solid, given the amount of mortar they were putting in).

In building software, it's important to add the "filler" to make sure things run smoothly (the development methodology and its related practices), but if you concentrate too much on it, you lose focus on what you're doing: writing code. Writing code is hard work, but it's the fundamental aspect of producing an application. The "mortar" of software development helps to keep it together (and keeps it from falling to pieces), but there's a limit to what help it can provide.

Of course, given our poor choice of location, all the mortar in the world wasn't going to help us when the sun came out. If we'd been at the North Pole, we'd have been okay.