I like this post a lot, but the example debates that seem like intractable aesthetic disagreements seem to be missing a 2 key ideas that are preventing resolution:
1. Shared verbal acknowledgement that regardless of the aesthetic considerations, the status quo is not working. If you’re debating the merits of “everyone pitch in” vs “specialise and outsource” and you’ve failed to recognise that people are generally not clearing up after themselves or funnelling money towards the problem, your first order of business shouldn’t be to get into a long-winded philosophical debate over aesthetics.
2. Overlooking resource constraints and avoiding fuzzy quantification. In the case of clean code vs quick hacks, unless you are writing the code just for fun, what each person prefers is much less relevant than the business-world constraints you are under. If you are under extreme time pressure and the thing must be done, the choice is quick hacks or death. If you are trying to “scale up” but there are no impending deadlines, whether a piece of code should be written cleanly depends on how reliant you expect to be on that code in future, how clearly you understand the problem it is solving, how much longer it will take to do things properly and the opportunity cost of that time. While you won’t have precise answers to these things, they will be a lot more tractable than reconciling aesthetic disagreements.
I like this post a lot, but the example debates that seem like intractable aesthetic disagreements seem to be missing a 2 key ideas that are preventing resolution:
1. Shared verbal acknowledgement that regardless of the aesthetic considerations, the status quo is not working. If you’re debating the merits of “everyone pitch in” vs “specialise and outsource” and you’ve failed to recognise that people are generally not clearing up after themselves or funnelling money towards the problem, your first order of business shouldn’t be to get into a long-winded philosophical debate over aesthetics.
2. Overlooking resource constraints and avoiding fuzzy quantification. In the case of clean code vs quick hacks, unless you are writing the code just for fun, what each person prefers is much less relevant than the business-world constraints you are under. If you are under extreme time pressure and the thing must be done, the choice is quick hacks or death. If you are trying to “scale up” but there are no impending deadlines, whether a piece of code should be written cleanly depends on how reliant you expect to be on that code in future, how clearly you understand the problem it is solving, how much longer it will take to do things properly and the opportunity cost of that time. While you won’t have precise answers to these things, they will be a lot more tractable than reconciling aesthetic disagreements.