Live data from Hacker News

Code doesn’t have to be a mess

danielsieger.com

151–160 of 190 posts

Re: Code doesn’t have to be a mess

#151

In my experience people refactor code to their own understanding of the problem and not all refactorings improve the code. People abstract before an abstraction is necessary. I find single file dense leetcode style code easier to understand and follow the flow. Algorithmic code I can reason around. A large mature codebase is far harder to get to know. One of the first things I do when I study a new codebase is find a…

>I find single file dense leetcode style code easier to understand

I find it really difficult to go through huge chunks of iterative code. I need abstractions otherwise I can't get my head around it. I often wind up refactoring into manageable chunks (even in pseudocode/diagrams) just so I can understand stuff.

For reference, my cognitive abilities are heavily skewed towards verbal/abstract reasoning - like several standard deviations above the norm - and my spatial/concrete reasoning is nearly the inverse of this, it's terrible.

I wonder if this has something to do with it!

Re: Code doesn’t have to be a mess

#153

In my experience people refactor code to their own understanding of the problem and not all refactorings improve the code. People abstract before an abstraction is necessary. I find single file dense leetcode style code easier to understand and follow the flow. Algorithmic code I can reason around. A large mature codebase is far harder to get to know. One of the first things I do when I study a new codebase is find a…

> People abstract before an abstraction is necessary.

Sometimes an abstraction cuts to the core of the reason why.

See for example https://algebradriven.design/

Good abstractions can communicate intent better than mounds of concrete code because they speak at a higher level.

However, mounds of okay concrete code is way easier to deal with then poorly thought out abstractions.

This means pragmatists get little practice in abstractions, where their pragmatism is needed most to uncover the useful abstraction and avoid the overly complex invented abstraction.

Abstract code also has the advantage of parametricity in strongly typed programming languages.

Re: Code doesn’t have to be a mess

#154
post #151

In my experience people refactor code to their own understanding of the problem and not all refactorings improve the code. People abstract before an abstraction is necessary. I find single file dense leetcode style code easier to understand and follow the flow. Algorithmic code I can reason around. A large mature codebase is far harder to get to know. One of the first things I do when I study a new codebase is find a…

>I find single file dense leetcode style code easier to understand I find it really difficult to go through huge chunks of iterative code. I need abstractions otherwise I can't get my head around it. I often wind up refactoring into manageable chunks (even in pseudocode/diagrams) just so I can understand stuff. For reference, my cognitive abilities are heavily skewed towards verbal/abstract reasoning - like several s…

> find it really difficult to go through huge chunks of iterative code. I need abstractions otherwise I can't get my head around it. I often wind up refactoring into manageable chunks (even in pseudocode/diagrams) just so I can understand stuff.

Understanding lots of code at a module, function, or even more granular level with a magnifying glass feels more productive than struggling to understand the full picture.

It also rewards you with instant gratification. Reading and writing ncrete code gives much more immediate gratification.

Re: Code doesn’t have to be a mess

#155
post #101

In my experience people refactor code to their own understanding of the problem and not all refactorings improve the code. People abstract before an abstraction is necessary. I find single file dense leetcode style code easier to understand and follow the flow. Algorithmic code I can reason around. A large mature codebase is far harder to get to know. One of the first things I do when I study a new codebase is find a…

> People abstract before an abstraction is necessary. This one really frustrates me. Write code to the complexity level needed to solve the problem, and nothing more. The only time I'd break from this is if I know for certain that the added complexity is going to be necessary in the near term. > ... not all refactorings improve the code. While true, I have a low tolerance for code that requires constant bug fixing, o…

>> People abstract before an abstraction is necessary.

> This one really frustrates me. Write code to the complexity level needed to solve the problem, and nothing more. The only time I'd break from this is if I know for certain that the added complexity is going to be necessary in the near term.

No, the ecosystem the code exists in and my ability to reason about the codebase is worth way more than any gain that comes from blindly stacking "simplest solution for problem a, b, .. z" atop one another without regard for higher level understanding of a codebase.

Re: Code doesn’t have to be a mess

#157

Earlier quoted context omitted.

> I find single file dense leetcode style code easier to understand and follow the flow. Algorithmic code I can reason around. A large mature codebase is far harder to get to know. I genuinely can't tell if you're being serious or not. If you are, do you also like to read books written as one giant chapter? Or entire chapters as one giant paragraph?

At one point in time I used OpenGrok to try understand large projects. Without documentation I find large projects difficult to understand. There's literally too many global symbols and I cannot see the forest for the trees. What's the model of this program? What are the core principles that the author is using? Do I really need to read every file to understand what is going on? With Leetcode style programs there's o…

> Without documentation I find large projects difficult to understand. There's literally too many global symbols and I cannot see the forest for the trees.

Good abstractions let you see the shape if the forest.

Most "good code" or "simple code" is an inedible potluck of "simplest solution for the problem at the time" with some documentation.

Actual good code has intention revealing abstractions that communicate the essence of the problem and problem domain.

Re: Code doesn’t have to be a mess

#158

Earlier quoted context omitted.

>> things grouped nicely together fixed it for ya :) I'm a maintenance programmer. Even working layers of layers of layers above the actual shit does not make it not stink. >> jumping around ...should be intuitive and joyful, not a disaster to your brain. EDIT: I am a fan, though, of SOC. I guess enterprisey code tries to be that (but fails hard at it).

Okay, great. You are a maintenance programmer. You have a 1000-line program all in one file. You need to update the e-mail functionality of this program. You aren't following a stack trace or following a particular code path. There are 15 or 16 different e-mail related functions. How do you find the e-mail function you need to update? Do you memorize line numbers? Use regex search? Do you have vim marks setup?

If you have 15 or 15 different e-mail related functions spread across a whole bunch of files, how do you find the one you need to update?

Re: Code doesn’t have to be a mess

#159

In my experience people refactor code to their own understanding of the problem and not all refactorings improve the code. People abstract before an abstraction is necessary. I find single file dense leetcode style code easier to understand and follow the flow. Algorithmic code I can reason around. A large mature codebase is far harder to get to know. One of the first things I do when I study a new codebase is find a…

If you are out there and WANT to write terrible code, An amazing essay: https://cs.fit.edu/~kgallagher/Schtick/How%20To%20Write%20Un... I cried the first time i read this.

Re: Code doesn’t have to be a mess

#160
post #101

Earlier quoted context omitted.

> People abstract before an abstraction is necessary. This one really frustrates me. Write code to the complexity level needed to solve the problem, and nothing more. The only time I'd break from this is if I know for certain that the added complexity is going to be necessary in the near term. > ... not all refactorings improve the code. While true, I have a low tolerance for code that requires constant bug fixing, o…

>> People abstract before an abstraction is necessary. > This one really frustrates me. Write code to the complexity level needed to solve the problem, and nothing more. The only time I'd break from this is if I know for certain that the added complexity is going to be necessary in the near term. No, the ecosystem the code exists in and my ability to reason about the codebase is worth way more than any gain that come…

I was not implying a lack of understanding of the ecosystem/codebase or to blindly stack "simplest solutions" on top of each other. I was stating that one should not add more complexity than is necessary for the problem at hand. Often people solve a simple problem with a complex solution due to some hypothetical future problem they've conceived in their mind. Most of the time these hypothetical problems never materialize, and they are now stuck with code that is much more complex than it needed to be.
Post reply on HN