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

71–80 of 231 posts

Re: Don't be clever

#71

Post by theshrike79 »

ravenstine wrote: post #38
assbuttbuttass wrote: post #28

Earlier quoted context omitted.

Agreed, when someone calls my code "complex" or "clever," it comes across as an insult

I wouldn't object so much to "complex" because there may be a much simpler way to writing my code. What I don't like about "clever" is that it's always a shit-sandwich that comes off as misrepresenting my intentions. I never write code with the intent of impressing myself or anyone else; my only interest is in writing minimal code that is maintainable and as easy to understand as possible. If my code doesn't achieve…

It's the focus on "minimal" that sometimes gets called "clever".

Some that I've found in actual code

Using ternary operators everywhere instead of if-else just because it's a few characters less, mixing them in the middle of already complex function calls so that it takes a less clever coder hours to untangle when there's an issue.

Creating your own classes for storage, the best of which was a custom from-scratch implementation of a Vector, but it kept the 3 largest items in the first three cells. It was 100% API compatible with Vector and no part of the API gave any hint of the weird sorting mechanic.

Fluent APIs. Just don't. They look pretty when written, but are a complete horror show to debug.

Re: Don't be clever

#72

Post by dclowd9901 »

> It's such a classic example, many of you probably recognise it. I wouldn't say my coding skills were bad, by the way.

Oh, coding skills. This isn’t about coding skills, this is about maintenance skills, which are wholly almost completely different than coding skills.

Maintenance skills are about creating systems where you can:

- extend, add or remove with low risk

- quickly read and understand

- quickly find a relevant bit

- keep modules simple enough that you can consider all possible cases and build them robustly to handle those cases

I see a lot in test code where engineers get overly clever and start writing looping test scripts and whatnot and pretty soon, you don’t have a clear picture of what’s even being tested anymore, or it becomes difficult to remove or change a part of the test.

Testing is _not_ an area you want to get clever with. There is already plenty of built in complexity in introspecting and mocking runtime code to be adding a layer of cleverness to it.

An engineer of a complex system doesn’t strive to make things that are clever or novel. They strive to make things that are maintainable (as defined above). If in DRYing up code, or creating a solution, it’s not making the code more maintainable, you’re going the wrong way.

Re: Don't be clever

#73

Post by tempodox »

Apparently the author hasn't learned the most important lesson: Think thrice before you use OO. And if you do, keep your hierarchies flat and simple. Prefer composition over inheritance. Make invalid states unrepresentable.

Re: Don't be clever

#75

Post by contravariant »

This once more confirms my theory that using agent nouns as class names is a mistake.

The author spent so much time thinking about what the CRUDController should be able to do they forgot to think about what it even is.

Re: Don't be clever

#76

Post by robertlagrant »

Verdex wrote: post #47
ravenstine wrote: post #26

I really dislike when someone considers my code "clever" because it always means they don't approve of it or think it's too confusing. No, I wasn't trying to be clever, but to create the most appropriate solution I could imagine. The author's problem isn't being overly clever, but that they had applied an inappropriate yet imtellectually-satisfying programming pattern that is notorious for being difficult to make exc…

Making things worse, I suspect there's at least two (and probably more) definitions for 'clever' that are thrown around and the intent half the time is that one definition is masquerading as the other. One plausible definition for clever code is that it's code that only works because of a non-obvious dependency on some other fact being true in the code base or outside of the code base. Once the fact is no longer true…

The other option is "yes this works well and is very neat, but it's not going to withstand 5 years of people changing it and only reviewing the diffs."

Re: Don't be clever

#77

Post by sanderjd »

wizofaus wrote: post #27
SanderNL wrote: post #13

I have swung both ways and I think I now settle somewhere near "boring is good" and "repetition is harmless (compared to the astronomic costs of wrong abstraction)". Especially repetition seems to be hated with the might of a thousand suns and while I get it, because I myself hated it, I now can see the beauty of it. What is currently a superficial repetition - a bunch of endpoint handlers, some forms - will often tu…

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 throwaway scripts, tools, and PoCs. That is a waste of time.

There is a series of xkcd comics about this, which are all spot on: https://xkcd.com/974/, https://xkcd.com/1319/, https://xkcd.com/1205/.

I refer back to that table in 1205 pretty often :)

Re: Don't be clever

#78

Post by sweezyjeezy »

bqm wrote: post #59

Someone once told me: "optimize code for reading. In most companies, a piece of code is read 10x more than it is updated". Usually, when you do that, you end up with simple logic and potential repetitions over complicated abstractions.

As a corollary, quite often in code there is a 'happy path', or small set of operations that people are going to be using 90% of the time. That code is going to get read even more, so make it as high quality and as simple as possible, don't mess with it unless you're very sure...

Re: Don't be clever

#79

Post by theshrike79 »

If the amount of time it takes to type your code is the biggest bottleneck in your project and you need to optimise for amount of characters written you're either the most genius 100x coder ever or ... not one of the best.

You should always optimise your (work) code for readability, even if it takes longer to type. I've spent way too many hundreds of hours of my 25 year career untangling overly clever code just to figure out what's wrong.

If you can't be sure the person who has to open up your clever code at 3AM to fix a live production issue can instantly see what's going on with the code, write more readable code. Preferably ask someone to review the pull request and see if they can understand what's going on.

You can be as clever and terse you want on your own time, but on company time write readable code even if it's verbose.

Re: Don't be clever

#80

Post by BowBun »

catchnear4321 wrote: post #18
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…

that’s the danger. you built a system for cogs. someone hired a thinker.

First time I've heard this, I love it. Definitely resonates both as the one who is there first, and then future ambitious folks would rather rebuild than understand and extend. Also, relatable when I come in somewhere and immediately start thinking about how I would re-build something instead of improving it. We sure have a lot of hubris in software, don't we?
Post reply on HN