I find that implementing a sound solution from scratch is generally lower effort than taking something that already exists and making it sound.

The former: 1) understand the problem, 2) solve the problem.

The latter: 1) understand the problem, 2) solve the problem, 3) understand how somebody or something else understood & solved the problem, 4) diff those two, 5) plan a transition from that solution to this solution, 6) implement that transition (ideally without unplanned downtime and/or catastrophic loss of data).

This is also why I’m not a fan of code reviews. Code review is basically steps 1–4 from the second approach, plus having to verbally explain the diff, every time.

▲

locknitpicker 2 hours ago | parent [-]

> This is also why I’m not a fan of code reviews.

That's specious reasoning. Code reviews are a safeguard against cowboy coding, and a tool to enforce shared code ownership. You might believe you know better than most of your team members, but odds are a fresh pair of eyes can easily catch issues you snuck in your code that you couldn't catch due to things like PR tunnel vision.

And if your PR is sound, you certainly don't have a problem explaining what you did and why you did it.

	▲	strogonoff an hour ago \| parent [-]
		Code reviews have their place. I just personally don’t like being the reviewer, because it’s more effort on your part than just writing the damn thing from scratch while someone else gets the credit for the result[0]. Of course, having multiple pairs of eyes on the code and multiple people who understand it is crucial. [0] Reviews are OK if I enjoy working with the person whose work I’m reviewing and I feel like I’m helping them grow.