More on this book
Community
Kindle Notes & Highlights
That was a very sad day for me.
“Yes, but these are professionals.”
the technical staff were professionals, in the best sense of the word.
the technical team actually self-organizes and makes real commitments.
he doesn’t get the feeling that the project is in priority somewhere between lunch and checking email.
They usurped the authority of the people who actually knew: the engineers.
wishing they’d called Dan Rather.
No one in your life will teach you more than your children will. Thanks, kids!
he served as the first chairman of the Agile Alliance.
Professionalism is something that our profession is in dire need of.
College was not an option for me, nor did it hold any particular enticements.
She told me that you never quit without having a new job, and you always quit calmly, coolly, and alone.
It’s a lot easier to be a nonprofessional.
But when a professional makes a mistake, he cleans up the mess.
Because, you see, professionalism is all about taking responsibility.
The reason I neglected the test was so I could say I had shipped on time. It was about me saving face. I had not been concerned about the customer, nor about my employer. I had only been concerned about my own reputation.
That would have been hard, and Tom would have been upset. But no customers would have lost data, and no service managers would have called.
Therefore, in order to be professional, we must not create bugs.
“Are you telling us we must be perfect?” Do I hear you object? No, I’m telling you that you must be responsible for your imperfections.
This sounds just like the ubiquitous objection by Christians to obeying the Torah.
Apologies are necessary, but insufficient.
It is unprofessional in the extreme to purposely send code that you know to be faulty to QA. And what code do you know to be faulty?
Any code you aren’t certain about!
Releasing code to QA that you don’t know works is unprofessional.
Am I suggesting 100% test coverage? No, I’m not suggesting it. I’m demanding it. Every single line of code that you write should be tested. Period.
But isn’t some code hard to test? Yes, but only because that code has been designed to be hard to test. The solution to that is to design your code to be easy to test.
If you compromise the structure, you compromise the future.
If you want your software to be flexible, you have to flex it!
Every time you look at a module you make small,
lightweight changes to it to improve its structure. Every time you read through the code you adjust the structure.
Always check in a module cleaner than when you checked it out.
They think that making a continuous series of changes to working software is dangerous. No! What is dangerous is allowing the software to remain static.
Why do most developers fear to make continuous changes to their code? They are afraid they’ll break it! Why are they afraid they’ll break it? Because they don’t have tests.
If you have an automated suite of tests that covers virtually 100% of the code, and if that suite of tests can be executed quickly on a whim, then you simply will not be afraid to change the code.
In short, they treat software the way a sculptor treats clay—they continuously shape and mold it.
Woe to the software developer who entrusts his career to his employer.
You should plan on working 60 hours per week. The first 40 are for your employer. The remaining 20 are for you.
Professionals spend time caring for their profession.
You should not be working for your employer during those 20 hours.
Those 20 hours should be fun!
A wealth of ideas, disciplines, techniques, tools, and terminologies decorate the last fifty years of our field.
Very few ideas of the past 50 years have become irrelevant.
Woe to the architects who stop coding—they will rapidly find themselves irrelevant.
It is not enough to simply do your daily job and call that practice.
Practice is when you specifically exercise your skills outside of the performance of your job for the sole purpose of refining and enhancing those skills.
A kata usually comes in the form of a simple programming problem to solve, such as writing the function that calculates the prime factors of an integer. The point of doing the kata is not to figure out how to solve the problem; you know how to do that already. The point of the kata is to train your fingers and your brain.
Think of the kata as a 10-minute warm-up exercise in the morning and a 10-minute cool-down in the evening.
It is the responsibility of every software professional to understand the domain of the solutions they are programming.
It is the worst kind of unprofessional behavior to simply code from a spec without understanding why that spec makes sense to the business.
And so, programming is an act of supreme arrogance.
So we went live on the date. And it was a blazing disaster.
