More on this book
Community
Kindle Notes & Highlights
It is worth remembering that nothing should be set in stone. Choosing to adopt a practice does not mean using it forever. As many Agile disciplines have taught us, we inspect and adapt.
Knowledge is the most common return on investment expected from a job.
If, for whatever reason, our job is terminated, knowledge and experience are the only things we will take with us.
If we always focus on learning and becoming better software craftsmen, finding jobs that can provide us with a good income, stability, and security will always be a much simpler task than if we had spent our careers just focusing on getting more money.
Choosing jobs just for the money can bring our careers to a halt, making it almost impossible to put it in motion again.
companies that encourage this type of behavior are left with a bureaucratic and incompetent layer of managers, totally unqualified to understand the intricacies of the job done by the more qualified people below them. This is called “the Peter Principle,” and its effect could be stated as “employees tend to be given more authority until they cannot work competently.”
The identity and culture of an organization are defined by its people and not by emails sent by the chief executive officer (CEO).
Job descriptions are anti-patterns. Lou Adler has a series of articles on the topic at the website www.tlnt.com. He says that traditional skills and experience-based job descriptions “are anti-talent and anti-diversity, aside from being terrible predictors of future success.”
No internal promotions: 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?
Recommendations should be encouraged but not financially rewarded.
Passion was the most important criterion, even when compared to technical skills and programming languages. I wanted people who were constantly learning, who took the time to try new things, who loved to share what they knew with others, and who were active in their communities.
means. This is totally context dependent. Different teams, with different cultures, developing different applications, will have different views of what a good developer means. I‘ve had this discussion with many experienced developers over the years and not once were good developers defined according to knowledge of a specific technology, years of experience, or academic background.
at least some of the following items: GitHub account, blog, open source contributions, technical communities and user groups with which they were active, summary of any pet projects, Twitter account, list of favorite technical books, conferences where they either gave talks or attended.
As a company, don’t think you are the only one applying filters and looking for the best people. Good developers are also filtering bad companies out and looking for the best ones.
No change can be made effectively if the people involved are not motivated or don’t really care about their jobs.
Bad tests are worse than no tests at all.
we will never change an organization by forcing people to adopt a new process or different practices. Instead, we should create a culture of learning, where people can find their own motivation to make things better.
However, instead of having managers trying to impose how, when, and what developers should learn, companies should empower developers to create their own culture of learning. If imposed, it becomes obligation, which in turn may lead to lack of interest.
Comments should never be personal.
It doesn’t matter who wrote the code.
Never look at the commit history during a group code review. Focus on changing the future, not on dwelling on the past. • Comments should be objective and constructive. The focus is on how to make the code better and not to say why it sucks. • Sometimes having a facilitator helps. Her role is to make sure everyone speaks and that there is no fingerpointing.
Choose a kata, add a few constraints (you cannot use an else statement, you cannot speak to your pair, you need to commit your code every two minutes, you need to use a tell-don’t-ask approach, you need to write acceptance tests first, etc.), and let them choose which languages and frameworks they want to use.
If you think you are going to change an entire organization with your enthusiasm and the knowledge you got from a few books, forget it. That’s not going to happen.
Over the years I found that convincing other developers to adopt technical practices and tools or change their attitude was far harder than convincing managers.
Many developers suffer from what Kent Beck calls adolescent surety. They think they have the secret formula for delivering great software and nothing else is worth considering.
Terrence Ryan, in his book Driving Technical Change,
The boss has management problems; you have development problems. Instead of “creating tools to automate something,” you need to say “reducing ongoing project costs.” Instead of “making code more maintainable,” you should say “deliver the project faster.”
The Ivory-Tower Architect: Besides the Irrational, this is the worst type of skeptic for a software craftsman to deal with. They think they know it all. They are smarter than any developer. They think they are at the top of the food chain. Ivory-Tower Architects usually haven’t written a single line of production code for years (useless proofs of concept that have no resemblance with reality do not count). They like to say they are responsible for every technical decision, but very rarely are they held accountable for any of them. If things go well, they get the credit; if not, they blame the
...more
“If I had the power, and could work without anyone disturbing me, and could hire and fire whoever I wanted, I would change this entire organization in a very short period of time.” This is something that crossed my mind many times during my career. However, this is a very naive, inefficient, and potentially self-destructive feeling. And above all, forget it; it’s not going to happen. A one-man army won’t win a war, so choose your battles carefully, one at a time.
Don’t split coding tasks into two tasks: one hour to code this service class and another hour to write unit tests. They are not separate tasks.
Testing, regardless of which type, is part of the coding task and not a separate thing.
Tests and refactoring are part of any coding task.
Refactoring for the sake of refactoring is a waste of time.
Unless you have nothing else to do, there is no point in opening a piece of code that you don’t need to change and spending days refactoring it. The Boy Scout rule says “leave the campground cleaner than you found it,” not “clean the whole campground until it is so clean that you could lick the floor.” Although it would be nice, that’s a pure waste of time and not very pragmatic.
Good practices and processes are good until we find better ones to replace them.
Being dogmatic about certain technologies, practices, or tools, without understanding the context we are in, is not Software Craftsmanship.
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.
The problem is not the amount of unexpected changes in a software project; the problem is our inability to cope with them.
As professionals, we need to understand that a software project is not about us and our egos.
If the value we add to a project is conditional to our continuous involvement in the project, it’s not value. It’s a point of failure.
Solving the problem with a simple and elegant solution is far harder than solving it with a complex and overengineered one.
Great developers even go beyond simple and short solutions; they strive to solve problems without writing any code at all. The best line of code is the one you don’t write.
“Four Rules of Simple Design,” as defined by Kent Beck: 1. Pass all tests 2. Clear, expressive, and consistent 3. Duplicates no behavior or configuration 4. Minimal methods, classes, and modules
J. B. Rainsberger’s version: 1. Passes all tests 2. Minimizes duplication 3. Maximizes clarity 4. Has fewer elements
Instead of choosing your favorite set of patterns and then trying to make your problem domain fit into them, focus on solving the problem via small refactorings, guided by the elements of simple design and SOLID principles.
I still remember the early days of my career. “We have a new application to build? Awesome. Let’s define the architecture for it. What patterns should we use this time?” We would then spend days discussing the architecture. “Cool, looks great. Now let’s speak to the businesspeople and figure out what problems we are trying to solve.” Teenagers, huh?
A craftsman’s primary focus is customer satisfaction.
Quality is not expensive. The lack of skills is what makes well-crafted software expensive. TDD doesn’t slow developers down. Typing is not a bottleneck. Learning and mastering a new skill, practice, or technology is.
Our job as craftsmen is to lower the cost of quality to a point that it is not a concern anymore.
True software craftsmen focus first on solving problems, not on writing code. However, when they do need to write code, they focus on writing quality code—code that is testable, easy to understand, and easy to maintain.
