Manager's Guilt

We're in the final week of the Digital Archaeology Project, and the students have really hit stride in terms of productivity. The content team has developed a working understanding of iterative design, and they are dealing with the technical challenge of XML-as-a-DSL. (NB: Not ideal, but in a five-week timeframe, nigh inevitable.) The technical team has shown remarkable growth in working with Unity: as I watch and listen to them work, I observe most of the conversation is about the problems of the domain, not problems with the technology.

Yesterday I started reading Clean Code, by Robert C. Martin. I've been enjoying it and am considering using it for Fall's CS222 class, but as I read it, I was forced to acknowledge the dual roles I have been playing on the digital archaeology project—or perhaps, the dual roles I'm not playing.

Early in the book, on page 6, Martin describes the tension between managers and developers, specifically with respect to a manager's need to meet production goals and a developer's need to keep code clean.

"But wait!" you say. "If I don't do what my manager says, I'll be fired." Probably not. Most managers want the truth, even when they don't act like it. Most managers want good code, even when they are obsessing about the schedule. They may defend the schedule and requirements with passion; but that's their job. It's your job to defend the code with equal passion.

I had a discussion (moderated by Google+) with the technology team just yesterday in which they pointed out that our methodology had been ad hoc and that formal code reviews would probably have helped our progress. It forced me to realize that I had been acting only as a project manager, trying to push this ambitious project into its five-week timeframe without stopping to consider the needs of the developers to write clean code. More specifically, I fear that I did not uphold my duty as an instructor to help the students learn how to do these code reviews, how to write usable code. David's recent post on the team blog highlights a symptom of this problem: we both saw that some of his code was unclean, but I fear I did not adequately authorize him to be able to tell me that he needed the time to clean it up. That is, if I only criticized it but did not impart on him the authority to deal with the criticism, then it was a learning opportunity forever lost.

Not that this has all been bad, by any means. Watching the team learn .NET with almost no prior introduction to it was great, and as I mentioned above, their savvy with Unity is laudable, especially after such little calendar-time working on it. Several times, we have been able to reflect on our lessons from Morgan's Raid and apply them to this new context, for both technical design and experience design issues.

But, as this is my place for reflective practice, I feel it is important for me to reflect on the feeling of guilt that washed over me as I read Martin's book. The challenge for me, moving forward, is to me cognizant of my two roles. This is significant for project-oriented, inquiry-based learning. For me to be a facilitator of learning, it's not enough to be a project manager: I need to be aware of those times that the schedule needs to be adjusted in order to help the team to understand the "principles, patterns, practices, and heuristics" that then they can "grind... into your fingers, eyes, and gut by working hard and practicing." (Martin, Clean Code, p.xxvi)