... you think it's stupid. Or if you don't want to do it. It should be obvious, but to truly succeed with something in life, you have to truly believe it's worth doing.

As such, I'm going to suggest something to all the people out there who don't think agile is a good idea: don't do it. Please, find something better. Maybe you'll hit across something we can all learn from. I'll be happy to move on from agile once I see something better. Just remember that saying "I'll do these kinds of things when I feel like it" isn't agile.

posted by Jeff L.  # 9/27/2007 04:35:00 PM 0 comments links to this post Database TDD Blogs

A friend, "Joe," requested some tips on interviewing after returning from one where he felt uncomfortable and didn't get the job. Here's what I told him:

1. enjoy yourself. Convince yourself that you're there to find out more about the place and see if it's somewhere you want to work. Don't view the interview as "I gotta get a job."
2. act yourself and relax. This is very similar to recommendation #1. If you're somewhat obnoxious in person, make sure a bit of that comes out. Hiding things rarely works, and if they can't handle you being yourself, then you probably don't want to work there.
3. enjoy yourself. Figure out how to make your visit entertaining. Even if you don't get the job, you'll have had some kind of adventure. If the visit ends up sucking, or you don't get the job, you'll have a good story, and will have had an opportunity to figure out how to do better for the next one.
4. it's not what you say, it's how you make them feel (straight from Weinberg). This is a critical mindset for making sales, consulting, training, etc. It's an approach I'm still learning how to do well, but have noticed that it can work wonders. If you leave them thinking, "wow, I just had a great time while Joe was here," then you're probably getting the job. People won't remember the specifics of what you say, unless you say something really stupid. But they do remember how you make them feel.
5. see recommendations 1, 3

According to Joe, it went real well on a subsequent interview, particularly rules #1 and #2.

posted by Jeff L.  # 9/24/2007 04:34:00 PM 2 comments links to this post Database TDD Blogs

It's been well over a year now since a difficult incident that occurred after I spoke at a well-known software company. I'm normally thankful for people willing to engage in honest debate, and for people who correct me in a constructive manner. That wasn't the case with respect to this incident: I was basically assailed after the fact by someone who wasn't professional enough to challenge me in person.

Of course these things are very painful. I still get angry when I think about it. I wonder, "did I really come across as stupid as I was made out to be?" I second-guess myself now, every time, when I speak in front of audiences. I fear that I will be called out, perhaps publicly humiliated again.

With respect to the attack, it was one of those things where where comments were taken out of context. The author is someone who appears to have a personal agenda against not just me, but the entire agile community. Having thought over the whole incident many times, I've come to a perhaps smug conclusion: my assailant was acting out of his own fear.

Fear? I doubt he would admit it, and probably doesn't even know it yet. Fear often masquerades itself as arrogance. Arrogance is knowing that your way of doing things is the right way; it hides the fear that something you don't completely understand might be better.

I spoke at Agile2007. I got the chance to attend one of Bob Martin's sessions on Code Craft, about professionalism in software development. If anyone has cajones, it's Uncle Bob. He projects no fear, and was bold enough to say something like, "software professionals use TDD" in his conference talk. I believe he is absolutely on the money.

Many people claim to fully understand TDD, but insist that it's something you might do only when "you feel like it." Unfortunately, that statement right there represents a severe lack of understanding about what TDD is and why you might do it. That's something I've been trying to help correct, by demonstrating first-hand the benefits of TDD and the high costs of viewing it as an optional activity.

I'll project some confidence, which might similarly be construed as arrogance: soon enough, we won't talk about TDD. It'll be like subroutines, compiling, and automated builds--we'll just do it. The holdouts will become like the dinosaurs who still insist that OO is a passing fad.

Behind this arrogance I have no fear--if there's something better, show it to me. I haven't seen it yet, and it's most certainly not the claims that programmers are smart enough to know when their code is perfect and needs no tests. For now, then, I'll stick with TDD--all the time.

posted by Jeff L.  # 9/15/2007 11:09:00 PM 1 comments links to this post Database TDD Blogs