More on this book
Community
Kindle Notes & Highlights
Started reading
March 9, 2018
Professional developers make it their responsibility to work with stakeholders and testers to ensure that all parties know what is about to be built.
Acceptance tests should always be automated.
it is the developer’s job to connect the acceptance tests to the system, and then to make those tests pass.
Single Responsibility Principle (SRP). This principle states that you should separate those things that change for different reasons, and group together those things that change for the same reasons. GUIs are no exception.
What every professional development team needs is a good testing strategy.
QA Should Find Nothing I’ve said this before, and I’ll say it again. Despite the fact that your company may have a separate QA group to test the software, it should be the goal of the development group that QA find nothing wrong.
There are two truths about meeting. Meetings are necessary. Meetings are huge time wasters.
Professionals are aware of the high cost of meetings. They are also aware that their own time is precious; they have code to write and schedules to meet. Therefore, they actively resist attending meetings that don’t have an immediate and significant benefit.
The important thing to realize is that remaining in a meeting that has become a waste of time for you, and to which you can no longer significantly contribute, is unprofessional.
To use the participants’ time wisely, the meeting should have a clear agenda, with times for each topic and a stated goal.
Iteration Planning Meetings These are the most difficult
Priority inversions are a lie we tell ourselves. We can’t face what needs to be done, so we convince ourselves that another task is more important. We know it’s not, but we lie to ourselves.
Moving forward through a swamp, when you know it’s a swamp, is the worst kind of priority inversion. By moving forward you are lying to yourself, lying to your team, lying to your company, and lying to your customers. You are telling them that all will be well, when in fact you are heading to a shared doom.
It is the primary wedge that has been driven between business people and developers.
The problem is that we view estimates in different ways. Business likes to view estimates as commitments. Developers like to view estimates as guesses. The difference is profound.
Estimates are fraught with error.
The professional developer is calm and decisive under pressure. As the pressure grows he adheres to his training and disciplines, knowing that they are the best way to meet the deadlines and commitments that are pressing on him.
Professionals realize that “quick and dirty” is an oxymoron. Dirty always means slow!
The trick to handling pressure is to avoid it when you can, and weather it when you can’t.
The most efficient and effective way to review code is to collaborate in writing it.
Programming is all about working with people. We need to work with our business, and we need to work with each other.
What you learn in school and what you find on the job are often very different things.
My favorites are JUNIT for Java, RSPEC for Ruby, NUNIT for .Net, Midje for Clojure, and CPPUTEST for C and C++. Whatever unit testing tool you choose, there are a
