Ask HN: How to Teach Coding? - <AUTHOR> I finally did it and I get my first Trainee.
I already teached coding to internships for a few weeks. But this time I have three years to share my knowledge and grow with him.
I already checked methods and stuff online like pair programming, visualization of data flows ect.
But what I would love to know is, what has worked for you guys on both sides. Sharing knowledge and get trained.
I want to be the best mentor I can be and I want to proof that this is a thing I can do good and continue doing it the next years of my career.
So, what helped you to train others or receiving knowledge? <comment><USER4> 1\. Tell them what to do but do not tell them how to do it. (Just give a few pointers otherwise they'll be lost.)

2\. Give them a playground to fail - Offload any non-business critical tasks and let them make mistakes. No one I know ever learnt programming without making any mistakes. Immediately tell them about best practices and how to avoid such mistakes in future.

3\. Show them the impact of their work - There's nothing more motivating than seeing the impact of one's work.

4\. Build curiosity - Answer as many questions as you can answer. Admit when you don't know any answers and start looking it up on the web right in front of them. People pick habits by looking at their superiors.

If it's absolute beginning to programming, this video is a great way to show how difficult it is to teach a machine to do something and how clear instructions can help get things done: [https://www.youtube.com/watch?v=cDA3_5982h8](https://www.youtube.com/watch?v=cDA3_5982h8)

<comment><USER5> I have never liked the "make a sandwich" task. It sets people up for failure, because the teacher can always take things literally enough to make the student wrong. (For example, when given the instructions: "Take out two slices of bread", the teacher can rip open the side of the plastic bag rather than use the opening.) Some students end up with the feeling of "If I can't even explain how to make a sandwich, how will I ever be able to tell a computer to do anything?"

Here's an exercise (not sure where I discovered it) that I use at the community college level: [https://www.youtube.com/watch?v=meSK1rn2VbA](https://www.youtube.com/watch?v=meSK1rn2VbA) It has the same elements of analyzing a problem, breaking it into steps, and making sure they're in the right order; but it's set up for students to succeed.

This exercise is very effective when you put the students in groups of two or three to work on it.

<comment><USER6> Sounds like this make a sandwich exercise is rather good for understanding the issues with gathering software requirements; it confronts the students with creeping requirements, before they even know how to code.

Coding should probably be taught with a background of requirements that are precisely given in terms of the abstractions that are being used in the code. So that is to say, the problem itself doesn't have to be something abstract (like a number-theoretic computation); it can be connected to something in the real world. But the representational mapping from that domain to the computer should be established by the teacher, so there is no irrelevant fumbling about the requirements.

In the case of the sandwich, we should provide a procedure which somehow takes the slices of bread out of the bag. Similarly, we provide all other necessary procedures, and only those procedures are to be used. Then we eliminate questions about the detailed requirements about what those procedures themselves do, like can the bag be ripped, or does the removal have to be tidy.

A good domain for teaching coding might be game playing (cards, etc). People understand that the objects used in games are abstract, and that certain details do not matter to the game, like the exact shape of a rook in chess or its precise placement within a square. It could just be the letter "R" in an 8x8 grid of characters (with "r" being the opposite color).

Symbolic games are basically a form of mathematics that is instantiated in the real world whose abstractions people readily understand. Moreover, they have a point (to have fun), so the "why are we doing this" question is settled.

</comment></comment></comment><comment><USER7> I try to get people to understand that coding is writing logic. That is actually two separate skills: writing and logic. Many people want programming to be something that it isn't, possibly something glorified by games or media. That said you can generally detect potentially great future programmers without talking about any code or coding experience.

When teaching people to write code I try to get them to practice thinking about writing instructions. Actually practicing their writing skills. The important part of that is that they struggle through the thinking process of finding a solution as a series of pieces and that they communicate that solution clearly.

What I want them to avoid is them thinking about programming as lego pieces they put together, because that becomes their expectation and reality. The problem with this is that when a person limits their expectation to putting things together and they move from education to employment they tend to be really good at configuring things and really bad at writing original code.

<comment><USER8> 1000% this. Just because LEGO pieces fit together doesn't mean they take the form of a cohesive argument. It's actually concerning to me that there is too much focus on practical coding skills in e.g. high school, to the detriment of essay-writing and critical thinking in non-technical domains. The "five paragraph essay" is actually fantastic preparation for "defensive coding" - <USER3> you can write good counterarguments, you can write error handling code.

<comment><USER9> Another good writing task for programming is to write down a recipe (properly). However, to do it off-the-cuff would mean you need to know how to cook - so maybe not the best example.

Something that could be done is describing the task of making coffee, or a sandwich, or describing your entire morning routine.

Focus on teaching the details - let the students try it first without any prompting other than telling them to try it. Then select one at random and go over it showing where certain details are missing.

For instance, they might say "I brush my teeth, then I get in the shower" \- but what they really did was "brush my teeth, turn on shower, wait for a particular temp, until that temp continue brushing teeth, when temp is reached, stop brushing and get into shower".

Of course, even that isn't detailed enough (do they still have their clothes on? maybe those should be removed before getting into the shower?) - but it would show how you have to think in such extreme detail for programming, plus the whole "control logic" and "logic flow" of such a description.

Recipes are like this too, but knowing how to properly write one does require cooking knowledge, which many people don't have. But everyone (usually) has the experience of "getting ready for work" or something similar...

</comment></comment></comment><comment><USER10> I teach coding. Here are some of my insights:

— Remove the instrumental barriers first. I start with teaching the basics of UNIX shell, navigating the file system, processes, editing files etc. Students will move much faster if they do not stumble on basics.

— Continue with the notion of system libraries, dependencies and teach how to use system package managers to install stuff.

— Explain what APIs are and teach how to call them manually for some useful results. E.g. use curl and Twilio API to make phone calls.

— Write simple scripts: call multiple API endpoints, use variables to store intermediate results, use simple loops. I hate bash, though, so any other language will do.

— The lowest-level API is machine code / CPU instructions. Write simple assembler code to calculate something, translate it to ASCII string (explain how symbols are encoded in ASCII and Unicode/UTF-8), and package it to the boot sector / boot it via QEMU.

— Move to C, learn about data types, arrays, pointers, etc. Use some fancy GUI library for additional immediate gratification.

<comment><USER11> Interestingly, I learned to program in a completely different way. When I started in 1979, the computer terminal where I learned could only run BASIC. There were no directories, just BASIC. We had one book that could teach you most of the commands, IF--THEN GOTO, SET, PRINT, FOR, NEXT, GOSUB. There was no WHILE statement. I think I spent months playing with those before learning about arrays. The biggest breakthrough was finding a Star Trek game in BASIC. I was amazed at what could be done with such simple commands. After a year or two, my father bought a TI 99 4A computer and I got a Commodore 64 about a year after that. You could write assembly code on the C64. I learned about ASCII file input and output in 1982. I don't remember learning about directories until I got to college in 1983. I don't think I used any libraries before 1986. (I did use punch cards in 1982). I think the first time I saw UNIX was 1990. I don't think I saw a package manager before the 1990's after I had been programming for over 10 years. The first time I did object oriented programming was about 1994 I think, C++. I got an MSCS in 1996.

<comment><USER12> I learned how to program BASIC in the early 80s from magazines, when program source code was printed out and you had to type it into your computer verbatim. At some point, you switch from being a typing drone to trying to understand what you were typing.

The worst part was when there were bugs in the printed source code. If you didn't know how to fix it, you had to wait until the errata showed up in a future issue of the magazine.

</comment></comment></comment><comment><USER13> There's the entire field of CS Education, besides all the initiatives outside of that. There are also off-the-shelf intro textbooks, such as: [https://htdp.org/](https://htdp.org/)

If you have a trainee in a work context, where they're expected to soon be productive in the particular tools your company uses... get them started with those tools, point them to good instructional material, give them appropriate work assignments, and give them lots of mentoring (talk with them at beginning/milestones/end of each assignment, walk them through things they need to know that aren't in the materials, find the right balance of being available for questions but also getting them comfortable finding answers, etc.), and also get them started familiarizing with your organization's stuff and examples of good practices (e.g., reading select internal docs/code, monitoring Git commits, etc.). You'll also notice things they're doing or not doing, that you didn't think to mention before, so you can give tips as you see them. And it's important to be encouraging, not discouraging, even if you're encouraging them to work harder/smarter at something.

<comment><USER13> Another suggestion: If they're a team member, treat them as such. When there's things to review, like a design document, include them as a reviewer, even if they're brand new and have no experience.

At my last long-term consulting arrangement, I helped hire and onboard a developer who was a new college grad (who'd had military work experience, but in a different STEM area). Because the team was growing, we needed some lightweight process tweaks, and I decided to involve him as a peer in determining those tweaks. (Secondarily, I didn't know what his military experience had been like, and this new role required him to be comfortable speaking up.) On a couple of occasions, it would've been easier for me, had I declared myself benevolent dictator on the decisions, but I think the peer treatment from the start worked out well for the process, and set a good cultural tone.

<comment><AUTHOR> This is a good idea, we have to build so much swim-lane-diagrams, why not including him.

He only can learn from this.

Thank you for your feedback

</comment></comment></comment><comment><USER14> To teach programming is to take on the following roles:

1) Information provider - search for suitable materials. For example, if the student finds the materials not engaging, it would be your role to find different material that suits the needs of the student better

2) Problem provider - this is extremely important. It is difficult, for example, to care about loops when all the textbooks show only that--loops in isolation. Your role is to construct or find problems that the student can solve with their new knowledge. Generally, the challenges/issues should be one level above the student's knowledge, so that it pushes them forward.

3) Guidance role - it is your job to analyze the students' motivation behind learning how to code, and provide suitable path. E.g. if one wants to become a web designer, it might not be the most suitable to start with assembler. You should also course correct, e.g. when you see a web designer to be struggling with data structures, it is absolutely appropriate to make a detour into some CS territory with data structure classes.

But, of course, most of the learning does the student him or herself. You can't teach anyone anything ever. You can just be there for the student, to help them and guide them.

My 2c as a self-taught developer.

<comment><USER15> This is very good advice, especially number 2. Teaching programming, especially to a trainee, is a great opportunity for project-based learning approaches. Give your person problems and tasks that are difficult enough that they have to learn something to do it, but not so difficult that they'll just bounce off of it. Much of being a good teacher is learning to quickly calibrate tasks like this.

Provide help when they need it (critically, also teach them to recognize when they need help, most novices are pretty bad at this), but don't over support (if the student isn't reaching, they probably aren't learning).

Pair programming can also be a great tool in general for learning (with you playing the role of metacognition [1] for the trainee, which again is notoriously difficult for all novices - even experts in other fields have a hard time being metacognitive in new ones). The key there is again: don't prevent all of your trainee's mistakes as they happen, but try to guide them toward noticing them and repairing them before they get too stuck. The other part of teaching that's a learned skill is determining how much struggle / wheel-spinning is productive for your particular student.

All of this is with the caveat that YMMV - people learn best in different ways, but productive struggle and real tasks are really good starting points for most (and way better than lecturing).

</comment></comment><comment><USER16> Figure out something (meaningful?) they could build in that time frame, but make sure that project entails as many "basic concepts" as possible. Something where one concept / piece builds upon the next and there's a defined end goal that they can see / imagine.

No one wants to hear "Ok. Now delete that folder and let's start over on this other concept" especially when that new concept is likely using the old one, etc. That type of (online) training annoys me.

I would think there's got to be a good book(s) on basic CS / programming concepts. Get them that book, as something they can reference / explore when you're not available. Having a mentor is great but being self-sufficient __(and having your self-esteem crushed) is also an important skill.

 __True story. In college my advanced calc (?) prof walked in on the first day and (more of less) said, "I'm not going to teach you. There's the book. I and TA's will be here to answer questions, etc." We (i.e., the students) left that class swearing up a storm. What's he getting paid for?!?!? etc.

Long to short, it was one of the best things that ever happened to me. Up until that point all my STEM learning was taught to me. I had never imagined I could read those bloated text books and teach myself. Let's just say that for the remainder of my college career my attendance rate for my STEM related classes was cut in half, sometimes even lower. I didn't need to go to class. I could teach myself.

It might a common HN trait, but I don't think it's true for a lot of people.

</comment><comment><USER17> There's a lot of knowledge we take for granted when programming. A lot of problems in coding come from having an inadequate mental model, so I always try to explain how code runs on the machine as my first lesson.

I'll give an example, to an experienced programmer you can look at code and tell what sequence the lines are going to run in and what sequence the expressions will probably be evaluated in. To a new programmer this isn't obvious and they can make mistakes by making assumptions based on the code running at the same time and having an inaccurate view of the state at different points in a program.

I also think people dont emphasize how to find solutions to problems enough. Most time spent coding is spent trying to find someone else's solution to something and figuring out how to apply it to your code. For example, a strategy like searching on google with site:news.ycombinator.com or site:github.com is not as obvious as you might think it is. Everyone has strategies for finding libraries, tutorials, and docs you should try to share them with students.

<comment><USER9> > to an experienced programmer you can look at code and tell what sequence the > lines are going to run in

Unless the code/language is asynchronous - which requires a different mindset. And/or event driven - yet another mindset.

I've seen developers struggle with both; I know when I first learned event- driven programming (via Visual Basic 3 - yep, that long ago) - it was a different thing to think about, but it eventually became second nature. Windows 3.x cooperative multitasking helped to make it clear, too).

But yeah - they have to start somewhere, and sequential processing is the standard entry point, because most people understand cause-and-effect in the real world.

Technically, they also understand asynchronous and event-driven models, too - because both are real-world things as well - but they really don't think of them that way - or at least don't use those terms (if they think about them at all). Figuring out what terms they do use for those type of things might be key in teaching them such concepts...

</comment></comment><comment><USER18> What prior knowledge does your student have?

In my experience, what helped me the most when starting to learn how to code was having a motivating problem that I wanted to solve. Why do I care what a for-loop is if I can't see how it is even helpful? Many tutorials have examples when teaching, but I believe that the problem should come first, and act as the glue between the basic ideas that will be introduced. Then, the mentor's most important role is to guide the student through best practices, such as style and performance.

<comment><AUTHOR> His father is a coder too and he is making a specific IT school here. So he comes with basic knowledge about data structures, databases and how code is build.

Yeah, real world problems are what my favorite way to teach particular ways of building things. No one wants to build the 7th calculator.

Thanks for your Feedback!

</comment></comment><comment><USER19> I'm in a well known bootcamp in SF right now (after flirting with idea for a few years and finally making the timing work). Having hit the half way point, I would say the day-to-day format has been very conducive to learning, at least for me.

Basic structure is: -nightly readings and videos on a new concept -a homework on the readings -a quiz on the material

Next day: -a half day lecture on the new material from the previous night. -a half day of paired project work on the material.

I think the reason why it's a pretty effective format is because it forces you to struggle on your own the night (homework and quiz force you to do something and not just read along) before some new concept is taught, meaning you're not going into a lecture completely cold. Then in the lecture you can solidify your understanding of the material, ask questions, follow along demos, and then really have things sink in with the longer, more difficult project work that same day.

<comment><AUTHOR> I never experienced a coding camp (and i don't know if this is a thing here in Europe).

But that sounds reasonable and i just made a note about this for my plannings.

Thanks for your insights.

</comment></comment><comment><USER20> Three years is a long time. I've taught bootcamps where I had to do it in 4, 6 or 12 weeks. Three years is luxurious.

Here are my initial thoughts:

\- For a timeframe this long it's less "let me teach you" but more "let me guide you in your own learning." If you view this as only imparting knowledge I think you will burn yourself out.

\- I would help them formulate a curriculum, keep them on track and make them push themselves. Anyone can learn a lot in three years, but with your guidance they hopefully learn 2x, 3x, 5x or even 10x what they would have learned alone. Ask yourself this every time you check in with them "How can I speed them up? What can I teach them now that will save them time?"

\- I would periodically check in and asses what's been learned and what's left to learn. I would also reassess if the curriculum is working or needs tweaking. I would be open to changing things up periodically. Maybe one year is project based work, maybe another focuses on reading classic texts. Three years is a long time to do one thing.

This sounds really fun, good luck and have fun!

</comment><comment><USER21> Don't teach coding. I haven't come across a discipline yet where:

1/ there's such an astronomical disparity between students 2/ where it's more of a requirement to be an autodidact.

All the good devs i know just pick up books and start reading. If you look professional devs out there, if they all taught themselves how to code, then one must wonder whether you can even produce a good coder by teaching them directly.

Instead, pointing them in the right direction on their learning path at the right time is probably going to be hugely beneficial.

I know for myself i wish i'd spent more time learning than building things. It's been useful too building, however my ratio was off by quite a bit.

<comment><USER22> It's possible that the state of education, documentation, and general programming know-how was so bad and fragmented before and so almost everyone _had_ to rely on some self-learning.

<comment><USER23> it is still fragmented. you can't point to a definitive source for "how to be [x] developer". you can just give them a roadmap at best.

</comment></comment></comment><comment><USER24> I also just had my first intern. But I also taught at the college level and have had a few employees. A few suggestions to add to the already good lists here.

1\. Tell them _why_ you do something.

This helps with cognitive load while learning, and helps them overcome some mental stress when investing in new techniques/methods.

2\. Provide real code examples that work, and demonstrate them.

This is analogous to hearing a song played when learning to play a musical instrument. It's really hard to convert notes to music without knowing how it is supposed to sound first.

3\. Be patient and ready to describe things from multiple angles.

I noticed I was more patient with people I have little time with. The more time you spend with someone the harder this gets. So be prepared for this.

4\. You are likely to be wrong, be ready to learn yourself.

Every class I taught something slightly off, or made a mistake, or simply a student had learned some obscure thing from the internet that I had not learned myself. I learned alot by teaching others, but also by screwing up in front of an entire class. Be humble, expect to be wrong from day one, and be grateful when you are taught something new from anyone from any skill level.

Note: knowledge is easily attained these days, understanding why you use one thing and not another is not as easily learned. When an old experienced codger on the internet say to do something a certain way, take it really seriously and study why, then you can pass this on as well.

<comment><AUTHOR> Nice additions.

I am self-tought and i made the experience that being wrong helped me to evolve. I guess i grinded the gears of many people in bulletin boards or irc channels in the moment i came by with my naive solutions.

But getting corrections and new insights helped me to grow. This is something i want to transfer to my trainee aswell.

I'm thankful for your thoughts :)

<comment><USER24> I would also add that it's important to learn that what you are teaching now may be considered an anti-pattern down the road. Or that the framework de jour is going to become tech debt in 5 years.

So it's really important to distinguish between long term viable fundamental skills/techniques from current best practices.

A specific example of this is I started using javascript a lot, then Prototype.js then jQuery came out (which did not litter the core objects with protoype inheritances, which is better...) and now back to vanilla js now that the browser incompatibilities are minimal. The only long term viable skill here is coding in general, and vanilla js, everything else was a fad of sorts.

Have fun teaching, I really enjoy this part of my work.

</comment></comment></comment><comment><USER25> In addition to the other suggestions here:

Ask the student what they want to build or achieve.

Like if they want to make a game, or an app, then sit with them to code the simplest form of that, step by step, starting with the player data model (score/HP/ammo), then the HUD, and so on.

You may even write the first version all by yourself while they watch, accompanied by your live commentary.

Let them know that development is generally about sending messages/commands to things (APIs) that send messages to other things (CPU/GPU) on your behalf, so they can understand early on that coding is as much about SDKs and frameworks as it's about languages and platforms, and the ways of talking to/between them changes across APIs, so one of the most important skills is _learning how to learn_ ; to figure out how to dig through all the different ways of achieving the same result.

Tell them they can generally make things easier by putting in more intermediary messengers between themselves and the screen: Dev » Unity/Unreal/SpriteKit » C#/Swift » DirectX/OpenGL/Metal » iOS/macOS/Windows » App Store/Steam » Player

and they generally get more control by removing the middlemen, but if they change a layer in the chain they might need to relearn how to talk to all of them.

</comment><comment><USER26> Code reviews and more code reviews. In both directions. Walk him/her through your stuff, explaining "why" as much as "what" and "how". Also, give your trainee a small coding task (ideally, one both simple and also similar to something you've walked them through). Review their stuff together, line by line, providing feedback as you go. Strive for some small wins they can build on to generate confidence. If there's an opportunity to refactor, that can be very instructive too. Also, take the time to sit w/ them and ensure their dev env is in good shape so the tools don't get in the way. Linters and the like can provide solid guardrails. Also, provide guidance on how to look things up (e.g. "mdn" search prefix, and bookmarks for your preferred reference materials). Finally, since your novice developer as yet has no bad habits to unlearn, strive for best practices in everything you do together (eg TDD; in fact starting w/ tests might be the best 1st step after the dev env is set up). /$.02

</comment><comment><USER27> First, I noticed that I had much more impact teaching things I had done recently (even if I know the theory). So when you create your exercises, try to solve them in order to 1. check the difficulty and 2. know where your students will strugle, what are the main pitfalls you will have to explain them or give them more hints.

Second, a session should be composed of a few exercises with immediate feedbacks / rewards (something quick to code but with enough notion to understand the subject of the day). Then build the momentum toward more complex exercises. The last exercises should be a bit more advanced than the current expected level of your students.

When I was a student, I had this structure were we had a between 6-10 exercises to learn C in 30 days (even if we did not understand all of it under the hood) from nothing to pointers, circular list, object-oriented (with structure) C. I found out that even if most of the students struggle, some of them will try to solve all of the exercises. After many days, they had made tremendous progress and were capable to achieve all of them most of the days.

These students boosted the rest of the class for the next few years as we were encouraged to share knowledge and teach each other.

</comment><comment><USER28> I have mentored many junior developers through my career. And recently, started to train junior developers as a side gig. (Had been helping friends to get up to speed in their new jobs but wasn't charging anything for it.)

So these are the developers who already have basics of programming but they usually don't understand whole ecosystem around it. For example, many don't understand version control, server vs local env, etc. Normally, many senior developers get really frustrated when junior devs ask them about such basic concepts. I used to be like that too, however, I learned to be patient and tried my best to help them. And some of my teammates started to ask me if I can help their friends in other teams/companies.

So this is what I have learned about mentoring:

* Encouragement - Unfortunately, tech world if full of genius jerks. Many junior developers get discouraged by such behavior. A lot of time I find myself convincing them that they will catch up to senior devs eventually. Sometimes, I feel like I am teaching them how to manage their senior developers/managers instead of teaching them technical topics.

* Find out what their objectives are - Another big issue is that many developers have big egos and they would try to hide their ignorance by asking very specific question. If it's a senior developer, I would just answer the question. However, if it is a junior developer, I usually ask them what their end goal is and many times they are going down the wrong path.

* Let them ask you questions and then use search engines to find answer together, even if you know the answer.

* Code Reviews are great but you have to be sensitive towards junior developers. I usually make a small comment in CR and then meet with the developer to explain it further and to make sure they understand the reasoning completely. For example, many developers from non-English speaking countries have hard time understanding difference between verbs and nouns, and they name variables and methods which are hard to decipher. It is hard to explain that in CR but in-person much easier. Also English is not my native tongue so I also get criticised for my namings too still. So I can understand it can be hard to come up with a good variable name for non-native English speakers.

* Help them find good training material. You cannot spend hours training junior developers, so make a list of good resources to learn from and ask developers to review them. These cannot be 40 hour course, but something more narrowly focused on their current problem.

</comment><comment> din-9 Understanding that we all have different mental models, and that affects how we learn. Understanding my own vs my students' helped me to get them to understand what I was trying to communicate.

<comment><USER29> This in particular is massive. Some people like (and work well) pair programming, others want reading materials, others yet need videos.

Just being there to answer questions or help when they have issues can be a tremendous assist since it means they're rarely left frustrated by being unable to move forward on their own.

<comment><AUTHOR> Wow, thank you two. That's something i experienced before with my internships. One learned better while solving some atomized questions and the other one learned better in live coding sessions.

I am glad that i will start with only one Person here and i can focus on how he learns :)

</comment></comment></comment><comment><USER30> Logic was an important piece of the puzzle for me when I was learning. When I started my CS degree, I didn't have this, and some of the courses were extremely helpful in building it.

If you are a very math-oriented person, you might expect that people already know this. But it's not true. We are not born with innate knowledge of it.

I'm talking about stuff like basic propositional logic, maybe a little first- order logic, definitely some boolean algebra, and maybe some Hoare logic.

You might not have to or want to get too formal or hardcore with it, but it really helps to at least have some basic grounding in the subject.

Before I had that grounding, I would spend a lot of effort trying to get code working, but it was often a jumble that I couldn't sort out. The conditions in my if statements were a mess. My loops wouldn't terminate, or I couldn't figure out how to write them.

</comment><comment><USER31> Each person is different, honestly have a sit down with your trainee and ask how they have been successful in the past learning new skills. Some people like to read theory and understand it fully before ever putting pen to paper, others like to try and error out. If you put the wrong method in front of the person, neither of you will enjoy it.

</comment><comment> jerome-jh Remembering the very first course I received at 9 y.o. (logo with turtle) the pleasure came from seeing the actual output of the program on the screen: a drawing. Remembering my first C course at 20, whose program was a one liner designed on purpose for us to understand nothing: don't be afraid to tell "I cannot explain you that now" (e.g. why #include). Today if I had to choose a language/platform to teach coding, that would be the Arduino. Simple system, visible output, simple language although perfectly well formed C++.

<comment> jerome-jh Going on with my Arduino idea: when they have enough of C you can do some assembly. You can teach interrupt handling, the source of all concurrency on a single core, in C or asm. You can do communication on an unreliable link (2 boards & LEDs), sensor conditioning. A wheeled robot may help some students "seeing the world from the computer eyes", although they may be a bit too old for that.

Of course data structures are best taught in C on a desktop. Functional programming is certainly interesting but further apart from how a modern computer works.

During my studies I even did opcode programming on antic 8085 dev boards, with a 20 keys keyboard (hex digits, reset, run, memory up/down). You can't imagine how much fun that was, akin to woodworking or pottery. That certainly grounded a number of ideas on programming, that may look otherwise mystic to students.

</comment></comment><comment><USER32> If I could teach my younger self:

1\. Stop theorizing.

2\. Write lots of software.

3\. Learn from your mistakes.

[https://blog.codinghorror.com/quantity-always-trumps- quality...](https://blog.codinghorror.com/quantity-always-trumps-quality/)

Success comes when there is nothing left to learn from failure. Fail faster to learn this sooner.

<comment><USER33> I would only agree with the caveat that someone experienced should read your code, comment on it and improve on it.

I spent years slowly learning how to be a better developer, on my own. If someone had been there early on to tell me: "this is bad because X", I would have progressed twice as fast.

Programming at its core is very easy, building maintainable software is much harder. Knowing what to avoid only comes with experience, but much of that experience can be quickly transferred to you from someone who already has it.

</comment></comment><comment><USER34> I have seen classes full of disinterested kids learn by:

1\. reading algorithm flows 2\. following changes in variables for C code 3\. drawing their own algorithms 4\. implementing those in C.

repeat for a whole semester.

in the end, those who are really interested will pick up tooling and go ahead by themselves.

<comment><AUTHOR> I am lucky that he already have those coding basics and wants to learn. And i experienced in his intership that he came back the other day and said "i tried this at home, how could i do this better" and was all open for suggestions ect

</comment></comment><comment><USER35> Long time ago at uni I used to give paid coding sessions to fellow students from IT facoulty (I myself could not make it to study on IT as I was not super star in math/physics which is requirement where I live, but I was passionate about coding and self thought and playing with code since 13). They was coming to me with their assignments in various levels of advancement so we was going through whatever they already had, salvaged whatever made sense and explained why other parts was of no use. Then we completed assignment together with proper explanation where things come from. I often heard this: 'you just start writing' and my answer would often be 'data structure is the fundation, I want to test different ideas so I can land at the best of my ability as soon as I can'... This was nice time in my life where I had no clue about maintainability and quality of code :)

On another note I remember watching video on youtube where someone said that for them programming is solving a puzzle. This resonates with me as solving puzzles is something you enjoy, programming should be something you enjoy and not just use to make your living...

</comment><comment><USER36> Teaching is about learning together. Once you start teaching it opens up a whole other dimensions, where you look at problems from the other persons perspective, and you really need to have in depths knowledge in order to explain something simply. So don't think of it in terms of you teaching him, it's more like him teaching you how to become a better developer.

<comment><AUTHOR> Awesome, I already thought about that this will be a task I can learn a lot from too.

Thanks for your answer

</comment></comment><comment><USER37> I completed the MIT and Harvard introduction to computation courses on EDX. I did it for fun, but both turned out to be truly inspiring on the subject on how to teach CS.

It depends on what you're teaching though. If it's bringing a new hire up to speed what works best for us is to give them access to a portfolio of how we do things and let them hack away at a problem on their own. If they have questions we help, and their mentor makes sure they aren't stuck and afraid to ask.

The sad fact is that 95% of our learning curve is figuring out how the damn toolset is used, and it only 5% of what's hard is actually programming. I'm sure it's different if you're a PhD at google, but in our shop we rarely invent new CS concepts, so it's mostly about learning how to make tools work. We'll get people who know JavaScript and .Net who have no idea how to deploy it on our IIS servers, or how to setup the config file so only a specific AD group has access to a specific API, stuff like that. I'm not sure where it all went wrong, but it did.

<comment><USER38> sounds like you have a lot of programmers and little system engineers / 'devops' engineers. in my opinion it's a different kind of person who can fight environmental details into working with some programs (i.e setting up some environment / server and getting everything tested / deployed) than a person who can write the thing being deployed. Generally i think both have very different information to their disposal. Someone who makes a life out of tying things together, will know a lot of these 'things' he ties together, like ldap/ad,dns,okta,random_api_xxx,etc. where a programmer might know just as much sorting algorithm as and methods to make efficient linked data structures as this other person knows different apis and python modules...

<comment><USER37> What good is a developer who can't deliver outside of a debugging/development environment?

I mean, I get what you are saying, but who can afford people who are that specialised?

<comment><USER39> A lot of places. The role of "devops" not withstanding, develment vs operations is one of the first distinctions to specialize in.

</comment></comment></comment></comment><comment><USER40> Yes!

I've found the most valuable thing is often good, uncluttered examples. Docs are often focused entirely on the API's but don't have enough to show you how to use them, and Google/SO can be a rabbit hole of examples that are overcomplicated or misleading.

"Try something like this" (with comments) goes a long way.

So much of being a beginner is not having been exposed to patterns and techniques. They need to fill our their toolbox, and in doing that, make sure to walk through what the code does and why, since nobody benefits from cargo- culting.

Let's see, also...

1\. Teach interactive shell and debugging early. It's life changing.

2\. Make sure to assign them entire projects. The fastest way to burn out a beginner is give them a series of small tasks in code they don't really understand.

3\. Chill out on code review. Limit yourself to a few suggestions for each PR. If you offer two suggestions and rationale, they might say "aha, that makes sense" and remember that. If you offer 15, nothing will stick.

<comment><AUTHOR> Wow, thanks for your answer.

Point 3 is something I haven't thought of yet. During reviews I pointed on some issues, not every. But that was never something I had a specific reason for, I was just focused on what we want to learn in this lesson.

I will keep that even more in mind now.

</comment></comment><comment><USER41> 1\. Know your skill tree and teach using it.

2\. Start small.

3\. Allow plenty of mistakes.

4\. Resist the temptation of always showing a better way, best practices, or rewriting the trainee code.

5\. If you use magic, explain it without magic first.

6\. Setup tooling yourself, even on the trainee's machine. No time to waste with that. This must include a good IDE, with a good linter.

7\. Auto format all code, no time to waste on style linting and formatting advises.

8\. Git is hard. Don't forget to explain it again and again in details, dev is just not code.

9\. Testing is hard for the beginners. Write the tests for a while. Nobody can learn it all at once. Forget TDD for 2 years, this requires a lot of experiences.

10\. Force regular feedback. They won't come to you. Don't ask what's wrong. Go to see. And be nice.

</comment><comment><USER42> I taught a Python course to people with humanities and non-technical backgrounds. The thing that helped me was to understand what was going on in their heads when I said things like 'array' or 'datastructure'.

Those of us that have written a lot of code take these mental structures for granted; we easily manipulate them in our minds to discuss things. People that are new at this will literally have no mental model for concepts embedded in datastructures and algorithms.

Every subject has to get around this; I struggled with this when trying to move from single variable functions to vector valued functions. The most annoying thing as a student is having an instructor talk at you and not to you.

</comment><comment><USER43> The lessons should be straight forward tutorials that builds something relatively functional. This builds practical knowledge of capabilities and motivation. Then you teach theory to some of the basics as the practical knowledge grows. Then more complicated abstract theory as they progress.

As a teacher, you minimize roadblock time. Not eliminate, minimize. Let a student flop around like a fish to debug for a while and before they suffocate, you point out the problem. Also, answer questions or provide different strategies with their pros and cons.

If I can teach a crayon munching marine to dev this way, I'm pretty sure 99% of the human population that wants to dev can learn that way too.

</comment><comment><USER44> Constant practice and small achievable goals definitely help.

If you don't keep practicing, you'll never see the value in what you're learning and you'll quickly get fed up. Additionally you'll start encountering road blocks during your practice and you'll start becoming eager to learn if there's a better way to do things.

Small goals make learning more enjoyable. If you set out to make a MMO online 3D game from the start, you'll never do it. But if you make yourself a to-do list app, word/numbers/guessing games, a note-taking app, you'll enjoy these small wins and more importantly will be eager to improve them.

</comment><comment><USER45> A great strategy in teaching a subject is connecting it with something the pupil already knows and finds interesting. This reference or association makes it meaningful and can motivate them to learn more by themselves.

You can show them what of a superpower programming really is, now they can sense, process and affect things that are normally out of their reach. Let them create a thousand files, read an API, create a bot, crash the system and blink an LED.

They can automate many processes and solve new technical problems or create something entertaining. Maybe a new small website. Or a mod for their favorite game.

</comment><comment><USER46> Teaching Tech Together[1] is an incredible resource for learning how to structure lessons in a way that makes ideas stick. Highly recommend.

Commoncog has a nice general overview [2].

[1]: [http://teachtogether.tech/en/](http://teachtogether.tech/en/) [2]: [https://commoncog.com/blog/teaching-tech- together/](https://commoncog.com/blog/teaching-tech-together/)

</comment><comment><USER47> There's a lot of great advice here, so I'll just add one more thing. Don't let them get too caught up on tools and "setups". Sometimes beginners will expend hours just tuning their IDE. Use something like repl or just any text editor. At our bootcamp, we created our own platform to host Jupyter Notebooks, the improvement has been huge: [https://notebooks.ai](https://notebooks.ai)

</comment><comment><USER48> Don't teach them coding, teach them how to build things _with_ code. I do this daily for a living ([https://cleverbeagle.com](https://cleverbeagle.com)).

The speed at which I see people pick up concepts is much faster when focused on writing code to implement an idea they have. "I want to build a real-time feed like Twitter" is a lot more concrete than "I want to learn websockets."

</comment><comment><USER49> Real teaching is exploring, discovering, inspiring, reminding and pointing in the right direction. Not so much imposing a ready-made system of thought on others. It takes experience, and discipline to get to the point where this is possible without egos crashing the party one way or the other.

Someone said that finding good teachers is difficult, and that's true from my experience; but it 's a Sunday walk in the park compared to finding good students.

<comment><AUTHOR> True, he have to learn himself. But giving that directions and insights is something that makes me happy.

Well after reading your message, i just hope to stick in the "good teacher" category soon.

My feelings say i found a good student who wants to learn, so i have a rock solid base here.

</comment></comment><comment><USER50> > So, what helped you to train others or receiving knowledge?

Start with thinking about what it actually is you aim to teach. Are you trying to teach someone the ability to work on a web application in a particular language, or are you trying to teach them how computers work so they can work on anything in any language?

Once you've identified your goal you can work backwords from there to what your trainee already knows.

</comment><comment><USER51> Coding is largely a ruminative effort. The process itself is difficult to transfer directly, it's mostly mapped through communication.

Encourage their effort and guide them on their own learning path.

Learning is a two way street. For every concept that is new to them that they bring to you, discuss it with them and find something new for you to learn.

Teaching is one of the best ways to learn.

</comment><comment><USER52> Although there is a significant number of Negative Nancies here I believe it can be teached but, even though I know it won't be a popular outlook, I see it like learning/teaching blacksmithy. Sure there is a theory, like which metal to choose, which degree to cook and which hammer to build but theory gets you so far. You need to show how a sword is actually done.

The concepts of programming can be learned from the noosphere easily, the resources are there to learn but good practices are not. A teacher should pass these as well, in addition to "what is a variable" etc. stuff. And like any course, if the student doesn't actually work on the stuff on his free time it is worthless - another analogy can be a guitar course here. No matter who your teacher is, if you don't play it at home willingly... you won't be able to learn how to play guitar.

My 2 cents...

</comment><comment><USER53> Critically, think about what actually worked for you in your learning. And help your trainee have the same experiences.

I have found that many new teachers to get things across by sharing insights they had only after they understood a subject. But that high level understanding is the _result_ not the _cause_ of mastery.

</comment><comment><USER54> Try and constantly keep track of where the edge is of their comfort zone, and suggest adequate steps away from it in terms of work to be done.

Help them grow by venturing into unknown terrain when the time is right, show them the path when they are lost. Give feedback when work is done to help them stay on the path.

</comment><comment><USER55> This is my advice for someone who didn't success as a software engineering major in University but ended up making a career out of it anyways.

Focus more on the concepts and less on the syntax. Have the student make up their own syntax for the concepts. That will verify they know the concept.

</comment><comment><USER56> I am of the opinion that you don't teach anything, it's the person that learns something.

So, I'd go for what others have already mentioned. Learn about the person, how they are, how they learn better, what are their interests.

Find something they like and enjoy, so they are motivated in learning.

Be ready and available to answer questions and adapt to their rhythm and needs.

Prepare materials and different options so they can chose their path as they go.

Facilitate them changing their mind, going back and forth, making their own mistakes.

In my case, for example, I learn by doing, and pair programing with somebody helps me a lot, but other people might prefer having a theoretical background first and will want to read a book before diving into coding.

EDIT: adding paragraphs for clarity

</comment><comment><USER57> It depends. What is the situation? You've mentioned internships so I am guessing it is business? What is the end goal?

I am far from a programmer but what I have learned has been through exploration. Here's a web page. how can I make a userscript to get rid of that nag screen? (I know I can use a popup blocker or something but I'm trying to learn) I want to make a little browser addon. let me find one that does something similar and look at the code. Search for the particular problem and find answers.

From the comments below it sounds like this person is farther along than that (probably farther along than me) but I think learning how to find answers is one of the best life skills.

<comment><AUTHOR> Well, he has the basics like data control structures, database usage, a little bit OOP. I think the missing link is how to build real world processes with it.

I'm sure we will find basics that are missing and will have to fill that with knowledge, but we have a good starting point.

By what you said above, don't underestimate yourself there. Building scripts that touch real things to make it better working for you (and others) is a great step on the journey to write good code! Thanks for your feedback :)

</comment></comment><comment><USER58> I'll refer to the talk [0] from last congress about the german sibling of the high-school version of MIT's How to Design Programms [1]. It's about teaching a functional-first style of abstraction with a _very_ rigorous structured approach to writing the design. I wish I'd started with HtDP instead of Pascal/Delphi (later Java), but it's the best approach I see if one wants to quickly be able to start a project of non-trivial complexity without it ending in a horror show of technical debt and/or frustrating bugs one doesn't even know how to analyze/tackle. If a slightly above average (1-2 sigma IQ, aka 120+-10) 6th grader isn't scared of the complexity, it should be possible to rely on the urge of curiosity to get said child to continue being teached by oneself. While I applaud the use of Racket for this teaching, it unfortunately scares off many who believe that companies prefer code-monkeys who can hack stuff together within Python's ecosystem. I know that, with some connections, it's easy to start with these functional skills in a company that has tasks that are suited for this approach, as well as senior engineers with some functional skills (enough to grasp what the new hire created). A good manager can let someone with no industry experience work on a well-defined component that takes 1~3 weeks to design and implement, with next to no micro- management. It only works though if the new hire is skilled in designing software, which HtDP has as it's main goal (it's even in the title). I'd hire a newbie self-taught with HtDP after testing stochastically to verify that he/she actually worked and understood all of it with just one 1~4 day in- office real-world task to test if the learned things compose into actual wholesome software design skills. I'd not like one who learned Python on his/her own and now has 1.5 years full-time experience designing&coding Python. Not without some specific testing to judge the quality of their design skills, which btw. is a far harder test than randomly sampling concepts of HtDP with short excercises similar to those in the book itself, followed by the mentioned few-day practice test. HtDP gives me the confidence to assume these few-day results scale to projects that take months, after just about .5~1 year of experience with projects that take a few days to weeks each.

[0] [https://media.ccc.de/v/35c3-9800-how_to_teach_programming_to...](https://media.ccc.de/v/35c3-9800-how_to_teach_programming_to_your_loved_ones) [1] [https://htdp.org](https://htdp.org)

</comment><comment><USER59> The best trainees I had were the ones who trusted me.

Sometimes it is hard to make a point about counter-intuitive procedures, like writing tests and assembling tests datasets, or setup logging, or ensure that dev tools are properly setup, before jumping into the code. It requires a leap of faith.

I had the best results when they were willing to take this leap of faith, so my suggestion would be to start by building trust.

As a trainee, I was willing to trust my mentor only when he showed effort in trying to understand my strengths and my limits. It never worked if they did not sat down with me with a "let's talk".

</comment><comment><USER60> How much experience does your PFY (trainee) have ? and are they doing an Aprentiship?

<comment><AUTHOR> Yeah, it is a 3 years apprenticeship.

He already has some knowledge because he visited an IT focused school here in Germany and his father is a coder too.

So I don't need to explain loops, or if statements and can go a bit further in logic and processes

</comment></comment><comment><USER61> People have good answers, here is my 2 cent opinion. (1) Accept that not everyone can be good at programming (as many other things). (2) Do your best. Also learn what not works for what type of people.

We need people like you. All the best!

</comment><comment><AUTHOR> I'm not able to answer all your comments right now. But i want to let you know, that i read all of them and i love your feedback.

Up to this moment i learned that going with real world examples is the way to go. Since i work in a software department of a real world company and mainly code Inhouse solutions, i am sure that i can provide a lot of them.

Beeing available for Questions and Feedback and provide Learning Material and doing sessions about technology and patterns, before they are needed to solve a problem is the next thing i noted down in my plannings.

I am very thankful for all the Feedback and can't wait to get more!

</comment><comment><USER62> _It depends on the student._

Don't make assumptions. Observe and test them frequently. How you should teach them will be driven by this, and nothing else.

Btw, I ran a tutoring company for 8 years with over 6k tutors.

<comment><AUTHOR> Awesome. Yeah i can not assume that everyone is an autodidact and teaches himself.

I will follow your suggestion.

Well, over 6k tutors sounds like you found ways to guide people successfully through the process.

My Question about this is, was peer-programming a standard tool, or just plain code-reviews?

<comment><USER62> With regards to peer-programming, or code-reviews, I don't think I could comment. Personally I am a firm believer in test it, and see what works.

This is the main benefit of 1-1 teaching. In a class room setting you can, and perhaps should use "recommended techniques", but 1-1, just do what works for your mentee. Anything you read about benefits of peer-programming or code- reviews is just an idea, which you should be able to verify very quickly with your own student. This trumps everything you might read.

You might find one method works better all the time, or you might find one works better in some situations.

If I may elaborate: What I believe you are teaching your student, first and foremost, is the _ability to observe themselves_.

In fact, you may never need to "teach" them anything, if they begin to understand the difference between good and bad, better and worse, themselves, they are well on the route to becoming an autodidact. You do this through testing - not just formal tests, but simple questions too. Your aim is to develop the questioning ability in the student themselves.

I like to think of these analogies: A painter's ability to _see_ is the foundation for their ability to paint. A chef's ability to taste is the foundation for their ability to cook. _Both the eye and the palate can be trained._

</comment></comment></comment><comment><USER63> Here is the lesson I gave a friend at a bus station waiting for a bus. First explain how a computer works in very basic terms because most people don't know. Don't assume they know how a cpu, how memory, or their screen works, even basically. They know none of that. Assume they think a computer is a magic black box.

Then using the same terms you used to explain how a computer works, sort an array.

</comment><comment><USER64> I have little experience with teaching but here are my 2 cents: What I observed is that at some point any new developer grows in ego and starts to question. So it's better to absent from teaching and let your pupil do something incorrectly on their own - if they fail they will learn a lot more than when being instructed to do something properly right from the start.

</comment><comment><USER65> Once they've got their feet, make sure you continue to offer thorough and critical code reviews until they're well settled.

</comment><comment><USER66> In addition to the myriad wonderful sources of online learning. Such as The Coding Train and Lambda School. I recommend an intro to the nascent discipline of "Product Design". Ideation, creative problem solving, and learning to iterate user feedback loops are very much indeed teachable skills. Best of luck ;)

</comment><comment><USER67> Has anybody found that, while coding is simple super to us, your less fortunate friends who are actively stuck in career paths like bartender/waiter/laborer with no path out don't find it as simple?

Do you guys think coding (low level, junior frontend developer type stuff) could be taught to anybody?

<comment><USER68> It could be taught to most people, but aptitude correlates with enjoyment - <USER3> they don't get joy from creating things, or they don't enjoy spending time in a world they have to use their imagination to fully see, then they will probably never learn to code. I don't know if you can get people to enjoy these things if they don't already by the time they're 25 or so. Everyone is naturally either more cerebral or more somatic, and environment can affect this balance, but once the brain is done developing there's not much that can be done to change it. In my experience, somatic folks take a lot less readily to software and try to figure out a way to avoid figuring out the actual problems.

</comment></comment><comment><USER69> Learn how to speak english really well!

</comment><comment><USER70> "One size fits all" is what you're looking for at school but you have the luxury of only having one person to mentor so they are a good person to ask first! They will tell you about their learning experiences, what worked and didn't work, etc.

</comment><comment><USER38> some guy told me to learn assembly. most valuable tip ever :d. on a more serious note, for me personally, programming is 'easy' to learn as long as you have an interesting project to work on. none of my 'mentors' ever sparked that interest in me as they always gave very generic excersizes or projects to practice in. It's a good idea to try and find what this person has an interest towards in programming, even if they might not know it themselves yet. creating that initial spark will drive them to learn more eagerly / efficiently. Like learning anything, if you enjoy it / have a good motivation, in any case it will go better.

</comment><comment><USER71> This is what I did. Extremely time consuming but does the job pretty well. [https://www.youtube.com/watch?v=DpIkP4OUlkY](https://www.youtube.com/watch?v=DpIkP4OUlkY)

</comment><comment><USER72> "If you want to build a ship, don't drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea." - Antoine de Saint-Exupèry

</comment><comment><USER73> We built [https://learnruby.bigbinary.com/](https://learnruby.bigbinary.com/) to introduce programming concepts using Ruby.

</comment><comment><USER74> \- Teach what a stack is, and its first-in-last-out principle.

\- Use stack to program how to escape a maze.

\- Teach Functional Programming, and optional OOP.

</comment><comment><USER75> I am trying to self-learn to code from a quite some time now, couple of years to be exact.

Can't really tell objectively how is my process going because my end goal is to be able to sit down imagine a thing a code it, not even close.

I get some concepts a lot better because I am constantly going back to the basics and start over, but still I struggle on low-level real world examples or mid-level problems from websites like codewars and etc.

Here is my advice to you. Make real world examples. What I mean by that, don't make a tutorial how to do a calculator or a weather app or something like that.

Instead, after each new concept or lesson that you make introducing something new about coding, create real life scenario examples with a minimum of 10 examples that your students needs to code. For example make them write 10 different functions that do something in different situations, and niches - business related function, pet related function, vegetables related function, cars related function, water related function and so on.

Why? It is very hard for a new person to grasp the concept of coding, most of the courses and tutorials do that - this is a function, they give you an example with function a + b that returns the sum and that's it. So when you are a complete beginner then you struggle to figure out a function that can applied in complete different situation like a function to sort a music playlist.

By proving different scenarios from the real world for your students and break it into small chunks after each new concept and lesson, it will be easier for them to understand better how you can use this skill in the real world. By making them repeat it with different examples will help them memorize it faster, and recall the solutions when they see something similar that they need to do.

Why this works in my opinion? I live in a small country and in high school I had to learn English. The teacher made us write every single new word that we were introduced to in our notebooks, like minimum of 30 times. Not only that helped to memorize the words and their right way of syntax but then you get to start using them in a more complicated sentences.

My English is far from perfect but I haven't taken any addition classes and it helped me a lot so far.

After all you are also teaching a language, with which you communicate with the computer, I think you can take a look at different disciplines and apply some really good practices to make you a better code teacher.

This of course is from my personal perspective like a super beginner that try to do that in his free time online.

Best of luck to you.

</comment><comment><USER76> For beginners, programs that output graphics are motivating. I have developed a browser-based programming language and environment that makes this easy.

[https://easyprog.online](https://easyprog.online)

</comment><comment><USER77> Make it fun. I've taught millions.

</comment><comment><USER78> I don't think programming is suitable for teaching. Everyone who is good learned it by himself.

</comment><comment><USER79> Teach them using Scheme and some other language, but begin with Scheme.

* explain what a variable is and how to create and assign a value to it

* explain what a list is

* explain what a lambda is

* explain and show if else loops...

* explain what a closure is

* show them how to build a struct out of closures

* explain what a class is

* show them how to build a class out of a struct

* explain what an interface is

* explain what a module is and why it exists

* now show your trainee another programming language

* point out that the other language contains more or less the same building blocks as Scheme

* talk about how to format code

* explain a bit the command-line

* talk about basic patterns, like builder and singleton

* talk and show how some pieces of code could be written in different ways and why one solution might be "cleaner" than another

* read some code on the internet together

* do an excursion to databases (sqlite)

* point out what your trainee knows and where he could study topics by himself further

* show them some tools you like and some other popular tools

* talk about what kind of languages, frameworks different programming disciplines a.k.a. dev-stacks are being used today (this is important to get a rough overview, as beginner, you don't know what you don't know)

Don't:

* throw a million buzzwords at your trainee

* don't try to be neutral, be opinionated about the topics/technologies you teach and tell your students why you think/act in a certain way

* don't teach a topic by going through every point in existence (this approach takes long and is confusing as hell, because it mixes too much information targeted at different skill levels into one stream of unsorted information - doing this is a major failure)

* don't do math (math is a sub-field, it is not needed to understand how-to program)

* don't show off that you are smarter by throwing too complex problems or solutions at your students

* don't reach for the limit, a relaxed mind is capable of more

</comment><comment><USER80> Getting acquainted with git could be a suitable task for him. Acquiring that skill should pay of well for him. These two links might be a good start: [http://gitimmersion.com/](http://gitimmersion.com/) and [https://jwiegley.github.io/git-from-the-bottom- up/](https://jwiegley.github.io/git-from-the-bottom-up/)

Best of luck!</comment>


Want a Diaspora invite? - <AUTHOR>

leave your email here. <comment><USER2> email@example.com

</comment><comment><USER3> email@example.com

<comment><AUTHOR> invite sent</comment></comment>


Ask HN: Know of a good Anemometer (Wind Speed Sensor) for a Computer? - <AUTHOR>

I am trying to monitor the output of our cooling system for the server room.  I already have temp gauges, but would like a sensor to indicate when the wall unit is no longer blowing.  It would give me a little more time to respond then the temp sensors.<p>I would like a Anemometer (wind speed indicator) that is able to hook via USB / Serial and be read by a UNIX (OpenBSD, OS X, etc.) box.  Ethernet would be fine also.  It has to be lightweight as I am hanging it off the ceiling. <comment><USER2> Could you make one with a piece of card taped to a microswitch ? You could adjust the size of the card and the angle of the microswitch until it detected if the fan was on or off.</comment>


Ask HN: How to be altruistic while working full-time? - <AUTHOR>

I'm a full-time software developer at a company based in Boston, and most of the work that I do is backend (python/mongo/data) and is really tailored to the applications we're currently developing
I'd really like to contribute to open source projects but I feel like i never have the time to, or that If I were to contribute I would be spending less time doing work and more time focusing on the projects I'm contributing to. You would say that I should write better code and release code as packages or blueprints, but most of the code is proprietary, we're still validating our products, and if I were to do that I would have to spend a lot more time to add more functionality that really isn't used in my application, and iterations would generally take longer.
My question is this: how do you give yourself time to work on open source projects? do you feel like contributing to open source is better (in some sense) than contributing to the growth of your own company? or how do you make contributions/build open source projects as part of your job? <comment><USER2> It sounds like you are trying to optimize for two goals:

1) Contribute to open source 2) Limit the amount of time you spend on tasks that don't contribute to your company

The solution seems simple enough. Examine the open source tools that you use to build your company. When you find problems, issues or inefficiencies in those tools, fix them. This will hopefully improve the tools and speed up your work on your company at the same time.

Alternatively, give the tools free press in your Twitter/Facebook/blog/whatever communications and hopefully you'll encourage someone else to contribute instead. As an added bonus, such communications may help spread word of your company.

</comment><comment><USER3> Unless you own the company, the work you do outside of work should contribute to YOUR growth, not the company's. Are you going to be learning something new and interesting? Building a portfolio to get your next job? Not sure what the answer should be in your situation, just something to think about.</comment>


Ask Entrepreneurs: Obama and capital gains tax increases - <AUTHOR>

The majority of entrepreneurs that I know are big fans of Obama despite the likely tax increases. This also includes a steep increase in capital gains.
I'll be the first to admit that I don't follow politics as closely as I should and I'm not trying to use HN for political debating...but I was interested in hearing other entrepreneurial minded people chime in on this.
As a hacker at a startup...why do I want a 25%+ capital gains tax if we're successful? It's like being punished for working hard and taking a lot more risk than the average schlep. <comment><USER2> If you're successful, a 25% capital gains tax is not all that onerous. What's the difference between $20M and $15M? Sure, it's $5M, but what can $20M buy you that $15M cannot?

Many entrepreneurs are much more concerned with _becoming_ successful, and having a reasonably tech-friendly politician in the White House like Obama would help. Net neutrality can generate far more wealth for entrepreneurs than the capital gains tax will take away.

Of course, then he had to go and nominate _Biden_ for VP...

<comment><USER3> _If you're successful, a 25% capital gains tax is not all that onerous. What's the difference between $20M and $15M? Sure, it's $5M, but what can $20M buy you that $15M cannot?_

After the fact, yes. But a 25% capital gains tax reduces your expected outcome by 25%, so if you are thinking of starting a business that within a year you suspect has a 10% chance of being worth $1 million, and a 90% chance of being worthless, your expected return goes from $100K to $75K -- and that might rule it out for people who are already making a decent amount of money.

<comment><USER2> Only math dorks go by expected returns. ;-) (Which includes myself, since initially I got into entrepreneurship because I figured "10% chance of $40M, 90% chance of 0 - hey, a $4M expected return for a couple years of work beats most other professions." Silly me.)

Utility functions aren't linear, and often aren't continuous. For most people, the increase in utility from $75k to $100k is negligible - it just means you can buy a fancier car, get a bigger TV, and have a few more lattes. The increase in utility from $100K to $15M is enormous, because it means you never have to work again. The increase in utility from $15M to $20M is, again, negligible.

<comment><USER3> As far as I know, people act as if they're math dorks, even if they don't make those explicit calculations (the same way your average basketball player doesn't know that f = ma, but can still apply f sufficient to give a particular m the a necessary to make a three-pointer).

 _For most people, the increase in utility from $75k to $100k is negligible_

Well, the savings rate is not variable enough by income for that to be true. It looks like people ratchet up their consumption nearly as fast as their income increases, so it is fairly linear. And if you consider utility to be the optimal bundle of goods, even rapidly diminishing marginal utility doesn't change the fact that you get exponentially more consumption bundles with more money, so the best bundle is likely to require a high income.

I still think that talking about the final outcome is not useful, since the final outcome is hidden behind the probability of failure. You can't talk about the incentive to play the lottery just by reciting the prizes -- the odds are important, too.

</comment></comment></comment></comment><comment><USER4> Here's why: <http://www.paulgraham.com/inequality.html>

</comment><comment><USER5> You are rewarded for being born in a country that has a rule of law, reasonably well-regulated securities markets, little chance of having governmant thugs take your successful company away from you just because they can, and you bitch about giving some of it back?

<comment><USER6> It's not about _how much_ tax you pay. It's about how the government uses it.

For example, in most of Scandinavia, the tax rates would make a typical American's eyes bleed. But what they get for it is: clean streets, low crime, great public transport, education and healthcare, and so on. Here in the UK we're taxed almost as much and our government is staggeringly inefficient and pisses most of it away. Filthy streets, knife crime, falling literacy and numeracy rates, a healthcare service that is as likely to kill you as cure you. If I relocated to Sweden or Iceland, I'd have no problems with paying their taxes. But I bitterly resent every penny that goes to the UK government.</comment></comment>


Machine learning can boost the value of wind energy - <AUTHOR> https://deepmind.com/blog/machine-learning-can-boost-value-wind-energy/ <comment><USER2> I have been working in the same field, quite a few years in my own forecasting company and then later on as a side project.

Not wanting to steal the thunder of Deepmind, but I feel should mention my site which is currently beta as in "works for a few electricity power load and supply forecasting scenarios" and quite well so. Also, it's out there, cheap and fast.

[https://ausblick.cryptoport.net](https://ausblick.cryptoport.net)

Unfortunately, it's only in German but the basic rule is:

\- upload an excel (or csv) file

\- wait a minute or so (for a typical dataset of say 3 years of hourly data)

\- get back the results

There are a few design rules how the excel file should look like, e.g.,

\- a date/time series per sheet (it accepts most English and European formats) and as many number series as you want (always use a decimal point instead of comma here)

\- one series has to have consecutive missing numbers at the end, this will be the target value

Other than that, it should just work.

Feel free to comment.

PS: The examples might be the best explanation - [https://ausblick.cryptoport.net/examples](https://ausblick.cryptoport.net/examples)

<comment><USER3> What prediction algorithm are you using for this? Not sure if it's mentioned elsewhere on the site

<comment><USER2> No, it's not mentioned. It's currently a mix of very simple techniques

\- a number of smart features (usually a few k) depending on the series (using lags, aggregates, curve fits, combinations of features, ...)

\- an iterative algorithm that selects features using maximum relevance (~ correlation with the target) / minimum redundancy and adds them to the model

\- simple pca and ridge regression (because it's fast)

\- a few optimizations of the final model (removing features, selecting a better ridge regression alpha with CV, ...)

The stack is pure Clojure / Clojurescript.

<comment><USER4> How did you find developing your models in clojure? I would love to switch away from python for ml but it seems to just have the ecosystem.

<comment><USER2> Actually, I use both but my production models are in Clojure.

I often end up implementing minor things myself using lower level abstractions (e.g., Linear Regressions or PCA with whitening using Matrix libraries) and I check the results and/or try new things using scikit-learn.

So in general, I'd say I do the programming (outputing intermediate CSVs, tests, web service, thread handling, UI, ...) in Clojure(Script), and try other approaches (e.g., other models/parameters/...) in Python.

I'm quite happy with this pipeline but probably to some extent because I really love to understand how things work and nothing pushes you to learn as much as a missing function in your ML library :-)

</comment></comment></comment></comment></comment><comment><USER5> No paper, no code, no comparison to other models - hell, they didn't even label the graphs. This is just Google PR spam.

<comment><USER6> The optimization for their datacenters used a 3 layer neural network with 6 neurons. I wonder if this is much more complicated than that...

<comment><USER7> You can still do cutting edge work with 3 small layers, for example most of the advances in robotic control (using neural networks) use networks with similar sizes.

</comment></comment></comment><comment><USER8> > Using a neural network trained on widely available weather forecasts and > historical turbine data, we configured the DeepMind system to predict wind > power output 36 hours ahead of actual generation.

Interesting. Something I've long wondered about:

\- Many wind farms are located in very specific places that have measured high winds and are otherwise good places to locate a wind farm.

\- Global climate change is changing local climates too. Are the studies that were done 10-20 years ago to discover ideal wind farm locations no longer as accurate as they used to be?

\- How are wind farm locations decided today? Is there is skill in predicting where a wind farm might be optimally located in 5 years rather than where it should be located today? Or if not (since probably not) what are the right risk mitigation actions to take if you are planning a wind farm but unsure about location?

\- Since Machine Learning is useful in improving the value of the existing wind power, could it also be useful in this endeavor, finding optimal wind power generation locations?

\- Lastly, is this something a person could research at home with open data and code? Just curious. :)

</comment><comment><USER9> A demonstration of the astonishing value of a relatively small government program: weather observation and forecasting.

<comment><USER10> Weather forecasting is _not_ a small program, NOAA & NWS are both pretty big, but they're not the largest.

Actually, scratch that. On the scale of government, they're more medium size.

</comment></comment><comment><USER11> Is this a substantial improvement over existing neural network models? I've seen models that were being used to trade renewables on PJM's market that seemed at least as good as these. And, similar models are currently being used to manage DERs in micro-grids.

I don't mean to downplay these results. I'm not an expert. Just mentioning it in case someone at deepmind sees this and wants to reach out to PJM. I believe those models were created almost 10 years ago.

<comment><USER6> It is probably not. Their neural network to optimize their warehouse efficiency had 6 neurons. The neural network used here is probably pretty small too

</comment></comment><comment><USER12> Reminds me of some of the excellent advice in Bret Victor's essay about global warming:

[http://worrydream.com/ClimateChange/](http://worrydream.com/ClimateChange/)

The investment is not only in the machinery, but in tools to model, observe, and predict efficiency.

</comment><comment><USER13> If anyone is interested in this type of work, our team at Amperon is hiring data engineers, data scientists, and front end engineers. We're funded by SV Angel and Notation Capital and we've already got traction in ERCOT (Texas).

More info: [https://medium.com/@astanway/introducing- amperon-2cded368284...](https://medium.com/@astanway/introducing- amperon-2cded3682847)

<comment><USER14> I'm not seeing a data engineer role by title or description in the angelist site linked to at the bottom of that post, is that the right spot?

Is remote (Texas) viable?

</comment></comment><comment><USER15> How exactly does this need machine learning? Naively I would assume that it's somewhat directly correlated with wind speed (and little more, maybe direction) and a very simple model based on that data will give you good predictions.

<comment><USER7> I think determining the wind speed and direction 36 hours in advance is the tricky bit.

<comment><USER16> Weather forecasting is difficult problem but it's problem that as far as I know has been worked on intensely for quite a while.

Weather forecasting is based on physics-based models that, so far as I know, are essentially correct with the fundamental barrier to prediction being a combination of random effects and the difficulty of solving the complex equations numerically.

Deep learning involves training a heuristically approximate a system based on past data. It has been used to emulate various human-learning behaviors like recognizing images or recognizing good or bad position in games. Essentially, the visible successes are in "we don't know but can extrapolate roughly from data" (or we "know" but can't easily program it, in the case of image recognition). So I'd be surprised if deep learning do a good or better job in situation where _we do know_ how things work, we already running algorithm which is correct - the situation with weather.

</comment></comment></comment><comment><USER17> I didn't see any comparison to other simpler methods. I'd like to see how well a time series model works.

</comment><comment><USER18> I was super excited when I read the headline and saw that deepmind published the article. I was hoping for something along the lines of applying reinforcement learning on the turbine or park level to optimize power output. Finding the optimal pitch angles, better yawing algorithms (yaw misalignemnts are one of the most common causes of underperforming wind turbines), or finding optimal yaw directions for the entire wind park (downwind wake effects can have a negative impact on other turbines)...

Unfortunately this is really only about predicting wind speeds to then forecast power output. IIRC, grid codes in some countries are starting to require 24 hour, 15 minute interval forecasts for renewables? I've also seen this feature being advertised by other companies over the years as well, although I don't recall seeing any numbers on accuracy for any of the models.

</comment><comment><USER19> > Our hope is that this kind of machine learning approach can strengthen the > business case for wind power and drive further adoption of carbon-free > energy on electric grids worldwide. Researchers and practitioners across the > energy industry are developing novel ideas for how society can make the most > of variable power sources like solar and wind. We're eager to join them in > exploring general availability of these cloud-based machine learning > strategies.

Would be nice to know a bit more detail? Which power grids was this approach tested on? How does this approach work exactly? Are we talking about DNN on time series? The graphs also really need labels to inform.

<comment><USER20> >> _... join them in exploring general availability of these cloud-based machine learning strategies._

... is probably the operative part. Possibly uncharitable, but this appears to be 'thought leadership' marketing generally supporting the idea of GCP managed services.

</comment></comment><comment><USER21> Of course it can, but only on the margin as this article suggests. The real potential is in figuring out where to put them, what to put in the spots, and most importantly, who to choose to build them and support them given the aforementioned variables. There may also be some advances to be made in the actual design, but I do not believe machine learning is going to help so much there.

</comment><comment><USER22> "Statistics are useful for forecasting."

Meteorologists have long used a metric, forecast skill, to evaluate different techniques. It would be good if the researchers used standard benchmarks.

ML is probably much more useful in understanding the demand for power, the reaction to weather and current events. But even still, it seems a stretch.

</comment><comment><USER23> Perhaps some people are missing the point here?. The post is not about the technical challenge/novel but rather how _existing_ ML techniques can play a part in making reusable energy more efficient.</comment>