Alexandre Lim

A classic book in the software industry. We should always strive to grow and make the software industry a better place. Software Craftsmanship is about professionalism in software development. It's about humble and passionate developers wanting to perfect their craft, share their knowledge, and serve their clients to the best of their abilities.

Notes

How it is done is as important as getting it done.

The longer we stay away from code, the harder it is to get back to it.

There is a huge difference between having ten years of experience and having one year of experience repeated ten times. Seniority is transient and relative. Seniority is not a badge we can wear for the rest of our lives after completing five years in the industry. We need to ask ourselves: senior compared to whom? In which technology? In which context? There is no such thing as a senior or junior developer.

Agile can help to make sure the team is building the right thing and the thing right.

We don’t do Agile. Either we are Agile, or we are not.

Agile does not solve any problems; it exposes them.

Being good at writing code is the minimum skill expected from software professionals. Testing, understanding the business, and good communication, have become part of the skill set that software professionals need today.

Agile and Software Craftsmanship complement each other. Agile methodologies help companies to do the right thing. Software Craftsmanship helps developers and companies to do the thing right.

Software Craftsmanship is about professionalism in software development. You can think of it as an ideology or a mindset.

Sharing and mentoring are at the heart of Software Craftsmanship.

Choosing to work for a client who is not interested in or does not value the skills of a software craftsman is pointless.

If we think that a piece of code we wrote sometime in the past is still good enough today, it means we didn’t learn anything.

For us, software craftsmen, caring about and being proud of our work is a given. Constantly finding ways to become better professionals is a lifetime commitment. Satisfying and helping our customers to achieve what they want to achieve in the most efficient way, is our main goal. Sharing our knowledge with less-experienced software craftsmen is our moral obligation.

Who owns your career?

Companies should invest in their people, but software professionals should not see that as their obligation.

Keeping up to date and constantly getting better at what you do is key to a successful career as a software craftsman.

Type of books:

All software developers should have their own blogs, regardless of their experience. We should treat our blog as a record of our learning and progression—a history of our thoughts, ideas, and views of the world over our careers. We should first write for ourselves.

If we want to be good at writing quality code, we need to practice how to write quality code. When practicing, the focus should be on the techniques we are using. Not on solving the problem.

We should always try to create opportunities where we can learn something we don’t know.

The day we stop learning and practicing is the day we start losing control of our careers.

Not being honest and transparent may cause huge damage to the entire company. Learn how to say no and provide options. Negotiation is a skill we all need to learn. Don't avoid necessary confrontations.

A good professional would never do something that could be harmful to a client just because the client is paying for it.

Code is organic, not mechanical. Like a garden, code needs constant maintenance.

When the code base gets into a situation where changes or additional features take too long to be implemented and developers are scared to touch the existing code, action must be taken immediately.

We don’t have time, but apparently, someone else does.

Dedicated QA teams are an anti-pattern. Testers should not waste their time executing test plans that could be automated by the development team.

We cannot say that a coding task is done if it is not tested. Testing should never be a separate task.

Software projects are not about a single developer. Software projects are not about you.

If we want things to be better, we need to do something about it.

We can either see all the challenges of working with legacy code as pain, or we can see them as very interesting problems to solve.

Our attitude toward our job will make it more or less enjoyable.

Saying we have values is not enough. Values are things you live by.

The Boy Scout rule should just be applied when we need to make a change or understand one area of the code, not everywhere.

Being pragmatic is one of the best qualities that a software craftsman can have. Dogmatic thinking is bad. We should constantly ask ourselves why we are doing what we do.

The best way to know if one practice is better than the other is to compare the value both bring to the project. Then compare how long their feedback loops are. Choosing to adopt a practice does not mean using it forever.

We, software craftsmen, value and control our careers. We understand that a career is a life-long journey that, depending on our choices, may or may not lead us to mastery.

When we are unsure where we want to go with our careers, we need to start and open doors. We need to create situations where opportunities can be presented to us.

When it comes to our career, there is no right or wrong. Keep in mind that knowledge is forever. Money, stability, and security are not.

With basic needs satisfied, software craftsmen always choose jobs with autonomy, mastery, and purpose.

Our careers will always be more important than any specific job or company. Pursuing a career inside a company is not the same thing as pursuing our own careers.

Interviewers very rarely realize how bad they are at interviewing. They do not always know exactly what they are looking for or how to find it.

The identity and culture of an organization are defined by its people.

Job descriptions are anti-patterns. If one is needed, the focus should be on detailing the expected attitude and responsibilities, types of projects, technologies used (not required), and the values and culture of the company.

Recruiting when you are desperate will make you bring the wrong people to your organization.

Having an open conversation about real-world and concrete scenarios, exploring different approaches and solutions, and writing code together are the best ways to determine a candidate's experience.

Recruiting the first developers for a new project is slightly different from recruiting for an existing project.

When interviewing, be honest and humble. Treat candidates like fellow professional developers. Listen to the candidates and keep your mind open.

Low morale can be one of the main reasons a software project fails.

Nothing is more annoying for a developer than having a manager or an architect dictating what she should do.

The best person to motivate a developer is another developer. A good developer. A software craftsman.

Creating a learning culture is one of the most efficient ways of injecting passion into a company.

If you think you will change an entire organization with the enthusiasm and knowledge you get from a few books, forget it. That’s not going to happen. You don’t need to change every person to make the organization more effective or a better place.

Forcing developers to attend any of the learning initiatives will just make things worse.

Sometimes it is just impossible to accommodate everyone.

The secret to having a healthy community, and keeping the sessions going, is to have a rhythm.

The first thing that any software craftsman needs to do before trying to change a team's culture or introducing new practices, tools, or processes is to identify the different types of skeptics she is facing.

The most important thing to drive change is courage. You can’t be afraid to engage in heated debates.

We can’t change anything if people don’t trust us. Know your stuff, lead by example and choose your battles.

Fear and incompetence are two of the culprits of bureaucracy and politics inside companies.

If you want to change things around you, don’t fear. Prepare yourself, practice, be ready, study, and be the best you can be. Regardless of what happens, always speak the truth. The only advice here is just to be careful not to be an asshole.

Real software professionals understand that responsibility should always come with accountability.

Driving technical changes is hard. Very hard. Prepare yourself. Be brave. Drive.

Don’t rush to call people unprofessional just because they don’t use certain practices. Ask them what practices they use instead, and then compare the benefits they have over your practices.

We need to understand that a software project is not about us and our egos.

Generic code is great, but it doesn’t come for free. The more generic, the more complex it becomes. Only introduce abstractions when they are really needed.

Craftsmanship without pragmatism is not craftsmanship.

One of the best ways we can help the business to achieve its goals is to be able to change the code almost as quickly as they change their minds.

Climbing up the software development ladder doesn't mean becoming a manager or an architect. This is not a career progression but a career change.

Being a craftsman doesn’t mean you are superior or better than any other developer. It’s just stating the values and professional attitudes you live by. Also, that doesn’t mean that developers who don’t call themselves craftsmen don’t have the same values or attitudes.