4 ms·

While I generally disagree with what he's saying, I do think that most of his points are understandable, even if not persuasive to me. Except this one: >> I w

by luord 6y ago

While I generally disagree with what he's saying, I do think that most of his points are understandable, even if not persuasive to me. Except this one: >> I will get you to think about a directed graph or as operations on a directed graph > No human thinks about that! Well, that's not wrong, people don't usually think like that, but people also don't usually think about possible specimens living in some forest during a hike, or the odds and the reasons why a given storm could become a hurricane when they read about it in the news, or all the most likely reasons why a given body part might be hurting. No, those are thought by zoologists, meteorologists and physicians, respectively. With that in mind, I see thinking about graphs and other areas more complex of version control as being, similarly, part of the job and the cognitive load of software engineers. In short: People don't usually think like that, but, in my opinion, thinking like that is part of a software engineer's job, so I don't see an inherent problem with that.

Toutouxc 6y ago
You could also say that software engineers should be able to focus on building the product, instead of splitting their cognitive capacity between the actual work and fiddling with the versioning system. Getting dirty with git when you really wanted to build the product sounds a lot more like the zoologist binding and gluing together his notebook in the middle of the forest.
- luord 6y ago
  I see your point, but in my opinion, part of a job is knowing how to use the tools for the job. New, easier to use or more efficient tools could be created? Absolutely, but knowing how the tools work is never a disadvantage, IMO. And at least we software engineers have an advantage there in that most, if not all, of our tools are themselves software. For instance, an analogy with zoologists I would make is knowing how to set up their observation equipment in whatever remote area they're doing their research. They have to do it and they have to know how to do it, and maybe they even have to do troubleshooting in case something is not working quite like it should. None of that has to do with zoology per se, but it is part of a zoologist's job. They can get better and/or more reliable tools over time? Absolutely, which is what I think most of TFA is understandable. I happen to think that git is already a pretty good tool, but I absolutely do see why many people disagree.

by luord 6y ago

Toutouxc 6y ago

You could also say that software engineers should be able to focus on building the product, instead of splitting their cognitive capacity between the actual work and fiddling with the versioning system. Getting dirty with git when you really wanted to build the product sounds a lot more like the zoologist binding and gluing together his notebook in the middle of the forest.

luord 6y ago
I see your point, but in my opinion, part of a job is knowing how to use the tools for the job. New, easier to use or more efficient tools could be created? Absolutely, but knowing how the tools work is never a disadvantage, IMO. And at least we software engineers have an advantage there in that most, if not all, of our tools are themselves software. For instance, an analogy with zoologists I would make is knowing how to set up their observation equipment in whatever remote area they're doing their research. They have to do it and they have to know how to do it, and maybe they even have to do troubleshooting in case something is not working quite like it should. None of that has to do with zoology per se, but it is part of a zoologist's job. They can get better and/or more reliable tools over time? Absolutely, which is what I think most of TFA is understandable. I happen to think that git is already a pretty good tool, but I absolutely do see why many people disagree.