4 ms·
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
by 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 agoThanks. 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 agoI 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 agoThere 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.