Permission, Approval, and Feedback

There are endless debates online about the relative merits of code reviews/pull requests vs Ensemble/Mob/Pair programming. I’m not going to talk about any of that. You can read about it at one of more of those links.

I’m going to talk about the world that many (most?) developers live in. Requirements are identified. Designs are done. Work is discovered. The work is turned into tasks. Tasks are prioritized. Tasks are selected by / assigned to an individual. The individual does the work in semi-isolation. There is a code review/pull request process to follow before the code is merged into the main branch and then deployed. There are lots of variants on that, such as requiring design docs, automated tests, code coverage checks, required reviewers, sprint planning, time boxing, and such, but that’s the basic flow.

At each of those stages, there is some kind of gate to get out of the current state and into the next one. That’s where the differences between permission, approval, and feedback become very important. At many places you are required to have someone sign off on the work done. There are tools and processes in place that ensure you meet the requirement. That’s permission. To follow the official process, you need someone else to put a stamp on your work and say it’s OK. Sometimes there is even a defined person or set of people who are allowed to say it’s ok. They also have the power to say no and then you can’t move forward.

The next level is approval. Approval is someone saying, “I can’t really stop you, but I think that’s OK.” Approval is nice, but it’s not required, and it doesn’t really mean anything.

Then there’s feedback. Feedback is really interesting. It can range from silence to “LGTM” (Looks good to me), to “This is a great approach and simplifies a complicated problem.”, to “This is the exact wrong approach, and will make things harder in the future.”, to a more generic “Here’s another approach that might make things easier.”, or “Have you thought about how this change will impact X? I think there’s some interaction there.” The thing about feedback is that while it’s a gift, you don’t have to take it. If you’ve got the required permission, then you can ignore the feedback and move on.

That’s the rub. The most useful information is often in the feedback. The part you’re most likely to ignore. Especially when the feedback comes from an unexpected place. If someone you didn’t expect to care, like a customer, user, or some team that thinks about non-functional requirements (like security, UX, QA, PM, Finance, etc.) takes the time to give you feedback, that’s probably the most useful information you’re going to get.

Those apparently unrelated folks have a very different viewpoint than you do. They approach the problem from a different place and are focused on their area. If someone from Finance says that they’re concerned about how this change is going to impact the bottom line, or the security team is concerned that there’s an uncovered vulnerability in the design, then there’s a problem. There’s at least a problem with the work you’ve done in that it doesn’t explicitly state that you’ve thought that issue through and have a plan/mitigation in place. More likely, they’re pointing out a blind spot in your thinking and it’s something you need to go think through and make sure it’s addressed.

In a perfect world, the folks that are giving you permission are paying attention to the feedback, and it’s good to have another set of eyes to make sure the feedback is addressed, but it’s not their job. It’s your job, as the person doing the work, to take the feedback, internalize it, and respond to it.