> But just tell me this -- didn't you ever had a coding problem that legitimately took weeks to even figure out, let alone solve afterwards? Trust is paramount. We should absolutely try very hard to avoid micro-management, wouldn't you agree?

Yes, I've had lots of large problems that took weeks & months to solve, I'd say hundreds in my career so far. And at times I've desperately wanted people to not bother me while I solve them and stop asking for status reports and just trust me.

I've argued with PMs so fiercely over this, they've put warnings in my personnel file that followed me for years. I've had jobs where the daily status report for a 1 month project took two hours of work per day, and I tried to explain that the overhead meant it would take a full extra week to complete the job. It didn't matter, and I was wrong, and because I'm stubborn, it took me a long time to realize why I was wrong. I was optimizing for my own experience, and my own efficiency, and not for the team's. That's the problem with the manifesto.

Never once have I had a multi-week problem where I delivered the work without either the direction changing or else delivering a solution that was incorrect and had to be partially or completely redone. Never once have I seen another programmer start down the path of a weeks or months long project who didn't require a course correction within days. Usually the problem is incomplete or misunderstood requirements, frequently it is unforseen complexity & unanticipated consequences, sometimes requirements actually change.

My experience has been that when a smart, well-intentioned, and trustworthy programmer (including myself) works on a problem without review for more than a week, it has always resulted in delivery of something that didn't solve the problem, because the problem itself was not understood.

I now believe it's absolutely critical to continue talking about what the goals are regularly, and what the solution needs to do. Clear communication is harder than it seems, and you can agree completely with someone on very specific implementation details for hours and hours one day, only to find out there was a huge and glaring difference of vision the next day.

The efficiency gained by avoiding a 1 hour weekly meeting is lost in very large multiples when the solution is incorrect, and the probability the solution is incorrect is at least proportional to the amount of time it takes to solve.

This is why it's a mistake to equate a manager's desire for regular meetings with a lack of trust, and why regular checkins are not micro-management. Micro-managing is when someone tells you how to do your job and hovers constantly and repeatedly requests bad implementations. I've never had a real micro-manager and I suspect they're extremely rare. A weekly or even daily short status report isn't micro-managing. But being asked what you're doing frequently is often mistaken for micro-management, and a lot of programmers think they're being micro-managed when they aren't.

> My really badly communicated intent here was to implore you to never forget that there are those of us who work better when given bigger breathing room. Nothing else.

I understand completely, and I think this is what the manifesto is saying too. And it's what I want when I'm writing code too. But getting that breathing room and catering to our individual comfort and efficiency doesn't actually help the team as much as you hope, and it can and frequently does do real damage.