This is a great book! Before reading I didn’t know there is an actual software craftsman movement. I’ve heard Uncle Bob use the term but I was unaware of the movement. The book totally speaks from my heart. Many of the attitudes and ideas described by Sandro Mancuso are very similar to my own and the book gave me many new ideas and insights.
Here are a few ideas that I really like:
Agile methodologies are all about quick and short feedback loops. Agile does not solve any problems; it exposes them.
Basically agile consists out of two things:
- Process oriented agile disciplines: The disciplines affect how teams and organisazions work California region phone , collaborate, and organize. It’s about building the right thing.
- Technical oriented disciplines: the disciplines are specific to the challenges of designing, growing, maintaining, and developing the software itself. Examples are Test-Driven Development, pair programming, continuous integration, and simple design. It’s about building the thing right.
Sandro says that many companies that wanted to transform to agile only did it partially. They hired some agile coaches and changed their process to an agile process but did little or even nothing to make their developers better at writing quality software. They assumed the only thing they need is a better process.
But: Every software process, including agile processes, assume technical excellence! It is really important to recognize that the developers need to work on their own technical excellence! And that is basically where the whole software craftsmanship comes in…
Sandro’s definition of software craftsmanship:
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 better themselves. Software craftsmanship is all about putting responsibility, professionalism, pragmatism, and pride back into software development.
The manifesto for software craftsmanship is the next step from the agile manifesto:
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
Attitude of a Software Craftsman
For us, software craftsmen, caring about and being proud of the work we do 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.
How to keep ourselves up to date:
- Read books
- Read blogs and technical websites
- Practice: Do katas, have your own pet projects, contribute to open source projects, practice pair programming
- Socialize in user groups and technical communities
- Expose yourself to situations where you can learn something about the context your are in. This is especially important during the starting phase of a new project. The more we understand about the domain and the business the better.
Quality is always expected
The main problem is this big and wrong assumption that cheap and average code is good enough – maybe in the short term, but never in the medium and long term. As the big ball of mud grows, cheap doesn’t remain cheap: the number of bugs increases, time to develop new features increases, and conversations about rewriting the entire application become more frequent.
If a piece of software is expected to live and be maintained for more than a few weeks or months, neglecting its quality in order to go faster is an illusion.
Misconception about TDD
A very common misconception is that TDD is about unit testing. Although TDD has “test” in its name, TDD is actually a design practice. When test-driving our code, it becomes very difficult to write complex code. Complexity in our code and bad design choices are highlighted by the complexity in maintaining and writing new tests. These tests lead us to re-analyze the design of our code and refactor to make it simpler.
Career as a Software Craftman
The most important thing is to treat every single job as an investment, a step toward a bigger goal. Software craftsmen invest their ever-increasing knowledge, passion, time, dedication, and professional attitude in every job they have. Therefore, like any other type of investment, we need to be clear about what we expect as a return, and we need to measure it regularly throughout the length of that investment.
What I wanted as a return on my investment varied. Exposure to certain technologies or industries; experience with different type of projects; opportunities to develop different skills, play different roles, and have different types of responsibilities; or even having more money were all things that at some point in my career I wanted as a return.”
Our careers will always be more important than any specific job or company. If pursuing a career inside a company means that we would be deviating from our long-term career aspirations, we should probably find another job.
When we are not so sure where we want to go with our careers, we need to start opening doors. We need to create situations where opportunities can be presented to us. No one will offer us a good opportunity if they don’t know who we are, what we do, and, most important, how good we are. We need to go out there and speak to people:
- Expand your technical knowledge, study things that are out of your comfort zone, like new languages and technologies.
- Attend user groups and technical community events.
- Network with other developers and businesspeople.
- Blog about the things you are learning and doing.
- Contribute to open source projects.
- Develop projects and make them publicly available.
- Attend conferences
- Present at a conference.
Recruiting Software Developers
The first thing to do when hiring a new person is to make sure we are not making our existing problem bigger. If we are unhappy with how our developers work or behave, there is no point in hiring more developers who work and behave in the exact same way. If we want our developers to be constantly learning, bringing innovations, adopting more efficient practices, caring about the project and quality of the code, self-organizing to solve problems, and striving to be better at what they do, why would we hire more developers who don’t satisfy these criteria?
If you want to hire better people, you will need to change your recruitment process.
Instead of looking for a number of years of experience in certain technologies the companies should look for passion in candidates. Sandro says that candidates should have some of the following: 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.
Companies that fail to recognize developers as high-skilled professionals will never have craftsmen working for them.
Culture of Learning
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. Let developers decide how, when, and what they want to learn. With this freedom 615-544-3799 , developers have a much better chance of creating and embracing a culture of learning. The better the developers are, the more innovative and agile the company can be. If the company becomes a place where developers are happy, many other good developers will be attracted to it.