Preface to The Software Craftsman: Professionalism, Pragmatism, Pride

From the book 

Back in the mid-1990s, two years after I started my professional career, a large international company in São Paulo, Brazil, announced that they would be hiring 60 developers in one go. Their selection process would take a few weeks, divided into four phases: a three-hour-long technical test; two weeks of training in their proprietary technology followed by a test; a full day of group dynamics; and a round of final interviews. They announced it in a major newspaper and around 900 developers applied. I was working for a small software house at the time, a place where I was very happy, but I felt that I was ready for something bigger. Since the first phase would be on a Saturday, I decided to apply. Fewer than 300 developers passed to the next phase, and I was one of them. I was happy and confident but worried as well. I had to resign from my current job in order to move forward with the selection process because I would need to take too many days off for the remaining phases. Back then, my financial situation was not great and I could not count on any monetary support from my family. It was quite hard to resign from a job I liked in order to pursue a dream job that I had no idea I would get. Also, I had no idea how I would pay my bills if I didn’t get that new job. But I had to do it. I had to try. That was the type of company I wanted to work for. That’s what I wanted for my career.

I was 21 years old, and although I was young, I already had quite a few years of coding experience—I started coding when I was 11 and started my professional career when I was 19. The problem is that the mix of youth and a bit of experience can easily lead to arrogance. And by no means was I an exception. Think of an arrogant young developer you know. I could beat anyone hands down. I used to think I was awesome, better than any other person who studied with me at university, and better than the vast majority of the developers who worked with me in my previous jobs.

After going through all of the four phases, the international company announced that they could not find 60 developers at the level they were expecting. They hired just 32, and I was one of them. I was over the moon and more cocky than ever. In my first week there, I was placed in one of the teams responsible for delivering one of the business modules of the system. For the first few weeks, while speaking to developers from different business modules, I heard them talking about this other team, a team that was supposedly the best team in the company. They were the “architecture” team, responsible for the core of our system and for providing all infrastructure code used by the business teams.

The architecture team was led by this incredible guy who, besides doing all the management work, was also a fantastic developer. He was a busy man, but he would always find some time to code, check in code against his name, and review the code written by his team. I heard their team was always working on interesting things and that their code was really good. That’s exactly what I was looking for. I wanted to be working with the best.

After a few long weeks, I decided to speak to the manager of the architecture team, this guy that I heard so much about. I didn’t really know what to say or what to expect. I was only certain of one thing: I had nothing to lose. In the worst-case scenario he would say that he was not interested to have me on his team. One day I saw him alone in the coffee area. I was shaking. I approached him and introduced myself. “Hi, I’m Sandro.” He looked at me and shook my hand with a smile. “I’m Namur. Nice to meet you.” He was calm and relaxed. “I want to work for you,” I nervously said after a few awkward seconds. He was a bit surprised but apparently took it in a very positive way. We then started talking about the selection process, why I applied, what I was expecting from the job. He also asked me if I had pet projects, technologies I was interested in, if I wrote code outside working hours, and some other random things that I don’t remember. After around 30 minutes of conversation he asked me when I could start. I was shocked. I was not expecting that at all. I was expecting to schedule a meeting, have a formal interview, and so on. It took me a long time to realize that he spent the entire conversation measuring my passion for software development. He was analyzing whether I cared about doing things right. He was not worried about my current technical knowledge. “I’ll speak to my manager and hopefully it will be as soon as possible,” I said. After a few weeks I was sitting among my new teammates.

My first day was a Monday. In the morning, Namur came to talk to me and assign me a task. He explained one part of the application and what I had to do, and he said he would sit with me again on Friday to check what I had done. I was thrilled. That was my chance to shine. I had to show him why I deserved to be there. I stayed in the office until almost midnight, slept a few hours, arrived very early on Tuesday, and around two o’clock in the afternoon, I was done. I had finished my first assignment in less than half of the time I had been given. I was feeling great. Well, I always knew how good I was, but being able to do that in that team, in a totally unknown code base, was a huge achievement.

I rushed to Namur’s office and with excitement I said, “It’s done. I finished it. And it is working.” He stopped typing and turned to me. “Making things work is the minimum I expect from someone that is paid for it,” he calmly said. “When you say that something is finished, it is implied that it works.” That was like a big slap in my face. My smile faded away a little bit but I thought, maybe it is just his way of saying things. Maybe he is having a bad day. No, he definitely did not mean to be rude. “Sit here and let’s see what you’ve done,” he continued. I sat there and watched him typing in the command line, checking in the code from source control, and opening my single .pas file containing all my code. He opened the file using this horrible black and green editor on the command line. That was the first time I had seen vi. We were using Delphi back then and Delphi was very famous for its amazingly powerful integrated development environment (IDE). For me, seeing someone opening Delphi files on vi (a Unix text editor) was very alien. “Come close so we can have a look at it together,” he said. I had written about 200 lines of code. He positioned the cursor on the first line and started looking at the code line by line. Every five lines he would stop and say things like “Do you know what happens when we allocate and deallocate memory? Can you see here? You are allocating memory in one method and deallocating it in another method. This is a potential risk of memory leak. Have you heard about temporal coupling? Can you see this block of lines here? If you thought a little bit harder, you could reduce these eight lines to two. Do you know what happens when you have a try/catch block this big? What about the names of this variable and method? What do they mean? Have you ever thought that some of your colleagues, when needing to change this code, may not have the same amount of information and context as you have now? How would you feel if you knew nothing about this part of the code but you had to maintain it? What about this hard-coded bit here? Have you ever thought that if we wanted to change where it points to, we would need to open it, change it, recompile it, and redeploy the entire application? Why do you have this piece of code duplicated all over the place? Wow! This is a big method. Do you know how much we would need to keep in our heads if every single method were that big? What about making them smaller and naming them according to their behavior?” He went on and on.

At some point he stopped and started staring at a few lines of code. He spent a few minutes there, occasionally moving the cursor one page up and down again. Back in the 1990s, a developer would be considered a senior developer if she could write code that no one else could understand. “Wow! She must be really good. I have no idea what her code does.” And I made sure to have some cryptic code in there, trying to show how clever I was. At some point he figured out what the code was doing. I was expecting a compliment, at last. “Do you know how disrespectful this is?” he said calmly. “We work on a very large system, with many teams and developers working on the same code base. Can you imagine how hard it would be to understand the code if everyone decided to show off how smart he or she is? Imagine thousands, if not millions of lines written like that.” And that was a second slap in my face.

It was just 200 lines of code, and I could not answer any of his questions or find a good excuse for the points he had raised. Line by line he looked at the code, criticized it, and explained to me how it could be better. Once we reached the end of the file, I was ashamed and extremely annoyed. He was still very calm, as if we had been looking at some random code written by an absent stranger. “Have you understood everything I said? Do you agree with all the suggestions?” Without saying a word, I just nodded. “Do you feel you could write this code in a better way now?” Without looking at him, I just nodded. “Do you feel you can apply the things we discussed as we move forward?” Once again, I just nodded. He then pressed a few keys and deleted the entire file with all my code in it. “Excellent. Since you still have three days left, do it again.”

I was shocked. I didn’t know how to react to that. I stood up and slowly walked to the door without saying a word. “Sandro,” he called me when I reached the door. I stopped and looked back at him. “How it is done is as important as getting it done.” And with this, he turned back to his computer and started typing again in that horrible green editor.

I was frustrated. In fact, I was furious. I left his office, went straight downstairs, and then outside the building. Who the hell does he think he is speaking to me like that? What a bastard. I can’t work for a guy like that. That’s it. I’m done with this company. I’m resigning. After a few cigarettes, feeling a little bit calmer, I started reflecting on what had happened. Namur had spent over one hour going through my code and explaining to me how it could be improved. He listened to me on the few occasions I expressed my view and calmly showed me that either I was wrong or there were better ways. I realized that for the first time since I wrote my first line of code, I had found someone who took the time to show me how to write good code. I had found someone who, besides being far better and more experienced than I was, really cared about helping others become better. I had found someone who cared about producing great, quality software. I had found someone who took the time to teach me. And more than that, I had found my first mentor.

After a few more cigarettes, I pulled myself together and went back inside a different person. That day I learned I was not as good as I thought I was. I learned how to be humble. I learned that I had a lot more to learn. I learned that just getting things done was not enough, especially when you are working in a team. I learned to be respectful to my peers and clients, not leaving crap code behind. I learned that a great professional cares about his or her work.

For two and a half years I worked with my mentor and some of the best developers I have ever met. That experience shaped me not just as a professional, but also as a person. Although we never used the term, I realized more than a decade later that that was my first encounter with Software Craftsmanship. I learned a lot from all those guys. Technically speaking, it was a great experience, but that was not the most important thing. What was really important to learn was the attitude that my boss and all the other developers had toward their career. The last words he said during our first code review session changed me forever. Ten years later, I founded the London Software Craftsmanship Community (LSCC) (http://www.meetup.com/london-software-craftsmanship) and Namur’s words, “How it is done is as important as getting it done,” were some of the first words I put on the website. Later I also had LSCC t-shirts printed with those words on them. Those words did not just make me a better professional but also made me a better person.

About This Book

After decades and many different methodologies, software projects are still failing. Although there are many reasons why they fail, there are a few things that cannot be ignored: managers see software development as a production line; companies do not know how to manage software projects and how to hire good developers; and many developers still behave like unskilled, unmotivated workers, providing very poor service to their employers and clients. With the advent of Agile methodologies, the software industry took a big step forward, but the percentage of failing software projects is still incredibly high. Why are all these projects still failing? Why are we so bad at delivering successful projects? What is missing?

Although the term “Software Craftsmanship” has been around for over a decade, it was not until recently that it emerged as a viable solution for many of the problems faced by the software industry today.

Software Craftsmanship proposes a very different mindset for developers and companies. Although Software Craftsmanship is not a methodology, it strongly recommends the adoption of certain technical practices and disciplines, mostly the ones defined by Extreme Programming. With a great synergy with Agile and Lean principles, Software Craftsmanship promises to take our industry to the next level. Professionalism, technical excellence, and customer satisfaction are the main focus of Software Craftsmanship. One of its main focuses is changing the perceptions that software developers are like workers on a production line and that software projects can be run as if running a factory.

How can we become better developers? How can we deliver better software projects? With real stories and practical advice for developers and companies, this book is relevant to all software developers and every professional directly involved in a software project.

Foreword

In 1973 Roberta Flack sang “Killing Me Softly.” You’ve no doubt heard it in elevators or on your grandmother’s radio station. It’s a soft, lilting ballad about a woman who goes to a concert and hears a young man sing a song that she so strongly identifies with that she exclaims: “I felt he found my letters and read each one aloud. [He was] strumming my pain with his fingers, singing my life with his words.”

The book you are holding feels that way to me. Sandro Mancuso’s career has been very different from mine. He is a bit younger than I. He and I have lived our lives and worked our careers on different continents and in different cultures. We share neither nationality nor ethnicity. I’ve met him only a few times, and each time it was never for more than a few minutes. In short, about the only thing we have in common is that we are both programmers. But that, it seems, is enough.

Within the pages you are holding you will find a fascinating alternation between autobiographical anecdotes that chronicle the author’s vast experience and authoritative recommendations based on those experiences. If you are a programmer, you will feel these stories and recommendations resonate within you. You will say to yourself, as I did, “Been there. Done that.” And you may hear the strains of that song echoing in your mind as he strums your pain.

And strum your pain he will, because this book is about pain. It is about the pain that you and I and, indeed, all programmers experience. It is the pain of feeling constantly constrained to do a poor job. It is the pain of feeling trapped in an un-profession. It is the pain of wanting to do better and not knowing how.

This book also contains the antidote for that pain. Indeed, I believe it contains the cure. You see, this book is all about software professionalism. Not just the professionalism of the programmer; but the professionalism of the whole software organization. This is a book about Software Craftsmanship.

In these pages the author lays out a plan, a strategy, a set of attitudes, and a suite of principles that every programmer, programming team, and software organization can use to haul themselves out of the mire of mediocrity, to make themselves more professional, more productive, and more proud of the work they do.

The scope of this book is incredibly wide. Topics range from design patterns, pair programming, and Test-Driven Development to how to conduct and evaluate interviews, how to respond to tight deadlines, how to write job descriptions, and how to relate to coworkers and managers.

In short, this book is an encyclopedia on the behavior, attributes, and structure of an organization striving to grow in professionalism and adhere to the principles of Software Craftsmanship.

If you are the type of programmer, team lead, or manager who craves to be able to go home after a long day of work, look in the mirror, and say. “Damn, I did a good job today!” then this is the book for you.

—Robert C. Martin
    August, 2014