A Case for Wizards

I have written an article discussing the practical applicability of wizards and the potential for their misuse. You can find it here, on the blog of Merlin, an open-source wizard framework for .NET.

NFJS now has a magazine

It’s amazing how the same bunch of cronies can keep blabbering about the same old stories and keep getting new revenues. Having gotten bored with blogs and anthologies, the speakers and organizers of the No Fluff Just Stuff tour now have a magazine. The articles comprising the inaugural issue are:

• Intro to Functional Languages
• Message Driven POJOs: messages made easy
• So You Want to be Agile?
• A Case for Continuous Integration

While you’re at it, how about some other breaking stories like “A Case For Avoiding Computer Viruses” or “Turning on Your Computer – a field guide” or “Hello, World in Three Lines or Less!”?

Proper Care and Feeding of Software Engineers

We all know a manager can’t just ask his reports “how am I doing?” without receiving a reply that is at least partly tainted by a desire to please. So as an engineer who’s had quite a few managers by now, I’d like to volunteer some observations about things I’ve seen great engineering managers do to create better relationships and deliverables. I can’t vouch for other engineers, but I think this is what they’d tell you if they were high on truth serum:

1. Engineering experience required. No way around it. If you haven’t been an engineer yourself, you will simply not be able to heed the suggestions that follow. You will also lack the “street cred” and the common ground that separate a leader from that dreaded four-letter word “boss”.
2. Laugh at yourself. We all know the stereotype, however inaccurate, of the clueless, lazy, bureaucrat manager, whose paycheck is as high as his usefulness is low. The easiest way to shed that image is to mock it openly. Joke that you can’t really do something because you’re just a stupid manager. Do an impression of Gary Cole’s character from Office Space. Regardless of how accurate or atrocious your impression is, the message is the same: I hate useless bureaucrats as much as you do.
3. Care about the code. Give suggestions about the code. Ask questions about it. Participate in code walkthroughs or volunteer (but don’t demand) to do a code review, when time permits. Listen to explanations and learn any new technical tidbits that your engineers bring up. The benefits are twofold: first, getting near code lets you and the engineers talk about what matters the most to them in their job, thus boosting your credibility and demonstrating to the engineers that you are “one of them”. Second, if engineers know you care about the design and quality of their code, they will too.
4. People over process. An old agile mantra that still is not applied even by some who know it. In the eyes of an engineer, process is something evil bureaucratic managers cook up to make themselves feel important. After all, if you’re not the one doing the work, why should you tell us how to do it? Thus, make sure processes are born organically, by group decision and consensus. When you must establish a process, or indoctrinate a new engineer into an existing process, make sure you explain all the motivations, listen to all the objections, and do your best to elicit buy-in. An engineer that considers a process to be a rubberstamp, may provide only demonstrative compliance. And it never hurts to question the value of a process already in place. Ask the engineers now and then, “is this working? Is this helping or hindering you?”
5. Regular face time. This one seems obvious – talk to the people, one-on-one, regularly. One engineering manager I had did this by scheduling monthly one-on-ones with all of his reports. That might be sufficient if you’re leading an army of robots, but humans and human relationships benefit from frequent and recurrent contact. Even if you just stop in the hall or drop by the cubicle for five minutes and ask “how’s it going?” you’ll keep yourself in the picture and reaffirm your presence on and your involvement with the team.
6. Meetings aren’t (always) the answer. How often have I seen (and heard of) meetings where one person is discussing his work with the leader, and the rest are sleeping. I am fiercely skeptical of the value of such meetings, particularly if the team is large. In that case, I’d limit the duration of such conversations (as in Scrum), or just talk to the team members one on one. You get more meaningful interactions (see previous point), and no one is snoozing or doodling.

Some of the aforementioned points call for a certain degree of involvement in the work of engineers. Some may argue that good engineers can work independently and a manager shouldn’t have to babysit. A manager should be able to trust his team to get the job done well. Certainly, many engineers can and do work pretty well independently (present company included). But how will that team-leader trust develop and grow without constructive and regular interaction? If you trust engineers with whom you do not speak regularly and whose code you never see, you cannot vouch for the quality of the code or the skill of its authors.

At the end of the day, no quantity of great engineers can save a poorly-run team. Great teams need great leaders. Where I work, we have some fantastic engineering managers, but I often hear stories from colleagues outside that make my heart twitch.

Dear managers, if we do our best for you, please return the favor.

 

Technorati Tags: programming, software, engineering manager, management, team, leadership

No way… they listened?

Take a look at the “Executive Orders” section of whitehouse.gov. They actually have added Presidential Memoranda, whose absense I tiraded about in my last post. I’m not sure if I’m the only one who sent comments calling for their publication (probably not), but that doesn’t matter… what matters is that someone actually listened! The memoranda weren’t on the site for the first several days of its uptime. And unlike proclamations, they weren’t given their own section. So it seems they have been tacked on to “Executive Orders” as an afterthought, quite likely in response to feedback.

It’s an incredible feeling to have been heard by one’s government. Let’s hope we all get that feeling more often. I think we just might.

Obama Promise of Transparrency Already Broken

I’m sure I wasn’t the only one who went to the new WhiteHouse.gov site today to see it in the Obama administration’s rendition. After all, the new administration promises to speak and to listen to the people directly; a promise of which the new site is a big part. And a promise which, on the first day, was already broken. Twice.

First, there is President Obama’s first order – nothing major, just the expected halting of the last-minute regulations of the previous administration. The real news is that this order appears nowhere on whitehouse.gov. Even if the “order” in question is just a memorandum to federal agencies, such notes are exactly the kind of document that a truly transparent administration would make public. If a president is happy with an agency’s performance, we want to know. If the president is unhappy, we want to know. If the president wants to adjust the goals or workings of an agency, we want to know.

And we want to know directly. Not from private news organizations, which are subject to editorial control. We want the words straight from the horse’s mouth, especially since we’re the ones who put the horse in his stable and are paying for his hay. So like the good citizen that I am, I go to the Office of Public Liason page, fill out the comment form, click “submit” and whoops! I’m told I have not chosen a subject when, in fact, I have. Just a bug, no doubt, all the IT people are probably out celebrating. I understand. But Barack Obama has become such a symbolic figure that it is easy, nay, tempting to interpret this occurrence as a symbolic gesture. The administration falls flat on its promise, and refuses to hear when citizens complain.

Or maybe the past eight years just turned me into one heck of a cynic.