blog.forgreatjustice.net

It comes up on occasion, so I thought I’d put together my list of books that have impacted my view of project management.

Manage It!: Your Guide to Modern Pragmatic Project Management. It covers the major methodologies and the ways to properly reason about them. It advocates for agile processes in some circumstances, but understands it doesn’t fit in everywhere. It’s clear, direct, and drawn from experience. Geared towards software, but applicable elsewhere (I think). This is my first stop.

Leading Teams: Setting the Stage for Great Performances. I categorize this book as slightly fluffier, but it gave me some good ideas as I got into a management situation.

Getting Things Done, the book / methodology / sortacult. It’s a strong set of practices and habits that work well together with great habits. I recommended picking and choosing the parts you adopt into your own system. The books is geared towards personal productivity, but it will give you insight into functional workplaces.

Dreaming in Code. This is not a management book per se, but instead is a very human look at the realities of software development. It’s half narrative and half philosophical musings on the nature of software development. I put this on the list because it gives you a sense of humility about how modest projects (and earnest workers) create the emergent complexity/dysfunction that makes project difficult.

Also, I wrote an essay on the kind of manager I try to be: the Cleric.

It is Ada Lovelace Day, “an international day of blogging to draw attention to women excelling in technology”. There is so much potential and power in the tech sector, and it is therefore imperative that our field is inclusive to all of society.

So, I’d like to talk about a friend of mine, “C”. We both came out of the Computer Science division at Harvard. I don’t want to get into an Ivy League grudge match, but I think it’s fair to say Harvard’s CS was no cakewalk: heavily weighted towards theory, and not a whole lot of hand-holding. We both spent some part of our youth tinkering with code and wading around Usenet. We both came into CS as transfers from our initial majors, later coming to terms with what field truly called to us.

There were differences, of course: for example, I walked away with a B.A., whereas she walked off with her Master’s Degree in hand. That’s a graduate-level work. That’s the choice she made to delve into challenging theory when easier options were available. As a younger man, I did not enjoy theoretical work; only later, having practiced in the real world, did I come to value proper theoretical understanding. Only later did I see how precious and how rare an understanding of theory would be.

And so, we both pursued careers (her in the DC area, and myself in Boston). We both went through cycles of new jobs, new challenges, and constant reinvention. I admire the path she’s taken: once she realized that web development was no longer her passion, she immersed herself in a new challenge – sysadmin work – when she could have found an easier job within her former niche.

Integrity is living by your own set of standards, beyond what the world imposes on you. For technical workers, we are presented with many easy options – and many threats to our integrity.

To hack and fix, or to learn from a problem, solve and actually understand? To hop from gig to gig – or to keep your commitments to a team that relies on your work? To settle for the buzzwords and acronyms of a resume bullet – or to leave the comfortable behind and forge a new set of skills? To code for a paycheck, or to code as excellently as you can, as correctly as you can, because there is simply no other way to do so?

Code with integrity. We can find solutions to the world’s toughest problems – but only when we treat our profession with the pride it deserves. With her as a friend and colleague, I know that I must work to a higher standard.

I’ve made a Rails plugin, sanitize_attributes, and (after some help from jnichols at a recent Boston.rb hackfest) I’m happy to share it. It’s a rather small plugin, adding a light DSL to ActiveRecord models to quickly define pre-save data sanitization.

This came out of some work I was doing to fight cross-site scripting (XSS) attacks. Once the plugin was done, adding sanitization was a snap:

class Comment
  sanitize_attributes :title, :body, lambda{|text| Sanitize.clean(text)}
end

The gem I’m referencing above is rgrove’s Sanitize gem. I prefer it to the built in Rails sanitization because it uses Hpricot (a true C-based parser) in the background. For fighting XSS attacks, if you’re not parsing/rewriting the HTML versus a conservative whitelist, you’re not actually sanitizing anything.

Relatedly, I’m working on lighting-talk about anti-XSS techniques that I could share at Boston.rb. I wouldn’t suggest that I’m a security guru, but there’s definitely some knowledge I want to share, and nobody wants to learn this the hard way.

When running webrick on rails apps, I run it daemonized. I finally got bored of manually finding and killing the process by finding it’s process id, so I made a quickie script for killing ./script/server.

I’m certain there’s better / more robust ways of doing this.

Auburn Quad is great. I got this mesage from my boss on Friday:

Just a reminder that Auburn Quad is closed on Monday. I hope everyone has a great long weekend!

And not to wax too poetic, but Labor Day is more than just a day off. Currently in my previous town, Boeing employees are preparing to strike because of an insufficient contract offer by Boeing. Some of the best Democratic leadership came out of the labor movement, which also brought us reasonable pay, decent work schedules, and days off like Labor Day. I appreciate unions, and I respect workers and what Barack Obama last night called the “dignity of work.” That includes the fabulous employees and contractors at Auburn Quad. I hope you find some time, in the midst of working hard and playing hard, to appreciate the courageous labor organizers who’ve given us a decent life. And I hope you find the right amount of challenge and a great sense of accomplishment from working at Auburn Quad. Thanks, everyone!

It’s important to me to work at a place that gives me that kind of respect.

I’m now working with Auburn Quad (the techpower behind ActBlue). (Geographically speaking, I’m in Harvard Square.) I’ve been doing Ruby for fun before, but it’s nice to work with it full time.

15′ until kickoff. The stadium is still filling up. The atmosphere is dense with humidity, electric with the anticipation of 60,000 other fans who, like you, are counting down the seconds until their team takes the field.

When I heard about the game at Giants Stadium, I knew I had to get back to Jersey (my ancestral homeland). With me that night: my dad and my uncle, and one of my buddies from high school. My dad and uncle had seen some USMNT games in person, but years ago. This was my first national-team game; my friend had never seen a pro soccer match in person at all.

The crowd was a 60/40 split between fans of Argentina and the US (which is a usually a good ratio for a US national game; that peculiar fact is a complicated one). A band of Argentina fans – by which I mean an actual band: brass, drums, chanting – stood just outside our section, making their show of bravado and generally trying to get in our heads. Their supporters unfurled the blue-and-white flag on their side of the field, and in turn Sam’s Army unfurled a huge “US Soccer” crest, emblazoned with our ancient motto. “Don’t Tread on Me”.

0′. Kickoff. All that waiting and clock-watching, and kickoff takes me by surprise. The game just starts off like a whisper: a look, a short pass and a roar from the crowd.

25′. The US is in it and fighting. From my view their play is rugged and scrappy, with burst of finesse being echoed with cheers from the US crowd. The players know how dangerous Argentina can be, and must leave them no room: two or more defenders quickly moved in to cut down any run by their side, and that wasn’t always enough.

You had to respect Argentina, the current #1 team in the world. They would frequently play “quiet” passing the ball back through their midfield and backline, but at any given second they would wake up and starting a piercing attack, slashing open layers of defense and leaving it up to our phenomenal goalie (Tim Howard) to save the day. There was no room for error.

67′. Outrage, incompetence.

There were questionable calls throughout the game, but then it seemed that one of the players was mistakenly sent off. How can you possibly eject someone from the game by mistake? (How can you eject a player from a friendly game for minor shoving?)

And yet: while Argentina has dominated for moments in the second half, the US has had its attacking share as well, and came as close as hitting the crossbar, but no closer.

I was in full fan mode, passionate and cheering for the USA, and blissfully biased in my take on the game. Intellectually I knew that not every run was a real chance at goal, and not every call against us was a grievous crime. I knew this, but I did not feel it. I could only feel myself chanting with the crowd. “U-S-A”: a simple chant, even painfully simple if you want to analyze it. But I certainly didn’t care. There was just my father, my friend and myself, caught up in cheers of the crowd.

85′. Thunderbolts and lightening.

I kid you not: in this, the 85th minute, one of the Argentine players was sent off, bringing the teams level once more. And at that moment, it started pouring down rain, and not just rain but a full lightening storm. The rain revived the happy crowd, and thunder punctuated the aggressive play of both teams.

As storm broke I saw a new ferocity in my players, now unlocked. In the last remaining minutes of the game, the US was on a relentless attack. They had so much more to prove in this game, and with the clouds on their side, they went for it.

95′ or so. After long stoppage time, and a final attack by the US: the final whistle. A 0-0 game, but the most exciting scoreless tie I could have seen.

“But in the end, none of that matters as much as the simple fact that software does not work the way we think, and until it does, it is not worth trying to perfect.” — Scott Rosenberg, Dreaming in Code.

My thought for the year: it’s called “culture” because it grows everywhere.

That is, when you establish the bare medium for social interaction – be it a weekly meeting space, a shared workplace kitchen, a mailing list, or an option to “friend” others online – the base medium exists for a social culture to emerge, evolve, self-enforce and self-define,  in a very shirky way. You can affect the process in some ways, but once it truly picks up, it’s important to recognize that you are no longer in control. The culture is an autonomous organism.

This shouldn’t be too surprising, but sometimes I’m impressed (occaisioanlly: exasperated or awed) by how social patterns evolve, everywhere, again and again.

Some folks at Thoughtbot suggested that there are three classic types of coders: the warrior, the wizard and the rogue. Good breakdown, but something is clearly missing.

The Cleric

You’re here to keep everyone else alive. When a Wizard’s design blows up in his face, your patches quickly put him back together. When the gnarled codebase ensnares the Rogue, your refactoring gives her room to breathe. When there’s work to be done, your tools and scripts provide the key buffs for the Fighter. Whenever a teammate is flagging and fatigued, you jump in to heal an ailing project. You might not slay a dragon on your own, but you can make sure everyone gets out in one piece.

…Suffice to say, I often try to be the team’s Cleric. That’s not my only role – I’ve pulled off some Wizardly design and Fighter-esque precision – but I’m happiest when I can keep everyone on my team fighting on against the Infernal Bugs and Treacherous Deadlines.

(Image credit: link.)