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

Don't be clever

stitcher.io

Post reply on HN
Print view View original

161–170 of 231 posts

Re: Don't be clever

#161

Post by eternityforest »

bob1029 wrote: post #156

My first lesson around this was in manufacturing. It has stuck with me much more strongly than any sort of software industry jargon. It is an incredibly simple phrase too: "Value-add". I just stay focused on that item. "Is my proposal/refactor/shiny thing going to make a customer want to spend more money, sign additional/longer contracts, or somehow smooth out support & operations?" If I get an "ehhh im not sure" or…

I love best practices, and I'm even a fan of cargo cult development to a certain degree, staying with what's tested, reducing novelty, making things repeatable and declarative, choosing a million line framework over 1000 I'm house lines.... But it's not worth trying to maintain your own Ansible in your own custom language with a GUI in your own GUI toolkit, just to avoid some ugly hacks and workarounds you'd need if you just used the popular tool.

Re: Don't be clever

#162

Post by IshKebab »

sjducb wrote: post #113
lijok wrote: post #11

At a consulting gig I did, we were bootstrapping a brand new python engineering team for a new line of products. We chose the frameworks, set standards via decision records, wrote a template service that you would copy paste, and build on top. Cross cutting concerns were pulled out into a library that all of these services installed. Most things were standardized, all APIs felt like they were written by a single pers…

If you feel confident refactoring some code then you have been able to read and understand it easily. If you can read and understand it easily then it’s good code, leave it alone.

"Never refactor"? Great advice

Re: Don't be clever

#163

Post by wizofaus »

horsawlarway wrote: post #61
wizofaus wrote: post #27

Earlier quoted context omitted.

I hate repetition because it's nearly always laziness - it takes less thought/time to copy and paste a few lines of code than it does to factor them out into a reusable function and decide where to put it (and with what name). I'm taking about scenarios where the business logic needs to be exactly the same in both cases, there just happens to multiple ways to reach that point. On the other hand I also hate having to…

> I'm taking about scenarios where the business logic needs to be exactly the same in both cases, there just happens to multiple ways to reach that point. I've seen lots of these cases turn out to be "the business logic happens to be exactly the same in both cases". It might have been a single feature at one point where it should have been identical, but two flows going there in two different ways means it's serving…

But the divergence is more often than not unintended and causes inconsistent/ unexpected behaviour when a change is made in one copy and not the other, which is why it ends up using up more time in the end. And how is extracting a few lines of code into a function and calling that more complexity than having two identical copies of it?

Re: Don't be clever

#164

Post by wizofaus »

sanderjd wrote: post #77
wizofaus wrote: post #27

Earlier quoted context omitted.

I hate repetition because it's nearly always laziness - it takes less thought/time to copy and paste a few lines of code than it does to factor them out into a reusable function and decide where to put it (and with what name). I'm taking about scenarios where the business logic needs to be exactly the same in both cases, there just happens to multiple ways to reach that point. On the other hand I also hate having to…

Laziness is good though. If repetition requires less work for the same outcome, that's good. If abstraction or automation of some kind (like codegen) requires less work, then that's good. But the question is, "less work over what time scale?". Repetition usually requires less work over short time scales but often requires more work over longer ones. But not always! I see people abstracting and automating things in th…

> Repetition usually requires less work over short time scales but often requires more work over longer ones

Yes, that's been exactly my experience, and not by a small amount either.

Re: Don't be clever

#165

Post by IshKebab »

lijok wrote: post #11

At a consulting gig I did, we were bootstrapping a brand new python engineering team for a new line of products. We chose the frameworks, set standards via decision records, wrote a template service that you would copy paste, and build on top. Cross cutting concerns were pulled out into a library that all of these services installed. Most things were standardized, all APIs felt like they were written by a single pers…

From why you've said it sounds like maybe the issue was really how they factored out the common code (Python loading base64 encoded Python is clearly insane) rather than the fact that they did.

It's difficult to draw conclusions from these sorts of things though because the answer is "sometimes you should copy and paste a bit, sometimes you shouldn't" and you just have to have skill and taste to know the difference.

Re: Don't be clever

#166

Post by dietr1ch »

cogman10 wrote: post #64
wallmountedtv wrote: post #34

Earlier quoted context omitted.

As a blog post with the title "Don't be clever" ending up with the author's answer being an even clever-er solution, than talking about the hidden fight against complexity in software, was an odd ending note.

"Don't be clever, now let me tell you about the non-clever solution of writing a bespoke meta programming language to solve the problem of copy/paste"

And with this inconsistency the author really pushed you into rejecting complexity.

Maybe by looking like a fool he fooled us all?

Re: Don't be clever

#167

Post by fuzzy2 »

jader201 wrote: post #97
fuzzy2 wrote: post #88

Earlier quoted context omitted.

This is sometimes also called scaffolding, which I think is a better term. Code generation often means (compile-time or otherwise) generation of code from something else (like .proto definitions). Code that is not supposed to be modified by the developer and will be overwritten automatically.

I've also seen "scaffolding" used to generate code that shouldn't be manually modified. E.g.: https://learn.microsoft.com/en-us/ef/core/managing-schemas/s...

It’s a little ambiguous with Entity Framework. There is no rule that says you cannot change the resulting code. If you want to continue with Code First, that is a totally valid approach, there’s even a subsection on that.

Re: Don't be clever

#168

Post by aldanor »

jbandela1 wrote: post #15

> Yes, I had failed to see the proper solution: a class generator — so that I didn't have to manually copy code again No, please don't. This is jumping from the frying pan into the fire. If you think abstract base classes can be clever and hard to understand, code generators can be even more so. In addition, because code generators are a one way conversion, and the generated code evolves independently and the code ge…

I've read that paragraph with a /s at the end of it.

Re: Don't be clever

#169

Post by wizofaus »

laserlight wrote: post #125
sfn42 wrote: post #50

Earlier quoted context omitted.

If the function grows like you describe it's because the developers are doing bad work. Instead of extending the function into a monster it should be split appropriately according to the new requirements. In some cases it may end up being multiple classes and that's fine. What isn't fine is cramming multiple classes worth of complexity into one function just because it almost did what you needed.

> If the function grows like you describe it's because the developers are doing bad work. Exactly. Evolving a nice function into one that accepts lots of arguments is a product of the same mindset that copy-pastes code.

Indeed...laziness in both cases! I certainly admit I've been guilty of "ooh this function already exists to do this, except in this case I need to tweak it slighty, so I'll just add another parameter" - which is usually OK the first or second time: the issue is when it sets in motion a pattern of behaviour that other devs keep following without stopping to question "has this function grown too complicated", or worse "I know this needs refactoring, but we need this bug fix in now, I'll create a tech debt ticket and come back to it later", but of course never do.
Post reply on HN