6 ms·

Imagine an electronic engineer complaining about an oscilloscope being hard to use because he cannot explain what all those knobs do to his wife. We are profess

by aulin 3y ago

Imagine an electronic engineer complaining about an oscilloscope being hard to use because he cannot explain what all those knobs do to his wife. We are professionals, our tools should be powerful for the advanced user, not beginner friendly.

JCharante 3y ago
Agreed. Imagine a pilot complaining that the controls are not simple enough.
dolni 3y ago
There has been a lot of push to commoditize software engineering. Unfortunately that has resulted in a swarm of people who want developer salaries without the work or expertise. Git definitely has some warts but you are right. It is an industry tool for expert, professional use. Some complexity is inherent to the problem of version control. Learning how to use your tools is part of ANY trade.
- tester756 3y ago
  >It is an industry tool for expert, professional use. If you were talking about things like Kubernetes, LLVM, Ghidra then I'd agree. But no git. This is not some expert tool. This tool's purpose is literally to manage your characters' history, that's it. Git could be used by any other profession that deals with letters - article writers, book writers, etc, etc.
  - allarm 3y ago
    > This tool's purpose is literally to manage your characters' history, that's it. Yes, but you seem to heavily underestimate the complexity of the problem and the volume of the use cases that git solves.
- janalsncm 3y ago
  I disagree. There’s always more that can be learned about anything but we live in a world with finite time and finite resources. So you can either devote time to learning git or you could spend it doing the actual work. The fact that git is used by experts and professionals is not an excuse for poor UX. The experts and professionals are almost never Git experts or professionals. I use my car every day, that doesn’t make me a mechanic. Having to understand the inner workings of a tool is an indication of poor design, not a gatekeep we should seek to maintain.
  - dolni 3y ago
    I think there are two things being conflated here. One is: how do you effectively manage changes to a codebase over time? Git has a model that, for day-to-day use, has primitives like "commit", "branch", and "tag". You also have to understand the difference between your working copy, what is staged for commit, and any other commit in history. These, in combination with the operations you can do with them is actually somewhat complex. This is the thing I am saying people need to learn. And people quite often complain about it. The other is the organization of git's porcelain layer, the arguments and flags each subcommand takes, and how stuff is presented back to the user. I think git stands to make significant improvement here. Be that as it may, the tool exists as it is. So your options are to use a different VCS entirely, use a different frontend, or learn how to use git as-is. If you choose to use git but deliberately avoid learning e.g. what a rebase is and why it's useful, you are choosing to be an ineffective developer. Could it be better in some ways? Yes, but it isn't. I don't think the car analogy is particularly compelling. The "primitives" of a car are already much simpler than git's. The fundamental primitives of a car are "go faster" and "go slower", along with some supporting things like managing your headlights, windshield defrosting, wipers, and horn. While additional tools are being added to cars to make them safer (e.g. a backup cam or collision detection), the complexity of those tools is increasing rapidly which makes them more prone to failure. And a driver is absolutely not excused from causing an accident just because one of these safety tools failed. You still have to know how to safely operate your vehicle in a variety of conditions.
  - aulin 3y ago
    I often heard this argument from people learning LaTeX in academia. It's difficult and I don't have time to study it. From people that spent years to master advanced maths, people that spent years to learn how to build and operate state of the art experimental setups. But for some reason there's never time to learn your software tools.
etrautmann 3y ago
Yes, but if the oscilloscope has some buttons that take out the entire company’s codebase if pressed wrong.
- mistercheph 3y ago
  If the entire company's work has been laid up into a single prototype, then an oscilloscope does have such buttons :)
lpapez 3y ago
A tool can be both beginner friendly AND powerful for advanced users. Speaking of your analogy, the role that most software developers fullfil is not an engineer wondering about the oscilloscope, but rather the construction worker installing electrical fixtures wondering why the cable clamp has such a weird interface. Both the oscilloscope engineer in an office and the worker doing the field work would benefit from having a simple and reliable tool fit for purpose of cable clamping. There is certainly a need for competent and "proper" software engineering that require special tools and detailed training, but I would argue it's niche and filled by people who build the tools themselves. IMO the largest share of developers today are doing brick-laying work (which of course takes skill, I am not underestimating it) and would benefit a lot from having simpler tools - they don't need to know how to use an oscilloscope at all.
- dolni 3y ago
  > IMO the largest share of developers today are doing brick-laying work (which of course takes skill, I am not underestimating it) and would benefit a lot from having simpler tools - they don't need to know how to use an oscilloscope at all. They're doing brick-laying work until they aren't. Most problems are easy to solve and don't require very much fussing over. The expertise comes in knowing which problems are worth fussing over and which aren't. Technology is becoming ever more present in our lives, not less. Reducing software engineering to a low-skill trade when there is, in fact, mountains of complexity is surefire way for software to be a heap of shit. And in a lot of ways it already is.
  - lpapez 3y ago
    > Reducing software engineering to a low-skill trade when there is, in fact, mountains of complexity is surefire way for software to be a heap of shit. And in a lot of ways it already is. I fully agree with this observation, but the reality is that this is where things are going. Software quality is simply not that relevant today for the majority of software. As long as the billing works fine, the management is happy to see your website barely working - screw the quality if the money is coming in anyway. Such software costs much less and can be built by bricklayers.
tester756 3y ago
>We are professionals, our tools should be powerful for the advanced user, not beginner friendly. You can have both - powerful and user friendly. This idea that engineer's tools must be a mess that is fine as long as enables to do something is idiotic. The same argument was repeated whenever C or C++ vs Rust discussions were happening "Just learn C and memory management (and all the quirks)" "Just use this new language constructs and you're fine..." and in reality we ended with a lot of CVEs - 70% in both Chrome and Windows were related to mem. issues. There's absolutely no reason why git's CLI cannot be better than it currently is. Once again - there is no reason. Proof? There are CLI wrappers or even GUIs like GitHub Desktop that make whole experience way better.

by aulin 3y ago

JCharante 3y ago

Agreed. Imagine a pilot complaining that the controls are not simple enough.

dolni 3y ago

There has been a lot of push to commoditize software engineering. Unfortunately that has resulted in a swarm of people who want developer salaries without the work or expertise. Git definitely has some warts but you are right. It is an industry tool for expert, professional use. Some complexity is inherent to the problem of version control. Learning how to use your tools is part of ANY trade.

tester756 3y ago
>It is an industry tool for expert, professional use. If you were talking about things like Kubernetes, LLVM, Ghidra then I'd agree. But no git. This is not some expert tool. This tool's purpose is literally to manage your characters' history, that's it. Git could be used by any other profession that deals with letters - article writers, book writers, etc, etc.
- allarm 3y ago
  > This tool's purpose is literally to manage your characters' history, that's it. Yes, but you seem to heavily underestimate the complexity of the problem and the volume of the use cases that git solves.
janalsncm 3y ago
I disagree. There’s always more that can be learned about anything but we live in a world with finite time and finite resources. So you can either devote time to learning git or you could spend it doing the actual work. The fact that git is used by experts and professionals is not an excuse for poor UX. The experts and professionals are almost never Git experts or professionals. I use my car every day, that doesn’t make me a mechanic. Having to understand the inner workings of a tool is an indication of poor design, not a gatekeep we should seek to maintain.
- dolni 3y ago
  I think there are two things being conflated here. One is: how do you effectively manage changes to a codebase over time? Git has a model that, for day-to-day use, has primitives like "commit", "branch", and "tag". You also have to understand the difference between your working copy, what is staged for commit, and any other commit in history. These, in combination with the operations you can do with them is actually somewhat complex. This is the thing I am saying people need to learn. And people quite often complain about it. The other is the organization of git's porcelain layer, the arguments and flags each subcommand takes, and how stuff is presented back to the user. I think git stands to make significant improvement here. Be that as it may, the tool exists as it is. So your options are to use a different VCS entirely, use a different frontend, or learn how to use git as-is. If you choose to use git but deliberately avoid learning e.g. what a rebase is and why it's useful, you are choosing to be an ineffective developer. Could it be better in some ways? Yes, but it isn't. I don't think the car analogy is particularly compelling. The "primitives" of a car are already much simpler than git's. The fundamental primitives of a car are "go faster" and "go slower", along with some supporting things like managing your headlights, windshield defrosting, wipers, and horn. While additional tools are being added to cars to make them safer (e.g. a backup cam or collision detection), the complexity of those tools is increasing rapidly which makes them more prone to failure. And a driver is absolutely not excused from causing an accident just because one of these safety tools failed. You still have to know how to safely operate your vehicle in a variety of conditions.
- aulin 3y ago
  I often heard this argument from people learning LaTeX in academia. It's difficult and I don't have time to study it. From people that spent years to master advanced maths, people that spent years to learn how to build and operate state of the art experimental setups. But for some reason there's never time to learn your software tools.

etrautmann 3y ago

Yes, but if the oscilloscope has some buttons that take out the entire company’s codebase if pressed wrong.

mistercheph 3y ago
If the entire company's work has been laid up into a single prototype, then an oscilloscope does have such buttons :)

lpapez 3y ago

A tool can be both beginner friendly AND powerful for advanced users. Speaking of your analogy, the role that most software developers fullfil is not an engineer wondering about the oscilloscope, but rather the construction worker installing electrical fixtures wondering why the cable clamp has such a weird interface. Both the oscilloscope engineer in an office and the worker doing the field work would benefit from having a simple and reliable tool fit for purpose of cable clamping. There is certainly a need for competent and "proper" software engineering that require special tools and detailed training, but I would argue it's niche and filled by people who build the tools themselves. IMO the largest share of developers today are doing brick-laying work (which of course takes skill, I am not underestimating it) and would benefit a lot from having simpler tools - they don't need to know how to use an oscilloscope at all.

dolni 3y ago
> IMO the largest share of developers today are doing brick-laying work (which of course takes skill, I am not underestimating it) and would benefit a lot from having simpler tools - they don't need to know how to use an oscilloscope at all. They're doing brick-laying work until they aren't. Most problems are easy to solve and don't require very much fussing over. The expertise comes in knowing which problems are worth fussing over and which aren't. Technology is becoming ever more present in our lives, not less. Reducing software engineering to a low-skill trade when there is, in fact, mountains of complexity is surefire way for software to be a heap of shit. And in a lot of ways it already is.
- lpapez 3y ago
  > Reducing software engineering to a low-skill trade when there is, in fact, mountains of complexity is surefire way for software to be a heap of shit. And in a lot of ways it already is. I fully agree with this observation, but the reality is that this is where things are going. Software quality is simply not that relevant today for the majority of software. As long as the billing works fine, the management is happy to see your website barely working - screw the quality if the money is coming in anyway. Such software costs much less and can be built by bricklayers.

tester756 3y ago

>We are professionals, our tools should be powerful for the advanced user, not beginner friendly. You can have both - powerful and user friendly. This idea that engineer's tools must be a mess that is fine as long as enables to do something is idiotic. The same argument was repeated whenever C or C++ vs Rust discussions were happening "Just learn C and memory management (and all the quirks)" "Just use this new language constructs and you're fine..." and in reality we ended with a lot of CVEs - 70% in both Chrome and Windows were related to mem. issues. There's absolutely no reason why git's CLI cannot be better than it currently is. Once again - there is no reason. Proof? There are CLI wrappers or even GUIs like GitHub Desktop that make whole experience way better.