[deleted]
Cognitive load is what matters
161–170 of 552 posts
Re: Cognitive load is what matters
#162"Domain-driven design has some great points, although it is often misinterpreted”. Agreed. The worst shops I’ve ever worked in are ones where the DDD/evans/fowler orthodoxy has run amok.
Re: Cognitive load is what matters
#163Earlier quoted context omitted.
Clearly they were missing Amanda, the engineer who's had to review others' terrible code (and her own) for 20 years, and has learned the hard way to keep it simple. She knows she's writing code mostly for people to read, not computers. Give me a small team of Amandas any day.
They were also missing Steve Jobs. Having had the displeasure to work with Microsoft tools and code for most of my career. Microsoft never in my experience just plain works. I had to fight Microsoft every step of the way to get things to "work". And when it does it invariably breaks in the next major software release.
Microsoft is/was far more developer friendly than Apple
MFC may have been a steaming pile of doodoo, but at least the tools for developing on the OS were generally free and had decent documentation
Re: Cognitive load is what matters
#164Earlier quoted context omitted.
It does work for awhile, until one day: Project Manager: "Can we ship an order to multiple addresses?" Grey Beard: "No. We'd have to change thousands of random if-statements spread throughout the code." Project Manager: "How long do you think that would take?" Grey Beard: "2 years or more." Project Manager: "Okay, we will break you down--err, I mean, we'll need to break the task down. I'll schedule long meetings unti…
If Grey Beard doesn't relent Project Manager: "Can we ship an order to multiple addresses? We need it in 2 weeks and Grey Beard didn't want to do it" Eager Beaver: "Sure" if (order && items.length > 1 && ...) { try { const shipmentInformation = callNewModule(order, items, ...) return shipmentInformation } catch (err) { // don't fail don't know if error is handled elsewhere logger.error(err) } } else { // old code by…
... and then that `callNewModule` has weird bugs like mysteriously replacing `+` with spaces, sometimes labels are empty but only if they are shipped to a specific company, sometimes the invoices are generated multiple times for the same shipment, after 1 year after Sales has already sold this multi-item shipment feature to massive companies it suddenly stops working because the new module wasn't properly hooked for auto-renewing credentials with a specific service and the backlog of unshipped items but marked as shipped grows by the second...
Of course Eager Beaver didn't learn from this experience because they left the company a few months ago thinking their code was AWESOME and bragging about this one nicely scalable service they made for shipping to multiple addesses.
Meanwhile Grey Beard is the one putting out the fires, knowing that any attempt to tell Project Manager "finding and preventing situations like this was the reason why I told my estimate back then" would only be received with skepticism.
Re: Cognitive load is what matters
#165Cognitive Load is not what matters, Solving problems is what matters.
"Cognitive Load" is a buzzword which is abstract.
Cognitive Load is just one factor of projects, and not the main one.
Focus on solving problems, not Cognitive Load, or other abstract concepts.
Use the simple, direct, and effective method to solve problems.
Cognitive Load is relative, it is a high Cognitive Load for one person, but low cognitive load for another person for the same thing.
Re: Cognitive load is what matters
#166Earlier quoted context omitted.
It does work for awhile, until one day: Project Manager: "Can we ship an order to multiple addresses?" Grey Beard: "No. We'd have to change thousands of random if-statements spread throughout the code." Project Manager: "How long do you think that would take?" Grey Beard: "2 years or more." Project Manager: "Okay, we will break you down--err, I mean, we'll need to break the task down. I'll schedule long meetings unti…
And eventually it took 3 years.
Some say they are still trying to get the original functionality back to this day.
Re: Cognitive load is what matters
#167I don't know, I'm seduced by the elitist approach: code with a high cognitive load keeps mediocre developers away.
Case in point: Forth. It generally has a heavy cognitive load. However, Forth also enables a radical kind of simplicity. You need to be able to handle the load to access it.
The mind can train to a high cognitive load. It's a nice "muscle" to train.
Should we care about cognitive load? Absolutely. It's a finite budget. But I also think that there are legitimate reasons to accept a high cognitive load for a piece of code.
One might ask "what if you need to onboard mediocre developers into your project?". Hum, yeah, sure. In that case, this article is correct. But being forced to onboard mediocre developers highlights an organizational problem.
Re: Cognitive load is what matters
#168Earlier quoted context omitted.
That feels like.. something the compiler should be optimizing for you? I would certainly be among those questioning this code.
The compiler can't know from the code alone which branch is more likely. This is a property of the input data and not the code. Really advanced JIT compilers can sometimes do those types of optimizations, but this is a fairly rare scenario.
Isn't branch prediction mostly a CPU thing? Do you have an example with corresponding assembly?
It's not that I don't believe you about the performance impact, as I have observed the same with e.g. Rust in some cases, but I don't think it has a lot to do with the compiler judging what's more likely, but rather more or less "random" optimization differences/bugs. At least in my case, the ordering had nothing to do with likelihood, or even had a reverse correlation.
I think in your example a compiler may or may not realize the code is semantically equivalent and all bets are off about what's going to happen optimization-wise.
I mean, in the end it doesn't matter for the commenting issue, as you are realistically not going to fix the compiler to have slightly more readable code.
Re: Cognitive load is what matters
#169Earlier quoted context omitted.
You reminded me of a rule of thumb that says: Keep the complexities in data structures and simplicity in algorithms
I have seen subscription systems built following that rule of thumb. It collapses pretty well, as the data structure then becomes impossible to engage with unless you are an expert, and the callers are never experts. Things make more sense when the data structure lives in a world where most, if not all illegal atates become unrepresentable. But given that we often end un building APIs in representations with really w…
Ironically, the attempt to prevent illegal states may create "complex" code (quoted since it may be due to perceived or actual complexity).
Re: Cognitive load is what matters
#170Earlier quoted context omitted.
For my frame of reference, do you think the Myers-Briggs Type Indicator are psycho-bullshit, too? Because I had characterized personas as a very similar "of course it's a generalization" and OP even said themselves "every engineer is a mix" but if you're coming from stance that bucketing people is disrespectful, then your perspective on MBTI would help me digest your stance
I briefly flagged the preceding comment for "psycho-bullshit" before concluding that it was just a really forceful way to say the developer personas were pseudoscientific (of course they are, nobody is claiming otherwise) but I think it's worth calling out that MBTI is also pseudoscientific; it has no real validity, or even test-test reliability.
[deleted]