Simple Ways of Reducing the Cognitive Load in Code • Hacker News Board

Re: Simple Ways of Reducing the Cognitive Load in Code

#101

Post by bdavisx » Tue, Jun 28, 2016, 3:23 PM UTC

alfiedotwtf wrote: post #86

tmaly wrote: post #82

I own Code Complete, but I felt I got better value out of the Clean Code book combined with the Pragmatic Programmer. I did find some value in Code Complete, but it is a little too long for my tastes. The naming and abstract data structure sections were probably my favorite parts of that book.

If you're just starting out in your career, reading Code Complete is like gaining experience by osmosis. Then once you know what you're doing, Pragmatic Programmer is like a light refresher that you read once every few years.

Yes, I read the first edition many years ago - it was a huge benefit to my naive "bash the code out however I can" practices.

Now, when reading it, I'm kind of like "yes, that's good, except when..." So you learn to temper the rules with experience. But in the beginning of your software development journey, you need something to keep you in line.

Re: Simple Ways of Reducing the Cognitive Load in Code

#102

Post by CuriousSkeptic » Tue, Jun 28, 2016, 3:25 PM UTC

reikonomusha wrote: post #94

SonicSoul wrote: post #91

Earlier quoted context omitted.

In cognitive psychology, cognitive load refers to the total amount of mental effort being used in the working memory seems like a correct usage to me. Anytime an ATM displays weird confirmation buttons like "Sure" instead of "Yes" or bloated confirmation text instead of "transaction completed" this increases cognitive load. I agree that it is debatable what kind of code exactly causes the least strain, but at least t…

It's not incorrect necessarily, just unqualified. Cognitive load is hard to meaningfully substantiate; it is person and experience dependent.

Actually, not at all. It's directly measurable http://www.ncbi.nlm.nih.gov/pubmed/17833905

"The pupil response not only indicates mental activity in itself but shows that mental activity is closely correlated with problem difficulty, and that the size of the pupil increases with the difficulty of the problem"

Re: Simple Ways of Reducing the Cognitive Load in Code

#103

Post by jimbokun » Tue, Jun 28, 2016, 3:25 PM UTC

lenkite wrote: post #80

delecti wrote: post #31

Earlier quoted context omitted.

I recently got a code review that in several places suggested I switch to the new Java 8 stream API [1]. I just flatly responded that it was far less readable, even if I could condense a half-dozen lines of code down to one. Where I can quickly scan over a foreach loop to get the jist of what it's doing, I have to closely examine each call in the new approach to have any idea what it's doing. [1] http://www.oracle.co…

Stream based programming is a paradigm that with some training and proper code indentation is much , much faster to read than a nested for loop. Once you get used to it,you can literally fast-scan code written in this style with the confidence that you are not missing anything. Also, assuming you do not use mutable state, it also has the advantage of being easily parallelizable without any code changes. (As well, as…

"Stream-based code is certainly not something you can read off the cuff."

    List transactionsIds = 
        transactions.stream()
                    .filter(t -> t.getType() == Transaction.GROCERY)
                    .sorted(comparing(Transaction::getValue).reversed())
                    .map(Transaction::getId)
                    .collect(toList());

I honestly think most programmers fluent in Java 7 programming, can guess this is finding "grocery" type transactions, sorting by "value" transaction property in descending order, extracting the transaction ids, and returning the result as a list. ("map" could be confusing, as this usage is borrowed from functional programming.)

May take a while to learn the performance and memory usage characteristics, and how to correctly write code in this style, but I'm not buying that it is difficult to "read off the cuff."

Re: Simple Ways of Reducing the Cognitive Load in Code

#104

Post by jorgeleo » Tue, Jun 28, 2016, 3:27 PM UTC

reikonomusha wrote: post #88

I've noticed recently that especially in online discussions, the term "cognitive load" is used as a catch-all excuse to rag on code that someone doesn't like. It appears to be a thought-terminating cliché. There's definitely room to talk about objective metrics for code simplicity, which are ultimately what many of these "cognitive load" arguments are about. But cognitive load seems to misrepresent the problem; I thi…

I agree with you. People use "Cognitive load" as meaning to say "people should be thinking the way I think, because to me that is very easy and straightforward".

The load gets bigger not because the code is more complex, but because we reason about problems differently, we build different mental models of the solution, and if these models are too different, then the cognitive load gets heavy.

The other side of the coin is that books like Code Complete go a long way into making those mental models more clearly stated.

Solving the underlying problem (big variety of mental models) means standardizing how we thing about solving programming problems. The GOF book, head in that direction... then again, they become used for the sake of implementing a pattern instead of solving a specific problem. I think this is one of the things that keeps software development in the craft area, as opposed to engineering. but that would be a different rant

Re: Simple Ways of Reducing the Cognitive Load in Code

#105

Post by reikonomusha » Tue, Jun 28, 2016, 3:27 PM UTC

collyw wrote: post #98

Get a decent high level architecture, good, consistent database design and you don't write anywhere near as much application code. Start hacking about using one field for two purposes or having "special cases" and everything starts to get messy. These special one off cases will involve adding in more code at the application level increasing overall complexity. Repeat enough times and you will code a big ball of mud.…

There's relevance in talking about both micro- and macroscopic guidelines. Both are important.

Very rarely does someone "read" an entire code base "with one look" and be able to deduce issues. You do, at some point, have to get into the weeds. Managing that experience is what articles like these are about.

Re: Simple Ways of Reducing the Cognitive Load in Code

#106

Post by kilotaras » Tue, Jun 28, 2016, 3:28 PM UTC

rakpol wrote: post #47

escherize wrote: post #3

I'd like to add one: let your tools do the work for you. It may seem like a pain to learn the tooling behind what you do, but once you internalize it, it becomes a superpower. An example is that I use Clojure Refactor Mode (with CIDER) for emacs. A trick (and treat) that a lot of Clojure code uses is the arrow macros: -> and ->>. Clojure Refactor Mode has thread-first, thread-first-all, thread-last, thread-last-all a…

That's like the function composition operator [1] in Haskell, right? Very neat :D I wonder if there's an equivalent macro in Scala ... [1]: http://lambda.jstolarek.com/2012/03/function-composition-and...

|> from scalaz. API is not that usable though. F# have List.map, List.filter functions for example, which are not present in scala.

Re: Simple Ways of Reducing the Cognitive Load in Code

#107

Post by reikonomusha » Tue, Jun 28, 2016, 3:29 PM UTC

CuriousSkeptic wrote: post #102

reikonomusha wrote: post #94

Earlier quoted context omitted.

It's not incorrect necessarily, just unqualified. Cognitive load is hard to meaningfully substantiate; it is person and experience dependent.

Actually, not at all. It's directly measurable http://www.ncbi.nlm.nih.gov/pubmed/17833905 "The pupil response not only indicates mental activity in itself but shows that mental activity is closely correlated with problem difficulty, and that the size of the pupil increases with the difficulty of the problem"

My problem is precisely that these scientific methods are not used when "cognitive load" is being used as rationale. Wouldn't you agree that it would be a mistake for me to claim that cognitive load is an issue with something if e.g. I have not shown that pupils dilate (or some other reasonable experiment indicating correlation)? Unfortunately, doing these experiments is difficult, which justifies "hard to substantiate."

Re: Simple Ways of Reducing the Cognitive Load in Code

#108

Post by jahewson » Tue, Jun 28, 2016, 3:32 PM UTC

markbnj wrote: post #38

Good advice and worth reading especially for younger devs. With respect to... >> Prefix systems like hungarian notation were initially meant to add meaning, but with time they ended up being used in less contextual ways, such as just to add type information. Hungarian notation was pretty cumbersome to read, actually, and I think the main reason it fell out of use is that editors and IDEs began to make type and declar…

One of the major functions of Hungarian notion was to communicate information which was not contained in the types of the actual variables, for example an int could be a count of bytes 'cb', or perhaps a handle 'h', etc. But it ended up being mostly misused to communicate redundant type information, such as a char* being 'sz' (zero-terminated string), which tells us nothing we didn't already know. As you say, better IDEs made the latter kind of naming no longer advantageous (if it ever was) but that was true for some time before Hungarian notation fell out of favour - the real reason being a rejection of its redundancy within MS during the transition to .NET. Joel Spolsky details the good and bad of Hungarian notation here:

http://www.joelonsoftware.com/articles/Wrong.html

Re: Simple Ways of Reducing the Cognitive Load in Code

#109

Post by signa11 » Tue, Jun 28, 2016, 3:35 PM UTC

robmcm wrote: post #73

signa11 wrote: post #26

Earlier quoted context omitted.

sorry, but given this pre-condition (from gp): > ... a large function cannot be broken up usefully, because a lot of state needs to be shared between the different parts ... there is no way to break that up with multiple smaller functions without stowing away the state somewhere. sometimes reading a large function is not half as bad as reading 10 different ones with each altering the shared state.

state can be passed through as arguments...

Sure, but then there are more questions :) e.g. how many parameters ? 3, 4 ... ? what if they are of the same type ? would you change your numbers then ? users can get the order wrong etc. another thing : if you pass too many parameters, isn't that a hint to the fact that something is amiss ?

edit-1 : fixed typo

Re: Simple Ways of Reducing the Cognitive Load in Code

#110

Post by throwanem » Tue, Jun 28, 2016, 3:37 PM UTC

alisey wrote: post #22

larschdk wrote: post #11

Earlier quoted context omitted.

Shared state between different parts of the code sounds an awful lot like something that could be a class.

Yes, a Method Object pattern http://c2.com/cgi/wiki?MethodObject

Neat! Now I have to refer to an entirely different file (or a different section of this one, which is almost as bad) in order to figure out what this one function is doing.