Liz Keogh, lunivore

I will be there. If you’re there too, and anything I’ve written makes you feel like talking to me – even if it’s to tell me that Vogons write better poetry than I do – say Hi. I will be female, wearing glasses and sporting long red hair.

Thanks to Dave for clarifying, again, his concept of an apprentice as someone who’s been working in Software Development for less than five years.

I think that even within my first five years of software development, there were levels of promotion which may have been less clear-cut than a move into management. Becoming a software designer, learning to write customer requirements and convert them into acceptance tests, and mentoring junior developers were roles which I took on during this apprenticeship as I felt ready for them. So I understand and agree with Resist the Promotion, but I still think it’s important to recognise your own growth and take the next steps as they come to you.

Dave, you don’t have comments turned on in your blog, so I’m putting this here. A couple of phrases in your post gave me the impression that Resist the Promotion vs Step On Up might have annoyed you; if so, I apologise. My image of you and Pat as masters was based on my perception of your blogs, and your lovely website, not through any personal knowledge of you or your client work. As ever, perception is an interesting phenomenon, and again I learn something that should have been common sense: just because people know things that you don’t doesn’t mean they’re more experienced than you are.

Reading the discussions between Patrick Morrison and Dave Hoover on Dave’s pattern, Resist the Promotion (here and here), I hereby declare them to both be right and propose a new pattern, Step On Up.

This is what I think I’m doing by becoming an Agile Coach.

Dave says that he’s aiming his patterns at new programmers, but I’ve found that a great deal of them are applicable to where I am in my career. I don’t feel as though I’ve finished my apprenticeship yet, despite having over seven years of industry experience. Maybe they’re applicable at various stages of apprenticeship. I’ve recently come to realise that there’s a whole side to software development which involves communication, accurate feedback, customer interaction and other elements which have more to do with psychology than computing. Understanding the process which goes on in the minds of those involved in software production has to be an important part of software development. I accept that it’s important to understand the technical aspects of the job in depth, and therefore resisting a promotion is important, but I feel it’s equally important to recognise the point at which you as a developer can move on to help facilitate the process which turns ideas into reality.

The difference, I think, between the way Pat and Dave describe the transition to management is that Dave’s concept of promotion is something which someone else decides you’re ready for, whereas Patrick describes managers who really are ready. They’ve moved naturally into roles for which they’re suited, and as a result have redefined their value to the team. It’s very tempting to think that these managers, with their perfect lives and perfect facilitating abilities, have come to the end of their apprenticeships and are now considered to be masters. I don’t think that ever happens. They’ve just taken a natural step which has pushed them on to another level of learning, beyond the ken of us mere mortals.

At the end of the day, the universe is a highly intertwined place. Unless you’re God, you have no way of becoming master of the many interactions and influences which affect your project. Unless you’re a Buddhist who’s achieved enlightenment, I very much doubt that you’re master of your own head. In the same way that an elderly monk might teach a young novice, yet never cease seeking enlightenment himself, I can’t imagine a master who ever stops trying to master his craft. Apprenticeship has to be a life-long pursuit; a journey towards an unreachable destination, but an important journey nontheless.

Dave and Pat, if you read this; I’d be interested to know if this makes any sense to you. From my point of view, you’re masters. Do you consider yourselves to have finished your apprenticeships yet?

Occasionally, getting together with my colleagues from across the world, I’m suddenly reminded of how small the Earth is, and how many gulfs and divisions there are on this little planet.

Countries represented at our UK Away Day on Saturday included: US, Canada, Australia, China, India, South Africa, New Zealand, Brazil and no doubt a dozen more. We don’t have anyone (AFAIK) from Zimbabwe, Iraq, Cambodia, Afghanistan, Palestine or any of the other countries where things are ‘difficult’, and perhaps less westernised (by which I mean having access to decent sanitation, healthcare, world-wide communication systems like telephone and the internet, roads, railways, a stable economy etc. – the things which need to exist for a country to be part of a global community. I have strong opinions on morality, fundamentalist religion and various systems of government, but I don’t mean to bring them into this post.)

I’d love to see the world made whole; for people from every country to be working with people from every other. There will always be ‘difficulties’ wherever there’s a difference of opinion, but there are so many challenges thrown at us by nature that it seems a waste for us to be making our own. I’d love to see this happen within my lifetime. It seems as though it should be possible.

If the world started working together, we’d finally be able to concentrate on the real issues, like sorting out Earth’s environment and colonising Mars. If humanity isn’t going to be a blip in the cosmos then we’ve got to get off planet at some point in the future. It’ll take generations to achieve. It’ll take some brave pioneers, and I don’t doubt that people will die trying. It’ll mean taking technology to limits that we can imagine, but not yet realise. It’s going to be exciting, and fun, and scary. I won’t be around to see it, but I can see the start of it here in my own office; we’ve just been introduced to three gentlemen who are joining our client from India.

The world is getting smaller. I wonder how long it will be before we decide that it’s not big enough any more.

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.