________________________________________________________________________________
Comments from the original posting:
https://news.ycombinator.com/item?id=11093733
Comments from the repost 4 months ago:
https://news.ycombinator.com/item?id=23914486
The best code is the code you don't write.
I'll sometimes spend a couple of hours on a method, removing unnecessary code.
It does NOT always end up with more performant code (sometimes, the opposite), but it does reduce the "I don't wanna remove _all that code_" surface, and it usually* makes the code easier to understand.
> The best code is the code you don't write.
I envision your comment will be taken out of context to literally justify adding mountains of code written by other people. _Invented Here Syndrome_
:) Never even thought of that.
Not _necessarily_ a bad thing, if you are good at selecting dependencies.
But it can be a very, _very_ bad thing, if you are not so good at selecting dependencies.
I've seen both cases (people over-avoiding dependencies to detrimental levels, and people who are VERY bad, and very zealous, at selecting dependencies). While I think it varies per language community; overall, the latter seems more common.
That said, the worst codebases I've worked with were examples of the former. So it's definitely a tricky balance.
My codebases can be difficult to maintain (I know, because I'm the one that has to maintain most of them).
It's not because the code is bad. Quite the opposite, really. It's well-structured, and _incredibly_ well-documented.
It's because I tend to do some fairly ambitious things, and write in a modular, layered fashion that can distribute functionality throughout the stack.
I also tend to write in a fairly asynchronous fashion (would you call it "reactive"? I dunno. I've been writing code like that since long before "reactive" was an official buzzword).
Can be hard to grok.
I TOTALLY agree. As Solution architect, sometimes my work is
+ simplify it
+ reduce it
+ make the code more readable
When not possible, make at least more readable, like choosing the right method & variable names.
I feel this is somewhat muddled in push. I agree with all of the items, but I don't agree with how folks often pursue it.
My specific concern is where it pushes that a big ball of mud is easy to write, but hard to maintain. I agree, but oddly, a ball of mud is also somewhat easier to delete. Such that, it is best to grow your code from that core and only grow to reusable parts if needed.
I encountered this at work recently. I fully agree that reusable and "single responsibility" is nice. However, to extract out 5 lines of code such that we now have 3 new classes and possibly a new dependency seems the opposite of the spirit here. If we ever got where that logic isn't needed, as is, you delete 5 lines of code. In the "abstracted out" world, you have to delete several classes, making sure nobody else had taken a dependency on it.
I get that counting by lines of code is not the best metric, but it is an easy one. And, in general good faith code, the lower that metric, the better. It is less to read. Less things connected together to reason about. And, less stuff that you could delete in the future if able.
The problem with removing ball of mud code is that you don't know much of that mud is entangled with useful code.
I do think oop design patterns bring a lot of indirection sometimes but atleast we can use small well thought out functions instead of connecting all things inside one giant one
That is true of all code you delete. It had some use, or it would never have been added in the first place.
I'm not arguing for the entire thing to be a ball of mud. Just pushing that there are trade-offs. And, in general, less code is better code. Even if it is a larger method.
Granted, I think a lot of this is in strawmen. Breaking 5 lines out of a 40 line method so that you can be better abstracted is usually fighting the wrong things. Breaking it out of a 500 line function is different.
This is a pattern that's used in other fields too, e.g. electronic music:
_When Brian Eno lectured at RBMA in New York a couple of months back, he described [James] Blake as an artist who “works mostly by subtraction, he takes lots of stuff out and ends up with very skeletal pieces.” _
_Blake watched the Eno lecture yesterday, and he nods avidly when I repeat this analysis of his working process back to him. “One part [of a song] that doesn’t mean anything really pisses me off. Genuinely, it irritates me if there’s something that doesn’t need to be there. The thing is, it happens in other music as well; I’m not too fascist about it when it comes to other people’s music, but when it comes to mine I really try to do a spring clean on the track, to make sure that everything that needs to be there is there, and nothing extraneous is left just buzzing in the background, clattering and distracting me from the main idea."_
https://www.dummymag.com/features/james-blake-interview-song...
This is actually a different thing, though. This is pruning a working piece down to a smaller one. Kind of like gardening by only weeding. It works, but only if you have a full set of crops naturally.
This idea seems more to be about planting crops in such a way that you can remove them easily from a garden.
One of the hardest aspects about maintaining an in-house system at a small company can be refraining yourself from removing code that would decrease the company's tech debt. Most managers don't want to admit the smart code they wrote three years ago causes more problems than it solves, and it can get really awkward.
Managers at my small company don’t last three years
I have seen the "not too bright but durable manager" pattern at a few jobs now. They are usually the only (former) developer who has been at the company for more than 3 years, and the main reason they are your manager is that the CEO knows they are not going away any time soon.
I think thats' the hidden goal of modular programming.. or functional programming to an extent. Have easy variability to allow for easy adjusting to converge to an optimal solution.
https://github.com/kelseyhightower/nocode
What's up with the issues page on that project? There's many that are just random chinese characters?
Seems more like random Chinese sentences, based on Google translate anyway. Which seems inline with all the other issues posted in English. I think people are just screwing around making jokes/memes on a joke/meme repo. Take this issue in English for example: "The cow has eaten the grass and gone, so there is nothing left" -
https://github.com/kelseyhightower/nocode/issues/4201
I always tell people that “deleted code is the best code” but it takes a lot courage to delete code from an existing code base.
Excellent.
I just want to add that "Programming Pearls" by Jon Bentley is a treasure and (although it might not seem like it) has a lot to add to this sort of consideration (the slow painful evolution of elegant programming.)
If you write code, write code that is easy to read. If you can understand the code you are changing you are in a very good position to manage it.
I’d have another suggestion: Don’t break the back button on your CSS-free blog.
This is arguably easy to avoid, yet people manage to do it.
In what way is it broken? I was able to follow several links on their site and then use the browser's back button to get back to HN.
In Safari (iPadOS), I couldn’t get out of the site using the back button (unless I hit it fast enough to get past whatever it was doing to the browser history).
Interesting, it works fine on Firefox. I was able to reproduce it using Safari. After poking around I noticed it's a tumblr blog, so I tried some other tumblr blogs with the same result. It seems Tumblr's nav code does not get along with Safari/Webkit.
Thanks. That's good to know for the future, at least when I can easily identify something as a Tumblr blog. At least this wasn't one of the more egregious browser history hijacking situations. I've been on some sites that polluted the browser history as I scrolled through the page (each subheading coming into view got an entry). Two quick taps of the back button was enough to get around this one.
Code that is easy to delete is also easy to extend.
Not necessarily. Code that has been extended heavily is often the hardest code to delete. The extension itself becomes the "ball of mud" that was meant to be avoided.
uh oh. This page is at high risk of turning into a total dogpile of a bike-shedding session... let us all endeavour stay on topic, no?
How to write good code:
1. Comment as much as possible, stating intention.
2. Don't duplicate code. You need a function that does something similar to another one, but slightly differs? Do not duplicate it. Less code is less maintenance.
3. Don't circlejerk over code quality, your goal as a programmer should be to write the best software you can. The end goal is the software, not the code. Stop circlejerking in pull requests, issue threads, wherever. Make the best software you can and move on to the next problem.