Technique: Build Trust ✥

Why are the first techniques in this book (Changing Code Within One Function) about changing code in tiny, barely-significant ways?

Why not begin with the most impactful change techniques—e.g. those for team organization?

Most people (rightly) do not trust programmers. If a programmer says something will take two days, it will actually take two weeks. Once the programmer says it's "done", it will still have multiple bugs.

If you want to improve the system you're in, you need autonomy. To get autonomy, you must earn people's trust. The simplest way to earn trust as a programmer is to do good work. (Doing good work and hitting your estimates is harder; in general you should try to reframe conversations about estimates so you are not held to a date that turns out to be unrealistic.)

Trying to make radical changes to an organization without a solid technical foundation is unrealistic.