Taking responsibility

Some time ago, someone – let’s call him George – changed all the tests I had written for a batch of Support classes which had been created as a “temporary measure” and had now become part of the system. The tests started failing, and several of them were no longer testing the things they had been.

I found out today. I’d spent ages working out what the various classes were doing. I’d spent ages pinning down the behaviour and decoupling everything, and writing tests for all the new functionality I was adding. He’d broken my code. I was very annoyed. My instinct was to chew him out; to scream in frustration, because he so obviously didn’t get it. And it was his responsibility – right?

I don’t like blame. It’s never useful. Instead, I went for a glass of water and calmed down. When I came back, I invited George to join me for a cup of tea on the comfy seats downstairs. We had a long conversation about the culture of non-communication in the team; the fact that there were so many new people joining, and that he, as the most experienced person there, had a great deal of knowledge and wisdom to pass on. George mentioned the regular meetings which had somehow slipped by the wayside, and I agreed that it was a good idea to resurrect them. I suggested that we should pair on the problems we were investigating and invited him to do so with the new guys whenever possible, and to put that culture back into place. Eventually I got round to explaining that the conversation had been prompted by the failing tests (and by my rather possessive reaction; another reason to pair). We had an equally constructive conversation about the importance of running tests, some steps which we’ll both need to take to make sure they stay running (since there’s no Cruise Control on our little Support team), and some things I can do to make them less brittle and easier to understand.

When I got back upstairs, I had a quick chat with The Boss, and told him I’d only postpone my roll-off date if he helped put those ideas into action. He agreed that it was about time something was done, and said he’d help me do it. Turns out that the guy who used to be the major proponent of communication – the meetings, the conversations, the pairing – has left. So now I’m taking his role, because at the end of the day, this is my project too; and if I have a problem with the way things are going, it’s my responsibility to change it.

So much better than stamping my feet. And saves on the cost of new shoes.

This entry was posted in Uncategorized. Bookmark the permalink.

1 Response to Taking responsibility

  1. yatimk says:

    Hi, Liz. I think you did good. I’ve had experiences where developers, even team leads and managers, said things that were destuctive, even unprofessional. (How’s it like to see a junior get chewed out by an angry manager right in front of you while you’re trying to do your work? It ruined my day. I wonder what it was like for the junior.)

    I agree that blame is never useful. I believe it’s never appropriate to assign blame to a single person for any team deliverable. If any one person can derail the team, there’s something wrong with the development process. And even when someone is clearly at fault for something, constructive criticism is so much more helpful than blame.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s