So far my research, and small scale experiments (mostly one-on-one teaching), on this topic has lead me to these points.
I separated these into levels to make it easier to understand, however when teaching to some degree they can be mixed. *Level 0* These I consider fundamental, either you understand and learn them or you won't be able to program. Not knowing/understanding these are a better predictor than anything else I've seen: 1. Dealing with frustration 2. Problem Solving 3. Learning Dealing and understanding frustration is one of the least taught things, but it has the biggest benefit to the learners. It helps with motivation and means people can stand more difficult problems when learning... also better willpower. Many seem to think that programming is similar to writing just a piece of text and when things don't go that easy, assume they are stupid and cannot learn it. Dealing with frustration is essential part of programming. It can be avoided in two ways, either teach more gradually or teach how to deal and focus frustration. There's a process how people solve problems and how they can solve them better. "How to Solve It" by Polya is great book on this book. Often people start randomly trying things rather than take a more structured approach to solving problems. Learning here means that "learning the essence of things" rather than memorizing things. Some people have very good memorization skills, which means they can tell exactly what something is, but are not able to actually use it. "Learning How To Learn" is a good summary course on the topic https://www.coursera.org/learn/learning-how-to-learn Problem Solving and Learning can be made into a really good feedback loop -- i.e. you can "solve the problem how to learn faster/better" and you can "learn how to solve problems better"... Using LightBot (https://lightbot.com/) it's possible to teach all of these ideas together. I.e. explain how people feel frustration, how to deal with it. Let them self-monitor how frustration builds and how they react to it. When getting stuck, show how scribbling on paper helps. *Level 1* Here we need to learn computational thinking, for better or worse. LightBot really helps here as well. 0. Syntax and tooling or "we need to communicate with the computer" 1. Meaning of things or "computers are very stupid" 2. Making things concrete or "mapping your mental model to code" 3. Progams do what they do or "computers are still stupid" 4. Reaching the goal or "learn the process not the end-result" 5. Limits or "we are stupid" With this knowledge people should be capable of writing programs 1000-5000LOC, i.e. things that don't require architecural descisions. Extended notes, but old: https://github.com/egonelbre/spark/blob/master/basics-of-programming.rst *Level 2* This is mostly leveling up your skill and knowledge 1. Read code 2. Write code Pick some: 3. Algorithmics (http://www.algorist.com/) 4. Web programming 5. Machine code 6. How memory works 7. How floating point works 8. Concurrency 9. Few more languages ... *Level 3* Here we have skills that would help you to build 1MLOC+ programs. 1. Learning different tradeoffs 2. How to analyze tradeoffs between different solutions 3. Writing some real programs with someone reviewing 4. Process of writing large program or "gradual stiffening" For 2. there is a really nice exercise - write at least 10 different ways for converting temperature units. Mentorship is an essential part, i.e. getting better people to review your code is the best thing that can happen. 4. is currently incomplete and least formulated... I only have ~3000 pages still to read and ~5 projects to write :), before properly starting to write about it. Hopefully this helps somehow... *Sidenotes/Disclaimers:* *I haven't had a good chance in teaching this way, so there might be some essential parts missing. However one-on-one sessions seem to be promising. I'm aware that class-room situations are more difficult. E.g. people will learn these at very different speed and trying to homogenize it, would always frustrate some... it's better to let people advance at a different pace.* + Egon On Tuesday, 19 July 2016 18:16:05 UTC+3, Matt Aimonetti wrote: > > I just wanted to point out a post I published today talking about the fact > that we are often leaving new / less experienced Go developers high and > dry: > https://medium.com/@mattetti/go-is-for-everyone-b4f84be04c43 > > I'd love to see what you all in mind to help new or junior developers. > Maybe share some of the pain points you've experienced or seen (for > instance setting up the Go path, finding resources to get started etc...) > I'm thinking about a bunch of very short posts on basic topics and maybe a > real beginner tour of Go. We are going to do a beginner night next month at > our LA/Santa Monica Go meetup and hopefully better understand what the > current pain points/blockers are. > > What do you think? > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
