4 ms·

This is something I think about a lot nowadays. You have to try and fail a lot to develop an intuition for good design. How do you give people the room to exper

This is something I think about a lot nowadays. You have to try and fail a lot to develop an intuition for good design. How do you give people the room to experiment without paying for all the mistakes? It is tremendously expensive to produce a senior developer yet vital to do so because junior developers mostly produce crap. We could only assign them projects off the critical path, but we can't really afford to have anyone working on anything but the critical path. Plus it's a lot to ask of someone's ego to say, here work on things that don't matter for 5 or 10 years and we'll talk.

mikekchar 9y ago
I was randomly watching Youtube the other day and there was an ad for Herbie Hancock's Masterwork class (ha ha -- not a referral, no idea if it's any good). Anyway, in the ad he mentioned that he was playing with Miles Davis one time and that he made what was technically a mistake. Miles listened to it, picked it up and made it right. Suddenly I realised: "That's it! That's what I want to do." But, of course, it's much easier said than done. I won't pretend that I'm able to do it yet :-)
watwut 9y ago
You do it by modularising code into smaller parts that communicate in well defined ways and enforce that. Then you can take whoever and have him make one module with a lot of autonomy. If he fails and make mess of it, someone else (or even more experienced himself) will rewrite it relatively easy. Meanwhile, you let him make decisions in his module/plugin/part/web service/whatever while you enforce rules between them. Also, the work off critical path matters too, it would not be done at all otherwise, so treat it like it matters. It won't take juniors ego if older collegues take that job seriously.
intrasight 9y ago
That's what "side projects" are for. Go and experiment as much as you want. Then after you've succeeded, make a presentation to technical management showing what you've learned.

mikekchar 9y ago

I was randomly watching Youtube the other day and there was an ad for Herbie Hancock's Masterwork class (ha ha -- not a referral, no idea if it's any good). Anyway, in the ad he mentioned that he was playing with Miles Davis one time and that he made what was technically a mistake. Miles listened to it, picked it up and made it right. Suddenly I realised: "That's it! That's what I want to do." But, of course, it's much easier said than done. I won't pretend that I'm able to do it yet :-)

watwut 9y ago

You do it by modularising code into smaller parts that communicate in well defined ways and enforce that. Then you can take whoever and have him make one module with a lot of autonomy. If he fails and make mess of it, someone else (or even more experienced himself) will rewrite it relatively easy. Meanwhile, you let him make decisions in his module/plugin/part/web service/whatever while you enforce rules between them. Also, the work off critical path matters too, it would not be done at all otherwise, so treat it like it matters. It won't take juniors ego if older collegues take that job seriously.

intrasight 9y ago

That's what "side projects" are for. Go and experiment as much as you want. Then after you've succeeded, make a presentation to technical management showing what you've learned.