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

Code doesn’t have to be a mess

danielsieger.com

Post reply on HN
Print view View original

161–170 of 190 posts

Re: Code doesn’t have to be a mess

#161

Post by ParetoOptimal »

twawaaay wrote: post #69

I think this is terrific advice. Over decades I have compiled my own list which contains all these and bunch of other behaviours that are needed for successful project. I would add one or two very important thing missing from the list. One, not explicitly mentioned but covered in other points is to plan for simplicity . Make simplicity an explicit goal of the project and set up process to remind of it at various impo…

> Make simplicity an explicit goal of the project and set up process to remind of it at various important points in the process.

Which altitude of simplicity is most valuable?

Re: Code doesn’t have to be a mess

#162

Post by fjdbeb76 »

hinkley wrote: post #140
layer8 wrote: post #135

Earlier quoted context omitted.

It means communicating something quite clearly but by indirect means (and possibly inadvertently).

I've had this argument in code reviews a couple of times: Them (on the subject of 4 new methods): hey why did you make method 3 look "weird"? You should make it look like the other three. Me: because one of these methods can set the building on fire, and the rest can't. I bet you can guess which one is the dangerous one. Works as expected.

No post body was provided.

Re: Code doesn’t have to be a mess

#163

Post by codethief »

samsquire wrote: post #33

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…

> In my experience people refactor code to their own understanding of the problem and not all refactorings improve the code.

That's a great point. I once read (here on HN I think) that the value behind a piece of software is not the code but the team whose members all have the same mental model of the problem and can successfully map it to the code. Lose the team and you lose that map.

> One of the first things I do when I study a new codebase is find all the entry points

I follow the same strategy but… Good luck with that when you're facing a Spring application. :)

Re: Code doesn’t have to be a mess

#164

Post by xedrac »

zelphirkalt wrote: post #107
xedrac wrote: 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…

> 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. Mastery will be, when you write code in a way, that does not impose unwarranted limitations from the start, and still keep it readable and only containing mandatory complexity.…

We write abstractions to tame complexity. But abstractions themselves are inherently a form of complexity. A good abstraction may be simple to use, understand, and extend, but it can also make it harder to understand or debug issues because underlying data/state has been obscured. I agree that making anything "black and white" is a mistake. I merely said what I said because in my experience, most developers tend to abstract things that don't benefit anyone, and add unnecessary complexity. Besides, if you're writing an abstraction for a future hypothetical problem, chances are that you don't have enough information to create a good abstraction, and you're going to have to redo it anyway.

Re: Code doesn’t have to be a mess

#165

Post by [deleted] »

ParetoOptimal wrote: post #161
twawaaay wrote: post #69

I think this is terrific advice. Over decades I have compiled my own list which contains all these and bunch of other behaviours that are needed for successful project. I would add one or two very important thing missing from the list. One, not explicitly mentioned but covered in other points is to plan for simplicity . Make simplicity an explicit goal of the project and set up process to remind of it at various impo…

> Make simplicity an explicit goal of the project and set up process to remind of it at various important points in the process. Which altitude of simplicity is most valuable?

[deleted]

Re: Code doesn’t have to be a mess

#166

Post by Izkata »

lowercased wrote: post #90
camgunz wrote: post #71

Earlier quoted context omitted.

My irritation comes from that decision/realization happening after we already devoted engineering time to something--the most expensive time to reverse yourself.

I've hit this many times over the last 20+ years, and have come to recognize/accept that most people can not really grok something until they can 'use' it in some capacity, often with 'real' data. Clickable wireframes, design sessions, mockups, etc - they can all help explore ideas before code, and potentially save things. I've had numerous examples where I can identify "this is confusing" or "this doesn't solve the…

Years ago we had an open session for how to display some unintuitive data on one of our websites, and while few outside the dev team participated, theirs combined with devs' ideas resulted in around 5-10 totally different designs. Mine was one of the first eliminated, most people thought it was weird and confusing. Four months later, after developing and putting the two top-voted ones in front of users and finding they still didn't understand it, our designer came up with basically what I originally suggested, with a few tweaks to make it look nicer. We've kept that version since then.

That was a frustrating period.

Re: Code doesn’t have to be a mess

#167

Post by arwhatever »

wefarrell wrote: post #75

Personally I think the most important thing to minimizing code complexity is ensuring that it understandably maps to the business logic. The business logic is the essential complexity and everything else can be seen as waste. The first step is getting the lexicon right. Frequently the business lexicon is ambiguous in such a pervasive way that the people immersed in the business aren't aware of the discrepancies. For…

It’s almost as though business and software development within a company should agree on a ubiquitous language to describe concepts, and when it becomes too difficult to build a single unified model to define individual concepts, then perhaps the core domain should be split into bounded contexts … (and so on)

Re: Code doesn’t have to be a mess

#168

Post by eyelidlessness »

b3morales wrote: post #84
eyelidlessness wrote: post #19

Earlier quoted context omitted.

In probably my favorite software-related talk[1] (certainly the one I most frequently share), this is referenced as “functional core, imperative shell”. 1: https://www.destroyallsoftware.com/talks/boundaries

Does anyone know of a transcript of this talk? There is a link on the YouTube copy of the video, but it seems to be dead.

Thank you for asking. I regret posting this without looking for a transcript first, especially since my capacity for consuming video/audio content has declined as rapidly as a lot of topics I’d be interested in have embraced video. I may well contribute to transcribing it if I find some free cycles.

Re: Code doesn’t have to be a mess

#169

Post by jiggawatts »

Something that shocked me was working with junior programmers for the first time. For decades, I had either worked solo or with other experienced developers.

It was an eye-opening experience.

My style is influenced by Haskell and Rust, even when I program in, say, C# or PowerShell.

A simple example: I will extract the read-only logic into a pure function and minimise the size of the mutable procedure. This makes it trivial to test the logic in isolation without triggering any side effects. Similarly, the logic can have convoluted control flow but the imperative code can then wrap that with a single try-catch block, transaction, or retry loop.

For me this was such second nature that I didn’t even realise I was doing it until I saw the imperative spaghetti written by the juniors. I tried to explain with pair programming sessions what the benefits are of my approach.

Without fail, they would just “hack something” into the existing spaghetti, adding yet another mutable global variable to track some new state.

In every case they said they were in a hurry and that they would “fix it later”.

I replied: “there is no later.”

Re: Code doesn’t have to be a mess

#170

Post by switchbak »

hinkley wrote: post #45
samsquire wrote: post #33

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…

Maybe I'm weird but a lot of my refactoring actually concretizes overly abstract code. It's easier to think about adding functionality to a block of code when you acknowledge that at the moment it only does 2 things, rather than using obscure wishy-washy language that implies it could do a dozen things. Where I'm definitely weird is that I have a higher verbal score than your typical developer, and I'm not afraid to…

I think I'd like working with you.

Overly generic code is often pre-emptive, and most times the day never comes that you need that flexibility. And often when you do, you discover you need flexibility along a different axis anyway.

And most of what we do is story telling: what were the requirements we understood? What is our model to solve it? What are some precise examples that show it working in different capacities? When people treat the code as simply "the thing the computer interprets", instead of "the thing the next person has to comprehend", you get this inevitable slide into incomprehensible code.

Unfortunately our profession is obsessed with outdated approaches to (premature) performance optimization, and an addiction to being "clever".

I think I'd much rather surround myself with driven folks that have empathy and a strong desire to be understood. That's a long way from the programmer stereotype I'm familiar with.

Post reply on HN