More on this book
Kindle Notes & Highlights
Started reading
June 16, 2016
“How it is done is as important as getting it done,”
That’s how seniority was measured back then. If you couldn’t understand a piece of code, normally it was because you were not senior enough. And writing code that no one else could understand would make you a senior developer straightaway.
There is a huge difference between having ten years of experience and having one year of experience repeated ten times.
Agile does not solve any problems; it exposes them.
Individuals and interactions over process and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
Many Agile projects are now, steadily and iteratively, producing crap code.
The number of colorful Post-Its on a whiteboard became their true measure of Agility.
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. With all these important roles in place, they were ready to hire a few cheap developers—normally delegating the task of hiring to an agency or to HR.
Every software process, including Agile processes, will assume technical excellence. Without technical excellence, every software project will be a painful, frustrating, and expensive experience.
A quick feedback loop is key for any company aspiring to be agile. Reacting to the feedback they get quickly is what makes them truly agile.
It is never too late to make things better—it just becomes far more painful when you delay it.
right.
Agile allows compnies to do right things, SC allows developers to do things right
Software Craftsmanship is about professionalism in software development.
Although Jack W. Reeves suggested that software development is more a craft than an engineering practice in 1992, I believe that Software Craftsmanship really begins with the book The Pragmatic Programmer: From Journeyman to Master by Andy Hunt
Clean Code: A Handbook of Agile Software Craftsmanship and later in May 2011, The Clean Coder: A Code of Conduct for Professional Programmers,
Guidance for the Aspiring Software Craftsman, by Dave Hoover and Adewale Oshineye,
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.
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.
Sharing and mentoring are at the heart of Software Craftsmanship.
Software craftsmen are not factory workers.
Software craftsmen understand that being a good professional means having a good reputation, and for that they need to constantly delight their clients by delivering successful projects.
Developers who rely only on their companies to provide them knowledge are not professional software developers. They are just factory workers in disguise.
We may discover that many of the things we talk about today go back a few decades.
How it is done is as important as getting it done.
1. Decide on the task to be done. 2. Set the Pomodoro (timer) to 25 minutes. 3. Work on the task until the timer rings. 4. Take a short break (normally 5 minutes). 5. Every four “Pomodoros,” take a longer break (15–30 minutes).
We all have time. In fact, we all have exactly the same amount of time. The difference is how we choose to spend our time.
We made loads of mistakes during those long hours, including wiping out the entire production database at 3 a.m. We created things that were totally unnecessary. We had a very poor understanding of the real issues and did not create situations where we could provide better solutions. We allowed ourselves to be deprived of a personal life and even ended up discriminating against those who decided not to sleep in the car park or just work 12 hours a day. We were not acting professionally because we never said NO.
The second version of the application was scheduled to be released in three months’ time but, from what I’ve heard, it took almost nine months to be released.
Well, we can say whatever we want, but saying anything after that epic failure was of no use.
Professionalism means being honest with ourselves, with our teammates, and with our managers and customers.
As long as we do it in an honest and transparent way, there is a big chance that no one will get hurt and the whole team and the company will win.
Always saying no is also not a professional attitude. Every no, ideally, should be followed by a list of alternatives.
even when we say no, we should always be striving to say yes.
If we manage to deliver what we promised when we said yes, managers will be far more inclined to trust us when we say no.
Being professional and satisfying our clients does not mean doing everything they ask us to do. Our job is to help our clients to figure out what their real needs are and also advise them on the best way to approach them.
This is the same thing we would expect from a good lawyer, accountant, or doctor. We don’t tell these professionals what to do or how to do their jobs.
Rather than construction, programming is more like gardening. —The Pragmatic Programmer Code is organic, not mechanical. Like a garden, code needs constant maintenance.
The biggest problem here is that bad code is invisible to everyone besides the developers.
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?
Bad code is like a cancer, difficult to identify in the beginning, and hard to treat when it is finally discovered. And depending on when it was discovered, life can be prolonged but death is unavoidable.
With the adoption of XP practices, management noticed a one-third reduction in production bugs. With a decline in production bugs, a growing suite of unit tests, and debugging time reduced to zero, productivity reached a factor of ten times.
Since the Agile summit in 2001, XP has been considered an Agile methodology. However, very rarely do companies adopt XP practices during their Agile transformation.
Focus the discussion on the benefit they bring and how they compare to the practices they currently have. A smaller feedback loop; a better understanding of requirements and cost; knowledge sharing; reduction of bugs; and quick and totally automated releases to production are examples of values added by technical practices.
Source: From www.xprogramming.com/what-is-extreme-programming/; used with permission.
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.
knowledge workers are motivated by three things: autonomy, mastery, and purpose.
Software craftsmen always choose jobs where they have 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.
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.”
“For you it’s more than a job.”
