Broadly speaking, you should attempt to minimize the intrinsic [[Cognitive load]] (through training, good choice of technologies, hiring, pair programming, etc.) and eliminate extraneous cognitive load (boring or superfluous tasks or commands that add little value to retain in working memory). This will leave more space for germane cognitive load (where "value-added" thinking lies). [^fn1] [^fn1]: [Forget monoliths vs microservices. Cognitive load is what matters](https://techbeacon.com/app-dev-testing/forget-monoliths-vs-microservices-cognitive-load-what-matters) by [[@Matthew Skelton]] and [[@Manuel Pais]] (authors of [[Team Topologies (book)]]) ## Intrinsic load In development terms, the more complicated a feature is to develop, the more intrinsic load the person implementing it must handle. As a consequence ==we can only manage intrinsic load by breaking high load tasks into smaller, less complex ones==. [^fn2] [^fn2]: [MANAGING COGNITIVE LOAD FOR TEAM LEARNING](https://12devsofxmas.co.uk/2015/12/day-3-managing-cognitive-load-for-team-learning/) by [[@Jo Pearce]] Unless you’re well practiced in working with them, design patterns can also contribute to the intrinsic load of implementation. Not only do you have to contend with the complexity of developing widget X to satisfy requirement Y, but also having to write your code to conform with pattern or architecture Z. [^fn2] ## Extraneous (irrelevant) load Extraneous or irrelevant load is imposed by factors that aren’t directly relevant to the problem we are trying to solve or the information we are trying to assimilate. [^fn2] Examples of extraneous load: - Not knowing where to focus your attention. No prioritisation on tasks, etc. - Plethora of different frameworks and tools within same codebase ## Germane load Germane cognitive load is possibly the most difficult to manage as it is imposed by materials and tasks that are beneficial to the overall goal of the learner. In other words, we want to impose germane load, but need to consider the degree to which we do so. Any exposure to new patterns, architecture or areas of the problem domain could be useful germane load, but try not to introduce too much that is unfamiliar with each successive task or the burden could become too great and productivity could take a hit.[^fn2] Examples of germane load: - Rotating developers around different parts of the codebase in order to spread knowledge and reduce Bus Factor. The load imposed here is the context switching involved each time they switch to new area. - Similarly, in dev firms that have multiple concurrent client projects, moving developers between projects will decrease the firm's organisational risk but will incur extra germane load on each developer being moved ## Summary of managing techniques We’ve seen that we can manage the load we impose on our teams by considering the three components of cognitive load individually: [^fn2] - We can manage intrinsic load by reducing task size and complexity while we encourage automaticity and understanding within our team through regular code review. - Extraneous load can be reduced through minimising the number of distractions and moving parts. We can also help focus attention through writing our code to be read by human beings not just the computer. - Managing germane load is about guiding the learning processes of our team with respect to broader goals such as domain knowledge or language acquisition. We can achieve this through varying the tasks that we assign and encouraging sharing of knowledge between team members through pair programming. ## #OpenQuestions - Can I make a clearer distinction between intrinsic and germane load than those provided in references I've found? It's still not totally clear. - A: Maybe "ambient"could work, or more explicitly "the essential tech and processes you are using". Germane is maybe better termed "the domain-specific business problem". --- tags: [[Software engineering MOC]]