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.
2. Who is your book targeted to? What's its audience?
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.
3. That one is pretty popular actually.
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.
4. I was about to ask you. So Dave, what qualifies you to write this book at this time?
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.
5. Did you actually practice family therapy for a while?
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.
6. That's right and you didn't have any intention to write a book then.
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.
7. What are some examples of the interview questions that you gave the apprentices for you book?
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.
10. It's almost an inherent conflict of interest.
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.
12. Aslak Hellesøy - the CTO of Bekk in Norway.
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.
13. It's potentially insulting to call someone an apprentice if they are not expecting that, right?
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...
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.
15. And half way through your time at Thoughworks was 6 year into your career.
Yes, about 5. Middle 2005 I felt it was like I made that transition.
16. So finally is the book appropriate even in settings where craftsmanship is not an imperative?
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.