Software Craftsman, The: Professionalism, Pragmatism, Pride (Robert C. Martin Series)

by Sandro Mancuso

When we talk about steadily adding value, we are not just talking about adding new features and fixing bugs. This is also about constantly improving the structure of the code, keeping it clean, extendable, testable, and easy to maintain.

The relationship between software craftsmen and their clients should be seen as a productive business partnership, regardless of which contractual model we may have.

We need to remember that when we say yes, people will take that into account and make plans based on it. Our bosses will make promises to their own bosses, other teams, customers, or partners based on what we said. Not being honest and transparent may cause huge damage to the entire company. Professionalism means being honest with ourselves, with our teammates, and with our managers and customers.

We have two options here. We can either see all the challenges of working with legacy code as a pain in the neck or we can see them as very interesting problems to solve. I personally prefer the latter. It is easy to say that a piece of code is badly written. It is easy to complain or even laugh. But the question is: are you good enough to make it better?

Knowledge is the most common return on investment expected from a job. Developers choose jobs according to what they want to learn, and they leave their jobs either when they are not learning anymore or when whatever is left to learn is not aligned with their career aspirations.

Normally people get promoted into bigger jobs because of their achievements, leadership, team skills, and other important aspects related to the new job. No one gets promoted because they know the APIs of a framework or have five years of Java experience. If job descriptions are not used for internal promotions, why would they be effective to attract new talent?

As part of our selection process, we ask developers to complete a code assignment that may take at least a weekend to complete. In order to convince them to go through the process, even knowing that we are not ready to hire, we promise to provide them with a very comprehensive review of their code. With this approach, applicants at least get some valuable advice on their code, and we can build a pool of talented developers who have passed our selection process, and we can call them when we are ready to hire.

If a job description is needed in order to reach a wider audience of developers, make sure the job description clearly states your company’s culture and values; project details; expected responsibilities and technologies used (instead of required). Focus on passion instead of specific technologies and never use years of experience, academic background, certifications, or any other criteria that are not relevant to the job.

One technique I find very useful when conducting interviews (or should I say conversations) is mind-mapping. I usually take a few pieces of paper and a pen, and I start the interview with a very open question. What is well-crafted software for you? What are the main challenges in a software project? In these examples, well-crafted software and challenges would be the root of my mind map.

Whatever we do as an interviewer, we should never let the candidate struggle for too long. We should wait for a maximum of three or four minutes, and then make a few suggestions. The candidate is already under pressure, and making her struggle for too long will just make things worse.

Each candidate may feel comfortable with different tools and frameworks. Asking the candidate to bring her own laptop to the interview is a good way to see her working with her own favorite tools, and it can save precious interview time.

Experienced developers should always take less-experienced developers to the interviews with them. Watching more-experienced developers interviewing will help them to conduct interviews in the future. Over time, they can switch roles. The less-experienced developer will be the interviewer, and the most-experienced developer will be the observer.

When the business is still trying to figure out what they want, and the only things they have in mind are ever-changing, half-baked ideas, the best way to help is to put something in front of them as soon as possible. We should be able to change the code almost as fast as they change their minds, giving the business an opportunity to visualize their ideas and also to get feedback from the people who will use the application.

Generic code, although more extensible, is more complex than specific code.

not always. abstractions can be used to encapsulate complexity

Passion. That summarizes it all. Software craftsmen are passionate about software development and their profession. They are passionate about solving problems with simple solutions. They are passionate about learning, teaching, and sharing. Software craftsmen are passionate about helping the software industry to evolve; sharing their code; mentoring young developers; sharing their experiences via blogs, books, talks, videos, and conversations; and being active in technical communities. Software craftsmen are humble, always ready to learn from more-experienced developers, and eager to help the less experienced.

Whenever we feel we are not moving forward, we are not learning or enjoying ourselves anymore, we should move on. Loving the company and our colleagues is not reason enough to stay in a job.