PRs welcome!
- explicitly state why things may be easy to do versus hard. Explicitly say that. Don’t be sheepish about it
- show them the backend just for fun, the index.js file which is super complicated. They need to be humbled in some part.
- why do we use ” and when do we not?
- input breaking down
- please extract zip files
- what’s the difference? Is there a diff? We learned it in one chunk
- figuring things out on the computer requires perseverance. It’s hard. People may not be willing to put in the effort
- can we get to the point where they can do small task?
- change the course descriptIno
- change the money required to pay for the course
- go do MOOCs to figure out how people are being taught this material
- Don't do stuff that "will make sense later"
- explain why the braces are used more coherently (group code together, encapsulate, ...)
- what gets put into quotes and what doesn't? variables are not easy to understand
- camel casing is hard to get right, especially that getElementById
- don't make text disappear and reappear. what is the point, no one gets
- explain the ordering of inputs into the function and how that matters
- when explaining functions, motivate why we need a "recipe" in the first place, that doesn't make sense
- Less changing of screens from slides to code to browser - trainers know what to look at but participants don't, and hence they cannot keep up.
- make sure that the content is easily copy-pasted over
- explain more high level concepts, they don't need to write code, they just need to be able to speak to vendors more confidently
- bigger printed out notes so that people don't confuse ) and } and ]?
Latest feedback from conversation with Doris, Director Executive Programs, CSC:
- State explicitly the myths you want to debunk
- It's helpful for people to type in code and see how the autocomplete helps you in programming
- showing cause and effect with the code that they write
- They should learn about the bigger picture of how coding is done. What software are you using? Did you have a choice? If you did, why did you choose what you did?
- Try out the LEARN app
- GovTech is working on something with David Eaves for directors and above to participate in
- Record the sharing over video and send it out to folks
- explain why your team is valuable through the course
- Too many functions and functions calling other functions? You can tell by their questions that they don't know what's happening and just want their program to work.
- Write more comments throughout the code explaining what's happening so that they can reference them whenever they are confused
- More comments above chunks of code to explain what it's doing. So if participants are lost, at least they can read comments.
- APIs are hard. Reduce it to only one API
- More skeleton - Have a good basic template, participants can just modify small chunks of code on their own, instead of just copying and pasting. e.g. and they edit on their own
- Specify that keydown is not ArrowDown
- console is hard to understand, so try to avoid it and instead display text on screen using the div tags or alerts
- put the javascript and css into the same page as the html code so that they don't need to toggle between files
- change stuff to make sure that they don't appear, then tell them to make it disappear, then reappear it
- Write comments in your code so that they know what is happening after you stop talking
- every milestone that the user does should be a change so that they know what the impact of writing the code is. Cause and effect should be made clear and explicit