Bad Lessons Managing at Dotcoms

My second stint as a manager, about 6 years ago, was leading a team of web developers at a dotcom ecommerce consulting shop called XUMA. We specialized in ATG Dynamo, a java application server you’ve likely never heard of.

Like many, many dotcoms we went through the boom and bust cycle during the 18 months I worked there. I joined a brand new office in Las Vegas as one of three people to found the office and grew the office to almost 50 people before the layoffs started. Those layoff experiences heavily influenced my management style.

We had three rounds of layoffs before it was over. In the first I was asked to layoff 4 people. At the time I had a staff of 8 people so 50%. For those managers who haven’t had the experience of managing through a layoff it works pretty much like this:

The timing couldn’t have been better as I had just staffed up four new people in the two prior months to bring my team up to 8 people. Some of them had actually moved across several states to take their new jobs. This was early December of 2000.

I had to make some fast, horrible decisions. Lay off a solid performer who had proved themselves or lay off a new employee who interviewed really well, but never got to work on a project. It was a gut wrenching experience, so much so that one of managers in the office threw up the morning of the layoffs. By June 2001 we ran through the third round of layoffs and closed down the office.

I came away with the lesson that I had to keep a certain distance, emotional and otherwise, between myself and my employees. At any moment I could be asked to make a layoff decision, so I had to be prepared and not overly connected to my staff. I’ve viewed a lot of things since then through this filter.

In the last year or two at my current job I’ve begun to re-evaluate that lesson. Layoffs will always be around, but you can’t really motivate people if you’re always worried about keeping a certain professional distance. It’s also just not part of my natural optimistic tendencies so it was always hard to keep in place.

If you’re really going to be able to motivate someone you have to know what drives them. And you have to be able to share your own motivations. Keeping your distance just to make layoffs a little easier isn’t worth the tradeoffs.

Employees Providing Laptops

According to Gartner by 2008 at least 10% of employers will require laptops to be provided by employees. All I can say is I certainly hope so. I’ve used my personal laptops for at least three employers in the last 6 years.

I’d much prefer to use my more productive Mac laptops versus your generic IT provided Dell laptop. The unwritten conclusion I can make is though they’ll require an X86 laptop running some specific version of Windows. Unless things like AlienWare and Apple laptops show up in some laptop magic quadrant.

Technorati Tags:

Local Variable Names: Whole Words Versus Letters

I’m trying to make sure I really understand Ruby’s blocks and closures, so I was digging ahead to Chapter 22 of the Pickaxe book on ‘Blocks, Closures, and Proc Objects.’ On page 358-359 there was a bit of example code:

def meth1
  (1..10).each do |val|
    return val  # returns from method

I would have just used


for the variable name, but maybe this is a very popular idiom in Ruby.

t = do

OK, this is the sort of stuff that drives me crazy in Java when people do it. Instead of just naming it thread or something logical we just assign it to


, a meaningless English character. When you read later down in the code you get no hint about what


is so you have to hold that in your brain or refer back to its definition again.

Then there’s there’s these examples :

pr = { next 99 }
p = { return 99 }

Couldn’t it have been at least


! At this point I don’t grok enough about ruby’s Proc class to really come up with a better name, but it appears to be a closure so that might be a reasonable name as well.

I know the counter arguments. One, this is a book with example code so they’re trying to save space. Possible, but you’re also introducing the language to people so you should probably try to be as clear as possible. Two, it saves typing. True, but typing is not what slows down my coding, defects and harder to follow code does. Three, that’s the Ruby idiom. That may be very true, so this may seem as normal to me as using i,j for looping counters. I’ll just have to see if that proves out.

Technorati Tags:


Mini-Review: Aardvark’d: 12 Weeks With Geeks

Short take, a really good concept, but not that great a documentary. You can find longer reviews here and here. I really appreciate Joel’s attempt at producing a documentary on Fog Creek Software’s internship program. The only problem would be a narrative never really develops beyond time passing over the 12 weeks and the growth of a tomato plant.

You do get the feel of a small startup, and you get to see the nice private offices (but not for the interns) and dual monitors + Aeron chairs for everyone. I did think seeing the interns negotiate for the domain name was funny. There was almost no actual negotiation. The first price from the owner of was 20k. The interns decide the most they want to pay is 10k, and they end up paying 10k because the owner claims there are ‘other bidders’. Don’t know the details, but it barely seemed like a negotiation.

I did like the quote from one of the interns on Coldfusion:

“I’m not really even sure. I don’t know what Coldfusion is. Umm, some web programming thing, I guess is some kind of half real language, according to the hard core people. And it’s the best thing ever according to the Coldfusion people.”

That was pretty much my experience starting a job back in 1997 and finding out the web team did all their applications in some strange thing called PowerBuilder.

Since I saw they were showing the movie at Software Development 2006 I may see it on a big screen and see if I get more out of it. With Joel and the director there maybe there will be some good stories to go along with it.

Technorati Tags: