It's honestly something that i found out entirely through self-experience. I'm a self-taught Perl developer who spent 5 years to reach a proficient level. I managed to get another developer with little Perl experience to nearly my level within 6 months by handing him two excellent books and reading his code and pointing out issues in his algorithms and semantics.
The local maxima i am aware of here are:
1. Outdated books. When i learned Perl i wasted a lot of time on books that are now known widely to be objectively bad, but are still recommended widely. The ones i recommended allowed learning with little friction.
2. Algorithmic and semantic problems that have to be resolved through lengthy investigation sessions long after they're implemented. I spent a LOT of time figuring out what doesn't work well in the long run. He's been able to skip those and spend his time more productively on problems that i haven't encoutered or solved yet.
I'm not trying to toot my horn here and i think i'm not a good teacher. But the advantages he had from me being available were staggering.
> I spent a LOT of time figuring out what doesn't work well in the long run. He's been able to skip those and spend his time more productively on problems that i haven't encoutered or solved yet.
This is one thing teachers are really good for!
I'm sure some students would figure out not to sure GOTO after awhile, but, well, think of all those wasted years! Easier to just explain to them the problems upfront!
> I managed to get another developer with little Perl experience to nearly my level within 6 months by handing him two excellent books and reading his code and pointing out issues in his algorithms and semantics.
Part of this is natural ability as well. I have a friend who much to my dismay is not a software engineer, but who only dabbles.
I was able to explain lambdas and closures to him in a couple of minutes over IM, and he was almost immediately able to see their uses.
Meanwhile, I know experienced software engineers who cannot fathom the purpose of a Lambda, and a few friends I know who are just not intelligent enough (?) to comprehend on a deep level how lambdas and closures work.
Now all this said, the college professor who was supposed to teach us functional programming did such as piss poor job at it that I ended up not understanding basic FP concepts until I started using them in C# and reading about how they are implemented in the CLR. (Part of this is because Eric Lippert is a damn good writer...)
I think the text book we had at the time defined them solely in terms of mathematical constructs. Ugh.
The local maxima i am aware of here are:
1. Outdated books. When i learned Perl i wasted a lot of time on books that are now known widely to be objectively bad, but are still recommended widely. The ones i recommended allowed learning with little friction.
2. Algorithmic and semantic problems that have to be resolved through lengthy investigation sessions long after they're implemented. I spent a LOT of time figuring out what doesn't work well in the long run. He's been able to skip those and spend his time more productively on problems that i haven't encoutered or solved yet.
I'm not trying to toot my horn here and i think i'm not a good teacher. But the advantages he had from me being available were staggering.
(The wordy rant to offset my quotable. ;) )