The Opportunity To Fail

Usually, I try to build my post from unrelated experiences. However, sometimes I just need to comment and to provide what I consider to be insight. This is one of those times.

Now that I'm in management, I have to choose my "style." Many managers like to control and dictate; others like to keep their hands off. I tend to be a little of both. One aspect of my style has to do with failure. I believe in giving people the "opportunity to fail."

The opportunity to fail implies the opportunity to succeed beyond my expectations. And that's the real motivation. But, why put it in terms of failure? Why not say: "opportunity to succeed?" That's an interesting question and the point of this post.

However, before discussing the failure versus succeed issue, it's important to understand the implications of the "opportunity" part. I believe in giving people a chance. On the flip side, I think it's inappropriate to drop someone into a lake to teach them how to swim. You might consider that an "opportunity to fail" (and, in a sense, it certainly is, since there's a good chance that they will fail and drown), but I don't. It's not an opportunity because they haven't been given the tools that they need to succeed. You don't really lose a race when they tie you up and make you crawl...it doesn't "prove" anything.

"Give them enough rope to hang themselves." Or, "When you're at the end of your rope, swing." They mean the same thing. One is a positive outlook (swing!), and the other is a more negative approach. Why approach it from a negative view?

Developers like challenges. Tell them one way and they'll find another way (as long as it's their way). Posing a negative approach challenges them to prove your wrong. It's the resistence training that they need to build their ego. I like the analogy of computer games. If you're playing Doom or Quake, you can always use the cheat codes to get through, but it's not nearly as fun. It's more fun because you know you can fail (get fragged).

So, I let 'em fail. But, I gently remind them to "impress me" if they can. Sometimes, I'm surprised at how well they can impress. Typically, they succeed, but just barely. Sometimes, they fail. When they do, I make sure to help them learn from it.

You Take the High Road, I'll Take the Low Road

I was pondering on my commute home today about different types of developers that I've run across in my career. I came to the conclusion that there are basically two types of developers (major disclaimer here: I'm over-generalizing this, obviously, so don't be too critical of the narrow-mindedness of this post): those that need to "go deep" with a technology or concept--the "deep diver," as I call them; and those that love to play with all sorts of technologies, collecting them like sea shells on the sea shore--these I call the "tinkerers".

There are various shades of these two personalities. For example, some "deep divers" like to *really* go deep on a particular technology, to the exclusion of pretty much anything else. These people are sometimes referred to as "fanatics." Others just like to spend enough time on the technology such that they feel that they've mastered it (not just "good enough" but "right enough"), and then move on to another that interests them. These tend to specialize in related technologies, languages, or concepts.

Some "tinkerers" may just love to play with technology, never really learning to use it beyond piecing it together. I've noticed that they really like scripting languages like Perl, Python or Ruby (not that there are no deep divers that like these languages). Others "learn enough" to do what they need to do and move on. They tend to have a broad background across many technologies, but have never truly mastered any particular one.

Rarely do you run into anyone that would come close to fitting in to both groups. The reason for this is simple: there's just too much "stuff" to learn, see, or play with. Many consider themselves to be a hybrid when they really are a "learn enough" tinkerer, since they don't "see" the depth that they are lacking. Others feel that they have a broad background when they know only a language or two and have worked with a small handful of libraries, but have mastered these extensively (typical mindset: "...this is how you should do that because that's how it's done here, and there's no better way of doing it because this is the greatest technology...").

Is being in one group or the other better? I don't think so. What puts us into one or the other is based upon interest. We go where we find "interesting things." For some, that means diving into a particular topic and really understanding it. For others, it's viewing the grand landscape that is the information technology industry. However, taking one of these to an extreme (too deep to exclude all else, or so broad that you don't really understand what you learned) is probably not appropriate.

Does knowing which group you're in matter? Is understanding that there are two types of personalities matter? I think so, and here's why: if I could convince someone who believes that "technology/language X" is the best solution to whatever problem is before them (when you have a hammer, all problems look like a nail) that there are *many* possible solutions (many of which could do the job just as well or better), then I've made them more humble and a better practitioner of the art. I wonder how many technological errors are made because the decision was made by someone who couldn't see deep enough or broad enough to fully understand the possible solutions.

Unfortunately, we're all human and at this stage in the industry's maturity, there's no way that a single person can know and understand (to a sufficient depth) all the possible solutions and tools available to apply to a particular problem set. We all work with limited knowledge. The goal is becoming humble enough to be open to new ideas and courageous enough to go deep when it's time to really understand something.

(By the way, I'm a "deep diver" type.)

Juggle This

I'm in a management role where I work, and though it's certainly not as difficult, technically, as what I was dealing with as a developer or architect, it's more difficult in other ways.

Certainly, the people-aspect of it is the most challenging, but also the most rewarding. What I didn't expect, and this may have less to do with management and more to do with my specific responsibilities, is the amount of pure "juggling." There are so many things to keep track of.

Development requires a certain amount of deep concentration and focus. Developers that are hounded all day about anything rarely have time to actually get work done. In my current position, it's been more about tackling a lot of different things (i.e. follow-up with this person on this issue; check to make sure that this task was done; review this or that work; go chat with person X because they look like they're having a bad day; etc.), with little time to focus on a particular task.

It's about juggling.

When you learn to juggle (and, as an interesting sidebar, learning to juggle can be a fascinating experience, if you think about what is necessary to learn), you have to learn to not only coordinate throwing and catching...you have to, internally, accept the possibility of dropping something. At least, initially, you accept this. Ultimately, you gain the confidence necessary to actually be successful by finding out that you can actually do it.

Here's the drill: take two juggling bags and throw one up and over to your other hand (which has a bag). At it's peak, throw the bag from the other hand, but don't concern yourself about catching the first throw. More than likely, you won't, but that's okay because it's more important to throw the second bag correctly. This drill is the most important in learning how to juggle (it's not the only one, though).

I'm finding that I'm going through a similar learning process with my movement into management. Some days I rarely sit at my desk; others, I rarely get away from it. In either case, it's tracking down and dealing with many small tasks that, ultimately, keep the overall show entertaining.

Bowling By Skill or Score

We had a team outing a while back in which we invited my team and their families to an outing of bowling. I'm not a great bowler, though I actually took a class on it in school and even got some one-on-one time with a skilled bowler at one time. So, though I don't bowl that well (nor that often), I do know *how* to bowl.

My wife, on the other hand, doesn't know how to bowl, doesn't bowl well, and doesn't bowl often. So, at the very least, I know better. Unfortunately, that didn't help me much that night as she beat me (though I might add, barely).

Now, I learned how to throw a hook, how to place it properly in the available pockets, etc. My wife was unaware of these, as she just let it go down the middle. But, she still beat me. In my defense, I'll repeat that I don't bowl often (about as often as my wife, which is next to never). But, I should know better. She still beat me.

Did I mention that she still beat me? Good. I thought I had. And that got me to thinking. What does it matter that I know how if it doesn't prevent me from humiliation in front of my co-workers? You see, it wasn't just my wife. My eight-year-old daughter *almost* beat me (can you see me hiding my face?).

So, I got to thinking about this. Anyone can pick up a ball and throw it down the lane and hope for the best. It's not that hard to pick up a language and throw some code together. It may seem that an inexperienced person can code just as quickly as a more experienced one. What about the proper process being followed during a project? There are plenty of successful projects that don't follow any known process; in fact, they're typically pretty haphazard.

I don't have an answer (other than I was out of practice) other than to believe that, over time, you'll have more successes when doing it "the right way." Having the right experience or following the process or bowling...eventually, the "right way" will win out (my best bowling score is still a lot higher than my wife's). Over time, a properly trained and intelligent developer will learn better, get better, and do better.

That's why there's technique... It's a "technique" because it was found that doing it that way "worked better." Just don't lose sleep over those times that it doesn't (and try not to be embarrassed that your daughter might almost out-bowl you).

Designing Software Development Methodologies

As a side note to my normal entries, I wanted to mention a website that I've started that explores a new/different approach to software development methodologies. The site is at www.methodologypatterns.org. At this site, I put forth the opinion that methodologies should be designed, not necessarily pulled off the shelf.

Not only should they be designed, but it's important to go back to "first principles" in understanding what a methodology is and how it should be designed. The idea behind the methodology patterns is to first advocate for methodology design, then define the first principles from which to perform that design, and then to provide a library of practices to use and patterns of those practices to piece together a viable methodology. See the site for details.

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.