Live data from Hacker News

Code doesn’t have to be a mess

danielsieger.com

31–40 of 190 posts

Re: Code doesn’t have to be a mess

#31
post #6

There's a great section in The Practice of Programming where the book describes how you should structure your code to not just be structured nicely now, but to plan for the future; to structure it so that changes are easy, organized, and don't break anything. It's not exhaustive but it's a powerful general idea and I always like introducing developers to it for the first time.

I must say here that I agree this point but one should also exercise caution that they don't go overboard with abstractions while planning for future. Abstractions for future planning should be lean and flexible enough to be extensible.

Having not read the book OP mentioned, I would say it's important to emphasize that structure does not necessarily mean abstraction. Starting a new project is more like getting groceries and stocking the pantry than it is starting a stew and agonizing over which type of onions to toss in.

Good abstractions evolve naturally out of good structure.

Re: Code doesn’t have to be a mess

#32
post #26

> Say No Getting junior devs to do this is like pulling teeth. Trying to get a feature stopped after they've built it is soul crushing for them. It's a problem. At this point I've all but given up beyond minimizing the blast radius in code review.

There ought to be a Zen lesson hidden here somewhere.

Perhaps tech companies could have kickoffs/workshops where the participants would create sand mandalas together?

Re: Code doesn’t have to be a mess

#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 all the entry points and follow the flow of code from beginning to the thing I am interested in.

One person's beauty is another person's mess.

It's harder to change an existing codebase than to write a simple program that does the new thing but not in the context of the original program. A reference implementation of the various components is far easier to understand than one big ball of mud. Fitting problems together is hard. You need to understand the old thing before you can introduce the new thing and it ends up being forced or hacked in if the design doesn't support the new thing.

I tend to write reference implementations of everything, then combine them together as a separate project.

I find an empty file far more reassuring than a large codebase.

Re: Code doesn’t have to be a mess

#34
post #32
post #26

> Say No Getting junior devs to do this is like pulling teeth. Trying to get a feature stopped after they've built it is soul crushing for them. It's a problem. At this point I've all but given up beyond minimizing the blast radius in code review.

There ought to be a Zen lesson hidden here somewhere. Perhaps tech companies could have kickoffs/workshops where the participants would create sand mandalas together?

Depends. Can I put the mandala in my promo packet or not?

Re: Code doesn’t have to be a mess

#35
In my personal experience a lot of the mess stems from complex layer-to-layer interactions. Within my own modules I'm pretty good at keeping things clean but marshalling data from C# to C++ (or Python to C or this lib to that lib) is where I get sad. Or mapping return and error codes, or catching exceptions etc....

The cleanest code I write is for embedded systems without an OS, basically a sparkling gem of refactored goodness.

Re: Code doesn’t have to be a mess

#36

> Minimize Dependencies ... Consider doing it yourself. This is terrible advice! Maximize your dependencies. Adopt as much external code as possible. Build what you can with it. Then, as you reach the limits of those dependencies, and you absolutely understand what needs to get done replace them as you need to. The vast majority of what people write will be trashed and/or changed radically. You should adopt whatever…

It sounds like you work in prototyping, which is cool, but a lot of us work in engineering and need more control and surety in the fit, quality, durability, and predictability than we can expect to find in the work of some stranger with no accountability to or insight into our project.

Re: Code doesn’t have to be a mess

#37

In my personal experience a lot of the mess stems from complex layer-to-layer interactions. Within my own modules I'm pretty good at keeping things clean but marshalling data from C# to C++ (or Python to C or this lib to that lib) is where I get sad. Or mapping return and error codes, or catching exceptions etc.... The cleanest code I write is for embedded systems without an OS, basically a sparkling gem of refactore…

Drawing the line for separation concerns is one of the hardest things to do well in CS.

Re: Code doesn’t have to be a mess

#38

> Minimize Dependencies ... Consider doing it yourself. This is terrible advice! Maximize your dependencies. Adopt as much external code as possible. Build what you can with it. Then, as you reach the limits of those dependencies, and you absolutely understand what needs to get done replace them as you need to. The vast majority of what people write will be trashed and/or changed radically. You should adopt whatever…

When the dependency is deprecated, I have to stop what I'm doing and replace the dependency. If the dependency has a show-stopper bug, I either have to wait, vendor the dependency, or rewrite. That's what the original article advocates for: be careful what you import. leftpad, probably write it yourself. React, OK to use, but maybe vendor.

Yeah, dependencies makes you dependent :D

Re: Code doesn’t have to be a mess

#39

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 try to encourage newcomers to refractor the code into a form they understand, fix the problem and then undo that refactoring as much as possible. If they actually come up with a better abstraction I'm up for it.

Refactoring will give them the chance to see what the actually moving parts of code are.

Re: Code doesn’t have to be a mess

#40
post #26

> Say No Getting junior devs to do this is like pulling teeth. Trying to get a feature stopped after they've built it is soul crushing for them. It's a problem. At this point I've all but given up beyond minimizing the blast radius in code review.

Why are people going directly to your junior devs for feature requests?
Post reply on HN