More on this book
Community
Kindle Notes & Highlights
Unfortunately, the notion of seniority hasn’t changed much in the last 20 years. Software developers are normally considered senior according to the number of years they have worked in the industry and not according to their knowledge.
There is a huge difference between having ten years of experience and having one year of experience repeated ten times.
Seniority is not just about writing code or being very familiar with a language or framework. Modern developers need to know how to speak to customers, automate tests and deployment, make technological choices that may affect the entire business, work in distributed teams, help clients to define and prioritize requirements, report progress, manage changes and expectations, present products to potential clients or partners, help with pre-sales activities, estimate time and costs, interview new team members, design and evolve the software architecture, deal with nonfunctional requirements and
...more
Being good at writing code is the minimum skill expected from software professionals. Testing, analysis, ability to understand the business, good communication, and a more extroverted personality became part of the skill set that software professionals need today.
The best architectures, requirements, and designs emerge from self-organizing teams.
Every team member could do whatever he or she wanted—as long as his or her boss agreed.
Having such an amazing software delivery capability in their companies, the only thing they needed was a better process, promoting communication and empowering people, and everything would be great. “Let’s improve our process and everything else will be OK.” In their minds, magically, the same old developers with the same old habits would start producing amazing software.
For a feedback system to work, we need talented and passionate professionals who care enough about what they do, raising their voices when they feel something is wrong or could be done better.
But when it comes to XP adoption, things get ugly. Many customers immediately reject the idea of having two developers pairing together—they think it is a complete waste of money.
Sometimes, the rejection comes from the developers themselves. They just cannot see the point in pairing. Some think they would be exposing their lack of knowledge in certain areas. They do not want that. They cannot see the point of writing tests either, since at the end of the day they are great developers and do not make mistakes. Just mediocre developers need tests, they would say.
Some companies thought that the important things for a successful software project were a business expert writing requirements, a technical leader (who doesn’t code) drawing diagrams and writing documents, and a manager to supervise (micro-manage) the project.
The developers were then presented with a pile of requirements and technical documents—that were prepared months in advance—and presto, software comes out the other end. One year later, developers present the software to the business, everyone loves it, and the bug-free software is deployed to production.
Another common problem I’ve seen is that the people leading software projects are normally too far away from the software itself. Many are either not technical or can’t even remember when they wrote their last line of code—if ever.
Every software process, including Agile processes, will assume technical excellence. Without technical excellence, every software project will be a painful, frustrating, and expensive experience.
Having amazing developers who can produce high-quality code but having a process that does not enable them to work well will also not make projects succeed.
Improving the process without improving technical excellence is pointless.
Software craftsmanship is a long journey to mastery. It’s a mindset where software developers choose to be responsible for their own careers, constantly learning new tools and techniques and constantly bettering themselves. Software Craftsmanship is all about putting responsibility, professionalism, pragmatism, and pride back into software development.
Software Craftsmanship is about professionalism in software development.
The Pragmatic Programmer: From Journeyman to Master by Andy Hunt and Dave Thomas in 1999.
In August 2008, during his keynote speech at an Agile 2008 conference, Uncle Bob proposed a fifth value for the Agile Manifesto, namely “craftsmanship over crap.” He later changed his proposal to “craftsmanship over execution.”
The 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 the following: 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
...more
You are scared to change parts of this code because you don’t understand how it works, and you have no confidence you will not break something else.
This application is working software, but is it good enough? Well-crafted software means that, regardless of how old the application is, developers can understand it easily.
A paraphrase of a Boy Scout rule (first applied to software by Uncle Bob) states that we should always leave the code cleaner than we found it.
The problem is that the same bad techniques that were used to build the old application will also be used to build the new one—making the new application as bad as the old application after just a few months or years.
I was quite surprised to hear from some developers and Agile coaches that the Software Craftsmanship community is a group of self-selected and elitist developers. A developer cannot be considered a software craftsman if he or she thinks Software Craftsmanship is about elitism, is not humble enough to learn from others, or is not willing to share his knowledge and mentor less-experienced developers.
Turning up to work on time, keeping your head down, and just doing what you are told to do is not what it means to be a professional.
Software craftsmen are not factory workers. We want to actively contribute to the success of the project, questioning requirements, understanding the business, proposing improvements, and productively partnering with our customers or employers.
Developers that say it is not their job if the task is not code-related are not real software craftsmen.
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 some time in the past is still good enough today, it means we didn’t learn anything since.
Developers who rely only on their companies to provide them knowledge are not professional software developers. They are just factory workers in disguise.
The Pragmatic Programmer, The Mythical Man-Month, Design Patterns (GoF), Test-Driven Development: By Example, Extreme Programming Explained: Embrace Change, The Clean Coder, Software Craftsmanship, and Refactoring.
We can find a good source of coding katas at codingkata.org, codekata.pragprog.com, and kata.softwarecraftsmanship.org.
Pair programming is more a social activity than a technical practice.
I’m the smartest man in Athens because I know that I know nothing.
If you are the type of person that says, “I don’t want to touch a computer outside work,” you probably should think again about your career choice;
Some managers can be very persuasive in getting developers to commit to a tough deadline. “Guys, you know how important this is. I know it will be tough but I trust you. We really need to get this done. I’m sure if you guys work hard you will be able to deliver.” In order to avoid confrontation or to demonstrate a can-do attitude, developers respond: “OK. We will try our best.” When we say we are going to try, two things normally happen: the person or people we say that to will understand that we are going to deliver it. For them, “trying” is equal to “yes, it will be done.” The other thing is
...more
Professionalism means being honest with ourselves, with our teammates, and with our managers and customers.
Traditional managers and business consultants can say whatever they want about the importance of a good process and documentation, but the truth is that in a software project, the most important deliverable is the software itself.
Rather than construction, programming is more like gardening.
Interestingly, some people say that they don’t have time to do it properly, but it seems that they always find a way to justify the amount of time and money spent on long testing and bug-fixing phases. “This is how software projects are,” they say. “First there is a construction phase, then there is the testing and stabilization phases. Every software project is like that, isn’t it?”
Our industry is finally learning that quality code may not guarantee the success of a project, but it can definitely be the main cause of its failure.
Dedicated QA teams are an anti-pattern. Testers should find nothing. Zero. Nada.
Done means tested.
If you don’t like something, change it; if you can’t change it, change the way you think about it. —Mary Engelbreit
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?
For example, all team members must want to be better, to improve communication, to have quicker feedback, to achieve results fast, to reduce the number of mistakes, to do their best to provide a good service to their client, to feel bad when they can’t do their best or are not learning. These are values.
Practices are the validation of values. Practices and values have different scopes. XP practices are specific to software projects. Values are things you live by.
There are many different types of automated tests, with literally tens of definitions for each one of them—many overlapping or conflicting with each other.
