[dead]
Cognitive load is what matters
531–540 of 552 posts
Re: Cognitive load is what matters
#532Earlier quoted context omitted.
> I think anyone that thinks mudball is OK because business is messy has never seen true mudball code. I’ve seen and created some pretty bad stuff. Point is not that it’s okay, but that that’s the job: managing, extending, and fixing the mess. Yes a perfect codebase would be great, but the code is not perfect and there’s a job to do. You’re not gonna rebuild all of San Francisco just to upgrade the plumbing on one st…
Sure but again you are referring to somewhat structured systems that went off the rails a bit. Thats not what I consider a mudball. I've seen numerous places trying to hire someone to fix a 5-10 year mudball that has reached a point where progress is no longer possible without breaking something else which breaks something else and so on. There is an endgame to the mudball and it does end in complete and total develo…
This gives me PTSD
Re: Cognitive load is what matters
#533I had the exact same experience with layered architectures like described in this article. Avoid them as much as possible, naive and simple code is often better. It might look messy on the surface, and the layered code might look much cleaner. Until you drown in indirections, that are impossible to keep track of.
We've only made good experiences with layered architecture (onion architecture in particular, which is quite straight forward). We also never built it with the idea in mind to ever replace the storage engine. No, the big, big benefit has been that we can test everything without ever mocking a single class.
I also don't get the point about "going back to IoC" ... how is that mutually exclusive from using a layered architecture. This section was weird and didn't offer any good alternative.
Re: Cognitive load is what matters
#534This is why I make lists. Of everything. Checklists for technical processes (work and personal). Checklists for travel. Little "how to" docs on pretty much everything I do that I'm sure I won't remember past a week. It completely removes the stress of doing things repeatedly. I recently had to do something I hadn't done in 2 years. Yep, the checklist/doc on it was 95% correct, but it was no problem fixing the 5%.
In like Apple Notes or what do you store the checklists in?
Switched to Apple Notes recently. Used to use org mode, but the apps on iOS ... just bad.
But, I use different things for different situations.
For work, I use text files in a "howto/" subdirectory of a main repo.
Re: Cognitive load is what matters
#535brb adding this to my CLAUDE.md
Re: Cognitive load is what matters
#536brb adding this to my CLAUDE.md
For the lazy:
### Reduce Cognitive Load By:
*1. Simplify Conditionals*
``` // High cognitive load if val > someConstant && (condition2 || condition3) && (condition4 && !condition5)
// Low cognitive load isValid = val > someConstant isAllowed = condition2 || condition3 isSecure = condition4 && !condition5 if isValid && isAllowed && isSecure ```
*2. Use Early Returns*
``` // Nested ifs if isValid { if isSecure { doStuff() } }
// Early returns if !isValid { return } if !isSecure { return } doStuff() // Happy path is clear ```
*3. Prefer Deep Modules*
- *Deep module*: Simple interface, complex implementation (e.g., UNIX I/O with 5 methods) - *Shallow module*: Complex interface for simple functionality - Few deep classes > Many shallow classes
*4. Use Self-Describing Values*
``` // Numeric codes requiring mental mapping 401 // expired token? 403 // insufficient access?
// Self-describing { "code": "jwt_has_expired" } ```
*5. Apply DRY Carefully*
- Don't create abstractions too early - Avoid tight coupling between unrelated components
### Avoid These Anti-Patterns:
*1. Inheritance Chains*
``` AdminController extends UserController extends GuestController extends BaseController Use composition instead ```
*2. Too Many Layers*
- Unnecessary abstraction layers add indirection, not simplicity - Only add abstractions when you need actual need to
*3. Framework Magic*
- Keep business logic framework-agnostic - Use frameworks as libraries, not containers for your logic - New developers shouldn't need months to learn framework "magic"
Re: Cognitive load is what matters
#537I'm probably one of the "smart developers" with quirks. I try to build abstractions. I'm both bothered and intrigued by the industry returning to, what I call, "pile-of-if-statements architecture". It's really easy to think it's simple, and it's really easy to think you understand, and it's really easy to close your assigned Jira tickets; so I understand why people like it. People get assigned a task, they look aroun…
Perhaps expressing intend and describing the underlying domain carries more value than pure “abstraction”.
I'm not surprised to be downvoted, it truly speaks for the state of quality in the industry or lack thereof.
Re: Cognitive load is what matters
#538Earlier quoted context omitted.
Often you can check validity one time before everything else. 5 bools might only actually be valid in 7 possible combinations instead of 32. Convert in one place to a 7 element enum and handle with exhaustive switch statements everywhere else can sometimes be a lot cleaner. Making invalid data unrepresentable simplifies so much code. It's not always possible but it is way underused. You can do some of it with object…
> Making invalid data unrepresentable simplifies so much code That's the dream. Error handling is what crushes it :)
Often invalid data it is still representable where you ingest it, but you can then do all the error handling there and convert to a representation where it isn't, instead of having all the code constantly sanity checking it. Not always possible but it can make a big improvement a lot of times.
Re: Cognitive load is what matters
#539The ability to create code that imposes low cognitive load on others not only is a rare and difficult skill to cultivate- it takes active effort and persistence to do even for someone who already has the ability and motivation. I think fundamentally the developer is computing a mental compression of the core ideas - distilling them to their essence - and then making sure that the code exposes only the minimum essenti…
I learned a lot this in competitive programming. I used to write code that were 3-5x the size of the intended solution. There are many reason why you could write a worse/bigger solution but sometimes when I compared both solutions one thing I could notice is that I could remove a lot of things from my solution until nothing could be removed anymore and the final solution would really seem like it were the essence of the problem.
But even if the intended solution seemed simpler, it could be much harder to discover it.
Re: Cognitive load is what matters
#540[dead]