Bio Dave spends the majority of his time as a coach and lead for the Craftsmanship Studio at Obtiva. His passion for learning and mentoring inspired the writing of Software Craftsmanship: From Apprentice to Journeyman.
The International Ruby Conference or RubyConf, is the official annual gathering of Ruby developers from around the world, founded in 2001. RubyConf has historically been the venue for announcements regarding the future of the Ruby programming language as well as a place for the creators of all the major Ruby implementations to show their work, compare notes and involve the community
1. I am with Dave Hoover of Obtiva in Chicago and coincidentally Dave is an old friend of mine, so I have to ask you, you have book that just came out and it's pretty cool stuff: "Apprenticeship patterns". Tell us a little bit about the book.
It's kind of inspired by Pete McBreen's book that was published back in 2001. The name of the book is "Software Craftsmanship: The New Imperative". I read that and it kind of helped me understand where I was, I am a self taught programmer so I didn't have a computer science education, I didn't have a software engineering education and I really didn't feel that I was cut out for those two labels and reading Pete's book kind of game me a label I could attach to myself. But his book was really written at more senior people, people that had the power and opportunities to create teams that kind of molded around the ideas of software craftsmanship.
The idea was that I felt this was this kind of hole because I read his book and I was inspired then, but there really wasn't a good like intro book for newbies, somebody like me 8 years ago who was just kind of looking for how to become a great software developer. So this is targeted at new people coming into the profession either as like recent grads or self taught people and helping them kind of give them some of the patterns, the behavioral patterns not design patterns, but behavioral patterns that can help them get up to the next level. It's definitely common sense to like experience people, just like design patterns are often common sense. One would be like "be the worst, be the worst person on your team", it's grabbed from a quote from a musician who is giving advice.
And I think that's in the passionate programmer because Chad and I are reading the same blog the quoted that musician. And a lot of these patterns are pulled from my experiences being a self taught guy.
It was kind of an interesting transition for me from my previous career. I was 26, I was a family therapist, I actually enjoyed that career, but I'd always been interested in computers and it was 2000 and the .com boom was exploding and I wanted to give it try. So I switched careers and as I was saying I was 26 years old, I had just finished a Masters degree in family therapy, so I was all super reflective and kind of thinking what I was doing all the time.
Yes, for 4 years, from undergrad. So I felt I was in a kind of unique position of somebody who was super passionate about this new thing I was doing, but I was also a little bit older and I had to have some kind of training about how to introspect on my experiences more than most people. So anyway like in 2005 a couple of series of events happened that kind of led me thinking: "Oh, there is this space here kind of between the pragmatic programmer and Pete McBreen's "Software Craftsmanship" where maybe there's something that's missing that I could fill in. So from there I just started writing these patterns and just kind of took off a little bit like you invited me to come speaking at Atlanta for that user group.
No, it was really just a pattern language at that point, it was like a wiki and I started publishing it online and then grabbed the coauthor who started interviewing people ... extracted from my experience is that I felt it had a kind of successful apprenticeship, I didn't have a formal apprenticeship but it just kind of cobbled one together using these patterns.
What we did was just kind of tested the patterns that we've been putting together. A pattern isn't a pattern if it's just Dave's experience or Adewale experience. Adewale Oshineye lives in London, works for Google. Anyway so we wanted to just kind of test these little theories or one instance of something that worked for us because we can't really call it a pattern language unless it's true for a community or like a significant population of people. So that helped us kind of refine whether they were just idiosyncratic for us or general principles. So it wasn't super structured, we are basically developing patterns at a certain point and then we'd get a group of people like just over email and ask them whether they fit them it or not and then people would be like: "No, I didn't." that was like the opposite experience for me.
Well, in a behavioral patterns book like this those stories are basically the code you'd find in a design patterns book. You can't just have the UML diagrams and then that's it; you have to see the code. So those stories are really kind of the codified or like an instance of the actual pattern. So Desi had a story in there about how she started. We tried to make you that we found at least one story per pattern and there's between 20-30 patterns.
One that really worked for me and it was easy for me because of my training was expose your ignorance, which it's difficult especially people in a consulting situation to show your client or the code developers that are with you that you don't know something.
It is. It really is and it's risky. Basically the idea is if you hide your ignorance then your setting yourself to learn more slowly, but if you can expose your ignorance especially if you consider yourself an apprentice you know what kind of way you're at, you're kind of low, you're still at the beginning of your career. It should be fairly easy to do that. If you understand where you are and exposing your ignorance should basically facilitate you learning and ultimately especially for consultants or people like in that role it basically exposes the learning process to the people around you. Instead of feigning incompetence and maybe in your off hours trying and figure things out, you are letting them see. I didn't know about this this week and then the next week I'm like kicking ass at it and so ultimately believing that the power of learning I think is more important than the actual knowledge that you have. You can show a client or an employer that you can learn it just opens up tons of possibilities.
11. So one last question specifically about the book, apprentices obviously are the target market so they should go get it. Why should employers get this book for their people and how would they present it to them?
Like Aslak was considering he it trying to maybe get it for all at Bekk.
I guess it would be a way to just give a vocabulary for people and that's ultimately the best part of a pattern language, it's just naming things.
Yes. And it's not something that I would ever want. I mean we have an apprenticeship at Obtiva, but it only lasts 6 months and they are not done with their apprenticeship after those 6 months...
14. Reading the book I got the sense that many of the people that I work with even those that have years of experience already, would still fit into an apprenticeship model because they haven't really come very far in terms of learning ...
I agree. I wouldn't want to put labels on anybody, it's something that was really useful for me to call myself an apprentice, I didn't really talk about it, but it was a really useful gauge of where I thought I was, so half way through my time at Thoughtworks I still thought like I was in a press and during that time ... like a transition.
Yes, about 5. Middle 2005 I felt it was like I made that transition.
Yes, for sure. I mean it's really actually not meant for people in a formal apprenticeship at all. I mean it's still helpful for those people but there is obviously a small number of people that have that opportunity. It's really for people that were like me or they was just like kind trying to find a way to some tough IT organization and then find my way into better organizations and be able to create my own organizations.