Dina, one of the creators of the project management podcast Controlling Chaos, is heading back to MBA school at age 42. Better yet, she’s planning on attending UC Davis MBA School which is currently the best available option in the Sacramento region. And best yet, she’s blogging the experience.

Her decision to go for it came down to:

I really like being a project manager and the company I work for is a super place to work. But I’m at the top of the pay scale and top position for a project manager. There is no where else for me to go unless I want to move into a functional manager role. Upward mobility and taking on more responsibilities, decision making authority, being a part of driving the strategic direction of a company, and yes, more salary is very important to me. Not going to happen in my current position.

I’m rooting for her to get a good GMAT score for selfish reasons, to see what MBA school at UC Davis is like.

My wait and see thinking from a year ago still holds:

• Fully engaged as a development manager.
• We’re still paying off my wife’s law school loans.
• I need time to spend with my two daughters.

Good to know I’m not crazy for still considering an MBA at 37.

Today, I learned Haskell doesn’t like tabs. Haskell apparently uses some syntax conventions to connote things like blocks. I was working my way through a Haskell tutorial when I found the following snippet of code kept getting compiler errors:

fails
main = do putStr "You are? "
          name <- getLine
          greet name

Turns out you can also enclose a block in angle brackets so this code worked

compiles
main = do { putStr "You are? ";
name <- getLine;
greet name }

Then it dawned on me. My TextMate Haskell setting were showing

instead of

with spaces. Flipping it to use spaces made the same code pass compilation.

compiles
main = do putStr "You are? "
          name <- getLine
          greet name

Experimenting with lining up the arguments after the do showed that all of the statements had to line up vertically. Thus this reasonable looking syntax would fail:

fails
main = do putStr  "You are? "
                  name <- getLine
                  greet name 

I’m still very much at the beginnings of digging into Haskell, but it’s nice to play around with a language purely for intellectual curiosity.

We had a sort of ad-hoc demonstration of Wicket at the local Sacramento Java Users group (SACJUG) this week. Out of about 25 people there two people are actually using Wicket. Since there are a ton of web frameworks and we ended up in the JSF camp I just don’t spend a lot of time looking at new options, but spending an hour or so watching a demo wasn’t going to kill me.

Wicket is very component centric and I like the syntax:

And it has some nice features:

• Stateful by default.
• No JSP pages.
• You can use the back button.
• Minimum reliance on special tools.

Of course my favorite is the POJO centric nature and the fact that they just build their unit testing support package,</p>

</a>, into the main API. Almost makes me want to spend some time playing around with it, but I think I’ll wait until I see some more uptake, since there are far too many web frameworks and no winner or limited pool of winners currently.

Over the weekend I upgraded Crucible, our code review tool, to the 0.9 release. Looks like it’s nearing 1.0 readiness. When I upgraded it on Saturday night I noticed they fixed an annoying bug where you couldn’t just delete a review. We had a few test reviews in the system that we wanted to delete since we were just showing people how it worked.

Deleting away I realized we’ve been doing less reviews over the past two months or so. Code reviews are not exactly your stickiest developer practice without some coaxing. It also makes a good point why pair programming especially with rotating pairs can be a really effective way to actually have a high level of code review. Since pairing is still very optional in our shop we’ll be using Crucible for a long time to come.

Paradigm: You get promoted based on your expertise as an individual contributer. You need to give up your focus on your technical work and spend the time on managing and developing your team.

It’s a well worn cliche that many technical managers don’t get this and I catch myself wondering if I’m able to walk the line. My response to this dilemma has always been to keep up with the technical aspects by coding, reading, and developing on my own free time. I rarely sign up for any deliverables on any project, and most of my contributions like code reviews, configuring tools, and writing up demos for internal training don’t put any project in harm’s way from my ability to deliver.

This applies to aspects beyond coding, because I find it even easier to fall back into project management/Scrum Master duties because I hate to see a project struggling with delivery. Probably 50% of the time I’m covering some PM role on a project with one or more of my developers either because a PM simply isn’t available or they don’t have time to really dedicate to a project.

With all these conflicting pulls on my time I hope I’ve been able to keep the focus on management and developing my team, but sometimes I wonder if I haven’t let some larger strategic things slip through the cracks because I let myself get pulled in too many directions.