Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to reduce the cognitive load of your code

chrismm.com

Post reply on HN
Print view View original

131–140 of 239 posts

Re: How to reduce the cognitive load of your code

#131

Post by SpaceCadetJones »

glhaynes wrote: post #113
strommen wrote: post #109

Earlier quoted context omitted.

Based on your list of how you like to write English, I agree. But I think your list is way off-base when it comes to human languages. The beauty of human language is that it allows us to express our individuality as humans. There are an infinite number of ways to write the same thing, and each author can have a unique style based on how they choose their words, structure their sentences, etc. This is fantastic, and i…

Wouldn't want a novelist to strictly follow that list, but I wouldn't mind a technical writer doing so.

Yes, with technical writing I (generally) just want the author to help me get the information into my mind with minimal cognitive effort. There are times where being poetic can help, such as selling me on a new programming model, but most technical writing out there is too long winded for my taste.

Re: How to reduce the cognitive load of your code

#132

Post by vitd »

gknoy wrote: post #117
msluyter wrote: post #75

Earlier quoted context omitted.

Re: "null != variable": I don't think it's necessarily confusing, it's just that usually we tend to think of the elements we're working with (variables, objects, functions, etc...) as taking on values, and so linguistically, we ask "is my thing null?" Not, "is nullness something that applies to my thing?" Hence "thing operation value" is arguably cognitively cheaper than "value operation thing." So you could argue th…

I think the point was, that as soon as you are aware that typos of "=" and "==" are common, and hard to catch mechanically, the _habit_ of using the (constant == myvar) pattern can suddenly be seen as having more value as a hedge against human error. I'd rather write it that way, and then later change it in code review to `(myvar == constant)`, than risk writing it as `(myvar = constant)` and have it sneak through. G…

For me the _habit_ of using (constant == mylar) is way harder to get used to than using "=" vs "==", which the compiler will warn me about if I mess it up.

Re: How to reduce the cognitive load of your code

#133

Post by lotyrin »

lostcolony wrote: post #128
msluyter wrote: post #95

Earlier quoted context omitted.

Well, sure, but that's why you don't share project files. I think that if you do things correctly, your concern is mostly mitigated. My last job was Java/Spring. As someone noted above, you really don't want to be working with Java/Spring without IntelliJ. But we never had issues with anyone breaking builds due to screwing up project files, because those weren't shared and the project would run/build/test immediately…

Sure. Does it require a specific IDE then? Does it cleanly import, from scratch, with working tests and etc, regardless of whether they're using Eclipse, IntelliJ, Netbeans, etc? Or is there One True IDE? Is that IDE available everywhere you have to touch code? Is it straightforward to integrate it with your CI/CD tools, despite conforming to that IDE convention? Will it continue to cleanly import after you've left t…

The idea is that you still conform to the convention of the project (Rails, Spring, etc.), not the IDE, and the FOSS CLI tools etc. can still understand the project, but so does the IDE (because it is made to understand the convention, e.g. how the annotations/XML files work, how to get a list of all your Rake tasks).

By not sharing IDE project files, not having any IDE-specific machinery in the project, but still expecting CI to be able to run it, being able to theoretically hack on the project and get results (build, test) even with just bash and grep and nano, you get the best of both worlds.

Modern IDEs are better at this than they ever used to be. I was really anti-IDE for a long time, but JetBrains' products made it make sense finally.

Re: How to reduce the cognitive load of your code

#134

Post by st3v3r »

hinkley wrote: post #48
hbt wrote: post #41

Earlier quoted context omitted.

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…

Walk away. Life is far too short to have to deal with that crap.

Re: How to reduce the cognitive load of your code

#135

Post by st3v3r »

ktRolster wrote: post #67
mathattack wrote: post #25

Earlier quoted context omitted.

It's both. Some of my worst code was to look at someone else's code after a manager shouted "FIX THIS NOW!!!" with some kind of quick and dirty hack, and then never going back to get it done right. I'm pretty sure this happens independent of whether or not I am any good. :-)

When you're really good, you learn to FIX IT NOW while also not making a hack. Your code becomes flexible enough to handle that kind of change.

That's assuming it's your code. Most of the time it's not your code. While one would hope that the rest of the team writes flexible code as well, that's not always the case.

Re: How to reduce the cognitive load of your code

#136

Post by st3v3r »

protonfish wrote: post #64
JoeAltmaier wrote: post #57

Earlier quoted context omitted.

Isn't that just another philosophy? Lets be more charitable. Engineers are given limited time to do any job (time == money). So they do what they can. Mostly on a budget.

The bad code I see isn't because someone was in a rush - it's because somebody spent a lot of time and effort to make it a mess. I swear 80% of developers don't know the difference between clear, elegant, readable, and modular code and a giant pile of mess. This is why I've stopped encouraging team members to refactor; the end result is most often worse.

Part of that is that any 3 developers will have 4 different opinions on what is clear, elegant, and modular, and what is a giant pile of mess.

Re: How to reduce the cognitive load of your code

#137

Post by the_af »

lostcolony wrote: post #130
norswap wrote: post #59

Like often with this kind of article it barely scratches the surface. "null != variable" will confuse people is downright silly. People confused by this won't have an inkling of what any non-hello-world program does. The rest has some validity, but it focuses on syntax and programming in the very small. It might take a bit of effort, but I can make sense of a tangled function (that's not an excuse to code sloppily th…

I think you're reading too much into 'confusing'. It won't leave someone without understanding; it -may- cause them to momentarily pause, going "WTF?...uh...probably does ~this~. But why would someone do things this way?" That's still delaying them, that's still distracting them, that's still putting up an obstacle. Not one a future maintainer can't overcome, but -why do it-? That's the point.

It seems like a reading micro-optimization to me, though. Surely most of the delays in understanding code lie in things other than "Yoda" conditionals. I'm going to guess complexity elsewhere in the code (even conceptual difficulties, such as "what is the purpose of this at all?") dwarf minor details like how one writes conditionals. If so, what is the point of this piece of advice?

Re: How to reduce the cognitive load of your code

#140

Post by jimbokun »

msluyter wrote: post #88
jimbokun wrote: post #72

"Avoid using language extensions and libraries that do not play well with your IDE. The impact they will have on your productivity will far outweigh the small benefit of easier configuration or saving a few keystrokes with more terse syntax." This is the main reason to avoid Spring. Having so much critical code in XML and properties configuration files, annotations, and magical interfaces that somehow sprout implemen…

Interesting. Are you familiar with IntelliJ? My experience has been that its Spring integration provides most of what you're asking for.

IntelliJ is amazing, and the only way I can function at all with our code base.

But there are definitely still times when Spring manages to elude even IntelliJ. How anyone thought "magically appearing interface implementations with no code" was a good idea still baffles me.

Post reply on HN