Kurt's Blog

November 22, 2011

Three Conferences

Filed under: agile, conferences, kanban, lean, Software Craftsmanship — Tags: , , — Kurt Häusler @ 4:21 pm

Earlier this year I went to three conferences and I never got around to blogging about them as I was pretty busy with a lot of things like finding a new job, finding a new flat, preparing to move, preparing for a new baby, finishing my masters and organizing the code retreat.


The first of the three was SoCraTes 2011 from the 1st to the 3rd of September. The name comes from Software Craftsmanship and Testing, which is an interesting combination. I suspect a few people who would have otherwise been interested in the Software Craftsmanship aspects were turned off by the Testing part. SoCraTes was definitely about the union of those two topics rather than the intersection. It was English speaking too, and great to have some visitors from outside Germany. I even did a lightening talk, where I mentioned that I would be giving all my books away. That’s right, I brought a box full of books and let people help themselves to them.

SoCraTes had an interesting way of scheduling the sessions. Each session was either a big one split into a 30 minute introduction and a hour long in-depth section, while other sessions were just hour long sessions. I tended to move between them a lot. For example on the first day I attended the first 30 minute intro to the Craftsmen Coding Contest, then moved to the in-depth part of the Specification by Example session. Unfortunately I didn’t feel like the second part of specification by example, where they wanted to discuss examples, worked very well without being there for the first 30 minute introduction. I remember going outside to enjoy the great weather and joining another spontaneous, unplanned session happening out there.

After that I saw the first part of Soft Skill Essentials, then went to the Scala Test in-depth session. After lunch I went to the Crafting Object-Oriented Code session. This was one of my favorites. In partners we had to develop a small program according to provided requirements, but we also had to follow a rather extreme set of object oriented, clean code type rules. You might not want to be so strict all the time, but it is a great and fun exercise to help show how these clean code guidelines actually work, by doing them on in an extreme way, on a fairly small simple, easy to understand code base, you can really see what effects these rules lead to.

Later in the afternoon I went to another practical, hands-on session, SOLID for Dynamic and Functional Languages. We split into teams that chose a language associated with a non object-oriented paradigm. I ended up in the Clojure team, and I can’t remember what the other languages were. We were asked to look at code sections that broke a solid principle, and we had to refactor it so it obeyed the solid principle. The main idea was to discuss how aspects of dynamic and functional languages might make the solid principles either unimportant, different, or irrelevant.

The following day was Open Space. I think I attended sessions on “Laws of Software Development”, actually looking at a picture of the board, that is the only one I recognize. I do remember sessions on mentoring, developing SC communities in Germany and the others were mostly just general chats out in the sun.

The discussions on further steps to take regarding software craftsmanship in Germany were interesting. I didn’t think anyone needed to start a SC group up in the Cologne/Bonn area as we already have the Bonn Agile Meetup, and other user groups, that discuss the same topics. I was however inspired to bring the Global Day of Coderetreat to the Cologne/Bonn area though.

The date for the SoCraTes 2012 has already been set and it will take place from August the 2nd to the 4th, with an optional code retreat on the 5th!


The second of the three conferences was the Agile Lean Europe 2011 in Berlin from the 7th to the 9th of September. The whole family came to this one because there was a special spouses and children track with activities and trips organized. Now at this conference all the talks (except keynotes) were 30 minutes long, and they felt for the most part like dragged out lightening talks, or chopped down hour long talks. For me the open spaces were the highlight. I remember some great discussions on things like estimation, and whether we need managers or not. The keynotes were great too. Rachel Davies’ one on the first day was memorable for her comments on enterprise agile, which I seem to agree with. All the keynotes were fantastic. Beyond Budgeting for example is something I am really interested in getting to know more about.

The second day I had to give up a couple of sessions as I was informed I needed to do some last minute improvements to my masters. In the evening a small number of us went on a trip to catch up with the Berlin Lean Startup Group, for one of their meetings and some dinner.

I remember having a lot of thoughts about agile becoming too fluffy, and did a lightening talk about that, and there was some discussion on twitter about my views on coaching that I said I would flesh out in a blog post, but I can’t really remember what it was all about now. The last day was probably the best. I enjoyed all the talks on the Science of Kanban, Relearning Smalltalk, and the Agile Meme. On one of the days we also had a cool open space session “for programmers” with Brian Marick. You could consider it a warning sign if a session at an agile conference was notable for being “for programmers”.

Afterwards my family and I stayed in Berlin for a bit to have a look around.

The next one will be in Barcelona I believe.

Lean & Kanban 2011 Benelux

I enjoyed this one so much in 2010 I decided to go again this year. The whole family came again and we had a look around Antwerp. I won’t go through and comment on every session I attended. The highlights were probably David Anderson’s “When is Kanban not appropriate” talk, Don Reinertsen’s keynote, and the Real Options talk by Chris Matts and Olav Maassen. Would I go again next year? Sure, but there are 3 lean/Kanban conferences all happening around the same time, so maybe next year I could check out the LKCE or the LSSC ones instead.

Not many images on this post, so here is one of my daughter and I in Antwerp.:



May 28, 2011

Software Craftsmanship 2011

Filed under: Software Craftsmanship — Tags: — Kurt Häusler @ 1:52 pm

On Thursday I went to Software Craftsmanship 2011 at Bletchley Park. I was a few minutes late getting there, as I stupidly decided to walk the short distance from the hotel. I should have taken a taxi. It wasn’t actually far but the combined foot and cycle paths are poorly signposted and don’t always lead in the direction you want to go in.

Software Craftsmanship 2011

I couldn’t really decide what sessions I wanted to attend so I decided to prepare my Mac laptop for maximum flexibility, and updated MonoDevelop and Eclipse. I had a non-default Ruby installed with RVM and decided to follow the preparation instructions for one of the Ruby sessions just to make sure I had all the gems etc. It didn’t quite work out as nicely as I expected and reminded me of the shambles I experienced last year when Ruby 1.9 and Rails 3 came out, with all the version conflicts caused by the whole gem, rvm, bundler mess. I just put it down to early versions. I still had problems so I deleted my .rvm and started from scratch. I had problems at bundle install, with nokogiri, something to do with the versions of libiconv and/or libxml2 I had installed with brew, which I generally keep up to date. From googling I got the feeling I needed to install a specific version of libxslt from source so I did that, and tried to reinstall nokogiri with gem but still didn’t get anywhere. It felt like using linux in the 90s but a bit worse. At least in linux there were 2 ways to install libraries, from source or as a precompiled package and once it is installed it is available. Here I didn’t really know why some things needed to be installed with brew, some with gem, and some with bundler, and what libraries ended up where. The ruby infrastructure seems to be a lot less elegant than it used to be with all this rvm and bundler nonsense. Strangely I just now tried to do the bundle install again and it got past nokogiri but had problems with mysql2. Probably because I need to install a native mysql library with brew or something.

Anyway, I got there late on the day and my first two choices were full, so I went to the "Space Invaders vs Continuous Testing" one. It was only my third choice because it sounded as if I may really need Visual Studio and Windows to get the most out of it, but I decided it might be fun to try it with MonoDevelop. Technically MonoDevelop worked fine, and did not hold me back at all (the only issue was not being able to install NCrunch, which was not critical to the task). As I missed the explanation at the beginning it took me a while to work out what had to be done, but I was able to make a start, and caught up with most of the others. We really needed more time though. The first 200 points were easy to get, and most of us got that without actually doing any programming, and only one team actually managed to get 400 points. I still feel motivated to work on it, and see if I can solve it at some stage. If I have time I will have to see if it is possible to work on the kata without the server, that tests how well our code actually performs in defending cities against waves of invading aliens.

After the coffee break I attended a session on "Asynchronous Unit Tests in FlexUnit". It was interesting, and gave me a good introduction to not only FlexUnit and asynchronous tests, but to the whole Flex system which is not something I had played with before. We only had 3 participants because Michael Feathers showed up and most people wanted to see what he was doing.

During lunch we had an interesting tour of Bletchley Park, and after that I attended "The Lean Code Challenge" which was a lot of fun. In pairs we were to go through a series of 10 minute iterations building up and modifying a simple console program. We chose to do it in Ruby, because the session provided a minimal Ruby skeleton to work from, and it seemed as good as any other, considering my coding partner didn’t know c# and I didn’t know Flex. So we did ok I think considering we were both basically learning Ruby at the same time. An added bonus for me was improving my Vim skills. I still hadn’t managed to memorize many vim keystrokes, despite doing tutorials every now and then. I tend to forget how to use it effectively and revert to using it in a clumsy way. Pairing with someone who was able to remember a few keystrokes from when he used to use vi a lot really helped me learn some new vim keystrokes too, and it motivated me to improve even further.

One funny observation I made is because of time pressure I probably wrote the worst code at this event than I ever had in the past few years, which seems unfortunate for a software craftsmanship event.

In the evening we had dinner, drinks and an extra session "Personal Codes of Conduct" which was interesting, considering it was not hands on, and nothing to do with code. The discussion afterwards reminded me of some of the very long threads on the software craftsmanship mailing list and made me feel sleepy.

SC2011 did inspire me to think of giving a session at the upcoming SoCraTes 2011 in Germany. I think the best sessions involve:

  • Some aspect of a challenge
  • Working in pairs or small teams
  • Competing against other teams
  • Ideally less time pressure so people can come up with good quality code rather than hack something up as time is running out

I am sure I should be able to come up with something.

Here are some other blog posts I found about Software Craftsmanship 2011:

May 14, 2010

Book Review: The Wandering Book

Filed under: Software Craftsmanship — Tags: — Kurt Häusler @ 11:09 am

This book is indeed a very special one. The Wandering Book: Zeitgeist of the Software Craftsmanship movement is not something you can buy in the shops or order from Amazon. It is truly one of a kind in the most literal sense, and it is not even finished yet.

At the moment I believe it has ten authors, although more will hopefully follow. Each person writes a page or two, and then passes on to the next person. It is an interesting concept for me as I have an interest in quality writing instruments, especially fountain pens, and I am aware of the wandering book concept from the fountain pen community, which contains a surprisingly high number of old programmers that seem to embody the same values as those developers in the software craftsmanship community. Most of them thought the idea of the wandering book, and software craftsmanship itself to be wonderful. The reverse also seems to be true. I have noticed at conferences people associated with software craftsmanship also seem to prefer using quality writing instruments and paper, and even in my course we have already remarked on a strong correlation between those associated with software craftsmanship, and those who happen to prefer writing with fountain pens. I know personally I have the same kind of feeling when writing on decent paper with a good fountain pen as I do when adopting a craftsmanship approach to software development, taking care, building up a relationship with my tools, and feeling a strong personal responsibility towards quality work.

For me the wandering book bridges a gap between the published books, and the mailing list. The handwriting is at once a more personal connection to the authors than any printed text or electronic display could deliver.

Corey Haines begins by describing how he sees software craftsmanship following the work of the XP movement in improving quality by focusing on the internalization of craftsmanship values, and building up a community to assist each other.

Jason Gorman then says what Software Craftsmanship isn’t in his opinion, and states that if you care about software quality, then you are a software craftsman.

Dave Hoover talks about the journey to mastery and suggests that more people in industry need to take such a journey.

Eric Smith shares his personal experience becoming a developer and enjoying the opportunity to learn from others.

Michael Norton summarizes that to him, software craftsmanship focuses on three things: Learning, Practicing, and Sharing.

Micah Martin, in beautiful handwriting, reminds us that craftsmanship extends beyond our lives as software developers, and presents the idea that craftsmanship is a skill independent of software and can be built up by engaging in other activities that require the discipline of craftsmanship to master. He demonstrates this directly with his calligraphy.

Doug Bradbury writes about the physicality of software and the necessity for practice to burn the skills of working with software into our muscle memory.

Gustin Prudner writes several pages of how he sees software craftsmanship, as a set of practices, principles and beliefs, and their intrinsic nature that makes them as hard to simply list as they are to learn.

Bobby Wilson writes one of my favorite entries. He talks about craftsmanship being an introspective process based on ideas rather than rules, and mentions that craftsmen shine when faced with difficult legacy projects.

Michael DiBernardo writes my other favorite entry. He encourages more cooperation with universities in helping train and develop the next generation of software craftsmen. He also reminds us that in order to be seen as professionals we have to first present ourselves appropriately which I agree with. I was worried at first this may work against our rich heritage as geeks and hackers, and the relaxed approach to “irrelevancies” such as our external appearances we have built up as part of our culture, but clearly he is right. We can start from there and evolve to become a more professional, mature discipline and show our customers, co-workers, and the rest of the business community the respect the deserve by exhibiting a proper standard of presentation.

If you consider yourself worthy of contributing I would like to encourage you to register to receive the wandering book so you can share your ideas, and of course we should all thank NexWerk for hosting the project.

And to whomever has the book currently, pass it on already, it has been two months since the last entry!

So that concludes my short series of Software Craftsmanship book reviews. I would have liked to have included two more, The Pragmatic Programmer, and Clean Code, as they clearly present themselves as part of the “canon”, but I simply didn’t have time for it this week.

May 12, 2010

Book Review: Apprenticeship Patterns

Filed under: Software Craftsmanship — Tags: — Kurt Häusler @ 8:00 am
The next book I want to review was published in 2010, and uses a Pattern Language approach to provide tips for newer software developers, to grow their skills, including those in areas other than technical.

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave H. Hoover and Adewale Oshineye

The book draws on experience and interviews to find out what patterns developers noticed as they made progress, and dealt with situations and catalogs them in this book. Before I bought the book I heard many comments expressing that people wish they had this when they started their careers.

The patterns are ordered into sections. The first section, after the introduction where some background into software craftsmanship is provided, along with definitions of what it means to be an apprentice, journeyman or master, is Emptying the Cup, which is a reference to a story about a Zen master who overfills a student’s cup to illustrate how the student was not receptive to new ideas because he thought he knew it all. The theme of the chapter is all about keeping an open mind, and expressing the value of humility. Two of my favorite patterns in this section include Concrete Skills, which reminds us that having knowledge is not the same as having the practical ability to apply the knowledge, and encourages practice, and Retreat into Competence which reminds us, should we become overwhelmed, to step back a bit, and build up your confidence with some easy stuff.

The next section, Walking the Long Road is about thinking of a career long term, and in the short term preferring opportunities for growth rather than traditional indicators of success like salary or leadership titles. The most interesting pattern for me in this section is Sustainable Motivations, which reminds us that not all work is exciting and interesting, and sometimes we have to make compromises, or struggle against things we can’t control and this may impede our motivation. It presents a way to restore motivation by thinking long term, and using our long term needs to make informed decisions about what to do about it, which usually comes down to sticking it out, or making a bold change. Much of the other patterns in this section address similar issues. Use Your Title is interesting, it talks about promotions involving impressive titles, and what that may really mean, as well as referring to situations where hard work goes unrecognized.

Accurate Self-Assessment, the fourth chapter, has patterns involving how we relate to other developers, such as Being the Worst on a team, so we have people to learn from and room to grow, and Finding Mentors or Kindred Spirits who can help us grow by sharing experiences, and reflecting on each other’s ideas and progress. Rubbing Elbows reminds us that even the big names are often friendly and approachable, and can be an excellent source of knowledge and inspiration. Sweep the Floor reminds us of the value of humility, and provides a means for a new apprentice to slowly build up trust with his team by proving himself by doing menial tasks well.

The fifth chapter, Perpetual Learning has some fairly concrete tips for staying up to date on what is current in our profession, not just on building up knowledge, but Practicing in order to leverage that knowledge as concrete skills. Developing specific skills is encouraged including source reading, self-reflecting, and recording and sharing knowledge learned.

Construct Your Curriculum consists mostly of patterns related to learning from books, and how to select such books, but the pattern Familiar Tools also suggests building up a toolbox of things we may specialize in, or prefer to use across projects because we become expert in them, and knowing when to make changes to this toolbox.

I thought it was a great book, especially for those starting out. For me its greatest value comes in the contribution it makes to the idea of craftsmanship as a model for the discipline of producing software and software developers. It is a sparse field, and this book is significant for refocusing the software craftsmanship movement several years after McBreen’s book, after the community had some chance to develop the concept. Choosing to focus on apprentices, and structure the book as patterns were excellent choices, that help to solidify craftsmanship from being just a thought experiment, or alternative model, into something more concrete than can have a beneficial influence on the lives of developers, the profession and potentially help steer the industry towards a more effective future.

May 10, 2010

Software Craftsmanship Book Review

Filed under: Software Craftsmanship — Tags: — Kurt Häusler @ 8:28 am
I have been meaning to blog about this for a few months but since it is Software Craftsmanship Week I am motivated to take a break from the assignments and exam preparation and review some of the main books associated to the software craftsmanship movement. There are many relevant books of course, including things like The Pragmatic Programmer (which actually has “from Journeyman to Master” as part of the full title), Clean Code (A Handbook of Agile Software Craftsmanship), and The Passionate Programmer, but I am going to narrow it down to a few that have a more direct association to software craftsmanship.

Software Craftsmanship: The New Imperative by Pete McBreen

This book, first published in 2002, presents Software Craftsmanship as an alternative model for the software development profession, focusing on people rather than process. One theme is the changing nature of software development meaning that the industrial model of developing software where programmers, trained in a language, are essentially interchangeable, and given the same specifications will produce the same output is no longer valid, as better tools have meant that technical activities like programming are no longer the difficult or main aspect in developing software, and more experience, skill (not just concrete technical skills, but more abstract personal and interpersonal skills that approach values and principles), and knowledge (especially tacit).

The book begins by pointing out the current “software engineering” approach, which borrows ideas from other engineering disciplines, and explains that is was developed for large-scale defense type projects that may not only involve developing software, and although it may still be ideal for such work, most software is made on a smaller scale and can be more effective using more appropriate approaches.

I was a little confused at first, as McBreen’s use of the phrase “software engineering” seemed to differ from my own at the time I read the book. He seemed to use the phrase as a synonym for traditional, or waterfall-style, project management, whereas to me software engineering, as I studied it at uni, was related more to the practical aspects of producing software. Things like software design, testing, metrics, requirements analysis, architecture, the “grain” of interfaces, coupling and cohesion, and distributed computing. As I look back now, software engineering as I learned it was the forerunner of a lot of the clean code/agile/pragmatic practices of today, such as TDD, DDD, SOLID principles, customer collaboration etc. But I had a look at the SWEBOK and it turns out that McBreen’s view of software engineering was a lot closer to common usage than my understanding of the term. You can notice that in the current, 2004, version of the SWEBOK the chapters are organized according to phases, with “software construction” (the term itself reinforces the classic, yet inappropriate building metaphor), simply one among many. At least it acknowledges that this “construction” may occur within not only waterfall style phases, but agile style iterations. It continues to treat design and construction as separate activities, which technically they are, but not in the way the SWEBOK lays out. I am a firm believer in Jack Reeves’ “Code as Design“, (reinforced by Ivar Jacobson’s quote “Architecture without executable code is just an hallu cination”); programming IS designing, the source code IS the design of the software, construction is what the compiler does to turn that design into an executable.

Anyway, I still believe the SWEBOK, and indeed the topic of software engineering is valuable, as too many developers still think developing software is a purely technical discipline, a matter of programming, or typing in source code, and neglect the aspects upstream and downstream of that activity, probably because they are used to some analyst or manager doing all the hard work and throwing it as a document over the cubicle wall.

But I digress, the book Software Craftsmanship also addresses thinking about the entire value stream, and in a way that is probably more appropriate for most software development efforts today, and in a way that is more in tune with the Agile values that seem so popular today, especially the one about individuals and interactions over processes and tools.

The book presents the idea of personal relationships, and vouching for one another, being a more appropriate indicator (for say a hiring manager, or potential client) of someones skills than certification. That is a great idea, but seems more valid for independent contractors that work on short term projects rather than long term permanent employees, and could also end up indicating nothing more than who knows who, or who has worked with whom rather than a true indicator of skill. I mean if I work with someone and I want them to vouch for me, and they do, how would it be if I were to withhold vouching for him because I didn’t think he was good enough!

I am especially fond of the idea in the book that focuses on the strong relationships that software craftsmen have with their users. For me that is one of the great “secrets” to developing successful quality software that fulfills both the customer’s needs, and is maintainable. I don’t know why it is a secret, it should be obvious, but still even companies that claim to be agile still have a wall of analysts or project managers that talk to the customers and then throw documents over the wall to the developers. I think one of the causes of this is Scrum who claim that the developers need to be shielded from the customers by the Product Owner and ScrumMaster. Nonsense! For me the difference between developing software quickly, with care and respect for the customer’s needs is completely dependent on the relationship I can build with them. The Scrum idea that developers need to concentrate on tapping out code all day reflects an outdated view of software development inherited from traditional projects where “software designers” do all the thinking and write up a complete spec for programmers to convert into source code and type in. With modern tools, and the realization that the act of programming is mostly just plugging in libraries anyway, the time spent in front of the keyboard tapping away is the easy bit, and should not constitute most of the developer’s time.

What I also like is the idea that these relationships with customers should be long term, and should be carried through as long as the software is still being used and maintained. In the software craftsmanship world, maintenance is a high-status activity, rather than something newbies do because no one else wants to do it. This was especially motivating for me as I am involved in the development and maintenance of a large mature software product, and the various constraints and other challenges that that imposes was demotivating as it conflicted with my ideals of how I would have done things with the advantage of starting from scratch using ideas that were not so common when the product first began to be written.

Thanks to the book, I am proud to be a software maintainer, and enjoy the challenges that it brings.

The chapter on managing craftsmen is fairly short, and reflects much of the thinking on software management that has become mainstream over the last few years, such as self-organization, emergent leadership, servant leadership and the role of management as more of a facilitating and coaching one rather than command and control.

The book borrows from a traditional craft based model when it comes to describing the career or occupation of software craftsman itself: The Apprentice, Journeyman, Master model. The advantages of this model are only through close collaboration on actual real work, can apprentices learn the knowledge and skill required to become proficient at software development which is something I agree with. The biggest jumps I feel I made as a software developer were while working with others, learning directly from them in close collaboration. Naturally implied is the role of masters and journeymen not only in developing software but in training the apprentices. This aspect gives me hope for seeing software craftsmanship as a useful model for our profession here in Germany, as there is already an apprenticeship program in place for training new developers and allowing them to gain real world experience.

I probably see myself as a journeyman. Journeymen are supposed to move around between jobs every few years so they can pick up various skills from various masters, which is what I have done. It does however conflict somewhat with the concept of long term customer relationships.

One thing craftsmen should do, according to the book, is to build up a portfolio of work, and use that as our C.V.s in place of certifications and licenses. I am in favor of that, generally, but what makes it difficult for me, especially when considering my work as a journeyman over the past decade, is that the majority of the work was not mine alone. Almost everything I have done as been done together with others. In my current job, in maintenance this is even more difficult, as the work involves bug fixes and small modifications to existing functionality so I would hardly feel comfortable claiming credit for any functional part of the software, even in part.

The remainder of the book is mostly good advice that is found in most similar books, design for testability and maintainability, learn to collaborate, be wary of bleeding edge tools, prefer open source tools and libraries, don’t neglect user friendly user interfaces. Never stop learning and trying to improve, get involved with the community and reflect on your progress are the final three points the book makes, and ones that I fully agree with.

This review has taken longer than I though, so I will, hopefully, do another review later in the week.

By biggest takeaway from this book are at the values level, because that is how I think. The three biggest values that I have adopted after reading this book are Humility, Judgment, and Responsibility. Humility, because we should never assume we know enough, or that someone else’s ideas are less valuable than your own. Humility to accept that we are not always the decision makers, and to accept the decisions made by others and do our best to work with those decisions like true professionals, even if we continue to disagree with them. Humiltiy to be happy to do the grunt work, the less glamourous tasks, the bug fixes, and repetitive tasks.

Actually I thought about humility and craftsmanship the other day when reading a recent blog post from Obie Fernandez. He mentions that “I actively avoid trying to work with clients that have legacy issues, corporate politics, non-cooperative stakeholders, saboteurs, etc.” Now that way is a great way to ensure success, but it is almost too easy. I see it as an antithesis of software craftsmanship on two grounds. First I feel a good craftsman does his best in any circumstances. That is what, in my opinion, makes a software craftsman a bit more special than the classic agile developer who has read all the books and knows all the patterns, and can quickly produce a nice clean greenfield, well designed, web application, with modern tools, high code coverage and a highly engaged customer with similar values. Throw people like this in the deep end, with poorly designed legacy code, hordes of angry users, a hostile and change-fearing corporate or developer culture, or perhaps situations where they are expected to be the domain specialist or don’t lend themselves to classic patterns, and they wont get very far, they will insist on and depend on things that just aren’t available. A craftsman will remember when all development was like that, and draw on his vast experience, and store of tacit knowledge, connect with old colleagues, dust off his COBOL or C++ books, or his old computer science textbooks, and just get things done. The second point is related to how people learn in relation to their comfort zones. If one insists on working well within one’s comfort zone, one might get used to it. One might get very good at delivering value consistently in such an environment. But I doubt one will learn much. A craftsman will deliberately seek out opportunities that differ from what he is used to. Perhaps seek out some constraints or other challenges he hasn’t faced recently. He will thrive in situations that force him to adapt and learn. This is less related to the value of humility, but personally I find situations where I have to deal with “legacy issues, corporate politics, non-cooperative stakeholders, and saboteurs” and still be expected to deliver, exhilarating, particularly for the rate at which my principles and prejudices get challenged, and are forced to be adapted, and strengthened. It is a bit like evolution. The more predators there are, the more scarcer the food sources, the more hostile the environment, the quicker a species evolves to adapt traits that strengthen it, and increase its likelihood to survive. Species that evolve in more sheltered environments, like the birds in New Zealand, with no predators, lose their ability to fly, or to see clearly, and happily go along picking at the ground for food. Until the ecosystem changes, and new species come along, and either compete for the same food source, become predators. Success is great but you learn more from failure, and that learning makes success more likely as conditions change, as they always do. Evolution demands adapt or die, and staying within one’s comfort zone favors eventual death.

I wonder what Hashrocket does when its customers become successful and grow, and the code becomes legacy, and a political corporate culture develops. Do they get dropped in favor or other quick wins, low hanging fruit? I think the craftsman would not only favor preserving the relationship long term but thrive on the opportunity to hone his skills against the face of new challenges.

Judgment is important, as craftsmen must continually make tough decisions. What tool to use, whether to delete code and start from scratch, or struggle on with ugly legacy code, who to work with, what courses to take, what apprentices to take on, how to teach them, when to move on from a customer or job or stay with them. I think the difference between a programmer and a craftsman is that the latter rises up and exercises his judgment rather than carrying out orders from management, which leads on to:

Responsibility. One of the most important values I have adopted from the craftsmanship movement is that of responsibility, which is a natural consequence of exercising judgment. We need to stand up and take the fall when things go wrong, not blame the process (after all, we are either responsible for the process, or responsible for doing our best within the constraints of a process). If anything is not quite right, it is our responsibility to at least point it out to the decision makers, if not correct it ourselves. We are also responsible for our own careers. If you find yourself not learning anything, or notice some way in which you can deliver more value than in your current role, or feel that you are being overlooked for some task that you would be ideal for, don’t blame your employer, or your co-workers, or the manager. However craftsmen don’t get anything handed to them on a silver platter, including responsibility, without taking the initiative and proving that they deserve it.

Blog at WordPress.com.

%d bloggers like this: