I'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…
A pile of if statements is a direct model of business deal making, which is literally a pile of if statements. Sales contracts with weird conditions and odd packaging and contingencies? Pile of if statements. The other great model for business logic is a spreadsheet, which is well modeled by SQL which is a superset of spreadsheet functionality. So piles of if’s and SQL. Yeah. Elegant functional or OOP models are usua…
Cognitive load is what matters
51–60 of 552 posts
Re: Cognitive load is what matters
#52I'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…
When the problem itself is technical or can be generalised then abstractions can eliminate the need for 1000s of if-statement developers but if the domain itself is messy and poorly specified then the only ways abstractions (and tooling) can help is to bake in flexibility, because contradiction might be a feature not a bug...
Re: Cognitive load is what matters
#53It's been said: "Document the why , not the what ." I have a hard time separating the why and the what so I document both. The biggest offender of "documenting the what" is: x = 4 // assign 4 to x Yeah, don't do that. Don't mix a lot of comments into the code. It makes it ugly to read, and the context switching between code and comments is hard. Instead do something like: // I'm going to do // a thing. The code // do…
Ah, the chat gpt style of comments.
> Instead do something like:
The only negative is that there is a chance the comment becomes stale and not in sync with the code. Other coders should be careful to update the comment if they touch the code.
Re: Cognitive load is what matters
#54Cognitive load isn't a valid or useful concept: https://edtechdev.wordpress.com/2009/11/16/cognitive-load-th... https://www.tandfonline.com/doi/full/10.1080/00131857.2024.2... There are separate contexts involved here: the coder, the compiler, the runtime, a person trying to understand the code (context of this article), etc. What's better for one context may not be better for another, and programming languages favor…
Re: Cognitive load is what matters
#55This article reminds me of my early days at Microsoft. I spent 8 years in the Developer Division (DevDiv). Microsoft had three personas for software engineers that were eventually retired for a much more complex persona framework called people in context (the irony in relation to this article isn’t lost on me). But those original personas still stick with me and have been incredibly valuable in my career to understan…
Re: Cognitive load is what matters
#56Re: Cognitive load is what matters
#57Re: Cognitive load is what matters
#58I'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…
Re: Cognitive load is what matters
#59Brilliant essay. Bookmarked for future reference.
There is also a discussion between the author of Clean Code and APOSD:
Re: Cognitive load is what matters
#60I'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…