The Craftsman I Would Like to Be


Casa Batllo, Interior (Barcelona)A few weeks ago I visited an amazing city that has become one of my favourites, Barcelona. Whenever I visit a new city, I try to see it not only as a tourist but also from the point of view of people living there. As such, I prepare by reading about its history, daily life, local food, industry, status. I was expecting to have a great time in Barcelona, a city well-known for its good food, nice walks and many opportunities for leisure. What I didn’t expect at all was to learn more about being a software craftsman.

You may have heard about Antoni Gaudí, the architect that gave Barcelona some of its most interesting tourist attractions. I had read about him. I’d read about his naturalistic style and of his monumental design for “La Sagrada Família“. I thought I was well-prepared, but I was in for a big surprise. Antoni Gaudí was a revelation: he wasn’t only an architect, but a complete craftsman.

It’s impossible for me to explain in words what I’ve seen in his work. I can only hope to give you a hint of his craftsmanship by picking a few facts about him:

  • Gaudí was first a master of iron. He learned this craft from his father, and used it all his life to design and build metal decorations for his buildings. He then learned other crafts: ceramics, stained glass, carpentry
  • When he graduated the School of Architecture, he told his friend “they say I’m an architect now”, showing more interest for the job than the certificate
  • Unlike most architects, he disliked sketches and preferred building detailed 3D models. This allowed him to spot issues and see design improvements early
  • He viewed architecture as a complete art. He was on the building site, working with a (cross-functional) team of craftsmen filling various roles in the construction. He was thinking of every little detail: the windows were fit for the natural light in the site, the look of the staircase handles, the anatomical shapes of the door handles (custom-made, and different, based on his designs), the furniture and even the font for the apartment letters in the house.
  • He was pragmatic. Many of his solutions are brilliant combinations of simplicity and aesthetics done for a low price – sometimes from recycled materials, otherwise just applied genius.

To sum it up, Antoni Gaudí was an architect that believed in painstaking attention to detail, simplicity and aesthetics in every single thing found in his buildings.

This is the type of software craftsman that I want to become. What this means to me is that I should:

  1. Know the programming languages and techniques of the day (like Gaudí mastered the materials and building techniques of his day)
  2. Have the attitude that what I realize is more important than my title (he was always the same person, didn’t become an architect after getting a certificate)
  3. Think at different levels, from the strategical view of software architecture to the short-term view of software design (much like he could think of the building architecture and consider all the small details such as the door handles)
  4. Only by considering the triad of form, interaction and implementation on every decision I make can I hope to create amazing products. This means taking into account user interface, interaction design and code as a whole, not as separate parts
  5. Be pragmatic every time. Just because I know a tool doesn’t mean I have to use it. Just because I like a certain technique doesn’t mean it’s always useful. Simple solutions that create the required feature and make economies on the short and long-term are the most useful.
  6. Build an aesthetic sense from examples of high quality software that helps me make fast decisions. You might call it intuition.
  7. Gather a team of craftsmen that will not only work together but also learn and grow together over the long-term
  8. Deliver working software that delights users and customers. This is not only the job of the graphical designer, interaction designer, product owner. It’s also my job as a developer
  9. Write only the technical and functional documentation that is useful. Favour working software over detailed diagrams. (Gaudí had to work with real materials and build 3D models; we are lucky to work with code, easier to sculpt than stone – when written so that it’s easy to change)
  10. Learn throughout my life. Gaudí was a keen observer of nature, and copied its patterns in his works. A naturalistic style of writing code might be interesting too (we have adopted concepts such as fractals, growth, branches of code). More importantly is to learn from any other domain techniques that advance the craft.
  11. Always adapt to the medium and the customer context. Gaudí showed a high adaptability to the site, that allowed him to design parks, houses, utility rooms and cathedrals.

This is my ideal view of a software craftsman. As any ideal, I can only hope to get closer to it without ever reaching it. It’s useful for me because it gives me clarity and purpose and it defines my values.

Do you find this useful? Let’s see if we can advance together towards this ideal.

PS: Please don’t see this as a “certification” that you “have to meet” to become a “craftsman”. This is my list, and I will apply it to myself. If, by any chance, you find it useful, I’d be happy to work with you and advance in this direction. If you don’t, my only piece of advice is: clarify to yourself what you want to become; it will help you get clarity, purpose and values.

PPS: This list is far from perfect – it’s at best a first draft – and will probably get clearer in time. I felt it’s important for me to write it down now. I will appreciate any questions or feedback that will help me clarify it.


  • Nice article!

    One key point in Gaudi work is also that he invest his time in really few projects, that allowed him to achieve a quality and depth that is a costant in his art.

    Maybe we should focus on few languages/frameworks then?

    • Thanks Marcos! I appreciate it!

      It’s true, as far as I know Gaudì did invest his time in a few projects. However, he did invest a lot of time into mastering the things he needed for those projects. I found out from various sources that he learned many crafts such as: sculpture, carpentry, wrought ironwork, stained glass, ceramics, plaster modelling. He didn’t master them all, but he knew what is possible and what’s not possible. This allowed him to innovate in some of these domains.

      I won’t tell others what to do :), I can only say what I would like to do and motivate why. I know that learning more programming languages and more software architecture and software design styles has helped me understand programming better. I believe that learning more about the existing frameworks and languages helps me with my work.

      The interesting and possibly counter-intuitive thing is that they aren’t even that different. However, most programming languages tend nowadays towards a mix of OOP, functional and dynamic constructs. I’ve learned many of these constructs (except those extremely functional) and can use them even in programming languages that don’t support them by design. Of course, this is valid to a certain extent; I’m not sure that you can write monads in C.

      Same with frameworks. Standard frameworks were very different a few years ago in their treatment of collections but now use mostly generics / templates (see STL, JDK, .NET framework). They are still fundamentally different in some aspects, but that’s because they have different design principles behind: portability for JDK and STL, learnability for .NET Framework and ease of use for the python standard library.

      Web frameworks are however very similar. I’ve identified three main categories: * lightweight category (Sinatra, py2web) that do very few things by default and you can add more as plugins * the MVC convention over configuration category (ruby on rails, grails, django) * the everything-you-need-is-built-in category (ASP.NET, ASP.NET MVC).

      Mastering all of them definitely takes a long time. Learning the basic things, not so much.

      Again, I’m not trying to convince anyone to learn them. I don’t know if it’s the best thing for me, so it’s not fair to force it on anyone else. I did however try to justify why I think what I want to do is hard, but still possible. Thank you for giving me this opportunity.

  • Great list. I am really baffled of how much you want to achieve in your work! 🙂 One thing that confused me is your relation of Gaudi’s work to Software Craftsmanship. It is the big weakness of the craftsmanship metaphor: We always try to analogize our job as software creators. We look for builders, gardeners, plumbers, maybe butchers and bakers? – No, stop. I’ve never heard something like: Just as a baker does the same thing again and again we do the same again and again and try to perfect the routine of programming CRUD programs.

    Also, I believe Gaudi did not actually build his houses himself with his own hands or with a team of people having similar skills as he had. Gaudi was extraordinary. I doubt that a guy like he is a useful example for “the masses” of developers.

    • Imagine my surprise when I re-read the list! 🙂 I’m kidding, I know it’s impossible to achieve, but that’s what makes it interesting for me. Easy stuff is boring for me.

      Regarding the craftsmanship metaphor, I agree with you to some extent. First, any metaphor has limitations, and it’s obvious software craftsmanship has its own. Second, software craftsmanship was often described by comparing software developers with musicians and others.

      But I would add to this the following.

      To me, the fact we’re comparing with other crafts shows that we are in dire need of defining the software developer profession. Unlike most construction engineers who know what to do so that bridges won’t collapse, most software developers don’t know what to do so that the products will succeed. Maybe we’ll never reach that point, maybe it’s impossible. However, what are the things a software developer should know in order to get closer to that ideal? I don’t think anybody knows. That’s the main idea of craftsmanship to me: it’s a path, not a destination. It will probably go away as an interesting historical fact, after we figure it out (or after we figure out we can’t be predictable).

      Therefore the metaphor is about learning these things. I hope that if more people practice and learn the practices we know today – be it pair programming, TDD, design principles, refactoring – we will together find out if, when and how they’re worth it. The medieval craftsmanship was nothing more than learning a craft from peers through apprenticeship, journeying and practicing. Is this metaphor outdated? A bit. Can we bring it up to date? I think we can. Should we try? I don’t know, but I will try it.

      I’ve wrote about it in more detail here, if you’re inclined to discuss more:

      As about Gaudì, he was indeed extraordinary. This is why I took him as my and only my personal inspiration. I’m actively discouraging anyone from taking him as an example as well. I am aware, as I said, that I cannot reach his level of expertise, and it is therefore very wrong to ask anyone else to do so since it might prove a dead end and result in unhappiness. I am however incredibly fortunate in that I have the freedom to do to some extent each of the things on my list. It won’t be easy (otherwise it will be boring), but I’m in a much better context than most programmers (due to being unbelievably lucky).

      As for the relation between Gaudì and craftsmanship, I explained my views in the article. Again, I’m not trying to force it on someone else. Maybe the simplest way to explain it is this: I need an inspiration to move to the next level in my work. Gaudì is my personal inspiration. It’s as simple, and complicated, as that. Reflections on design, craft and software

A new home for merging ideas about design

It is my strong belief that software design can learn a lot from other design disciplines. I wrote blog posts, a book and did talks on this topic, and it was time to group them all together. These ideas have now a new home: My plan is to add more blog posts there, and to involve other people doing work in this area.

Read My Book “Usable Software Design”

How UX techniques can be applied to software design to develop software better (given that the developer is the user of software design).

Read My Book “Coderetreat Hosting And Facilitating”

Learn how to facilitate and host a coderetreat from two of the most experienced coderetreat facilitators.