11–20 of 32 posts
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.
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
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...
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. * I write Swift. Sometimes, less code is more obscure code, and I often have to go back and put…
+ 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 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.)
This is arguably easy to avoid, yet people manage to do it.
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. * I write Swift. Sometimes, less code is more obscure code, and I often have to go back and put…
> 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
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.
Earlier quoted context omitted.
> 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.
That said, the worst codebases I've worked with were examples of the former. So it's definitely a tricky balance.
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.