Liz Keogh's blog

Ade is collecting stories about apprenticeships on behalf of Dave Hoover. He asked me to write mine down. So here it is.

My educational background is in Electronic and Electrical Engineering, not IT, though I’ve always loved computers. I learnt to code on a MUD (Multi User Dungeon for you lesser geeks). It gave me a good grasp of object-oriented code (Zakar the Dark Elf inherits behaviour from the generic Dark Elf), but didn’t teach me OO design. I joined a software house after university, convinced that intelligence and enthusiasm would be enough to see me climb steadily from apprentice to master.

Lesson 1: you never know enough. A shaky year in which my previously untarnished record was marred by a scathing criticism of the maintainability and legibility of my code convinced me to put myself through some of the design courses which my company made available to me. Learning design patterns was a revelation. Suddenly some of the strange, incomprehensible things that the architects and senior designers had been coming up with made sense. My code became cleaner, more maintainable, and just as incomprehensible to the new developers joining us. Fortunately at this stage we had several copies of Design Patterns floating around the projects, and I took it on myself to point some of the new graduates towards it.

I also taught myself Java to escape from the terrible VB project I was trapped in at the time. We didn’t have many Java developers in the company and it was a skill that was increasingly in demand. Some other developers had the same idea, and eventually we managed to get ourselves a little Java project of our own; four devs, one team leader and a project manager. We came up with some simple rules for our project:

• Don’t check in anything which doesn’t compile.
• Write unit tests for new code before you write the code.
• Pair on difficult designs.
• Talk to each other.

This remains the most fun project which I’ve ever been on, and I wish it had lasted longer.

After a while we were joined by two junior developers, and the pointing to books turned into proper mentoring.

Lesson 2: nothing is original. Finding out that one of my developers was doing exactly the same thing that I had done, and making exactly the same mistakes, made me realise that the team leaders and managers must have made those mistakes too. They had learnt their craft from somewhere. Reading Design Patterns wasn’t enough; there was more learning out there to be had. We held an MVC workshop. There were patterns not covered in the book. I started buying books from my own hard-earned wages, and my software development library was born.

This was about the same time as the .com bubble burst, and there wasn’t a great deal of work coming in. I took voluntary redundancy and moved to London. Getting a London flat without a job was hard and used up all my savings and redundancy money in deposits, so I lived off of credit cards for a while, confident that I would find a job somewhere. It took me three months of job applications to find two companies that were interested. One of them suffered a recruitment freeze halfway through the job application, and the permanent job became a contractor position. The other put me through five gruelling interviews before finally turning me down. I was a bit depressed; I knew I could have learnt a lot at that company, but I recognised that my experience wasn’t sufficient for them to use me.

Lesson 3: embrace change. I became a contractor. I worked in different places, and had more interviews than I’ve ever had in my life. I met people. I saw areas of IT which I hadn’t considered before. Finally, two years later, with two years of successes and failures behind me, I thought about the company which turned me down, reapplied, and got in. Now here I am! And here’s where, I think, my apprenticeship has really started. I’ve never been around such a wealth of information before, or met so many people who knew so much. But there are still things in my past which are important.

Lesson 4: learn from mistakes. Not just your own. I have an inkling that as soon as I’m in the same position as some of the managers whose projects struggled to take wing, I’ll have a better appreciation of the problems they were facing, but for the moment I’m just keeping a mental list of the things they did that didn’t work, things they didn’t do that might have helped, and things I should have said at the time with a little more insistence than I did. Sometimes people at the bottom have a better idea of what’s going on than the project managers looking down at them. At the bottom, looking up, you can see the vultures circling. This is why I love Agile so much; because communication makes it really hard for problems to be hidden or ignored. My current project has its problems, but at least we all recognise them, and can prioritise and fix them where there’s time.

Lesson 5: learn from successes. Not just your own. I’m also keeping a mental list of things which I’ve seen and thought, “That’s a great idea! If I’m ever in a position of authority, I’ll do that too.” One of the things I’ve learnt recently is that I don’t have to actually be in authority to make change happen – people do listen to ideas, and if they don’t make changes it’s probably for a good reason – so this lesson is even more important to me than it used to be.

Lesson 6: find someone who seems to know everything, and get the reading list off of them. Be proactive. I’ve found it also helps to read articles, ask for help, turn up at evenings like XtC and GeekNight, and talk with everyone who can spare the time. My software library contains about twenty books.

Must-reads for me are Design Patterns, XP Explained and Refactoring. Other books I’m reading include Working with Legacy Code, Domain Driven Design and The Mythical Man Month.

Twenty books at about £25 each is about £500. I occasionally borrow from colleagues and lend books out too. The earnings that those books have bought me are worth far more than the money I’ve spent on them, and worth more still is the satisfaction I’m getting from knowing that I’m doing the best job I can (though I know I’ll do a better job next year, and a better job the year after that). Plus I love the smell of books, the weight of them and the ease of reading them off-screen. I’m a fan of writers, of anyone who’s been so certain of their knowledge or idea that they’ve not only committed it to paper, they’ve persuaded someone else that it’s worth doing too. So, buy books. Giving money to writers and publishers is a good cause, and occasionally you find out something interesting.

Dave, if you read this, I hope it’s useful. To anyone else who made it this far down the page and my life, thanks for sticking with me. These are lessons which I’ve learnt (mostly), and this is my story, but it only happened because of a great number of other people’s stories intertwined with this one. And it isn’t finished yet. Not by a long way.

Last night at the XtC, Rachel Davies and Tim Bacon did a dry run of their “Informative Workspace” workshop, to be held at XP2005.

Rachel said that she’d taken the term “Informative Workspace” from one of the new practices in the 2nd edition of “XP Explained”. The workshop explores the various ways in which tacit information is made explicit in Agile teams, small ceremonies and rituals attached to information presentation, the benefits of information delivery vs. the hindrance of information overload and interruption, socially bonding information, etc.

Hearing other participant’s stories of their own workspaces and how information was delivered, from a whiteboard-clad wall to blue flashing lights or strange noises to indicate the success or failure of a process, was entertaining. If you find yourself at XP 2005 and are lost as to which session to attend next, I would recommend this. I came away with some new ideas, a good understanding of the need to balance interruption and information delivery, appreciation of the kind of cultures in which certain delivery systems are appropriate, and a new awareness of the number of systems which are in place in my own project.

Good luck to Rachel and Tim, and thanks for a fascinating evening.

Darren and I had a chat about my article on arrogance. He said he didn’t like my “anti-pragmatic” stance.

I was confused. “But… I wasn’t anti-pragmatic. Was I? I said that idealists need to listen more to pragmatists. I parodied our idealistic attitudes and countered them with pragmatism. Why did my post seem anti-pragmatic to you?”

“Well,” he said, “you started talking about us (idealists) and them (pragmatists).” And that kind of talk led Darren (and others, we theorize) to an assumption that the us position is going to be defended against the them in the subsequent argument.

People see what they expect. I remember a television program in which two people carrying a door walked between a man who had stopped to ask a student for directions. While the door passed between them, the direction-seeker behind the door was switched to another man – not necessarily physically similar. I don’t remember exactly how many people didn’t notice the switch, but I remember it being surprising (like 50%).

So my post led Darren to expect a confrontational argument in which I backed my position as an idealist, and initially at least, that’s what he saw. (It wasn’t his only criticism, but it was the only one that I thought was brutally unfair. )

Maybe this kind of use of language is part of the “perception of arrogance” problem. Nobody expects self-deprecation. Who builds up a position for themselves and then attacks it? I did, uncharacteristically, and at least one person didn’t notice.

We also talked about negative and polarising language; the use of terms such as right which implies wrong, and the battleground formed by us and them. There’s no logic to it. Arguments aren’t won or lost on logic alone, nor can people be persuaded by it, but it always surprises me when very logically-minded people misunderstand communication – and makes me wonder how often I misunderstand, too.