How to reduce the cognitive load of your code • Hacker News Board

Re: How to reduce the cognitive load of your code

#41

Post by hbt » Tue, Mar 29, 2016, 2:07 PM UTC

naringas wrote: post #11

I used to think that a lot of bad code out there was made by lazy, incompetent programmers... But then, after a certain job, I realized that this is probably not the case. Now I belive that most bad code out thare is made by overworked and tired programmers in a rush to deliver something that works.

The main thing most programmers overestimate is their own working memory i.e the number of things you are retaining when writing a piece of code.

Problem is: working memory is short term. After a few days, you revisit that code and you realize how much it costs to load it all in your head again.

Basically, we need code reviews of code we wrote last week as opposed to code we wrote yesterday.

Re: How to reduce the cognitive load of your code

#42

Post by noelwelsh » Tue, Mar 29, 2016, 2:08 PM UTC

jt2190 wrote: post #17

HerpDerpLerp wrote: post #9

He advocates prefixes on variable names. I would like to see good examples of this as I have never seen them as helpful (especially the tblUsers and intUserId type that can be common) .

Christian points to Joel Spolsky's example of using prefixes to add meaning, not type information like your examples. From Joel's essay: All strings that come from [user input] must be stored in variables (or database columns) with a name starting with the prefix "us" (for Unsafe String). All strings that have been HTML encoded or which came from a known-safe location must be stored in variables with a name starting…

In modern type systems (Haskell, etc.) you can define a new type that wraps an existing type with zero runtime cost. In Haskell you could write

newtype UnsafeString = Unsafe String

(UnsafeString is the name of the type. Unsafe is the constructor you use to create an UnsafeString from the String).

With this and other techniques you can lift these characteristics of you data into the type system, which is IME much more useful than using hungarian notation.

Re: How to reduce the cognitive load of your code

#43

Post by maze-le » Tue, Mar 29, 2016, 2:08 PM UTC

reacweb wrote: post #19

naringas wrote: post #11

I used to think that a lot of bad code out there was made by lazy, incompetent programmers... But then, after a certain job, I realized that this is probably not the case. Now I belive that most bad code out thare is made by overworked and tired programmers in a rush to deliver something that works.

Most of the bad code was made by very productive developers.

This leads to the question what 'productive' really means. If a productive programmer writes a lot of code that isn't maintainable at all, can you really call that person productive? Maybe... but the poor sob tasked with maintaining the code later, will certainly not be called productive.

Maybe productivity should not be regarded isolated from other metrics and/or certain style-considerations.

Re: How to reduce the cognitive load of your code

#44

Post by DonHopkins » Tue, Mar 29, 2016, 2:12 PM UTC

igl wrote: post #21

No one ever mentions formatting. I really like aligning multiline blocks, adding whitespace and useless braces here an there. e.g: Having just a single space between function name and arguments makes it look less like a call. Yet almost all lint presets/defaults forbid this. Typography is all about the whitespace between letters forming easily recognizable shapes.

I like to break lines and use indentation to line up repeated text, so you can see there is repetition, and so the parts that are different are obvious. A simple example:

    if ((mouse.x == 0) &&
        (mouse.y == 0)) {

scores more points than:

    if ((mouse.x == 0) && (mouse.y == 0)) {

Re: How to reduce the cognitive load of your code

#45

Post by hinkley » Tue, Mar 29, 2016, 2:15 PM UTC

I spend a lot of energy discussing this at work, and mostly that has been "continue talking while people look at you like you have two heads"

It feels like maybe people are almost ready to listen now. I don't know how this relates to the number of libraries we use now, or the StackOverflow culture, but I have my suspicions that they are related. Maybe we should start talking about Library Fatigue...

Re: How to reduce the cognitive load of your code

#46

Post by matthewtoast » Tue, Mar 29, 2016, 2:19 PM UTC

Code clutter is much more consequential than it gets credit for. Poor formatting, inconsistent whitespace, snips of unused code, and misleading filenames are speedbumps (or worse, spike strips!) that a developer is going to hit every time they sit down to code.

And unlike bad abstractions -- which you can "learn" about and mentally model -- the friction of clutter is a constant damping to your productivity.

Building features in a cluttered codebase is like being asked to install plumbing in a hoarder's basement.

Understanding a cluttered codebase is like reading an advanced math textbook by candlelight that was written with broken typewriters by a group of modernist poets.

De-cluttering is the first thing you should do, and you should stick to it above all else. Before you add tooling, before you refactor, before you abstract and framework-ize, get rid of the clutter. That means format your code, and use a linter whose rules are based on widely adopted community conventions.

Re: How to reduce the cognitive load of your code

#47

Post by eterm » Tue, Mar 29, 2016, 2:21 PM UTC

igl wrote: post #21

No one ever mentions formatting. I really like aligning multiline blocks, adding whitespace and useless braces here an there. e.g: Having just a single space between function name and arguments makes it look less like a call. Yet almost all lint presets/defaults forbid this. Typography is all about the whitespace between letters forming easily recognizable shapes.

All this is solved by a linter though, there's no point even trying to remember this, just define your linter rules and let it deal with it.

It might not be the default linter styles, but set up your linter for your project and give your mind more important things to focus on.

Re: How to reduce the cognitive load of your code

#48

Post by hinkley » Tue, Mar 29, 2016, 2:22 PM UTC

hbt wrote: post #41

naringas wrote: post #11

I used to think that a lot of bad code out there was made by lazy, incompetent programmers... But then, after a certain job, I realized that this is probably not the case. Now I belive that most bad code out thare is made by overworked and tired programmers in a rush to deliver something that works.

The main thing most programmers overestimate is their own working memory i.e the number of things you are retaining when writing a piece of code. Problem is: working memory is short term. After a few days, you revisit that code and you realize how much it costs to load it all in your head again. Basically, we need code reviews of code we wrote last week as opposed to code we wrote yesterday.

The code I'm working on now, and the code I worked on before that, was designed to be memorized. I suspect the only reason the team is productive is that they are working from long term memory most of the time.

The insidious things about this are twofold. First, it makes all new team members look like idiots. These other guys are getting work done, what's your problem? Our problem is we can't figure out wtf is going on without breaking things to do it.

Second, everyone doing work to fix the problem is a threat, because they are moving code that is memorized.

I honestly don't know how to fix this problem, I used to just walk away but I feel like I should be able to do better than that. Boiling that frog is a long term commitment.

Re: How to reduce the cognitive load of your code

#49

Post by bnegreve » Tue, Mar 29, 2016, 2:22 PM UTC

hyperhopper wrote: post #34

Even the first example is a bit silly. Nobody is going to not understand that (null == foo) is the same as (foo == null).

It does increase the cognitive load for no particular reason. Which is what the author is trying to avoid.

Re: How to reduce the cognitive load of your code

#50

Post by noxToken » Tue, Mar 29, 2016, 2:31 PM UTC

ionforce wrote: post #36

noxToken wrote: post #32

I've found that diagrams help. Young developers (in my experience) tend to laugh at the thought of making UML diagrams. At the very least, a class diagram will tell what classes references what. Using some custom stereotypes can help give further meaning. Ideally, sequence diagrams (or a similar type) can help shed light on just how the project comes together. Explaining how a project works from a high level can leav…

What is a stereotype?

Stereotypes are an extension of UML to include extra information about the class. This[1] is a class diagram (albeit, overly detailed) I created for a library that we used. Above the class names are stereotypes. I know which classes came directly from the library, which are service classes, etc.

[1]: http://i67.tinypic.com/33xyaz4.png