3 ms·

I guarantee Joe understands a lot more about his application than Janelle does. I'm all for hiding complexity behind abstraction layers, but it's a really usef

by exelius 11y ago

I guarantee Joe understands a lot more about his application than Janelle does. I'm all for hiding complexity behind abstraction layers, but it's a really useful exercise for a developer to be given an app and told "figure out how to make it work, but feel free to ask any questions you have". It causes you to really think about how the application works, and the process of figuring it out yourself is FAR more instructive than any documentation would ever be. Not to say you shouldn't have documentation (because of course you should), but when you have to figure something out yourself, it sticks in your memory a lot better.

MrTonyD 11y ago
Remind me never to work for you.
- 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.
zorpner 11y ago
I think as long as this is made clear, it's a great idea -- onboarding a new dev is a rare opportunity to get dedicated but fresh eyes on your internal processes.

by exelius 11y ago

MrTonyD 11y ago

Remind me never to work for you.

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.

zorpner 11y ago

I think as long as this is made clear, it's a great idea -- onboarding a new dev is a rare opportunity to get dedicated but fresh eyes on your internal processes.