I see programming as an extended application of problem solving, and problem solving is just a different view on self-learning. Encouraging self-learning makes a team skillful and robust.

I once worked at a startup where the developers were regularly ignored. Try as we might to bring in new perspectives and experts, everything was dismissed. It eventually fell apart with the entire team leaving. This is an example of climate, and a highly toxic one.

I come from the world of startups. Companies with interesting products fail every day. Despite novel products, customers are disinterested and avoidant. In software, unit tests are widely acknowledged to be good practice. However, few developers write them. These two cases are prime examples of motivation failures.

Repeatedly explaining some idea without perceived progress is frustrating for both the teacher and student. Ideas feel compelling and actionable, but remember, knowledge is both declarative and procedural. Thus, feedback and practice are two halves of one process. Feedback is not effective without an opportunity to practice.

Think back to the first post on mastery. Expert blindspot is caused by information obvious to the master and imperceptible to the student, causing both sides to be baffled by the behavior of the other. This can be an issue with knowledge organization.

Every student views new information through the lens of prior knowledge. In fact, some researchers suggest that learning requires connecting new information to what we already know. Either way, more connections leads to improved recall and utility.

Defn: Mastery - a high degree of competence in a particular area.

Communication is hard. We’ve all (probably) experienced situations where our words fall flat; where repeated explanation just doesn’t seem to create understanding. In this situation, you are an educator. Learning and teaching are two views of the same process. However, those views don’t always line up. Each individual’s past experiences, goals, subject mastery, learning habits, and the environment can all cause disconnects. Not just these qualities in students, but in the teacher as well.

I absolutely love Scott Wlaschin’s work. He breaks down the unfamiliar and sometimes complex ideas of functional languages into approachable explanations. My one gripe with his site is that there is a bit of an implicit order to the content. Here’s my outline of how I think the concepts best build on each other.

I want to directly address the idea that moving quickly means bad code. Heavy design process is also not the opposite of either speed or sloppy code. To go fast is to go well, and that means fast incremental design.