Ask HN: Thoughts on idea to help novice developers bridge the learning chasm?
(1) work with others who are more experienced and through osmosis you begin to pick up aspects of their developmental style and process i.e. how to approach a project and ultimately implement a solution (this is not possible for those that don't program for a living);
(2) hack on your own and through trial and error eventually find your way (good but perhaps not the best or only alternative).
Concept: I'm proposing a third option or hoping if it already exists. I would find it incredibly helpful if there were a resource that detailed the thought process and implementation steps that an experienced developer took in approaching a set of problems or projects. Even better I'd love to see two developers independently approach a set of small to medium sized projects, detail their thoughts along the way, and see how their development process and their implementations differ.
What do you think? Valuable? Does it exist? Worth creating?
12 comments
[ 3.1 ms ] story [ 40.9 ms ] threadWhat do you think?: Good Idea
Valuable?: Yes, worth $34.59 according to Amazon
Does it exist?: Yes, see above
Worth creating?: Yes, if you can do it better than GoF
(Hear me out on this sacrilegious statement! :) It's just that some of the design patterns are really low-level and often described in terms that modern frameworks reuse with different names. Now this isn't the GoF's fault but it does get confusing for people. I'd pitch the book at someone with a bit more experience as I think 'getting patterns' helps when you've gone off the rails a bit and can see the benefit a bit more - otherwise they just seem too abstract and a bit arbitrary IMHO.
Have you seen books like http://railstutorial.org/book and similar? Is this sort of what you mean?
Is there something like this for python?
I'd definitely be interested to see two different programmers write up their approach to a given problem. Something like this would be an excellent monthly blog post.
I found it really encouraging. Here's this godlike coder who works at Google just doing incremental development until he has a really good finished product. At the end of it, you can't help thinking "but I could have done that!" In fact that was his overall purpose. In http://norvig.com/Lisp-retro.html he says 'The main object of this book is to cause the reader to say to him or herself "I could have written that"'
So yes, your option 3 is a great idea.
In using a variety of frameworks/languages, the learner gets more adept each time since lots of the abstractions are the same, but really jumps forward in the areas where the abstractions are different enough to create some food for thought.
It is that sort of thinking that helps differentiate the designed aspects of a program from the ones that are implementation specific consequences of the design.
What seems to work best, is to get them building anything, and then critiquing as we go. So, they're all hacking on personal projects, and all kind of making the same mistakes, and we go over what they've written and then move on to the next step.
As they run into various hurdles, it opens up lots of discussions on some of the finer parts of things, which would have made no freaking sense to them earlier.
I know you're talking about a slightly more advanced level, but I'd say the technique still stands: Keep hacking on your own (as this is kind of the most important), but put your code out where someone can make fun of it, get it reviewed and critiqued, learn to anticipate criticisms, and you'll be a great developer in no time!
tertiary education?