Just realized one very important point, that I should have highlighted: In the initial Level 0 and Level 1, helping and googling must be very controlled. The important part is teaching the process of solving problems and writing code.
While teaching, if there's an obvious syntax error, you should not point it out, but rather teach a process that helps them find it. Not letting them find the problem has a negative effect for solving more difficult problems. In other words, you've just let them skip learning "dealing with frustration" and "process of finding bug locations" on small scale. At all costs avoid giving them the answer. If necessary make up a similar situation and explain how you would solve it there, but let them solve the original problem. Only explain the process. *Once they learn the process, you can give the answers to move faster to the next step ... how ever, it prevents people from practicing those processes... so then use it with caution.* Now in Level 2, it's necessary to teach proper Googling skill and how to get help etc. Then you have learned the foundation so there's less problem with giving a direct answer. + Egon On Wednesday, 20 July 2016 10:56:28 UTC+3, Egon wrote: > > 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.
