3 ms·

So I guess that most programming languages would qualify as bad tools to you then? Seeing as how they force you to spend a lot of time "understanding" them bef

So I guess that most programming languages would qualify as bad tools to you then? Seeing as how they force you to spend a lot of time "understanding" them before you can be productive.

timr 18y ago
My job isn't to learn version-control systems. Time spent learning a programming language is a direct investment in productivity; time spent learning a version control system is, at best, a required distraction.
- KirinDave 18y ago
  Your job is most certainly to maintain a working and current toolchain. This includes programming languages and the tools that produce software in tandem with you. This isn't just for your employer, it's for the sake of your own career. Or do you want to be like those poor men who came before us, knowing and learning only COBOL, who now complain that software engineering is a young person's game? If I interview a software engineer and they don't know how to use a version control system and actively express disdain for the concept of making sure that the progress of development is captured, then I would not recommend we hire them. Anyone who's had git-bisect save them a huge effort locating a bug would probably feel the same way. Version control is every bit as important as your editor, debugger linker, and binary examination tools. If you don't know how to use them, you're not ready to start playing the game on a professional level. You might say that I'm using Ad Hominem here, but I don't feel it's that way. There are minimum standards for software engineers who want to develop software professionally, and using version control and understanding why we use version control is pretty high up on the list. If a basketball player isn't ready for the NBA, it isn't Ad Hominem to tell him his game needs more work, even though he may feel very insulted by the concept.
  - timr 18y ago
    "Your job is most certainly to maintain a working and current toolchain." Subversion works. It's well-documented, simple, and there are many tools that work with it. Tell me why it's an inappropriate choice for a "working and current toolchain". "There are minimum standards for software engineers who want to develop software professionally, and using version control and understanding why we use version control is pretty high up on the list. If a basketball player isn't ready for the NBA, it isn't Ad Hominem to tell him his game needs more work, even though he may feel very insulted by the concept." Not wanting to learn the version-control flavor of the week is a very different thing than not knowing how to use version control -- and it's suggestive that you've so confused the two concepts. To extend your basketball metaphor, version control software isn't part of the game, but rather, a piece of the equipment. If you suggested that an NBA player should spend even a day "learning" how to dribble with a new type of ball, he'd laugh you out of the room -- unless that ball added a significant advantage to his game. Being a professional is more about judicious decision making than it is about raw knowledge of technology. The transition of a pre-existing project from Subversion to Git adds huge complexity, in exchange for very little, as far as I'm concerned. When the situation changes, and Git adds more value than fad, I will re-evaluate.
    - KirinDave 18y ago
      "Subversion works. It's well-documented, simple, and there are many tools that work with it. Tell me why it's an inappropriate choice for a "working and current toolchain"." Because it is not a distributed version control system. As more and more people use a dvcs, they realize how incredibly flexible, useful, and generally more powerful it is vs. a centralized vcs. There is clear value added on numerous levels over subversion. You simply haven't bothered to research it. "Not wanting to learn the version-control flavor of the week is a very different thing than not knowing how to use version control -- and it's suggestive that you've so confused the two concepts." Git is not a flavor of the week. It is emerging as the dominant contender after literally 2 years of fighting and evolving for superiority within the dvcs community. This field is not new. It's suggestive of how out-of-date your information is that you aren't aware of these. "Being a professional is more about judicious decision making than it is about raw knowledge of technology." Yes. And I'm directly saying that you're making poor professional decisions. DVCS isn't fad anymore, it's the new standard.

So I guess that most programming languages would qualify as bad tools to you then? Seeing as how they force you to spend a lot of time "understanding" them before you can be productive.

timr 18y ago

My job isn't to learn version-control systems. Time spent learning a programming language is a direct investment in productivity; time spent learning a version control system is, at best, a required distraction.

KirinDave 18y ago
Your job is most certainly to maintain a working and current toolchain. This includes programming languages and the tools that produce software in tandem with you. This isn't just for your employer, it's for the sake of your own career. Or do you want to be like those poor men who came before us, knowing and learning only COBOL, who now complain that software engineering is a young person's game? If I interview a software engineer and they don't know how to use a version control system and actively express disdain for the concept of making sure that the progress of development is captured, then I would not recommend we hire them. Anyone who's had git-bisect save them a huge effort locating a bug would probably feel the same way. Version control is every bit as important as your editor, debugger linker, and binary examination tools. If you don't know how to use them, you're not ready to start playing the game on a professional level. You might say that I'm using Ad Hominem here, but I don't feel it's that way. There are minimum standards for software engineers who want to develop software professionally, and using version control and understanding why we use version control is pretty high up on the list. If a basketball player isn't ready for the NBA, it isn't Ad Hominem to tell him his game needs more work, even though he may feel very insulted by the concept.
- timr 18y ago
  "Your job is most certainly to maintain a working and current toolchain." Subversion works. It's well-documented, simple, and there are many tools that work with it. Tell me why it's an inappropriate choice for a "working and current toolchain". "There are minimum standards for software engineers who want to develop software professionally, and using version control and understanding why we use version control is pretty high up on the list. If a basketball player isn't ready for the NBA, it isn't Ad Hominem to tell him his game needs more work, even though he may feel very insulted by the concept." Not wanting to learn the version-control flavor of the week is a very different thing than not knowing how to use version control -- and it's suggestive that you've so confused the two concepts. To extend your basketball metaphor, version control software isn't part of the game, but rather, a piece of the equipment. If you suggested that an NBA player should spend even a day "learning" how to dribble with a new type of ball, he'd laugh you out of the room -- unless that ball added a significant advantage to his game. Being a professional is more about judicious decision making than it is about raw knowledge of technology. The transition of a pre-existing project from Subversion to Git adds huge complexity, in exchange for very little, as far as I'm concerned. When the situation changes, and Git adds more value than fad, I will re-evaluate.
  - KirinDave 18y ago
    "Subversion works. It's well-documented, simple, and there are many tools that work with it. Tell me why it's an inappropriate choice for a "working and current toolchain"." Because it is not a distributed version control system. As more and more people use a dvcs, they realize how incredibly flexible, useful, and generally more powerful it is vs. a centralized vcs. There is clear value added on numerous levels over subversion. You simply haven't bothered to research it. "Not wanting to learn the version-control flavor of the week is a very different thing than not knowing how to use version control -- and it's suggestive that you've so confused the two concepts." Git is not a flavor of the week. It is emerging as the dominant contender after literally 2 years of fighting and evolving for superiority within the dvcs community. This field is not new. It's suggestive of how out-of-date your information is that you aren't aware of these. "Being a professional is more about judicious decision making than it is about raw knowledge of technology." Yes. And I'm directly saying that you're making poor professional decisions. DVCS isn't fad anymore, it's the new standard.