efficient or elegant

choose neither

Is this about rust?

@BordedDev something something skill issue

@BordedDev For real I just watched the latest devin video from theprimeagen and I wanted to scream the way he writes JS. Holy hell, sooooooo much boilerplate and repetition and a very small amount of actual business logic

Complete opposite to my rust code. Just goes to show that you can write good and bad code in any language!

@12bitfloat Write it in C/C++ then ;P

I avoid youtubers like theprimeagen like the plaque that I see them as

Sounds like the unspoken commands I get from management at $work.

When I write short, elegant code, I get dinged for not writing *enough* code, as small PRs are a sign of not doing enough work, or that the ticket was too simple for how long it took to complete. Context? Complexity? Scope? Never heard of ‘em. All that matters is SLoC/day, days/ticket, tickets/quarter.

When I write performant code, I get chastised for “premature optimization” (even where obviously important) or for spending more time than is absolutely necessary to get the work done. Doesn’t matter if i can speed up lookups by 200x on every single api goddamn call we receive.

Likewise, fixing bugs that aren’t explicitly listed in my ticket earns me a serious redress because I should file another ticket and do the work on that to keep them simple for audit purposes. Fine, but when I do, both ticket and PR *always* rot until they’re automatically deleted a year later.

Man. Fuck this shit.

Simple. Always choose Simple.

also @root - the pain is felt here as well.

I read this in a book I'm reading on JS (Eloquent JavaScript). It says that there has to be balance and it's also situational.

If the code is easy to read in both efficient and elegant solutions, then pick the efficient version.

However, programs are often complex, making it helpful to trade in some efficiency for elegance. It is also mentioned you shouldn't add extra stress to your mind worrying about efficiency when you already have a complex system to worry about.

The approach the book recommends is: start writing the easy and correct version. When you notice it's too slow, then refactor. When a problem is easier to solve with efficiency, it is better to use that.

i chose suffocation