RR Software Craftsmanship with Noel Rappin
- Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman
- Software Craftsmanship
- Glenn Vanderburg's RailsConf talk
- Apprenticeship Programs
- Code Retreats
- Global Code Retreat day
- Software Craftsmanship Manifesto
- Dave Hoover's Apprenticeship Patterns book
- Capability Maturity Model
- omphaloskepsis: the contemplation of one's navel (Thanks, Josh)
JAMES: Maybe it's just me, but I think software has been like, in search for a metaphor for a long time.
CHUCK: Hello, and welcome to episode 30 of the Ruby Rogues podcast. This week on our panel, we have Noel Rappin.
CHUCK: Do you wanna introduce yourself, Noel since it's your first time?
CHUCK: [Chuckles] Thanks. All right, we also have Avdi Grimm.
AVDI: Hello, hello.
CHUCK: James Edward Gray.
JAMES: Yes, I am here. Got sick again, so if you hear me sniffling throughout the podcast, that's why.
CHUCK: Josh Susser.
JOSH: Hey everybody, I'm not sick, but I am disadvantaged by having a pacific time zone this morning.
CHUCK: [Chuckles] And I'm Charles Max Wood from teachmetocode.com. This week, we are going to talk about software craftsmanship. And Noel was actually over at Software Craftsmanship North America. Is that what it is?
NOEL: Yeah, SCNA - Software Craftsmanship North America.
CHUCK: Yeah, so he's over at the conference over there and he's been thinking about this stuff over the last week, and so, we thought we’d talk about it. So I think Noel, you pretty involved I guess in the community, or at least you made it to the conference. Do you wanna kind of introduce the topic and then we can go from there?
NOEL: Sure. CSNA as a conference, this was the third annual, and we have not, we are very close to 300 people there, talking about various topics relating to software craftsmanship, and the idea that software is a craft that is worth doing well.
We had opening keynote with Corey Haines, closing keynote was Chad Fowler, and we also had Gary Bernhardt from Destroy all Software who gave a really great talk, and Uncle Bob was there, Zed Shaw actually was there as well, gave a talk. And a lot of really good conversation in the hallway, people talking about what the limits are of software craftsmanship, and writing good code, and taking pride in your work. And also to some extent, really what the limit of that is, in terms of business value or providing the value that you are expected to provide.
CHUCK: Right. So it's rather interesting. I've talked to several people that are part of the community. I've actually interviewed Corey Haines, Michael Martin, Dave Hoover and a couple of other people about things related to this on the Teach Me To Code podcast. And it's really interesting, some of the things that come out of this, both from the sense of, “Are we craftsman?” “What does that mean?” As well as some of the principles from the software craftsmanship manifesto. And I'm wondering, how much of a sense did you get at the conference, that people were thinking about, maybe the manifesto.
NOEL: I think the manifesto itself is more of a starting plan. Like I said, it's not something that we all sort of pledge allegiance to. I think that there was a real sense at the conference, that these are the values that we value doing our work well, and then sort of what does that mean. How does that affect what we do on a day to day basis, does it change any of our practices, does it change the way we approach our jobs or our communities.
I think there was a straw man argument that the software craftsmanship movement is really just about going off in a corner and polishing their code into like green. And that really wasn’t the tone the speakers… or the tone of the talks… or the the the tone of the conversations I was involved in. It was really about how we do our job well, within the constraints of the value that we need to provide, and the expectations that are on us, in the environments that we work in.
JOSH: So Noel, you said that the manifesto wasn’t something that you pledge your allegiance to, but I go and I look at manifesto.softwarecraftsmanship.org, there's like hundreds of names signed in to this. [Chuckles]
NOEL: Sure. What I'm saying is, is that the point of the conference is not… the point of the conference and the point of the conversations that is going on in the community as I see it, are not about obedience to this manifesto, but are about how to apply this as a set of values. We believe that we bring the best values to our jobs, when we do our work well. And we believe that that’s how we create long term value, that’s how we create short term value. How does that affect our day to day approach?
JAMES: So you didn’t have to [unintelligible] or anything on the way in?
NOEL: Well, there's a tattoo, but I can't really talk about that.
JAMES: [Chuckles] Yeah, it's in an embarrassing location. I understand.
CHUCK: Yeah, and then a secret handshake, you know.
JAMES: There was a video from Glenn Vanderburgh at Rails Conf, it's 2007, 2008 somewhere in there.
NOEL: I think so, he also gave a keynote this year,. And he spoken at CSNA as well, this weekend.
JAMES: Gotcha, well I went back and watched the old Rails Conf talk, and basically in that talk, he seem to say that it seemed like he was trying to say… I think that was back in the time period where some people were dissolution with calling ourselves ‘engineers’, and I think he was trying to define what we do a little better. And he did think that what we do is at least in part engineering, but then he layered on also the craftsmanship.
NOEL: He is talking this weekend specifically about the overlap between the view of what we do as being engineering, the view of what we do as being craftsmanship, and the view of what we do being art, and how there are aspects of all of that in what we do… I'm just paraphrasing that, but he was looking at the elements of all of those disciplines, terminologies, in terms of the way that we affect the we think about what we do.
CHUCK: Yeah, that was the general gist I got from the keynote that he gave at Rails Conf. I thought it was last year…
NOEL: Yeah, he gave a keynote this year and yes, and he’s talk at CSNA was similar, but not identical.
CHUCK: All right, so I really liked what his points where he kind of started out and said, “This is how regular engineering works, and this is how software engineering works. And here’s how we kind of move into, this is what craftsman do, and this is how it's similar to what we do…” And I really liked it. One thing that really bothered me when I first started getting involved in software craftsmanship, and eventually, kind of maybe not get as involved as I would have in the community, was mainly because people were having this argument over what software craftsmanship meant, and I really felt like they were having the wrong… they were arguing over something that we didn’t make a difference. Mainly, they were saying, “Well, ancient craftsman’s had guilds; they did this, and they did this, and they did that, and they did the other.” And my thinking was, “Look, this was about writing better software, so it doesn’t matter what they did, unless there's a lesson there.”
NOEL: Right. I think a couple of things in my head out of that. One is that I think that one of the things that Glenn was saying was the idea that we sort of misinterpreted what engineering is, and that may have negatively affected the way that we see software engineering that we expect that engineering is all mathematical and formula and practice. It's not. And I think that the metaphor stuff, I don’t know. I personally feel like we can sometimes get a little precious with it; the naming and stuff like that.
I mean we have at Obtiva and on Groupon, we have apprenticeships, where somebody comes in and does something that is at least analogous to a classic guild apprenticeship where they work with experienced developers. But honestly, there's not much more… honestly, the difference apprenticeship and calling that it an intern or an entry level position, I'm not sure what the practical difference is. I think that there's value in thinking of what we do as having craft to it. I find that in dealing with non-programmers, it's very hard to get across the idea that there's an aesthetic to software development. And I think that craftsmanship can be a useful metaphor for thinking about what we do, but yeah, I think that the metaphor can get pushed too far.
JOSH: So I think that there's a whole spectrum of professionalism, and how you approach being a software development perhaps, that a lot of… that people who come in this podcast to talk, and the people who listen to this podcast, are already so far out on that scale about how they do their work, that for… the conversation that we tend to have about software craftsmanship is a little bit like how many angels dance on the head of the pin.
NOEL: Yeah, there are aspects of that, sure.
JOSH: But you know, if you look at the vast majority of people who write software for a living, on the planet or even expand that to the people who write software for any purposes, the professional class of software developer who works at Groupon or at any of these big companies that make a lot of money off of software, is already doing an amazingly good, professional job.
JAMES: I think that's pretty accurate. I was going to say that if you are someone who is into software craftsmanship or agile programming, or read the pragmatic programmer religiously, or you're just Kent Beck, or you’re almost … about figuring out your process and codifying it. If you are somebody who is doing any of those things, then you have a recipe for success -- in my opinion. You're viewing what you do, you're tracking what you do, and trying to improve on the formula all the time. And basically, that’s how you get better at something, I think.
CHUCK: Yeah, I really think that’s really kind of the point of software craftsmanship, but again… and I´ll bring this up over and over I think, because I mean, really the issues that I had trying to get involved and understand software craftsmanship of the issues that I have really came down to the community, because the principles are pretty sound, and they make a lot of sense, but there are people out there that do this kind of stuff.
One of the other things that really make me crazy, was just that… [chuckles] I'm sorry, I'm not going to turn this into a gripe session, I only have one or two more things that really bother me about software craftsmanship. But the other one was that it seemed like a lot of people were going out of their way to kind of get in other people’s face, and go, “Are you a craftsman?” Like, do you understand the terms? Are you part of the in crowd?
JOSH: Well Chuck, that was the point I was trying to make is that, if we are having a conversation about software craftsmanship and how to be excellent software developers and professionals, then it's a bit of an echo chamber. So is the point of the conversation about software craftsmanship in general, for the people who are already into being good software developers and professionals? Or is it to try and expand that thinking to like all the other software developers out there, who may not already be committed to excellence?
NOEL: I think a lot of the conversation that was going on… I think that one of the things that was striking about the conference itself, and we can use that as sort of indicative of where the community is, more or less. Two things struck me about the content of the talks; one is that a fair number of talks were at least… in some way or another, skeptical of the idea that this was going to be a magic bolt that is going to solve of a lot of problems. I think… and we're exploring maybe what that means in practice.
And also I think a big emphasis -- this year in particular -- was on teaching, and bringing people into the community, that software community in general, the craftsmanship community in particular. I think that that’s certainly an area that the people that I know that are passionate about this, have been putting a lot of effort lately, and I think that's the very important area for us to go.
JAMES: I think that’s actually probably one of the strengths of the software craftsmanship movement is the general interest in treating it kind of in the more old school guilds and apprenticeships, that in my opinion, that’s probably the most useful way to learn programming, right? In that…
NOEL: And we do a lot of that; obviously we have apprenticeships, a lot of the people here, and in the Chicago sort of Ruby community or craftsmanship community are involved with mentoring new programmers at Code Academy, which is a Chicago-local programming school. We are trying very hard to be doing that kind of stuff.
CHUCK: Yeah, that’s one thing that I did notice too is that, as I talk to these different people who are involved, they are all out in Chicago area, you have people like Uncle Bob, and Mike and Dave and some of the guys out there in Groupon, you know, it's really interesting that it's kind of there and centralized around there, but I really do admire a lot of the things that you guys do, to be involved. I mean, one thing is Corey Haines’ Code Retreats.
NOEL: Right. Yeah, we should talk about that with the day coming up. Has anybody here done a code retreat?
CHUCK: No, I signed up for…
JAMES: I haven’t.
NOEL: Oh, okay.
AVDI: I keep missing them.
NOEL: You keep missing them? Okay. Am I the only one here who actually done one? We did one where we brought Corey last year. Are you guys familiar with the basic idea?
JOSH: Yeah, let me see if I understand. I haven’t done one, but basically, you spend the day writing code that you know you're going to throw away, so that you can work on technique, rather than the thing you are creating.
NOEL: Yeah, the basic idea is the facilitator gets… you work in a pair, and you work typically on Conway’s Game of Life, and you do it in 45 minutes chunks. And at the end of each… because the problem with something… an experienced programmer can probably solve in about an hour, but you have 45 minutes. So the idea is you know you are not going to finish it, and you know you are not going to keep the code, so the idea is to explore different techniques.
And typically, the first time around, you do your favorite technique, and that over time, there are suggestions to try a stricter, test-driven technique, or to try it in a different language, or to try a radically different approach to the problem. And it's a lot of fun, and I was a little skeptical of it going in, but it really does was… it’s definitely something that will make you think about a way that you approach just sitting down in a keyboard and typing code.
CHUCK: I also understand that don’t you work in like, small things or something to work on.
NOEL: Pairs, typically.
CHUCK: Since then as you rotate, you also pick stuff up from people at work.
NOEL: Yeah, the idea is that, at the 45 minuet mark, you throw out what you have, and you rotate pairs.
JAMES: So to kind of expand, on December 3rd I believe it is, is Global Code Retreat Day, right? So groups are encouraged all over, to get together and try this experiment locally, so that you can gain a value of this. And I believe there's a website that walks you through how to facilitate one, and stuff like that.
NOEL: Yeah, coderetreat.com.
CHUCK: Yeah. And I know that the spots in my local area went really, really fast. In a couple of days, it was full. So we'll go out there to look. If it is full, then yeah like James said, see about facilitating one. But there's probably one within a reasonable distance from you, if you are near a major metropolitan area.
JAMES: So, how about the software craftsmanship manifesto? Shall we go through it?
JAMES: Okay, so I thought maybe we can discuss it point by point. I find it interesting.
NOEL: This is obviously intended to be an extension of the agile manifesto. It's a point by point extension.
JAMES: Right, and it becomes painfully clear, just almost immediately. So here’s the opening, here's the Manifesto for Software Craftsmanship, raising the bar:
“As aspiring Software Craftsmen, we are raising the bar of professional software development by practicing it, and helping others learn the craft. Through this work, we have come to value:
Not only working software, but also well-crafted software.”
That’s the point that software craftsmanship adds. So maybe we can stop and talk about that one for a little bit, “well-crafted software”.
NOEL: Yeah, the one speaker who actually talked about in CSNA I think got a lot of eye rolls in the audience, because somebody did talk about actually signing his code files.
CHUCK: The only signing I've ever seen was when I was working at Public Engines, there was a feature where you can draw an area of a map, and then it will tell you all the crimes that occurred in that area, and they neglected to put a size limit on there. And so one of the guy that’s on the team that worked on the flash component that did that, actually signed his name across the united states.
CHUCK: I don’t think that’s what we mean though.
NOEL: No, I think in terms of this, there's two angles to this; one is that, we as developers are sort of long-term, more satisfied in our jobs, when we feel like we are doing something well. And secondarily, I think the feeling is that we are producing, over the long term, we are producing value better for whoever it is we are designing software for. We are just doing… that will go better that’s a long term process, if we are designing long term… if we are crafting ourselves for a while.
JAMES: And I think this one is kind of a no-brainer, right? I mean, almost every aspect of software strategy begins with techniques for building better code. I mean, that makes it easier to build, more maintainable. These are things we understood, like 30-40 years ago.
CHUCK: Well, we've spent 29 episode talking a lot of the principles… so.
JOSH: [Chuckles] So I'm going to be devil’s advocate here for a bit, so well-crafted software... I mean, duh.
JOSH: [Chuckles] Yeah, thank you. So yeah, the pts. in the manifesto, I think they are hard to argue, that you should do anything different. The question is, since it's so hard to argue that you should do anything different, what's the point of arguing for them? And well-crafted software in particular, “Well, okay don’t like crap.” That makes total sense to me as someone who makes a living writing software, you wanna be producing something that other people feel is worth paying you for. So well-crafted software makes total sense.
When Kent was on, we talked a little bit about this, and he said that his focus for developing software that he thought was of good quality, was coming from the perspective of having compassion for somebody else who’s going to have to maintain your software in the future. And I think that that sort of… that makes it that much more concrete about what you mean by “well-crafted” and what's the point of… rather than just polishing this module, until it shines and you can see your face in it, what's the real goal behind saying that your software is well-crafted.
NOEL: I think part of the goal is the second part of manifesto, which is to be steadily adding value. I don’t mean to jump ahead or anything like that.
JOSH: That’s fine, I did. [chuckles]
JOSH: Right. But I think the point of well-crafted software is that it enables you to steadily add value. But I think there's also a legitimate conversation of what the limits are. I mean, one of the speakers at the conference pulled out the line you probably heard, what do we call people who shit big balls of mud? “Millionaires.” I think that there's a limit to… it's interesting to talk about where the limits of software craftsmanship is, or where the short-term becomes a long term.
JAMES: So I guess I´ll go ahead and catch us up here. To expand on the point Noel just brought up, the second point of the manifesto, there's only four main points, and the second one is, not only responding to change – again, that’s directly out of the agile manifesto -- but also steadily adding value. So that’s the new thing that… later on.
I think Avdi puts this one the best. I've heard her mention it before, that you like write crap software and you can make that work, as long as you are willing to accept more bugs and slower feature return, right? And I think it's what they are applying to here, by building better software we can more easily move it in different directions, right?
CHUCK: Yeah, one thing I wanna point out with this too, and it's kind of along the same lines that you were talking about James, is that if you writing poor software, and it takes longer to turn out those features, you can still overcome that, if you are consistently getting value. And the reason is is because as you find these issues and you fix them, so that the software is easier to maintain, easier to extend, then you start to build speed, because you are getting that momentum back. It's not as hard to extend it, the next time you have to touch that piece of software. So adding value isn’t necessarily adding features, it may be fixing deficiencies in the code.
JOSH: And this goes back to our conversation on technical debt, and where and how do you add value. You are adding value by removing bad things in the software, or by adding features or what have you. But again, putting on my devil’s advocate hat, if you are not adding value when you are touching software, what are you doing to it?
CHUCK: Well, also you’re being paid to work on the code, so they are putting value in to you, to put value into the code. So is that necessarily…
NOEL: Again, to some extent, this isn’t necessarily because people thought… I don’t know that there was a huge movement that programmers should not be steadily adding value to their projects. I think that to some extent, it’s an attempt to really extend or make explicit… something that was not in the agile manifesto, because it was one of the criticisms of the agile manifesto was that they didn’t talk about adding value. I may be misinterpreting history there, but I remember that being one of the criticisms of the agile manifesto. The value to the end client, or whoever you were building the software for, was what they addressed.
JOSH: Well, I think it's fair to criticize the agile manifesto in that regard. I know that even Kent has said that a lot of the original XP stuff was sort of a defensive move on part of developers to avoid some responsibility in the process.
NOEL: I was going to say, before I really started thinking about this in terms of craftsmanship, when I first became a professional developer, my metaphor for this is really just like a professional in any other field; somebody was specialized now, said you might go to for a specialized task… a more lofty like a doctor, or a lawyer, or also like a plumber or a mechanic. Sometimes I think plumber or mechanic are the best metaphors for what we do. And that somebody is coming to me, because I had technical knowledge that they don’t, so they need me to do a technical task. So it's incumbent on me, to point out the pitfalls in the way that they are approaching the problem.
And to be an honest broker, in terms of adding value, in terms of consistently doing the best that I can at advocating for the technical needs of the project, the same way that you would expect you would hope that a professional came out to would advocate for the technical needs of having to keep your furnace clean, in the same way that you would expect… that you would go to a doctor and expect a certain level… that the doctor will tell you that you have, that you have certain things that you need to do to keep yourself healthy. I think that that's still the way that I kind of perceive software craftsmanship.
AVDI: I think my view of it is pretty similar. I was thinking about this the other day, thinking about what I think of as craftsmanship and professionalism. I realized, when I think about hiring a professional, when I think about going out and finding someone I think is really a professional, I'm actually looking for somebody who will say no to me. If I pay top dollar, I'm paying top dollar, partly to have somebody say no to me. Like if I get somebody… a photographer, If I wanna get a photographer to take some headshots... and photography really is it's a craft, because there's art to it, but there's also an enormous amount of technique.
And I'm expecting that if I say, “Okay, now I wanna be in front of this back drop, and I wanna have this lighting, and I wanna wear this outfit.” I'm expecting a professional to say, “No, no, that’s going to make you look like crap.” “And I'm not going to take that picture. And if you want somebody to take that crappy picture, you are going to hire somebody cheaper.” And so, when I think about, what do I… what's sort of the heuristics that I look for, that’s one of things I look for with hiring somebody outside of software is somebody that will say no.
NOEL: One of the first arguments… this is literally actually one of the first arguments I had with my – for lack of a better word – management in my first software job, was is it ever appropriate for us to say no to a client. That the people who run this company really, and sincerely believe that if we started saying no to a clients, we would soon run out of clients. And I was continually advocating for basically what I just said, that these people came to us expecting professional opinions, and that is incumbent on us to offer professional opinions as to what's going to work and what's not going to work.
JAMES: Okay, so we've thrown around that word “professional” quite a bit, so let me go ahead and read the third point of the manifesto here. I´ll say upfront, this one kind of bothers me a little bit, but we can talk about it. The third point is, “Not only individuals and interactions,” again from the agile manifesto, “…but also a community of professionals.” That’s what software craftsmanship adds.
CHUCK: Yeah, I wanna kind of build off of what Noel was pointing out, that was that it is okay to say yes, or say no to your clients. It's okay to say yes too, but…
NOEL: [Chuckles] It's helpful to say yes sometimes.
CHUCK: [Chuckles] Yeah, “Will you work for me?” “Yes,” usually gets you paid. So I have a couple of clients have very varying technical levels of technical expertise, but there's one in particular that every time I tell them, “No, we don’t wanna do it this way,” or “Yes, we wanna do it this other way,” or whatever. He comes back to me and he's always like, “You're the expert.” And then that’s it. That's the whole conversation, well, you are the expert., so, okay. But the other thing is that there have been a couple of instances where I didn’t have the answer; where, I didn’t actually know the answer to his question or the solution to this problem.
And I think it's just as important as a professional to be able to look at your client and say, “You know, I really don’t know. I can do some research or whatever, but I don’t really have the answer you were looking for.” And you know, really just you know, represent to them what you have to offer and what you don’t. And it actually worked out in my favor, because this particular client had his brother in law coming in, and he is the original developer on Dentrix, which is the dental office management software, and that was the thing that really impressed him over anything else, was that I was willing to just… “Like, I don’t know about that. I don’t have expertise in that area.” But then again, you know, I'm saying, I sure I can learn it, and be professional about that.
AVDI: So to me, the big thing about this point is the community part. I mean, it's easy to forget in a Ruby community, but there are an enormous number of programmers out there that are pretty much living and working outside of any real community. And you know, it's easy for me to forget, because I'm in community all the time, at conferences and online and on Twitter, etcetera. But you know, part of this is just trying to draw… I think trying to get more programmers into that idea of a technical community that kind of hold itself to account and tries to better itself. And there's still, I mean, there's still tons of room for that to grow, because I talk to people every day. I´ll go out to regional conferences, not every day, but I´ll go out to regional conferences, and talk to people that they work with programmers that had never been to like the users group meeting, or anything like that, in our lives.
JAMES: Yeah, I actually really glad you said that, because I didn’t really take this angle on that one. And I run into Ruby programmers, and I ask them, just like you, “Oh yeah, do you go to any local Ruby Users group or regional conferences or whatever.” And when they say, “No.” I instantly think, “Oh, you don’t it.” Like, one of the killer features of Ruby is the community. So like, if you are not in that, then you are missing one of the great strengths of Ruby, you know. It's unfortunate.
JOSH: Yeah, but not everyone is as extroverted as you are, James.
CHUCK: [Chuckles] Well, I've worked with guys that had every excuse under the sun to not got. “Oh well, I´ll come next time.” “But this time, I have to help my wife wash her hair or whatever. It's just, how do you get these people to the point that they care? Where they want to get involved, because it doesn’t just reflect in, “Well, gee I don’t have time to go.” But it really reflected in there, in the principles of what we are talking about here, or they wanna be involved with like whether they are learning to write well-crafted software, where they are interested in other ways that they can add value to whatever they were working on. They don’t even care. All they care about is being there 9 to 5, on the job, and getting by on that. So how do you get them from that mindset to the other?
NOEL: Well, I think the thing you said… that the thing that hit me was they don’t care. Like we have to get people to care, like when people care about part of in the community, then they contribute to it…
JOSH: So a couple of people have said things that are cool about the communities that we experienced, but what's really the… why should they care about being part of a community professionals? If you’re a doctor, then being a part of the professional organization is incredibly important to your practice. If you are not part of the professional organization, you are going to get a really hard time being a successful physician. And if you are a lawyer and you are not part of the bar association or whatever, you are going to have a real problem being a lawyer. But if you are a software developer, you are not part of the professional organization, I think you are probably a successful software engineer.
NOEL: Well yeah, I think that communities exist to serve certain needs. There are place to get mentoring and assistance, there are places to learn about new techniques that you haven’t talked about, there are place to find future collaborators,. I mean, they have anywhere near the level of… they are not reaching the level of being a professional organization. I don’t think that anybody will see that as positive in our community. There's still something about having a shared experience, and with people in the community, that’s powerful, you know, I think and it's not like I'm mister extrovert. So I still do find value in a lot of these events, and getting to meet people that are doing the things to find out what people whose work I really expect that really respect find exciting, and find valuable.
JOSH: You know, we are definitely the choir that you are preaching…
NOEL: Sure. I get that. I get that.
AVDI: There's a story that I hear over and over again, talking to programmer, and its, I spent the first few years of my career working basically as 9 to 5 programmer. I really didn’t care. And something, and it might be something different for each case, but something got them into a community somehow, sort of drew them in; maybe it was a mailing list, maybe somebody dragged them to a users group or something like that, and they had a sort of road to Damascus moment, and discovered this community and started really like talking to people more, and working on their craft more.
And what's notable about all these stories is that they are all so much happier with having discovered the community, and the pride and the work and all that. And so for me, I don’t think everybody has to be a member of our club [chuckles] if it is a club. I don’t think it's something where, “Okay, we need to get all these people in.” But I think it's worth it just for the sheer joy of spreading that joy, because I just see that over and over; these programmers that say, they are so much happier since discovering community, and since embracing community.
JAMES: Yeah, I think it's not that to we have get everybody in. And like Chuck alluded to earlier, there's people that just don’t care, and those people, we probably can't help anyway. I think it's that we have to get people in that want end, that they are searching for that and we need to try to get that, is my opinion.
CHUCK: Yeah, I have to point out that a lot trying to get them involved is pretty kind of selfishly motivated thing, because then being involved and wanting to be a part of the community, and learning some of the stuff that I was picking up at the users groups, would have really made my life easier. So it was really about my happiness with work, rather than where we are going with our careers. But at the same time, I mean, it makes a huge difference working with somebody who cares, and wants to learn these stuff, as opposed to somebody who’s just there to not get fired.
JAMES: So we probably need to get on to the fourth point here soon, but I wanna say one more thing about this third one. The word “professionals” kind of bothers me a bit. And I understand what it is trying to say, that we should be professional about what we do, and how we treat people and stuff like that -- and of course, I fully agree. But I also feel like it kind of pigeon holes us a little bit, that rubs me a little bit the wrong way. I think of people like Aaron Paterson or why the luck stuff; and I don’t think the way they usually comport themselves to something like we tend to throw the professional label on, you know? But they have been very valuable to our community. I mean, in almost immeasurable ways. And so, a little bit, it bothers me that kind of, it almost feels a little bit…
JOSH: So you are saying professional sounds like “don’t be colorful”?
JAMES: Yeah, a little bit bothers me, like we are not allowed to have fun or we are not allowed to do stupid shit, or you know, which is all valuable to what we do.
NOEL: I would hate to see the word “professional” used as a club, to keep valuable people out of the community.
CHUCK: Besides, I've seen Aaron speak here with a certain tie, so…
JOSH: He wore a damn suit and he looks great in it.. [chuckles] He’s professional. [chuckles] But professional I think, is just holding yourself to a high standard of being responsive to you customer.
JAMES: I agree. And I think that’s valuable and stuff. I just hope we never take the other side of that. I think if you said, “a community of professionals,” to the average corporate programmer or something like that, they would take a pretty different meaning from it.
NOEL: My experience with this community, the Ruby community and also the craftsmanship community is that whenever anybody starts coming in, talking about anything that looks like a professional organization, people go nuts. And so I don’t… I don’t think that that’s coming down the pike any time soon.
JOSH: Yeah, there is a potential dark side here though, and that’s anytime you have a community, there is the potential for some individual roles to be excluded or ostracized from it. And you know, I have personal experience with a family member who was basically excluded from his professional community, because he was too Avant garde in his approaches. And you know, he got excluded because he was a threat to them, because he’s innovative.
JAMES: All right, let’s move on to the fourth point. I think we talked that one over pretty good. Number four: “Not only customer collaboration, but also productive partnerships.” And I´ll confess, I don’t really know what they mean by this one, so I would love to hear people explain it.
NOEL: I guess I can talk about how this was interpreted, or at least the way that [unintelligible] sort of in not compliance, but sort of in recognition of that, … as a consultant firm, was very interested in long term partnerships. We are not interested, for the most part, in working somebody who had something that they want to get out in one month; they were interested with somebody that they can work with over a period of years, and that effectively become partners with them, and building trust, and taking a long term interest, in not just their code, but also their business, so that we could both be successful. So to me, that’s what that phrase means.
CHUCK: I've seen that too in my business, working with some of my other clients. It really, really pays off if they feel like you are invested in their product. Not necessarily financially invested, but you care whether or not it fails or it succeeds.
NOEL: Their wins becomes your wins, and your wins becomes their wins.
CHUCK: Yeah, absolutely. And it really pays off. You almost wind up making friends through the whole thing, and you tend to add more value to each other, not just in the traditional “I wrote code for you, you gave me money,” sense, but really learn valuable lessons from some of my clients, because it’s become that kind of a relationship, as opposed to… whatever else it could be, just strictly professional, strictly, “I´ll talk to you about what I want. You write the code.”
NOEL: You certainly don’t wanna be in a situation where the client or customer feels like they've been kidnapped. When I was young, I used to talk about the client-developer relationship in terms of Stockholm syndrome. But I don’t think that… that's not a good long term metaphor for it, you don’t want people who feel like you don’t care about their business, or you don’t care about their wins, and you just care about getting the money. That’s not a productive partnership.
CHUCK: Yeah, I do wanna point out too that I've also been burned by this, when I was a full-time W2 employee, where I’d get invested in the business, and then something would change, or I would find out that the CEO or whatever wasn’t as invested in me, as I was in the company. And so, that in my opinion, isn’t a partnership. But if you can become invested in what you were doing, then you tend to have at least the first two points in this manifesto, coming up naturally, where you give in your best, and you are trying to add value in every way you can, to make it succeed, because you are in it for the long haul, and you care. And it's not just consulting, you can have this in your full time job. Again, you just have to kind of build that kind of a partnership and that kind of relationship with your co-workers, and with the people who are involved in the company.
JAMES: So just to kind of bring these two closer is, one more line in the manifesto after the four main points, it says: “That is in pursuit of the items on the left, we found the items on the right, to be indispensible.” And obviously, the manifesto is laid out, so that the agile items are on the left, and new software craftsmanship items are on the right. So I really think it's part of this secret of what they build here is, and they basically are just refining the agile manifesto, right? Which is probably the only reason anybody takes this very seriously, I would imagine. And there is a way to sign the manifesto if you want to… if you wanna add your support. And it has a very, very lot of signatures, so you can see what that’s like.
CHUCK: I wanna clarify something really quickly. I was being a little bit negative earlier, and like I said before, it has nothing to do with software craftsmanship movement. In fact, I would encourage people to go and check it out and get involved if they can, but I just wanted to voice some of the concerns that I had, because I think it's relevant to talk about some of those things, and make sure that the points and purposes are clarified like, even if some of the people involved on always acting accordingly.
NOEL: And if people wanna get a little bit more background information on this, I’d point them to Glenn Vanderburgh Rails Conf keynote. Also the Apprenticeship Patterns book is a very good book for thinking about… thinking about leveling up in your job, in terms of things that you can do to get better, or things that you can to think of yourself in a craftsman-like way. Both of those are pretty good resources for people who want to start walking down this path, a little bit more explicitly.
JOSH: I wanna say three words and get your reaction to them.
JOSH: Capability maturity model.
NOEL: Aaaah. I mean, sorry, what?
JOSH: [Chuckles] So…
NOEL: That was what I was talking about when I was talking about the community going bananas and people are doing anything that…
JOSH: Yeah. [chuckles] So for people who are naïve about this kind of stuff or newly hearing about it, do you just wanna say something about the insanity that is CNM?
NOEL: Like in general?
JOSH: Yeah. I mean, whatever.
NOEL: Capability Maturity Model, I'm not familiar with the generic form of it. I remember when there was that there was an attempt to create a Ruby consultancy sort of…
JOSH: Yeah, Obie tried to do that, the Rails maturity model.
NOEL: Rails maturity model, and you know, that didn’t really go very well. It's an attempt to quantify the quality of a process. I'm going to get this wrong, most likely.
AVDI: I'm actually distressingly familiar with CNM.
CHUCK: [Laughs] “Distressingly.” I like that word.
JOSH: [Chuckles] Sounds about right.
AVDI: Yeah, actually, you said those three words, and I blacked out for a moment, found myself drooling on a keyboard. And I'm still shaking. So the CNM is basically what happens when you get a bunch of nerds to try to codify what good engineering and craftsmanship and professionalism is, into an incredibly verbose set of documents, and then you build a huge business on top of certifying organization, according to that definition. But one of the funny things about the way that it's often interpreted. One of the funny things about that, that short-lived Rails maturity model thing is that, even the CNM, a lot of the people think, “Oh, it's going to tell you exactly how to code.” It does nothing of the sort. In it's incredible verbosity, it still says nothing about on how you do your work; it's more about how you think about how you do your work, and how you think about doing your work. It's like if you took the idea of agility, which is… constantly adjust your process, and then wrote an entire library of books about that, instead of just doing it.
NOEL: Now that I'm thinking about it, I was at a past company several years ago that was very, very concerned with becoming a level four, and then level five. And I recall it mostly as being an effort to have a process to define how to change our processes, and then process that define how we change our processes that change our processes. That was mostly how impacted me. But for the most part, I was able to completely ignore it, except that there were all of these processes for when you wanted to change the process that my team wasn’t using anyway.
JOSH: [chuckles] Okay, sorry for that Avdi.
NOEL: You file that up with six sigma, then you'll completely short circuit my head.
AVDI: Oh okay, now I need therapy.
CHUCK: This is like when Dave makes one of his naked jokes on Twitter, and then your brain just kind of ceases up because it's like, I'm not going there. Anyway, so let’s get into the picks. I'm sure we got good stuff. James, why don’t you go first?
JAMES: Okay, so I wanted to make two picks. So first of all, I keep forgetting to mention this, but a friend of mine, who is in the armed forces sent me a private message on Twitter a while back, saying that he loves downloading and listening to our podcast while he is doing his work in Afghanistan. So I just wanted to give a shout out to the troops and say, thanks for everything you do for us. I assume that all of us support the troops, whether you support what they are doing or not, it's not their fault. Anyways, I think it's really great that are out there doing that. They are listening to Ruby Rogues while they do it, how freakin cool is that? So thanks Tommy, stay safe out there.
So my other pick. I was at a different conference this last weekend. I was learning about all kinds of things, which I won't bore you with, but one of the things I was learning about is how freakin cool math is! We had a really great presentation on base theorem, and how you can use it prove or disprove elements of history, based on their probability and things like that. It was really cool talk, and I really enjoyed it. So I picked up some great references from that talk. Math literacy in general in the United States is pretty bad, and the companies in the Unites States, they know that, and they use it against us. So that kind of sucks, when you think about it. And there have been entire books written about that. Innumeracy, which is about consequences of mathematical literacy, and Proofiness, which is basically showing you how to use math against you, and things like that.
So if your math really isn’t up to speed, there are some lots of great resources for bringing it up to speed, for getting better, just as some simple, general audience you can pick up, it’s on 101 things everyone should know about math, it's pretty good stuff for like I said, general audience. And then, if wanna get your daughters interested in math -- which I think is cool, since I am a dad and I have a daughter -- there's great series of books by Danica McKellar, she was Winnie in the wonder years, if you can remember that series, and just gone on to do several other things, but she has this awesome series of books, Math Doesn’t Suck is the first one, and probably the best. Kiss My Math is another one, and then Hot X, which is about Algebra. And there are basically great series of books on middle school mathematics and getting that. Even adults tend enjoy them, and say they are quite good. So a little bit of feminism, so that’s always great too.
So anyways, I just wanna encourage everybody, I'm always trying to get better with my math. I am absolutely terrible at math -- I mean, terrible. So, I'm always trying to improve and do a little better if you want to, then these are some great resources for that. And it's worth it for you to do so. So those are my picks.
CHUCK: All right. Avdi?
AVDI: First of all, a little book called Rails Test Prescriptions, by some guy named Noel Rappin.
JAMES: Never heard of him.
AVDI: …which is the definitive book about testing Rails applications.
NOEL: I'm pretty sure I sold copies of Objects in Rails over the weekend by the way.
AVDI: Thank you very much.
AVDI: A non-technical pick, Olbas tea. I've had a cold for the past week, and this Olbas tea is an instant herbal tea mix that’s from Switzerland or something, and my wife gets it and it makes my head feel better. Actually, one more quick technical pick, I just started using Mail Catcher, I think it's called, to test sending mail in a Rails application, and like to do manual testing, so you can fiddle around in your app in dev mode, and have it send some mails out, and then open up this little Sinatra app, and look at all the mails that were sent out, and it just kind of works really well. So, that’s it.
CHUCK: All right. Josh, what are your picks?
Then, I have my semi-usual Netflix pick. I'm really excited that they now have all of the Star Trek series on Netflix, because this includes The Animated Series, which is pretty hard core even for Star Trek geeks. So it's all the original cast members, except for … for some reason. But all the original cast, voicing their own characters in animated form. And they have some pretty good stories in here; they have a very different short story called the Soft Weapon redone as a Star Trek episode, which was pretty cool. And then they have the Tribbles episode. So it's a lot of fun, it's worth checking out.
AVDI: I checked out the first episode of that the other day, and you are right. It is surprisingly well-written.
JOSH: Yeah, I was a little aghast of some of the first episodes and the moral stories and the moral conclusions that they came to, but the series definitely picked up, and there were some good stories in it.
CHUCK: Besides, if they have Tribbles, what’s not to like, right?
JOSH: True enough, true enough. And then I have one last little pick here. Speaking of star trek, there's an author named Diane Duane, and she’s written a bunch of Star Trek stories, and a bunch of fantasy stories. And the first thing she ever wrote, the first novel was the door into shadow, which was the beginning of a series, that has been called saccharine sweet, by some, but I found it very charming. And it was a great fantasy series. And there is a final book of the series that she's been waiting to write for, I don’t know, 15 years or something like that [chuckles] and those of us who are fans are going nuts, waiting for this final book in the series. So I´ll put a link in to her blog post that she put up in July, asking for input from people about whether she should write the door into starlight. So if you are a fan of Diane Duane, if you like writing and if you like a different kind of fantasy story, go check it out. That’s it.
CHUCK: All right, Noel what are your picks?
NOEL: I actually do have picks. I have a technical pick, and a non-technical pick. After I got iPad, I spent a lot of time trying to find an application that I can actually not even so much write code, but write prag markup, that was actually decent, and I was looking for something that actually has drop box and text expander support, and a good keyboard. And I finally settled on Textastic. I don’t know if any of you have ever used this. Textastic, is an iOS, it's an iPad app that supports Textmate bundles for syntax highlighting and themes that highlights a different bunch of files, it puts an extra row on the soft keyboard with a bunch of programmer’s symbol keys, has some navigation styles, you can connect to an FTP server, you can connect to Dropbox. The developer is super responsive to feedback, and updates it pretty frequently. And it’s just really useful. I actually do wind up writing on it quite a fair bit. So, Textastic.
Non-technical pick, anybody here watched the television program called the Middle Man?
JAMES: No, I didn’t.
NOEL: Okay, Middle Man was based on a comic book series, but the TV is actually better, ran somewhat weirdly on ABC family couple summers ago; summer 2008, maybe. It's a really loving send up of insane science fiction and it's goofy, and fun, but also takes them just seriously enough, so that it's not just just a satire. It's a lot of fun. One episode in particular has for instance, a confrontation between a martial arts expert and 100 Mexican masked wrestlers. It features vampire puppets in others episodes. It's insane, and wonderful, and fun. So that’s my other pick.
JAMES: That’s insanely cool.
NOEL: It is not available on DVD, and I don’t think it's on Netflix, but they are available on iTunes.
JOSH: The crazy thing is that I've seen a vampire puppet in a TV show before. [chuckles]
NOEL: There's also an alien boy band. I think it's aliens that are masquerading as a boy band.
JOSH: Oh wow, this sounds worth checking out.
NOEL: It's fun.
CHUCK: All right, I guess it's down me, huh.
JAMES: Beat that.
CHUCK: I don’t know if I cant. I'm kind of getting in to crosswords puzzles lately. I tend to move from one thing to another, so for a while it was Sudoku, and then it was the balloon tower defense thing, and now, I'm kind of getting into crosswords. And there is an app on Mac appstore… I'm trying to remember, it's called Crossword Light is the one that I have, and it has a couple dozen crosswords in it. And I think you can actually, more crosswords just in the app, but I haven’t fiddled with that. I haven’t finished them all, but anyway. Another good place to get crosswords is I've been going and doing the USA today crosswords. And on occasion, I feel the itch, and I don’t have a crossword handy, and I've already done the USA Today, so I'm doing the LA Times one as well. So that’s been some of the stuff that I've been getting into.
And then another one, and this somebody picked a while back, but it's just something that I've been using lately that just keeps coming up over, and over again, and that is acorn. I keep on saying audio. It's an image editing tool, kind of Photoshop, but way simpler. It's just super-duper handy, and has really made my life easier, because it has a lot of the common things that you need to do, just right on the menu, so you can just get to them like resize an image, or select an area and fill it in or whatever. In a lot of ways, it's easier to use than Photoshop. Anyway, I'm going to throw those out there and we'll go ahead and wrap this up.
I wanna thank Noel again for coming on to the podcast. It’s always fun to have guests.
CHUCK: Especially smart guests. So, thanks for coming.
NOEL: Like I said, any time. Thank you for having me.
CHUCK: All right, we also have in no particular order, Josh Susser.
JOSH: Been fun.
CHUCK: James Edward Gray.
JAMES: Thanks everybody, and don’t forget to read Eloquent Ruby. You have about two weeks left before we talk about it, and there's tons of spoilers, so.
NOEL: [Chuckles] Don’t give away the ending.
CHUCK: [Chuckles] Avdi Grimm.
AVDI: Happy hacking!
CHUCK: And I'm Charles Max Wood from teachmetocode.com. I've been working on the new site, so keep an eye out for that. In should come out in the next few weeks. I also want to point out that we are in iTunes, so if that’s what you are using against this, then leave us a review. And if not, there should be a link on the page on the webpage RubyRogues.com, or you can go ahead and just click that, and subscribe to the podcast. If you are listening from another app, I’d be interested to see that is, I get a lot of that in the stats that I look at, and I'm always interested in new options, especially things for the android or other system. So anyway, if you’re doing something like that, then go ahead tweet to Ruby Rogues and let us know if are listening on, and beyond that, we'll catch you all next week!