Too many times, software engineers, myself included, write code before even thinking enough about it. This usually results in time wasted both in rewrites, refactors, or worse, removal.
I've been thinking a bit about when we should give feedback and the consensus is early, frequent and actionable. Yet, we also need to balance it with the cost of giving feedback because it takes effort and time.
Everyone should first ask this question, "Do I need to write code?" Sounds like a stupid question but when your job is writing code, it's easy to jump straight to it. If we don't ask ourselves that question, we likely have not fully understood the problem we are trying to solve. Writing code has to be the best way to solve the problem. Once the problem is understood, and the tradeoffs of writing and maintaining the code we write are worth it, then it's time to get some feedback.
Now, down to the nitty-gritty of it. There are many ways to get feedback on software engineering tasks. A non-exhaustive list includes meetings, code reviews, code pairing and RFCs. How should we decide when to use which form of feedback?
Going back to balancing cost vs benefit, it depends on how much we already know about the problem we need to solve, and what kind of feedback we are looking to get. Questions that we ask should help us determine how clear we are on the scope and how concrete this scope is. Some examples of questions that we should ask are as follows.
- What is the overall direction and strategy?
- Who are our stakeholders?
- How do we measure success or failure?
- Are we the best team or person for the task?
- Have we as a team done something similar before?
- How familiar is the task to the one executing?
Explore
If this problem hasn't been solved before and it's entirely new, meetings or RFCs are likely worth doing. Code shouldn't be written before the team is clear on the direction it's heading. Timelines need to be flexible and milestones, shorter because all of them could change once execution starts as we learn new information. You might not have all the details sorted out; what you're looking for is early feedback and agreement between stakeholders in the direction you are heading. If stakeholders are not technical, you'll need to simplify your explanations or split up the meetings and RFCs for different audiences.
Imagine having to change scope or direction once code is already written. From experience, it's costly and you would want to avoid it at all costs.
The length of this phase depends on the entire scope of the project. There might be various stakeholders from the C-suite down to the engineers in your team. Depending on your role and the size of the project, you might want to also split up meetings for discussions and meetings for decisions. This helps increase the quality of discussions and you can have more information on the table before proposing or making a decision.
Execute
Once everyone is clear on the direction of the project, it's down to the next most important bit – execution. I won't go into details about what good software engineering practices are because that would take up a lot more than one post but I'll assume that your team is aligned on those. If they aren't, no one can help you here.
If you or your team has not done this task before, it'd be worthwhile to start with code pairing. Feedback would be real-time and any decision would have to be taken by at least two people, which in software engineering, is usually already a good proportion of your team. If at least one person in the team has done a similar task before, it'll be worth having this person pair with someone that hasn't. A good team shares information to make better decisions and pairing helps in transferring this informal knowledge that might be difficult to write down. Every line of code written influences other lines of code so inconsistency is obvious and confusing.
The cost of code pairing is undeniably time, and probably more exhausting as it requires constant communication between two people. That said, most of the time, it's worth it as code quality is higher and the team communicates more effectively. When the pull request is finally created, it's just a formality.
If a task is very familiar to the team and the one writing the code is very familiar with it, it could be worth just jumping straight to creating the pull request. Feedback in the pull request is likely slower and less frequent but that's okay if there are only one or two minor comments.
Warning signs of creating the pull request too early is a long list of comments or one major comment that would cause a huge rewrite. If we observe that, to save everyone's time, it's better to take a step back and go back to the earlier stages of feedback.
TLDR
How much we explore depends on how many unknown unknowns we think there are. And once we are clearer on what we don't know and we are confident enough, we start writing code, learning more as we start executing. If we discover more unknowns along the way, we may need to take one step back and explore again. It's seldom a one-way street but more like a cycle of exploring and executing because there will always be something that we didn't realize we don't know.
As a software engineer, feedback comes in various forms. And we need to know the tradeoffs between each form before deciding which is best. Sometimes, ego comes in the way and we'll need to learn how to navigate others and our own ego to gather feedback and respond to it well. No one is perfect at it but like anything else, it gets easier with practice.