Developer: "Hey, could you review my PR? I had this fantastic idea about X the other day, so I decided to give it a go. I think it turned out to be pretty good. What do you think?"
Reviewer: "Ehm, but that's not what we had planned. Did you design this by yourself? Did you stop and think about performance at all? Where are the tests? In any case, who would ever need to use this? And what's that new module intended to do, hmm? Oh, that's an obvious security hole…."
Developer: "... [weeps in silence, then sighs] Okay, fair points, I guess I'll go and fix these."
Developer (thinking): "I worked on this all week already. Screw this project and this team."
We are often tempted by grand visions of features we see as must-haves in product development. Thus, we strive to drive our impeccable vision to fulfilment. However, this is always a crucial point to stop and rethink the following:
- What value will my idea add to the product?
- Did a user ask for it?
- Do we need it now?
- Could we reserve the time spent for unplanned work for the actual planned work?
Especially in software engineering, adding new features (more code) without holistic thinking introduces a significant risk of adding new defects. The problem is that it's too late to stop ourselves and think once we get that sweet, creative juice flowing.
What we suffer from here is the consequence of long feedback loops.
As a team, we must always be the unshakable judges of each other, challenging our impromptu visions. This is a remarkable trait of pairing and mobbing: there is always one or more extra eye pair immediately scrutinising the way forward. The same cannot be said of solo work, where you may end up working with a tunnel vision for days only to get your idea shot down afterwards. It hurts like hell, I know because I've been both the developer and the reviewer in the above scenario.
Efficient collaboration practices and shorter feedback loops nurture team psychological safety and empathy by allowing ideas to be gently rejected or rehashed for more sustainable solutions. In addition, the earlier you get feedback from as many sources as possible, the less chance for your self-esteem to be damaged. This is a crucial reason why I like to ask the following interview questions:
"How do you ensure your team receives feedback as fast as possible?"
It's a powerful question with many sides, but one without a correct answer.
Generally, feedback from one person to another is worth every penny. But, respectively, input from the code to a developer is essential too. The key is to understand that feedback must occur in small batches as a continuous process. You should not ask for feedback only right before a 1-on-1 performance review, and your code should not wait for a sprint to end before being deployed to production for real live feedback.
Small batches. Both in design and implementation. Everywhere. All of the time.