I was out walking with my wife and kids the other day, and we decided to take the "long" route. That means we walked more than a couple of minutes. In fact, it took us half an hour. Though the weather was nice, and company was great, I was pretty worn out by the time I got back. I knew I was out of shape, but it was pretty embarrassing. Apparently, I need to "get out" more.
I've been in a number of "architectural" roles during my career, and in each of these, I've done a range of coding. In some cases, I did a lot; in others, I did very little to none. I remember those times where I moved from a position of doing very little coding to a lot, and I remember how rusty I felt. I was "out of shape" in my coding. Though nobody (fortunately) noticed, I felt embarrassed that I could forget so much. In fact, I've forgotten much that I learned early in my career (or in school), such as how to write Pascal.
It's an unfortunate (or fortunate, depending upon your perspective) part of life that we tend to forget things (okay, some people have better memories than others...I'm one of those that forgets pretty much everything), especially when we don't "remember" it often. In the technical world, that's the difference between hitting the ground running and falling flat on your face when the gate opens. You can always get back up, but it takes a little while (and it's a bit embarrassing, too).
Knowing that this happens makes me a little nervous about taking certain types of roles. If I take this job or that promotion, will I like it? And if not, will I be able to go back? Does the same kind of thing happen to a team on a collective level? If so, that could have a significant impact on productivity on a project.
Tuesday, April 26, 2005
Tuesday, April 19, 2005
Memories
My family was playing Charades For Kids the other day and my 4-year old did a charade of a computer. She knelt on the floor, folded her arms, and sat really quietly (she's not known to sit quietly). As I thought about how cute and funny it was, I'd wished that I'd taken a picture of it (or, even better, a video).
That got me thinking. Why do we take pictures, videos, write journals, etc. in our daily life? That's obvious. We want to hold onto the memories, to refresh them, to share them, etc. That's especially important to me because I have a terrible memory (fortunately, my wife is very forgiving).
But, why don't we do that on our software projects? Sure, we may have a company picnic and take pictures, but that's not what I'm talking about. Why don't we keep a project journal, take a "snapshot" of the brilliant insight that a co-worker had on a particularly tough technical issue, or record our team meetings where we made all of those important decisions? Sometimes, we do. Most of the time, we don't. We rely upon our memories, upon the memories of our co-workers, and in many cases, the *short* memory of our clients and customers.
The more I think about it, the more I think that there's not enough information about our projects stored somewhere that's long-term. It's hard to learn from your mistakes when you forget them so quickly (in fact, I tend to claim that I don't make mistakes; since I don't remember them, they didn't happen, right?). It's not that we don't have the tools (email server backups, wiki pages, blogs, shared storage, etc.). I'm not sure if it's a cultural thing (for geeks) or that no one shares my opinion that it's important. Maybe we never justify the time to write it down? If so, that's too bad, as I expect we lose a lot of time looking for information that was lost or forgotten. If I remembered everything that I ever did and learned, I'd almost be a half-way smart guy. Unfortunately, I didn't write it down, so I remain pretty dumb. Just forgive me if I have to ask your name a few times...
That got me thinking. Why do we take pictures, videos, write journals, etc. in our daily life? That's obvious. We want to hold onto the memories, to refresh them, to share them, etc. That's especially important to me because I have a terrible memory (fortunately, my wife is very forgiving).
But, why don't we do that on our software projects? Sure, we may have a company picnic and take pictures, but that's not what I'm talking about. Why don't we keep a project journal, take a "snapshot" of the brilliant insight that a co-worker had on a particularly tough technical issue, or record our team meetings where we made all of those important decisions? Sometimes, we do. Most of the time, we don't. We rely upon our memories, upon the memories of our co-workers, and in many cases, the *short* memory of our clients and customers.
The more I think about it, the more I think that there's not enough information about our projects stored somewhere that's long-term. It's hard to learn from your mistakes when you forget them so quickly (in fact, I tend to claim that I don't make mistakes; since I don't remember them, they didn't happen, right?). It's not that we don't have the tools (email server backups, wiki pages, blogs, shared storage, etc.). I'm not sure if it's a cultural thing (for geeks) or that no one shares my opinion that it's important. Maybe we never justify the time to write it down? If so, that's too bad, as I expect we lose a lot of time looking for information that was lost or forgotten. If I remembered everything that I ever did and learned, I'd almost be a half-way smart guy. Unfortunately, I didn't write it down, so I remain pretty dumb. Just forgive me if I have to ask your name a few times...
Wednesday, April 06, 2005
BBQ Grills
So there I was at one of those "very-big-home-improvement-stores" with my father-in-law. I was looking at barbeque grills. I enjoy grilling, as most males do, so I was "doing some research" on the one I'd like to get (when I can afford it). I already have one, but it's getting pretty old and miserable, so I was looking for an upgrade candidate.
They had grills that were really cheap, some that were really expensive, and lots in between. The price differential seemed to be based mostly upon the size of the grill (how many burgers do *you* want?) and features (can you say "rotisserie"?).
As I was inspecting them, I noticed something rather strange. There was a set of very nice ones that were basically the same, except that they ranged from smaller to larger (both in price and in size). It was one of those "series" things, where the manufacturer tries to hit several different price points. Nothing surprising or wrong about that. However, I noticed on the smaller/cheaper models that they used the standard "can" approach to catching the grease at the bottom of the grill. This was strange, since I don't think the approach is a very good one, especially when there are other alternatives that work as well or better (in fact, the top-of-the-line grill just had a slide-out tray). These grills with the "can" also had a slide out tray (out the back, instead of the front), but my concern was that they wouldn't catch all of the grease (grease sometimes goes out at an angle; wind blows the can around, etc.).
The strange part about it was that I'd found a cheaper model from another manufacturer that used a slide-in box (angle won't matter, and it doesn't get blown around), which I thought was pretty clever. I figured that if I spent so much more on the better model, it wouldn't have settled on a "can" approach. But, it did. (I should note, here, that there is a downside to the slide-in box: it'll be hot during and right after cooking, while the can won't.)
Looking back on that experience, I realized that it mattered to me which method was used because the maintenance of the grill mattered to me. In fact, I'll go so far as to say that that's one of the most important (if not *the* most important) features of a grill (to me). Why? Because I hate cleaning grills. So, the less work I have to do to keep a grill clean, the happier I am (and the more grilling I do).
It's all about what's important to you. Is it the number of burgers, etc. that you can cook at a time? Is it the amount and exactness of the heat? Is it the features, like having a rotisserie, a side cooker, and a built-in cabinet? Is it looks, mobility, or what? To me, it's the maintenance.
Programmers have the same question to ask: what's most important? Is it the speed of the code, the speed of the development process, the maintenance, the elegance, the framework used, or what? There may not necessarily be a right or wrong answer to that question (at least, not in a general sense). However, it's an important question to ask, and should be asked separately for each project. Different design or architectural decisions may be made because of it. For example, if it's speed of execution, you may lose some on the maintenance. The other aspect is that understanding your priorities allows you to counter-balance the decision with other processes. For example, if speed of execution is the priority, you may take extra care to ensure that the code is maintainable because you know that it tends to be forgotten. You may adjust your schedule to provide fewer features because you know it'll take you longer, etc. Understanding motivations allows you to adjust for them.
Certain types of grill surfaces require different kinds of cleaning materials or approaches. If you just don't pay attention, you'll be buying a new grill too often. You may buy the wrong grill. You may find that that cool-looking cedar-enhanced grill fades very quickly because you didn't keep it covered. If you don't care, then you don't care. Buf it you do and understand your motivations and priorities, you can adjust your behavior to suite the problem at hand.
They had grills that were really cheap, some that were really expensive, and lots in between. The price differential seemed to be based mostly upon the size of the grill (how many burgers do *you* want?) and features (can you say "rotisserie"?).
As I was inspecting them, I noticed something rather strange. There was a set of very nice ones that were basically the same, except that they ranged from smaller to larger (both in price and in size). It was one of those "series" things, where the manufacturer tries to hit several different price points. Nothing surprising or wrong about that. However, I noticed on the smaller/cheaper models that they used the standard "can" approach to catching the grease at the bottom of the grill. This was strange, since I don't think the approach is a very good one, especially when there are other alternatives that work as well or better (in fact, the top-of-the-line grill just had a slide-out tray). These grills with the "can" also had a slide out tray (out the back, instead of the front), but my concern was that they wouldn't catch all of the grease (grease sometimes goes out at an angle; wind blows the can around, etc.).
The strange part about it was that I'd found a cheaper model from another manufacturer that used a slide-in box (angle won't matter, and it doesn't get blown around), which I thought was pretty clever. I figured that if I spent so much more on the better model, it wouldn't have settled on a "can" approach. But, it did. (I should note, here, that there is a downside to the slide-in box: it'll be hot during and right after cooking, while the can won't.)
Looking back on that experience, I realized that it mattered to me which method was used because the maintenance of the grill mattered to me. In fact, I'll go so far as to say that that's one of the most important (if not *the* most important) features of a grill (to me). Why? Because I hate cleaning grills. So, the less work I have to do to keep a grill clean, the happier I am (and the more grilling I do).
It's all about what's important to you. Is it the number of burgers, etc. that you can cook at a time? Is it the amount and exactness of the heat? Is it the features, like having a rotisserie, a side cooker, and a built-in cabinet? Is it looks, mobility, or what? To me, it's the maintenance.
Programmers have the same question to ask: what's most important? Is it the speed of the code, the speed of the development process, the maintenance, the elegance, the framework used, or what? There may not necessarily be a right or wrong answer to that question (at least, not in a general sense). However, it's an important question to ask, and should be asked separately for each project. Different design or architectural decisions may be made because of it. For example, if it's speed of execution, you may lose some on the maintenance. The other aspect is that understanding your priorities allows you to counter-balance the decision with other processes. For example, if speed of execution is the priority, you may take extra care to ensure that the code is maintainable because you know that it tends to be forgotten. You may adjust your schedule to provide fewer features because you know it'll take you longer, etc. Understanding motivations allows you to adjust for them.
Certain types of grill surfaces require different kinds of cleaning materials or approaches. If you just don't pay attention, you'll be buying a new grill too often. You may buy the wrong grill. You may find that that cool-looking cedar-enhanced grill fades very quickly because you didn't keep it covered. If you don't care, then you don't care. Buf it you do and understand your motivations and priorities, you can adjust your behavior to suite the problem at hand.
Subscribe to:
Posts (Atom)