It is as you say problem dependent. In a high level language, you could start off with a generic std lib sort. Or you could start off with the intended sort alg

It is as you say problem dependent. In a high level language, you could start off with a generic std lib sort. Or you could start off with the intended sort algo and improve on it. The point is to make it more or less straight-forward and readable first. Then you find optimizations, inlining, etc., keeping intentions in comments and the like. For multithreaded there are design and tactics that can be documented separately, as comments would probably be too spread out anyways to be too useful. This is hard when working iteratively, as you have to work out a working solution before you know it. The problem is after tough work to end up with something working, but unreadable and less maintainable. The ideal would be to have the time to rewrite and retest, and not etch that magic brilliant code in stone. Ie. the linux kernel is a good example of code being iteratively refactored and rewritten many times. Though as you say, it'd require quite some time diving deep into such code anyway. Doing what works well should make it accessible to more than one dev. So the point is just so that others can access and modify the code a bit easier, even for tough sections. This goes very much against the grain, because of exhaustion and not wanting to take on further risks and rework.