Anything a developer does that doesn’t add business value is wasted cognitive load. That’s why we use abstractions.
I know my developers are smart enough to handle memory management if they needed to, but developers just as smart in the past were less productive and introduced buffer overflow bugs because they had to think about that as well as the business problem they were trying to solve.
I want my team to fix one novel problem a day, rather than 10 papercuts that have already been fixed and get in the way of business logic.
When I see a developer make a mistake, I always need to ask myself if that mistake is a papercut that other developers will suffer from, and if there’s a way to fix it before the next developer encounters it. Code that makes my team more productive is always useful code.
2 replies on “Developer cognitive load”
[…] c# specific example to follow up my blog post on cognitive load, since it coincidentally came up at […]
[…] continue my mini series on cognitive load, following my previous post on static vs extension methods, a couple more examples to consider. […]