What would you do, if you get a better solution purpose after PR?

In the first place, I'd recommend reviewing why that happened in the first place:

• Is this improvement just an implementation detail?
• Or does it involve a bigger change in terms of design/architecture?

It sounds to me like this suggestion is bigger than just an implementation detail. This could be a symptom of insufficient detail at the design documentation phase. It reminds me of this video where Rahul explains the scope that a healthy code review should have. I pretty much agree with him when he says that architecture discussions should not take place in a code review, they should take place in the design phase instead, where these kind of higher level issues should be addressed. I'd reflect on that to see if there's a way the design phase could be improved to make sure these kind of situations don't happen again.

On the other hand, now that this has happened, I'd try to find a compromise. I'd try to come up with a plan to migrate from the original solution to the solution your coworker proposed. I'd then discuss with my coworker the plan and I'd merge the original solution for the current sprint (since the coworker thought the code was good enough), but ensuring that in the next sprint the better solution from my coworker would be implemented. This is assuming that you have some sort of hard deadline where the code has to be merged for the current sprint.

Hope that helped!

I think it's important to define a "good enough" stopping point for anything that technically doesn't have a ceiling to it.

I'd treat implementing the "improvement" to your existing solution as an additional "feature" to put into the overall feature roadmap. This will help contextualize how important it is in the bigger picture (module, project, program, etc.). Unless there are subsequent design decisions that hinge on the implementation of your portion of the code, it's not a huge deal here since it can be placed into a backlog and picked up later when this is the best use of time vs. other tasks.

Especially, what if I have a bigger feature, spent one week for it and need another 3 days, if I will change my code. What would you do?

3 days is a long time in any engineering team that wants to move remotely fast. As Diego mentioned, I would try to debug whenever this happens to figure out why such a large design flaw wasn't caught earlier.

When it comes to the broader question here, the main question to answer here is: "How much better is the alternative?". Here's what my mentality is overall here:

• Code, like pretty much everything else in tech, should follow the 80/20 rule most of the time. Try to write a solution that has 80% of the quality with 20% of the effort. This is especially true outside of Big Tech. You can always spend an infinite amount of time rabbit-holing on writing the "perfect" code - That's unproductive as there is no such thing as perfect code.
• Rate your solution on a scale of 1 to 10. If the outside solution isn't at least +3 better (e.g. your solution is 7/10 and the other is 8/10), then I would be hesitant to derail your work to incorporate it.
  • If the solution is a marginal improvement, then you can designate it as some sort of fast-follow action item as Casey mentioned to make the other person feel heard.
• If the other solution is indeed way better (especially if it's in a mission-critical way like patching a massive security exploit), then retrospect deeply and maximize your learning around why you weren't able to come up with this solution yourself. We talk about this in detail here: "How can I think like a staff engineer?"

When it comes to proper technical planning and code quality overall, I recommend this playlist: [Taro Top 10] Becoming A Better Coder