This post originated from an RSS feed registered with Java Buzz
by Michael Cote.
Original Post: Hiring Techies, Project Management
Feed Title: Cote's Weblog: Coding, Austin, etc.
Feed URL: https://cote.io/feed/
Feed Description: Using Java to get to the ideal state.
On the drive back from Houston yesterday (where I've spent most of the past week with Kim's family) I listened to Johanna Rothman's interview on IT Conversations. From the short description, I thought it'd be just about interviewing technical people, but it quickly turned into a discussion about what it is a project manager ideally does which, itself, is really a discussion about how technical projects should be run. I haven't finished listening to the last 10 minutes or so, but overall I'd say it's very interesting and informative.
Understanding vs. Finishing
Kim's sister is a project manager for big-time government and military projects. We talked about project management while driving around town, and two of the themes I picked up were simply making sure (1.) things get done, and, (2.) that people get questions answered as quickly as possible. She was commenting that programmers aren't always the best at those two things: programmers tend to want to spend more time on both than they have two.
I've been thinking about those two things a lot recently. As a programmer, I have an urge to study any problem and completely understand it instead of simply getting the task at hand done with incomplete understanding and/or taking up someone else's time asking them how to do it. And, indeed, whenever you ask someone else to help you out, there's also the possible negative effects of (1.) they think you're wasting their time, and, (2.) they think your an idiot. I'd hazard a guess that many coder's "slowness" at tackling problems are motivated by trying to avoid those two things.
That slowness, however, understandably drives managers crazy. Their focus is simply on getting things done instead of understanding everything. Indeed, those are two very conflicting motivations. Another IT Conversations, Jerry Fiddler's talk from SDForum Distinguished Speaker Series, brushes up against this notion of taking the time to understand things rather than just getting things done.
Foggy Requirements
Another thing Kim's sister talked about was the every present problem of having unclear and/or unstable requirements. It was "comforting" to hear her talk about this as a common problem since she works in government and military projects: I always expected that of all the fields that software development happens in, those two would have requirements figured out.
Rothman talks quite a bit about this topic as well. The most interesting thing she says on the topic is to make sure that you always define ahead of time what the release criteria for a project is and that you get all the stakeholders to agree on it. "Release criteria" simply means the answer to the question "how will we know when we're done?" For example, it might be a list of features you must implement, a date (whatever's done by that point), or a bunch of functional tests that must pass.
Ranking Requirements
Another interesting thing Rothman talks about -- that I've only recently encountered in my more detailed SCRUM reading -- is to rank all of the tasks/features in a project. By "rank," she means to number them starting with 1 to however many features there are.
Then, you implement the features in that order. She points out that rating tasks as "high," "medium," and "low" isn't very useful at all: you always end up implementing just the high things (if all of those) and throwing out the rest. Instead, it's more useful and informative to simply rank all of the features in order or importance.
I've mentioned this idea to several folks at work, and they all seem to really, really like it. Everyone seems to have clued into the idea that rating features as simply high/medium/low is less than ideal. We still haven't reached the tipping point where we actually throw that rating out and go with ranking requirments. We'll see what happens next release.
Journal
The last interesting thing I recall is Rothman's suggestion to keep a daily, personal journal about your work stuff. Her justification, as I understand it, was that it can be used to empirically learn to be a better at whatever it is you do. I like this idea, but I don't know if I'm disciplined enough to do it. My theory is that you'd write down what happened during the day, why you made the decisions you did, and how things are going.
If you take the time to review those three things, you can start to learn what worked and didn't work, and, thus, get a rough idea for what will work in the future: "I had problem X 3 weeks ago, so I applied solution Y, which resulted in the less than satisfactory Z. Thus, I should make sure to reconsider applying solution Y when problem X comes up again."
I'm a big believer in the team reviewing itself to get better (at the code level all the way to the release level), so it makes sense that the same ideas would work on a individual level. We'll see how that pans out, if at all, for me.
Previous Topic
