3 ms·

Remind me never to work for you.

by MrTonyD 11y ago

exelius 11y ago
I trust my teams to manage themselves - and part of that is learning for yourself. Engineers learn through problem solving.
- MrTonyD 11y ago
  There is literally decades of research showing that it is possible to learn things faster and better with appropriate teaching materials. That is why we have Universities and schools to teach people - and don't just ask people to figure out everything for themselves (ie. high fidelity simulations were found to be less educational - since their high fidelity proved to be a distraction from building the important conceptual models.) So, while I can and have figured out complex systems on my own, it would really be much more helpful to have someone or something to help create correct mental models at the beginning (and again, there are decades of educational research showing that there is a cognitive cost to building incorrect models of systems. That cognitive cost may mean nothing to my manager - but that is exactly why I wouldn't want to work for such a person.)
  - exelius 11y ago
    I'm not saying we teach someone theoretical physics by saying "dive in!" But you're talking about things that are relatively static. I'm not going to spend a sprint building perfect mental models of an application because if your app is anything like the ones that I've built, they change significantly over the course of a year. We rip out services and and abstract them behind new API layers all the time. Legacy interfaces are provided of course, but the way things work internally is constantly a work in progress. Now, just because it's a good idea for a developer to learn how the system works today when they first start doesn't mean it's a good idea to carry that complexity forward to your production servers. So if the day comes when someone containerizes these applications with an actual business benefit, then let's containerize the fuck out of them. But I'm not taking on a bunch of tech debt (that will incur more tech debt as the application changes over time) just to make onboarding easier - when making onboarding push-button isn't necessarily accomplishing the goal of onboarding because the developer is going to have to learn those lessons sooner or later.

Remind me never to work for you.

by MrTonyD 11y ago

Remind me never to work for you.

I trust my teams to manage themselves - and part of that is learning for yourself. Engineers learn through problem solving.

MrTonyD 11y ago
There is literally decades of research showing that it is possible to learn things faster and better with appropriate teaching materials. That is why we have Universities and schools to teach people - and don't just ask people to figure out everything for themselves (ie. high fidelity simulations were found to be less educational - since their high fidelity proved to be a distraction from building the important conceptual models.) So, while I can and have figured out complex systems on my own, it would really be much more helpful to have someone or something to help create correct mental models at the beginning (and again, there are decades of educational research showing that there is a cognitive cost to building incorrect models of systems. That cognitive cost may mean nothing to my manager - but that is exactly why I wouldn't want to work for such a person.)
- exelius 11y ago
  I'm not saying we teach someone theoretical physics by saying "dive in!" But you're talking about things that are relatively static. I'm not going to spend a sprint building perfect mental models of an application because if your app is anything like the ones that I've built, they change significantly over the course of a year. We rip out services and and abstract them behind new API layers all the time. Legacy interfaces are provided of course, but the way things work internally is constantly a work in progress. Now, just because it's a good idea for a developer to learn how the system works today when they first start doesn't mean it's a good idea to carry that complexity forward to your production servers. So if the day comes when someone containerizes these applications with an actual business benefit, then let's containerize the fuck out of them. But I'm not taking on a bunch of tech debt (that will incur more tech debt as the application changes over time) just to make onboarding easier - when making onboarding push-button isn't necessarily accomplishing the goal of onboarding because the developer is going to have to learn those lessons sooner or later.