3 ms·

The point is that you shouldn't have to learn everything by brutal trial and error, losing hours of work each time you try to learn a new operation and make a s

The point is that you shouldn't have to learn everything by brutal trial and error, losing hours of work each time you try to learn a new operation and make a small mistake. It's the same reason consumer operating systems have a trash can and undo features. Just railing on people with "you should've known better" doesn't really help.

still_grokking 5y ago
Well, reading the fucking manual BEFORE you touch a machine is a very good idea. Otherwise the machine may rip out your limbs, or worse. The manufacturer of the machine won't be responsible for sure if you didn't even read the manual… Clear case. That's reality in engineering. If developers want to call themself "engineers" they should behave as such. On the other side you don't let people without special training even close to industrial machines! The risk they could get killed by an accident is just to high. Here lies the discrepancy actually: "Software industry" is as much an industry as running a kindergarten is. Also there is the most time no "engineering" at all in "software engineering"… Just trail and error until "something works" (or at least looks on the surface like it would, no matter how broken it is on the inside). As long as people are supposed to "learn on the job", and there are no clear quality / security standards in this "industry", and stuff is called "engineering" even no true engineering approaches are followed, nothing will change. Machines will continue to kill people in completely avoidable accidents (virtually)… But that's in my opinion a fully homemade misery actually.
- unknown_error 5y ago
  Y'know, for some of us peasants, dev work can just be a way out of poverty. We don't have engineering degrees from a top school, we don't work for the FANGs, and we don't work on mission-critical code. The software industry has expanded a lot since the 80s, and now hobbyists can and do make a living out of it even without formal training. So what? When I started web dev, I earned $15/hr. Beat the $8/hr I was making before that in landscaping. Now I make a little more than that, which still isn't much. My clients/employers don't pay crazy wages and they don't expect crazy quality work. They know they get what they pay for, and it works out for both parties. Maybe's OK to have shitty, mediocre code for 90% of the world's needs... a small biz website, with the ecommerce/PCI bits outsourced? Sure, why not. It mostly works, and if it goes down for a few hours a year, maybe that doesn't meet super-reliability standards (can we count 8s instead of 9s?) but it gets the job done well enough? Shrug. Sure, proper engineer techniques matter for certain applications. I would never want to touch industrial machines, or medical, or space, or automobiles... anything that could blow up and/or kill someone. But most code out there is just for some local, small-scale use, mostly temporary anyhow and bound to obsolete in a few years if not months. There will always be mediocre businesses needing mediocre devs for mediocre pay, just as there will be elite enterprises that require the world's smartest people. Problem is, git was designed by the super smart for the super smart, great engineering with terrible UX. And it was kinda just trickled down to the rest of us, and it feels a bit like trying to teach Mom to use DOS and edit config.sys just to play a game. Now consumer software UX has leaped forward by decades and it shows, but a lot of the command-line dev tools are still incredibly arcane. They don't have to be, but it's not a priority to fix/improve their UX because, I suppose, it's engineers who are proud of their engineering, not proud of their ability to dumb it down for the rest of us. I don't blame them, I just know I can't meaningfully contribute to git (the project) because I'm not smart enough, well trained enough, whatever, and that complaints would fall on deaf ears like yours. It's an altogether different culture. Elitist by design, or meritocratic if you will. And believe or not, I've probably spent more time learning git -- reading documentation, diagramming it out with coworkers, cloning repos and experimenting with commands, etc., following a shit-ton of tutorials -- than any other skill I've ever had to learn. It was quicker to learn Perl and regex than mid-level git. If you want to pay for the world's would-be engineers to receive all the training to go from mere dev to proper "software engineers", by all means please do. But otherwise, well... you know what? World's gonna keep producing mediocrity. Most of us are just average.
  - chefandy 5y ago
    As long as there are people who create things for others to use, there will be people who blame users for not being technical enough to work around their lack of ability or willingness to produce good interfaces. Developers just happened to also be the users in this instance.
- chefandy 5y ago
  Not a big fan of human factors in engineering, huh? Documenting poor design rather than improving it is lazy, bad engineering. Requiring rote learning of an very complex interface that poorly represents a moderately complex data structure is lazy, bad engineering. Macho, hyperbolic, gatekeeping arguments for non-design as a design philosophy is advocating for bad engineering. Being mad that people want products with interfaces that make sense is being mad that people want an important facet of good engineering.
- Griffinsauce 5y ago
  > Well, reading the fucking manual BEFORE you touch a machine is a very good idea. Otherwise the machine may rip out your limbs, or worse. We are discussing designing the machine in a way that removes these options altogether. This is objectively and obviously a better strategy because humans are fallible, even when well trained, and the time put into safety training can now be put into an actually productive direction. You're working from the perspective that machines and git must be dangerous to be effective. This is an assumption that should be challenged before the enormous waste of safety training is accepted.
- atoav 5y ago
  As someone who just learned a thousand electrical norms let me assure you of one thing: the way git handles "dangerous actions" that might delete things is NOT something you would find an equivalent for in the industrial machines, where you have mandatory warning signs, switches for operation with two hands (or even two people), mandatory inspections of these safety features etc. It is not a different league it is a different sport. If a factory was designed with the equivalent of gits usabilty today, it wouldn't even get a permission to be built based on the plans alone. Also the person who planned it would have a hard time ever doing so again. If git was a bridge it would have no handrails and it would oscillate in certain winds and for some odd reason there is a roundabout in the middle. It is still better than no bridge for sure. As one of the first of its kind a lot can be excused, but fundamentally better engineering is possible as well.
  - chefandy 5y ago
    Right. I've worked with many machines that can chop or rip off limbs and I can't think of a single instance in which the operator even had access to the manual. "Push these two buttons and this foot pedal to make it go. Don't wear loose clothing." If it was more complicated than a few button-presses to use and that risky, it would either be operated by a team or it wouldn't be used. The only single-operator machine I can think of which has an interface even 1/10th as complex as git is an automobile. The number of fatal accidents that could be remedied by reading the manual is vanishingly small.

still_grokking 5y ago

Well, reading the fucking manual BEFORE you touch a machine is a very good idea. Otherwise the machine may rip out your limbs, or worse. The manufacturer of the machine won't be responsible for sure if you didn't even read the manual… Clear case. That's reality in engineering. If developers want to call themself "engineers" they should behave as such. On the other side you don't let people without special training even close to industrial machines! The risk they could get killed by an accident is just to high. Here lies the discrepancy actually: "Software industry" is as much an industry as running a kindergarten is. Also there is the most time no "engineering" at all in "software engineering"… Just trail and error until "something works" (or at least looks on the surface like it would, no matter how broken it is on the inside). As long as people are supposed to "learn on the job", and there are no clear quality / security standards in this "industry", and stuff is called "engineering" even no true engineering approaches are followed, nothing will change. Machines will continue to kill people in completely avoidable accidents (virtually)… But that's in my opinion a fully homemade misery actually.

unknown_error 5y ago
Y'know, for some of us peasants, dev work can just be a way out of poverty. We don't have engineering degrees from a top school, we don't work for the FANGs, and we don't work on mission-critical code. The software industry has expanded a lot since the 80s, and now hobbyists can and do make a living out of it even without formal training. So what? When I started web dev, I earned $15/hr. Beat the $8/hr I was making before that in landscaping. Now I make a little more than that, which still isn't much. My clients/employers don't pay crazy wages and they don't expect crazy quality work. They know they get what they pay for, and it works out for both parties. Maybe's OK to have shitty, mediocre code for 90% of the world's needs... a small biz website, with the ecommerce/PCI bits outsourced? Sure, why not. It mostly works, and if it goes down for a few hours a year, maybe that doesn't meet super-reliability standards (can we count 8s instead of 9s?) but it gets the job done well enough? Shrug. Sure, proper engineer techniques matter for certain applications. I would never want to touch industrial machines, or medical, or space, or automobiles... anything that could blow up and/or kill someone. But most code out there is just for some local, small-scale use, mostly temporary anyhow and bound to obsolete in a few years if not months. There will always be mediocre businesses needing mediocre devs for mediocre pay, just as there will be elite enterprises that require the world's smartest people. Problem is, git was designed by the super smart for the super smart, great engineering with terrible UX. And it was kinda just trickled down to the rest of us, and it feels a bit like trying to teach Mom to use DOS and edit config.sys just to play a game. Now consumer software UX has leaped forward by decades and it shows, but a lot of the command-line dev tools are still incredibly arcane. They don't have to be, but it's not a priority to fix/improve their UX because, I suppose, it's engineers who are proud of their engineering, not proud of their ability to dumb it down for the rest of us. I don't blame them, I just know I can't meaningfully contribute to git (the project) because I'm not smart enough, well trained enough, whatever, and that complaints would fall on deaf ears like yours. It's an altogether different culture. Elitist by design, or meritocratic if you will. And believe or not, I've probably spent more time learning git -- reading documentation, diagramming it out with coworkers, cloning repos and experimenting with commands, etc., following a shit-ton of tutorials -- than any other skill I've ever had to learn. It was quicker to learn Perl and regex than mid-level git. If you want to pay for the world's would-be engineers to receive all the training to go from mere dev to proper "software engineers", by all means please do. But otherwise, well... you know what? World's gonna keep producing mediocrity. Most of us are just average.
- chefandy 5y ago
  As long as there are people who create things for others to use, there will be people who blame users for not being technical enough to work around their lack of ability or willingness to produce good interfaces. Developers just happened to also be the users in this instance.
chefandy 5y ago
Not a big fan of human factors in engineering, huh? Documenting poor design rather than improving it is lazy, bad engineering. Requiring rote learning of an very complex interface that poorly represents a moderately complex data structure is lazy, bad engineering. Macho, hyperbolic, gatekeeping arguments for non-design as a design philosophy is advocating for bad engineering. Being mad that people want products with interfaces that make sense is being mad that people want an important facet of good engineering.
Griffinsauce 5y ago
> Well, reading the fucking manual BEFORE you touch a machine is a very good idea. Otherwise the machine may rip out your limbs, or worse. We are discussing designing the machine in a way that removes these options altogether. This is objectively and obviously a better strategy because humans are fallible, even when well trained, and the time put into safety training can now be put into an actually productive direction. You're working from the perspective that machines and git must be dangerous to be effective. This is an assumption that should be challenged before the enormous waste of safety training is accepted.
atoav 5y ago
As someone who just learned a thousand electrical norms let me assure you of one thing: the way git handles "dangerous actions" that might delete things is NOT something you would find an equivalent for in the industrial machines, where you have mandatory warning signs, switches for operation with two hands (or even two people), mandatory inspections of these safety features etc. It is not a different league it is a different sport. If a factory was designed with the equivalent of gits usabilty today, it wouldn't even get a permission to be built based on the plans alone. Also the person who planned it would have a hard time ever doing so again. If git was a bridge it would have no handrails and it would oscillate in certain winds and for some odd reason there is a roundabout in the middle. It is still better than no bridge for sure. As one of the first of its kind a lot can be excused, but fundamentally better engineering is possible as well.
- chefandy 5y ago
  Right. I've worked with many machines that can chop or rip off limbs and I can't think of a single instance in which the operator even had access to the manual. "Push these two buttons and this foot pedal to make it go. Don't wear loose clothing." If it was more complicated than a few button-presses to use and that risky, it would either be operated by a team or it wouldn't be used. The only single-operator machine I can think of which has an interface even 1/10th as complex as git is an automobile. The number of fatal accidents that could be remedied by reading the manual is vanishingly small.