Apprenticeship patterns – my story

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.

This entry was posted in Uncategorized. Bookmark the permalink.

6 Responses to Apprenticeship patterns – my story

  1. anonymous says:

    Elizabeth, it’s really interesting to read about your career path. Do you have any tips to someone who’s considering getting a consulting job?

  2. sirenian says:

    Yes; consider what you’re going to get out of it that you’re not already getting. The work is varied, but uncertain, so you never know where you’re going to end up. It’s nice to have a company behind you who can help you in the career path, but you still have to be proactive about getting that help. The uncertainty can be problematic if you’ve got kids (I’m told).

    I think the most important thing I’d look for in a consultancy is a sense of integrity. I wouldn’t want to work for a place which just used you as a bum-on-seat-raking-the-money-in. That kind of place tends to spin the work out for as long as possible in order to make as much money as possible, and won’t empower the client. I can’t imagine enjoying ripping other companies off. My job here is to make myself redundant before I leave, which should be fairly soon, and it’s fun to be in an environment where everyone is learning from everyone else.

    I think the most important skill that consultancies would look for is the ability to communicate clearly and accurately, which includes listening and making sure you’ve understood as well as getting your own point across. Technical experience is useful, but can be learnt.

    I’m (also) reading a book which Darren lent me: The Secrets of Consulting, by Gerald M. Weinberg. Three pages in and hooked!

    Good luck, whatever you decide to do!

  3. anonymous says:

    Hello Elizabeth,

    Just wanted to say that you’re spot on regarding the value of owning (and reading) a good selection of software development books. Personally I felt that my coding career started improving when I stopped reading technology-specific Wrox tomes that were obsolete within six months and starting buying timeless Addison-Wesley hardbacks.

    Some of the titles on my list of “essentials” for any apprentice would be Code Complete, Domain Driven Design, Refactoring, and then perhaps Patterns of Enterprise Application Architecture. If I was in a cynical mood I’d also advise a copy of “The Career Programmer – Guerilla Tactics for an Imperfect World” stashed in a laptop pocket..

    Anyway, congratulations on your career successes thus far and good luck for the future. Keep up the interesting blogging!

    Best wishes,
    Ian Nelson

  4. rohan_kini says:

    interesting write up šŸ™‚

  5. sirenian says:

    Thanks for the recommendations. PoEA is on my list of books to buy when I’ve finished the ones I’ve got. That last one sounds like it might be entertaining; I like books which slip in under the radar.

Leave a Reply

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

You are commenting using your 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