5 ms·

> It feels like the industry mostly just re-learns the same mistakes over and over like we're in Groundhog's Day This is true, but also in life. I'm so sad I

by axaxs 5y ago

> It feels like the industry mostly just re-learns the same mistakes over and over like we're in Groundhog's Day This is true, but also in life. I'm so sad I can't just pass my knowledge to my daughter to give her a 30 year head start. I remember telling her 'dont touch that stove it's hot', she nods, and soon after is crying she burnt her hand. I wanted to be mad but it made me realize the one universal truth: advice and information is great, but humans just seem to learn most from mistakes. Made me realize how much time and energy and knowledge is lost, as every human learns a lot of the same things over and over. I'm sure there was a caveman telling his kid not to touch the fire thousands of years ago, too. And here we are. So don't be too cynical and depressed about this cycle, it's pretty natural.

adjkant 5y ago
I just want to give a giant explicit +1 to this sentiment and understanding of how humans learn, and then add a bit from there to connect it back to the problem highlighted in the first comment. IMO, there's a few ways to try and take a pragmatic approach to the problem above: 1. Make simple ways to do complex things. A library, a language, a framework, they all go after the same thing when designed well: batteries included complex functionality that the end user can't shoot themselves in the foot with. It seems like in this domain (microservices), we are still early and need better support for small companies to spin this up. I've found my current company runs microservices pretty well, but I know it took a TON of infrastructure, support, and education to get it to that point. Few companies can afford to have that. The danger with this approach is that people who understand the internals become rare, and surface level only knowledge can lead to issues when you get to edge cases. I'll still take it, but wanted to call it out. The linux kernel is a great example of what that looks like down the line. 2. Make as many places as possible for developers in training to fail and make those 5 years of mistakes with low stakes consequences. In some ways, the way the industry hires already does this, but I'm sure there are better ways we can come up with versus the current sandboxes. If your frustration boils over, this is a place to channel it positively.
- axaxs 5y ago
  Thanks. I really like idea number 2. In training, have people fail nearly purposefully. I think some of the problem is that there's no real standardized training for developers. Many have 4 weeks of 'bootcamp' and are cut into the wild. And I can't be too negative about it, I didn't even have that. I would just say I learned from 20 years of reading and mistakes.
  - throwawaaarrgh 5y ago
    > I would just say I learned from 20 years of reading and mistakes. One thing that's crazy to me is that when people make mistakes, in most cases it's forgotten or swept under the rug. Whereas if they do a full post-mortem and share it with the entire engineering organization, they're teaching everyone a valuable lesson (possibly multiple lessons) for free. If that lesson prevents the same situation from happening again even one time, they'll have "paid off" the first mistake, and it cost them nothing. Free money!
    - axaxs 5y ago
      I agree, but it goes back to my initial argument. Even if everyone documented every failure and had perfect documentation, the result wouldn't be a whole lot different. People just don't care or pay much attention until it affects them personally. That's not to say it's a waste. Once a person gets bitten, they look for resources and learn from that. But until then, we're basically all stupid apes making the same mistakes in perpetuity.
- hyperman1 5y ago
  There is another way: Junior dev does support and micro bug fixing. After a year of hell, you'll have a medior dev that knows the value of logging, troubleshooting, testing, and above all simplicity. a.k.a. someone who can be trusted to write code.
ZephyrBlu 5y ago
I think you're slightly wrong here. I'd say most, or possibly almost all humans don't learn from other people's mistakes. But _some_ people do learn _some_ things from other people's mistakes instead of their own. I don't think this is some sort of innate human thing, I think it's purely down to ego. You think you know more or you're better than the person who made the mistake, and therefore you don't listen to them because you would never do that.
- strken 5y ago
  It's easier to learn from other people making mistakes when it happens directly in front of you than when they tell you about it afterwards. I'm never going to use heroin, or try to move a broken leg without splinting it first, for example.
np- 5y ago
People shouldn't always just blindly accept what is told to them as truth either - they need to have the ability to determine if something is true or not on their own, and experiencing/verifying things yourself is a powerful way to do that. So overall it's a balancing act. There's also a lot of information that's lost when you merely just tell someone something. There's just no way to know exactly how bad it feels to touch a stove unless you have been through the experience yourself, there's no way for a human to convey that level of feeling to another human verbally, and as such it's inevitable that humanity's curse is that we have to relive things over and over again.

by axaxs 5y ago

adjkant 5y ago

I just want to give a giant explicit +1 to this sentiment and understanding of how humans learn, and then add a bit from there to connect it back to the problem highlighted in the first comment. IMO, there's a few ways to try and take a pragmatic approach to the problem above: 1. Make simple ways to do complex things. A library, a language, a framework, they all go after the same thing when designed well: batteries included complex functionality that the end user can't shoot themselves in the foot with. It seems like in this domain (microservices), we are still early and need better support for small companies to spin this up. I've found my current company runs microservices pretty well, but I know it took a TON of infrastructure, support, and education to get it to that point. Few companies can afford to have that. The danger with this approach is that people who understand the internals become rare, and surface level only knowledge can lead to issues when you get to edge cases. I'll still take it, but wanted to call it out. The linux kernel is a great example of what that looks like down the line. 2. Make as many places as possible for developers in training to fail and make those 5 years of mistakes with low stakes consequences. In some ways, the way the industry hires already does this, but I'm sure there are better ways we can come up with versus the current sandboxes. If your frustration boils over, this is a place to channel it positively.

axaxs 5y ago
Thanks. I really like idea number 2. In training, have people fail nearly purposefully. I think some of the problem is that there's no real standardized training for developers. Many have 4 weeks of 'bootcamp' and are cut into the wild. And I can't be too negative about it, I didn't even have that. I would just say I learned from 20 years of reading and mistakes.
- throwawaaarrgh 5y ago
  > I would just say I learned from 20 years of reading and mistakes. One thing that's crazy to me is that when people make mistakes, in most cases it's forgotten or swept under the rug. Whereas if they do a full post-mortem and share it with the entire engineering organization, they're teaching everyone a valuable lesson (possibly multiple lessons) for free. If that lesson prevents the same situation from happening again even one time, they'll have "paid off" the first mistake, and it cost them nothing. Free money!
  - axaxs 5y ago
    I agree, but it goes back to my initial argument. Even if everyone documented every failure and had perfect documentation, the result wouldn't be a whole lot different. People just don't care or pay much attention until it affects them personally. That's not to say it's a waste. Once a person gets bitten, they look for resources and learn from that. But until then, we're basically all stupid apes making the same mistakes in perpetuity.
hyperman1 5y ago
There is another way: Junior dev does support and micro bug fixing. After a year of hell, you'll have a medior dev that knows the value of logging, troubleshooting, testing, and above all simplicity. a.k.a. someone who can be trusted to write code.

ZephyrBlu 5y ago

I think you're slightly wrong here. I'd say most, or possibly almost all humans don't learn from other people's mistakes. But _some_ people do learn _some_ things from other people's mistakes instead of their own. I don't think this is some sort of innate human thing, I think it's purely down to ego. You think you know more or you're better than the person who made the mistake, and therefore you don't listen to them because you would never do that.

strken 5y ago
It's easier to learn from other people making mistakes when it happens directly in front of you than when they tell you about it afterwards. I'm never going to use heroin, or try to move a broken leg without splinting it first, for example.

np- 5y ago

People shouldn't always just blindly accept what is told to them as truth either - they need to have the ability to determine if something is true or not on their own, and experiencing/verifying things yourself is a powerful way to do that. So overall it's a balancing act. There's also a lot of information that's lost when you merely just tell someone something. There's just no way to know exactly how bad it feels to touch a stove unless you have been through the experience yourself, there's no way for a human to convey that level of feeling to another human verbally, and as such it's inevitable that humanity's curse is that we have to relive things over and over again.