Outline

TODO

• Chapter questions
• Index

Learning

• Main goal: learn to solve a difficult problem
• Mindset
  • Tenacity
  • Learn from failures
  • Learning is hard
• How to solve any problem
  • Understand, plan, code, reflect
• Breaking down problems, pseudocode, proof of concept
• Debugging
• Right tool for the job
• Be critical and opinionated
  • Be opinionated
  • Think like a villain
• Hack your brain
  • Read ahead
  • Walks
  • Rewrite the problem in your own words
  • Stuck for 20 minutes
  • Rubber ducking
  • Answer immediate questions now, write down later questions
• Learning a language
• Use of AI

Teaching

• Main goal: teach problem solving
• Use practical projects
• Teach tooling
• Students should have to make a mental leap, but not too far
• Emotional assist: it was tough for you, it's tough for everyone
• Research the topic, focus on the hard stuff
• Making clear notes
  • Stay away from Greek
  • Avoid single letter variables
• Blend lecture and projects
• Team leader for your students
• Cheating
• Student mindset
• Social
• AI

Ideas

Core ideas of learning

• Main goal: learn to solve any difficult problem.
• Like the job of a novelist isn't spelling, the job of a dev is not coding. The job of a dev is problem solving.
• There are a lot of tools and languages. Don't stubbornly adhere to only what you know. Use the right tool for the job, even if you have to learn it first.
• There's no one true solution, technology, or language that's best at everything.
• Professional devs don't fight language wars.
  • They might have a favorite, but they use the right tool for the job.
  • They know the battle is solving the problem. The language is just the tool they use to write down the solution.
• Keep attacking, tenacity is the prime quality
  • Try things. If something doesn't work, learn from it and try something else.
  • For two tenacious devs, there's no difference in skill other than number of reps put in.
• No one is born being a great dev.
  • It's all learned with time and reps.
  • People who love it will think about it all day and try things all day. That's a lot of time and reps.
  • People who hate it will procrastinate and not put in the same time and reps.
• Everyone is smart enough to be a dev. But you gotta want it.
  • It's mountains of very difficult and frustrating work.
  • I'm smart enough to be an accountant, but I can't make myself put in the work because I dislike the subject. Therefore I will not become an accountant.
• Understand, Plan, Code, Reflect
• Everything is hard/nothing is obvious
  • It doesn't pay the big bucks because it's easy.
• Think like a villain
• "Lose first 50 games as quickly as possible"
• Be opinionated with a rationale
• Failures can be better teachers than successes.
• Read the assignment right now, even if you don't understand it, and even if you're not going to code it until Sunday. Get your brain chewing on it.
• Build an interconnected web of knowledge. All techniques are related, and the more you know, the easier time you've have generating solutions to novel problems.
• If you have a bug, don't try another approach without first fully understanding why the bug is occurring.
• Learning new programming paradigms is harder than learning new languages.
• Learning new languages in a paradigm you know will become easy.
• Learning new things is hard.
  • In school, you learn new things 100% of the time without a break.
  • At work, you learn new things 100% of the time for about 3 months. After that, it gets a lot easier. After two years, boredom.
• What to expect at work.
• Join a club!

Core ideas of teaching

• Main goal: practice solving difficult problems.
  • We do this in a vehicle of networking, discrete math, statistics, operating systems, architecture, etc. for general edification.
    • A student might find a niche they enjoy by being exposed to many different areas of programming.
  • You might never need a particular solution to a problem given in school, but the problem-solving skills you develop solving that problem directly apply to everything you'll do at work.
• The foundation is impractical, but practice it with practical projects.
• Don't skim on teaching tooling.
  • What are files?
  • How does an IDE work?
  • How to be an intermediate Git user?
  • How does GitHub work?
  • What is a compiler and linker?
  • What is an object file? What is a library?
  • How do dependencies work?
• Make it a leap to understand, but not too far
• Remind students it was hard for you
• Recall what the sticking points were and give them extra time
• Explicitly answer all the questions you had when researching
• Don't skip steps.
• Never say something is easy or obvious unless it is easy or obvious to someone not skilled in the subject matter
• Explain what's important to know well, or just OK, or you don't need to know.
• Stay away from higher-level math notation and Greek letters. If you use them, spell out the meaning of the notation in plain language for the first several uses, and refresh for the first uses of each chapter.
• Single letter variable names in pseudocode are more damaging than multi-letter variable names in pseudocode.
  • Up for debate: needing to pore over the pseudocode to make sense of the single-letter variable names might be useful for learning.
• Pure projects are better than pure lecture. A blend is even better.
• Completely flipped classrooms are wasting an opportunity for student-teacher teamwork.
  • Reading for homework
  • Large projects for homework
  • Small lead-in projects in class to make the homework ones easier.
    • These can be simplified variants of the take-home projects.
• Lecture for as short a time as possible.
• No PowerPoint except for prepared animations.
• Make notes as you lecture.
• Post notes after class.
• Be a leader teammate with your students, not a professor. Be in it with them.
• Encourage questions by any means possible.
• Be relatable.
  • If a topic gave you trouble when you learned it, tell the students.
  • Live-code without notes. When things don't work, ask the students if they see the error.
  • When something is truly difficult for most, say so.
• Explain topics better than anyone has explained them to you.
  • Watch for those "why didn't they just say so in the first place?" moments when the light bulb switches on. That's the acorn for your oak.
• Don't skimp on learning. If you don't fully grok something, you can't teach it. Be relentless in your pursuit of clarity.
  • Use your clarity and noted pain points while learning to explain the topic better than anyone has explained it to you.
  • Ask books, peers, Reddit, ChatGPT
• Difficulty for difficulty's sake is detrimental. There must be a greater lesson.
• Everything is easy given enough learning time and reps.
• Relate all theoretical and foundational material to real-life problems.
• Never judge. Always encourage.
• Stress that failure the more valuable learning experience.
• Pretend you can't stop cheaters. (You can't.) How do you encourage people to not want to cheat?
  • Get them to enjoy the challenge.
  • Make failure a positive experience.
    • Turn it into low-risk exploration. In-class ungraded mini-labs are great for this.
  • Have flexible deadlines. Life happens. Inflexible deadlines are the #1 reason to cheat.
• Require self-assessment and reflection.
• Foster a social center

Thought experiment

Pretend students have instant brain-chip access to all facts and solutions to all your exams and programming projects. (This is not a far-fetched scenario.)

• What are the most important skills for them to develop?
• What do you teach them?
• How do you teach it?

I like this thought experiment because it:

• Forces us to focus on the core skills that are really important.
• Handles situations where the tooling (e.g. AI) punches a hole in our assessments.
• Allows for the leveraging of the exact tools will be used at work to great effect (e.g. ChatGPT, Stack Overflow, YouTube, etc.).

Learning a Language

• Knowing the language syntax.

  This is things like what statements (like if and for) you can use, how to define variables, functions, classes, and data structures, and what punctuation does.

  This is usually fairly straightforward, even in more complex languages. There's just not much syntax there, and you probably don't need all of it to get your work done.

• Knowing what libraries are available.

  This is a much bigger task. Python, for example, has a massive standard library full of functionality you can leverage.