3 ms·

It would be perfectly reasonable for someone to just say "no, I'm not going to imagine my job designing software as analogous to cabinetry," because argument fr

It would be perfectly reasonable for someone to just say "no, I'm not going to imagine my job designing software as analogous to cabinetry," because argument from analogy shifts some of the burden of proof to the analogy itself, and the analogy must be defensible. In this case, you're drawing an equivalence between OP's 100 complex things and 100 cabinet components that must be assembled, yet also drawing an equivalence between the 101st thing and a central tool of the cabinet maker's trade. This is an internal inconsistency. You must either acknowledge the 100 things as 100 tools of cabinetry, each more important than the 101st, or you must regard the 101st thing as yet another fixture to be added to the cabinet. A domain expert is telling you that version control is a peripheral concern in their trade, the 101st tool, and you're responding with an idealism of mastery that stems from notions of integrity and identity and establishes no reasonable boundaries. You're welcome to this ethic and idealism, it's not a bad thing to have, but you're second guessing someone else's mastery based on arbitrary reference to your own mastery. I might as well be chiding you for looking up man pages without understanding the command-line capabilities of `troff`.

PaulDavisThe1st 5y ago
> A domain expert is telling you that version control is a peripheral concern in their trade 1) I have no way of knowing if they're a domain expert. 2) With 35 years of software development under my belt, and a half dozen version control systems too, I'd consider myself likely to be as much of a domain expert as the OP, and I'm saying the opposite. 3) I am not as master woodworker. I have built cabinets and many other things. Philosophically I consider the disjunction between our culture's attitude towards physical tools (where there's an assumption that one will have to take time to learn how to use the tool before actually being able to make anything good with them) and digital tools (where there's an assumption that apprenticeship should be kept to a minimum, preferably zero) extremely interesting. 4) When I'm working on a task (I also build very specialized, highly complex software) the distinction between the cognitive load caused by the task and the cognitive task caused by the tools I have available to work with is not very big. It doesn't make much different whether the "101st" thing concerns a tool or a component, it's just another part of the big picture that I have to struggle to keep in my head as I move forward.
- escape_goat 5y ago
  This is an excellent reply, more interesting than my comment, and I certainly cannot gainsay you. However, '100' might as well be 'n'. Your reply suggests that there is a struggle to maintain contextual awareness of 'n'. In this model, for everyone, there will be an n+1, a necessary factor where the diminishing returns of mastery do not justify the cognitive load. I do not think the heart of your dispute truly lies so much his model of peripheral necessities as with his ranking of git as an n+1 tool.

PaulDavisThe1st 5y ago

> A domain expert is telling you that version control is a peripheral concern in their trade 1) I have no way of knowing if they're a domain expert. 2) With 35 years of software development under my belt, and a half dozen version control systems too, I'd consider myself likely to be as much of a domain expert as the OP, and I'm saying the opposite. 3) I am not as master woodworker. I have built cabinets and many other things. Philosophically I consider the disjunction between our culture's attitude towards physical tools (where there's an assumption that one will have to take time to learn how to use the tool before actually being able to make anything good with them) and digital tools (where there's an assumption that apprenticeship should be kept to a minimum, preferably zero) extremely interesting. 4) When I'm working on a task (I also build very specialized, highly complex software) the distinction between the cognitive load caused by the task and the cognitive task caused by the tools I have available to work with is not very big. It doesn't make much different whether the "101st" thing concerns a tool or a component, it's just another part of the big picture that I have to struggle to keep in my head as I move forward.

escape_goat 5y ago
This is an excellent reply, more interesting than my comment, and I certainly cannot gainsay you. However, '100' might as well be 'n'. Your reply suggests that there is a struggle to maintain contextual awareness of 'n'. In this model, for everyone, there will be an n+1, a necessary factor where the diminishing returns of mastery do not justify the cognitive load. I do not think the heart of your dispute truly lies so much his model of peripheral necessities as with his ranking of git as an n+1 tool.