At Cegeka, we believe in continuous learning, and we regularly organize reading groups as a simple and effective way to gain knowledge. The last reading group I participated in, and the one that inspired this blog, was Apprenticeship Patterns. We kept extensive notes during our reading and discussions. You can find these below, copy-pasted from our internal company-wide wiki, with minimal editing. As you will see, not all discussions are complete, feel free to comment! Also, especially at the start, many notes are very short. If you don’t understand something, go ahead and ask!

Please note that the entire book can be found online. Pretty useful if you want to see what we’re talking about!

Meetings

Date Location Content
30/09/2014, 15h Leuven Introduction
01/10/2014, 15h Lync Introduction
14/10/2014, 16h Lync Chapter 2 - Emptying the Cup
28/10/2014, 16h Lync Chapter 3 - Walking the Long Road
18/11/2014, 16h Lync Chapter 4 - Accurate Self-Assessment
02/12/2014, 16h Lync Chapter 5 - Perpetual Learning
10/12/2014, 16h (Wednesday!) Lync Chapter 6 - Construct Your Curriculum
13/01/2015, 16h Lync Chapter 6 - Construct Your Curriculum
27/01/2015, 16h Lync Chapter 7 - Conclusion + own progress + own actions

Lessons learned

Introduction

Craftsmanship manifesto

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

Not only responding to change, but also steadily adding value

Not only individuals and interactions, but also a community of professionals

Not only customer collaboration, but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

  • Meaning of “productive partnership” vs “customer collaboration”?
    • Maybe: developer is not working for a client / does not stand underneath the client. They are both at the same level, influencing each other.
  • There exists a community around the manifesto, where you can recruit apprentices for whatever project you are doing. You need to provide a place to sleep, etc. The apprentices will hang around you while you work, and they will learn from what you do. They will however not collaborate with you.
  • 8th light once again explains: http://blog.8thlight.com/micah-martin/2011/12/01/software-craftsmanship-manifesto-duh.html

Values overlapping with craftsmanship

  • Growth mindset
  • Adapt and change
  • Pragmatic > dogmatic
  • Sharing > hoarding
  • Experiment + be proven wrong
  • Internal locus of control
  • Individuals > groups
  • Inclusiveness
  • Skill-centric > process-centric
  • Related to individuals > groups!
  • Situated learning

Stages of the crafstman

Transitions between stages are gradual, not sudden

Transitions are noted by others who will give you more responsabilities. You don’t notice these transistions yourself

  • Apprentice
    • Focused inward, intent on growing your craftsmanship, learn how to learn
  • Journeyman
    • Keep roles of Apprentice
    • + focus on the connections between practicioners
    • + responsibility to mentor those around you and to communicate with the rest of the industry
  • Master
    • Keep roles of Journeyman
    • + focus on moving the industry forward

Implementation in Cegeka

  • We should spread this!
    • But how?
    • Something at guild meeting or knowledge sharing meeting?
  • Can we apply this to help people learn? Create trajectories for them on what to do?
    • But the book is not about “fixing your team” but about getting better yourself, cfr internal locus of control
  • Developer Guild discussion: is the developers guild an implementation of the “community of professionals”?
    • It doesn’t function as well as it should / could, because
      • Craftsmanship is a mindset that just isn’t there
      • Joining the guild was mandatory, and people didn’t like that
      • It’s hard to organize while being geographically seperate
    • The guild doesn’t replace the old software factory feeling, which died
      • Why did it die?
  • Isn’t quality THE huge selling point of Cegeka? Why do we have to cut the costs?
    • A craftsman is more expensive than an amateur, it’s with plumbing as it’s with development
  • A journeyman should frequently change masters and projects
    • We don’t really do this at Cegeka, definitely not in Hasselt

General remarks and nice quotes

  • Can you do craftsmanship without agile?
    • Yes, it’s about the mindset to be proud of your code
    • Yes, but it will be harder
    • No, the manifesto explicitely references the agile manifesto
    • Yes, they reinforce each other
    • Yes, craftsmanship is individual and skill-based, while agile is group-level and process-based
  • Comparison to other theories of skill aquisition
    • …
  • As read in Team Geek: developers usually don’t have the self-esteem and courage to work in Open Source software, to show their mistakes, … So they don’t do it, hindering their growth.
  • Shouldn’t we evaluate craftsmanship level on individual skills, instead of as a vague general feeling?
    • For example: I’m an apprentice at functional programming, journeyman at SOLID design, etc
    • Parallel with martial arts: to gain a degree in for example Kendo, you need to be able to do certain moves and do an exam of it
    • This helps to find areas where you need to improve
    • Seems like this book / Software Crafstmanship does not work that way, for some reason
  • Just telling people to do things, doesn’t work

Emptying the Cup

Your First Language

The White Belt

  • Rather hard to practically use
  • It’s about keeping the right mindset, even a master might need to act as an apprentice again if he enters a different context

Unleash Your Enthusiasm

  • Teams with a junior/senior mix outperform teams with only seniors.
  • This pattern also seems useful in reverse: explaining things to apprentices helps your understanding of a problem

Concrete Skills

  • Only seems relevant when you are trying to get started in software development, and you don’t have anyone else around with the skills you want to learn

Expose Your Ignorance

  • Be honest
  • Show that you have the learning mindset, and also show that you believe this is the best mindset

Confront Your Ignorance

  • Very close to Expose Your Ignorance

The Deep End

  • Within Cegeka: coaching is important to help push developers to the deep end, and to give them feedback about how they are doing
  • Measure your progress: what projects have you done? Are you stagnating?

Retreat into Competence

  • We kind of do this sometimes to keep our sanity
  • Maybe it’s also about benchmarking? How well can I do problem X, compared to 5 years ago?

Walking the Long Road

The Long Road

  • This is the pattern that keeps coming back in the others
  • Remember: the journey never ends!

Craft over Art

  • We seem to do this pretty okay at Cegeka
  • Pairing helps

Sustainable Motivations

  • How about motivating others?
    • See also Unleash Your Enthousiasm
  • How about motivation for side projects? It’s really hard to keep working on something just for yourself, if it only improves marginally on existing tools
    • Hackerspaces! User groups! You have to search for an audience to motivate you.

Nurture Your Passion

  • Don’t let your work kill you

Draw Your Own Map

  • We’ve seen a few people leave Cegeka to follow their own map. One employer cannot provide all paths.

Use Your Title

  • Isn’t it “Don’t use your title”?
  • It seems to be “use your title to assess the company you work for”

Stay in the Trenches

  • …

A Different Road

  • Leads to interesting stories!

Accurate Self-Assessment

Be the Worst

  • Being best or worst is multi-dimensional. You can be better at some things, but still be learning a lot about other things.
    • As long as you are learning enough to your liking, this pattern doesn’t apply.
  • You cannot stay the worst forever in the same team! That will just annoy the team.
  • This might be an issue in Cegeka. What if there aren’t any opportunities to move to a different team, and you are the best for the last past 10 years?
    • You will need to learn different ways, probably not as efficient
    • You might be past the stage of apprenticeship

Find Mentors

  • Contrast with Kindred Spirits: this is more one-on-one, directly for your own gain, with someone who is already farther on the path
  • Danger in blindly accepting mentors (especially when Rubbing Elbows): what if you learn the wrong things? Keep learning from different sources!

Kindred Spirits

  • Constrast with Find Mentors: this is more about the culture around you, trying to achieve the same goal while at the same stage on the path
  • User Groups are plenty on meetup.com
  • The litmus test to defend against group-think: does the community accept and experiment with new ideas, or are they rejected without thought?

Rubbing Elbows

  • We do this often
  • Rubbing Elbows accelerates learning, so might also accelerate learning bad habits. Don’t rely on pair programming alone.

Sweep the Floor

  • A good way to learn different parts of the team
  • Don’t keep doing it
    • But a good team should not allow one single person to keep doing this

Perpetual Learning

Expand Your Bandwith

Practice, practice, practice

  • Code retreats, katas, ..

  • The Real Guys seem to do this ALL the time. Even if they have only half an hour of downtime during a lecture, they are practicing:

    I [Uncle Bob] remember sitting down with Kent Beck one afternoon to write this algorithm just for fun. I figured it would take us 10-15 minutes. He and I paired on it, test first, for 30 minutes, and got nowhere. Eventually we gave up because we were teaching a class together and actually had to spend time with the students. (from http://blog.8thlight.com/uncle-bob/2012/04/20/Why-Is-Estimating-So-Hard.html)

  • If you possess Etudes for Programmers, everyone will be jealous
  • Some online resources:
    • …

Breakable Toys

  • You’ll learn different things from a one-time spike vs a toy you can keep working on (see also Concrete Skills)

Use the Source

  • An unexpectedly good way to pick up programming idioms in an unfamiliar (or even more familiar) language

Reflect As You Work

  • Personal Practice Map looks kind of intense and verbose just for reflection. Is this the right action?
  • Skill != experience

Record What You Learn

  • Is about yourself

Share What You Learn

  • Is about the community (and in giving, you will also receive, of course)
  • You can solve both patterns with a single tool: a public blog
    • Except for things you are not allowed to share to the public. This is especially risky with proposals still in the pipeline.

Create Feedback Loops

  • Objectivity is important here
  • Measuring is weasuring!1

Learn How You Fail

  • If you don’t fail, you’re either not doing anything or not noticing your failings. Both are bad.

Construct Your Curriculum

Reading List

  • Implementation of this pattern for books: goodreads
  • For blog posts etc you can use a bookmarking tool like Delicious
  • In the software factory Leuven, we give each new developer 3 books to read when he starts
    • These are: Refactoring, Head First Design Patterns and Domain Driven Design
    • This practice doesn’t seem to be followed as closely as it was a few years ago
    • Should we actually make people do this? Can’t they learn on their own?
    • Are these the right books?
      • What about Clean Code, Effective Java?
      • What about methodology books: Extreme Programming, Lean startup?
      • What about learning to learn: this very book, Apprenticeship Patterns?
    • Shouldn’t these be project-specific?
  • Very important in reading groups: have someone with experience to guide and help the group. That person will also learn from explaining!
  • How can we help each other with this?
    • Links to your goodreads profile might be a good start!
    • This is probably a more natural and more sustainable way than keeping lists on some forgotten corner of a project wiki
    • Although such a list2 can be an interesting starting point!

Read Constantly

  • What is next for us?
    • A CQRS Journey
    • Head First Design Patterns
    • Domain Driven Design
    • Working Effectively with Legacy Code
  • Interesting application of this pattern: don’t check Facebook for the 35th time, start reading blogs or books. Use you Reading List!
  • Another interesting application of this pattern: keep books on you smartphone. You usually have this with you when you have some time left.
    • Hooray for books that are available online (like Apprenticeship Patterns)

Study The Classics

  • There is more/different worth in books than in articles/blogs
    • Books are written to last for a while, books are proofread, books need an audience, books usually cite their sources
    • Blog posts are very in-the-moment, written by one person
  • What are classics?
    • Those books that get cited a lot in other books
      • It’s like PageRank for books
        • BookRanks

Dig Deeper

  • As opposed to “I don’t know how, but it works”
    • How far do you have to go?
    • Deep enough, be pragmatic
    • Until you understand enough for the current context. Don’t let yourself be stopped because you have to search in library code, specifications, …
    • You might want to go just a bit further than your current context, it’s useful to have some more notions about what you’re doing in order to minimize the chances of running into trouble by something you completely didn’t expect
  • Interestingly, closed source third party tools can prevent you from going deeper
    • Possibly one of the more important reasons to choose open source libraries and tools!
  • This is the number one reason why you’re never done with learning. You can always dig deeper!

Familiar Tools

  • Mostly, be aware of them and how they are evolving in the bigger picture
  • Newer is not always better
    • But the only way to know if something new is something better is to experiment with it. For each blog post saying it is better, there will eventually be two that say it isn’t.
  • To learn new tools, you might want to experiment with a Breakable Toy
    • Be aware of how many new tools you introduce vs how many familiar tools you use. You can quickly lose a lot of time on unexpected problems if you learn too many things at the same time
      • e.g. trying to learn angular via a Yeoman setup will also introduce you to grunt, minification, js test runners and probably the legend of the Holy Grail somewhere
        • You’re still learning, but depending on your goal it might not be the best investment of your time

Conclusion

  • Software is craft, not engineering
    • When someone creates a car engine that explodes, regulations and standards quickly arise.
    • When someone creates a software project that goes off the rails, no-one learns anything from it.
      • But we do have sets of best practices, like ‘prefer composition over inheritance’ or the SOLID principles
    • This comes down to: software projects are non-repeatable experiments. You can’t do the same project again, because the people, the tools, the setting will have changed, and because no-one invests in software that already exists. Compared with cars, which are created in factories, thousands at a time.
  • There are no master craftsmen in software
    • Oh snap
    • What about for example Thoughtswork? They seem to generate a stream of pretty good developers. Or is that simply because we subjectively believe they are better, by the blogposts they write? We haven’t studied the results…
  • Most developers think they are better than average, but are worse than average
    • That’s because of the skewed distribution and the maybe somewhat wrong definition of average on the graph
    • Everyone can call himself a programmer when they succesfully created something, even though they only used 3 skills of the 2000 that make a highly skilled programmer

Conclusion about the entire book

  • It inspired us to take action. One of us started a blog, someone else connected to the community on Twitter, someone else started a Breakable Toy and is getting colleagues to collaborate on it…
  • It changes the way we think
    • Quote: “another book, you just put away after you’re finished, happy you learned something. This sticks and keeps going in your head”
    • It even influenced the thought process of one of our developers while hiring, with more focus on ‘how much does this candidate seem interested in learning and improving’

What next?

We don’t want to force anyone to participate, and we don’t want to limit our audience and community to Cegeka people. So we should probably document our path and invite others along the way on media other than the internal Cegeka Insight portal. This seems like a more organic way to stay in touch. However, we shouldn’t neglect to share the relevant things on Insight and through word of mouth. To get you started:

Please add to the above list3, let’s create a community of software craftspeople!

  1. A silly translation of meten is weten, to measure is to know ↩

  2. Link to intranet site removed ↩

  3. Internally this is a wiki page, but on this blog you can always send pull requests! ↩