Watch and Code

What @Jonathan_Blow describes is precisely the focus of my teaching. It is also by far the hardest and most frustrating part of my work. It truly is the last frontier of programming education. Technical competence is nothing in comparison. I tried to describe the same phenomenon in my essay, "A Brief History of Watch and Code". What makes it frustrating is how few people even think it's a problem. It may be a case where only those that understand the problem can see it. watchandcode.com/essays/a-br… From the last section: "The systems I had built were extremely effective at helping students develop technical competence, but there was one final piece, design. You can think of it as taste, judgment, or something else. I still don't know exactly what I should call it. You have two programs, they are both correct. One is pleasing and simple, but the other is ugly and gives you a headache. This is what I mean by design. It turns out, good design, at least the type I'm describing, is chiefly a symptom of clear thinking. The headaches are a symptom of muddled thinking."

Big issue w/ full-time coding bootcamps: 3 mo is followed by a 12+ mo job search (if lucky) that creates a large gap that has to be explained. Companies become concerned & think, "there's likely a reason this person isn't having any luck", so the problem keeps getting worse.

From a conversation this morning: "To be merely competent, you have to stay with something until you understand it. To go beyond that, you have to stay far longer, until all the newness and excitement has worn off."

We're starting to see positive ripple effects from last Friday's proofs workshop. We are trying our hardest to fight against the unreliable-whack-a-mole "I tried a lot of inputs therefore it must be true" method🤦‍♂️. From a student today: "[...] Interestingly, at this stage, writing comments felt ‘proof’ like. There was an intuitive sense, ‘no, this is REALLY right’ this time. I’m not sure if that feeling itself can be fully trusted, but when all the parts of the function are somehow expressing the problem simply and clearly, there is something tangibly different about that [...] This is the first time I’ve written out a reflection like this, increasing the juice I get from one exercise and undermining the tendency to believe that ‘completing quickly’ is always a proxy for skill or growth, or even something that should be aimed for. Quite the contrary, it is this tendency that has HELD ME BACK from developing the carefulness needed to solve problems well."

People are so used to not understanding things that when they do, the reaction is often, "this is too basic, this is obvious, I could've figured it out, not impressed, not complex enough, etc". The common outcome is that people end up valuing misunderstanding over understanding.

We hosted a proofs workshop today (the math kind). Amazed that we've somehow gotten students excited about mathematical thinking. Great to see nerdiness spread. Some attendee quotes: "Is this going to be in the curriculum? I want it as a guide, I want to save it." "I personally found this more useful than the weekly practice problems, would love more sessions like this."

Over and over again, our internal data shows that students that “supplement” with other resources, do much worse than students that don’t. The underlying issue is when students use other resources as an avoidance mechanism. Rather than figure out what we are trying to say, they (understandably) believe that someone else will explain it better. They go on a hunt for “easy to understand” resources. The problem is that these resources often are easier to understand, not because they are clearer, but because they are dumbed down, and don't describe the same underlying idea. This comes up commonly with time/space complexity. We teach a difficult approach that *always* works. Most other places teach a set of rough heuristics that *mostly* work. Students, seeing that the heuristics feel good, adopt them eagerly, instead of our approach. They then do our quizzes/assessments and (not surprisingly) fail. Moral of the story: when someone says something, do everything in your power to understand. Don’t assume that “a simpler” message is the same message.

New essay, spurred by concern I'm seeing in students and the wider programming industry. Main themes: 1) The bar is 10X higher 2) What was optional is now required 3) Avoid x-month cram schools 4) Professional developers are vulnerable watchandcode.com/essays/flig…

How to make the most out of every job interview, identify mistakes, and prevent them from happening again. 1) Immediately afterwards, produce a detailed transcript of what happened. 2) Reflect and annotate the transcript with what went well, not well, what you could have done better. Grade yourself on a scale of 0-100 and justify that grade. 3) *PRIVATELY* share the transcript with a trusted objective third-party, ideally the harshest, most demanding person you know. Ask them to critique #2. [Emphasis on PRIVATELY. Do not publicly share actual interview questions.] There is usually a large gap between actual and perceived performance. This gap is the reason many struggle indefinitely. As the objective third-party in #3, I commonly uncover disqualifying statements/behaviors that were completely invisible to the candidate.