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

191–200 of 239 posts

Re: How to reduce the cognitive load of your code

#191

Post by collyw »

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 completely agree. While the small things do make things easier or more difficult, the architecture can make an order of magnitude more difference.

The last two applications I have inherited are horrendously over complex and they are performing relatively simple tasks. Far too many joins done at the application level. The front page of the current application I am working on makes over 1000 calls to the database. I don't think it needs more than one for the main part. (And if the logic is really so complex that it can't be done in the database, that's a sign that the database schema probably needs updated.)

Re: How to reduce the cognitive load of your code

#192

Post by jernfrost »

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…

Yeah that struck me as an exceptionally minor thing to care about. Seriously we got way bigger problems than this in most code: reams of code duplication, 10 classes deep inheritance hierarchies, monster classes, 2 pages long methods.

In fact one of the most counterproductive things I have seen at work is people arguing at length about tiny details in the code standard and wasting hours work and goodwill.

My take on this is, you give people advice on why a code standard is good to follow. But if they insist on tiny little quirk, let it be. It is not worth fighting over. The whole development community is full of people with all sort of little quirks.

At the end of the day we got to get stuff done, and you have to weigh the benefits of stepping on somebody's toes against what you gain from it.

Re: How to reduce the cognitive load of your code

#193

Post by emiliobumachar »

matthewtoast wrote: post #46

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…

What's a Linter?

Re: How to reduce the cognitive load of your code

#194

Post by collyw »

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.

I constantly tried to get the same problems (a "temporary solution") fixed in my previous job, but it was always put off until next month, as something more urgent came up. I wasted around 1/4 of my time cleaning data as a result, and that led to really low productivity because of all the interruptions it caused - I hardly ever got into the flow. Three years on, and I realised it was time to leave. It would have only taken me 3 -4 weeks to replace the crap code with something better, but instead my developer productivity was probably around 1/4 of what it could be for 3 years because of constant firefighting and dealing with unvalidated data going into the database and the firefighting / cleanup that it required.

Re: How to reduce the cognitive load of your code

#195

Post by jernfrost »

protonfish wrote: post #52
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.

In my experience, most bad code is written by dogmatic cargo cult programmers that are more interested in writing code that adheres to their pet development philosophy or framework instead of programming to solve a problem in the simplest way possible.

Think we all got different experiences there. My main problems have been with people who insist on just churning out features in the most straightforward way without doing any kind of upfront thinking. You end up with reams of copy past coding, code duplication and so much code that it is very hard to keep track of what is going on.

Like e.g. if you are parsing a file, and it is complicated you can save a lot of time and give a lot more clarity if e.g. you use some form of state machine or look into a little bit of theory of textual transformations and representations.

I mean I have seen people managing a forrest of state variables and who have never heard about regular expressions or any kind of methodology on how to deal with text formats.

You end up with a crap load of messy unmaintainable code.

But of course it is also a problem when people turn every operation into a ceremony involving factories, command objects and any design pattern you can think of. In the Java world that seems like a common problem. I think my own philosophy aligns more with how Go libraries are written. They are pretty simple and straight forward. They use smart approaches were needed but don't insist on adding indirections, encapsulation etc everywhere.

Re: How to reduce the cognitive load of your code

#196

Post by JoeAltmaier »

collyw wrote: post #194
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.

I constantly tried to get the same problems (a "temporary solution") fixed in my previous job, but it was always put off until next month, as something more urgent came up. I wasted around 1/4 of my time cleaning data as a result, and that led to really low productivity because of all the interruptions it caused - I hardly ever got into the flow. Three years on, and I realised it was time to leave. It would have only…

So common! My friends gave notice. In his remaining time he rewrote the data-onboarding-and-sanitizing code for performance (something that there was never time to do) and reduced it from 2 days to 2 hours. Which probably had a larger impact than anything else he'd done in his entire time there.

Re: How to reduce the cognitive load of your code

#197

Post by collyw »

mathattack wrote: post #25
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.

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. :-)

I was having this dilemma on my walk home. I try to write good idiomatic Django code, and know how to make it efficient in the ways described in Two Scoops (a book about Django best practices). I have inherited an app, parts of which are exactly the opposite of Django best practices (thin models fat controllers being the most obvious one - the application's documentation says that's the philosophy , while Django encourages, and works better the opposite way).

So do I spend more time refactoring and bringing this application to a decent state, or do I just keep on hacking more crap on to it? No one except for me seems to give a shit as long as it seems to be working.

Re: How to reduce the cognitive load of your code

#198

Post by the_af »

mreiland wrote: post #170
the_af wrote: post #137

Earlier quoted context omitted.

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?

> It seems like a reading micro-optimization to me, though. It's a "reading micro-optimization" in the same way that not littering your code with comments is a "reading micro-optimization". It makes you pause and interrupts your flow of thought as you contemplate something not directly related to what you were modeling in your head 2 seconds ago.

I don't think it's the same. I'm not arguing against code cleanliness or good practices. Code readability matters. I favor concise, expressive languages over verbose ones for precisely this reason.

Littering your code with comments IS a huge readability problem. You are forced to filter them out to find the real code, since they are mostly garbage, but you can never be sure you aren't skipping some vital bit of information. Likewise, boilerplate and needless ceremony obscure the intent of the code, so they are obstacles to be reduced in good, clean code.

Contrast this with writing Yoda conditions. They are no big deal. They interrupt your flow of thought exactly once: the first time you encounter them. If your train of thought is interrupted every time you encounter them, you are way too novice a programmer. So I think this is a really minor issue in the sea of software complexity; so minor, in fact, that it seems bizarre to me to mention it.

I think whether to use Yoda conditions, much like the placement of braces or the number of whitespaces for indentation, are the stuff of flamewars and endless argument because they are the kind of things we programmers love to obsess about, but they are really not very important.

Re: How to reduce the cognitive load of your code

#199

Post by JoeAltmaier »

collyw wrote: post #197
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. :-)

I was having this dilemma on my walk home. I try to write good idiomatic Django code, and know how to make it efficient in the ways described in Two Scoops (a book about Django best practices). I have inherited an app, parts of which are exactly the opposite of Django best practices (thin models fat controllers being the most obvious one - the application's documentation says that's the philosophy , while Django enco…

A rewrite is a different animal than writing new code. The problem with rewrites is the marginal utility is a diminishing return. Unless the code is really bad, or will require very frequent revisits.

Re: How to reduce the cognitive load of your code

#200

Post by mathattack »

collyw wrote: post #197
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. :-)

I was having this dilemma on my walk home. I try to write good idiomatic Django code, and know how to make it efficient in the ways described in Two Scoops (a book about Django best practices). I have inherited an app, parts of which are exactly the opposite of Django best practices (thin models fat controllers being the most obvious one - the application's documentation says that's the philosophy , while Django enco…

I think the best practice is to just refactor the bits that you need to touch. At a minimum avoid leaving them worse, and in an ideal world leave each piece you touch better for your having looked at it.
Post reply on HN