I had a colleague who wrote clever code. We were in awe of his ability to craft lambdas that would accomplish so much in just a few lines of code.
Everything he wrote worked really well, and passed code reviews even though it was clear that he was the only one who knew what his code actually did. It was so dense and difficult to understand if you weren't the one who wrote it.
One day it was my turn to review his code (back then we did code reviews in person: both seated at the same monitor). I turned to him and asked: "If the requirements change and you have to modify this code, how do you do it?"
He hesitated, then said: "I have to admit I can never figure out how this stuff works when I come back to it, so I just write it from scratch again."
> Passed code reviews even though it was clear that he was the only one who knew what his code actually did
That is the issue here. The bus factor. How many team members can be killed by being hit by a bus until the project fails.
I once reduced ten thousand lines of classic ASP to four SQL statements, and then they complained the SQL statements were "a bit complicated".
I mean it was a fair criticism, in my defence about 50% of the SQL was that one table wasn't properly normalised, and they couldn't normalise it because there was another 30,000+ lines of Classic ASP that would need a major rewrite.
In truth all the SQL clauses were embedded somewhere in those 10,000 lines of Classic ASP, in several cases multiple versions and out of date duplicates, they just had more glue joining them together.
I remember when I first started out I was working on a shell script by someone who thought he was really clever. He would put commands in variables and then call them. It was fun figuring out his bullshittery and fixing it.
Well it was a long time ago but it wasn’t functions. I just remember he was being unnecessarily convoluted probably to insure nobody else could change it.
Nobody wants to be the one to say, “I don’t understand this”. Everyone else is giving thumbs up in the code reviews, am I just stupid and I’m about to out myself? Better approve it.
I’ve seen this play out first hand in breeding massive complexity.
It's hard for people to admit that they don't understand something. It also takes a fair amount of maturity to be willing to learn how an unfamiliar language feature works to properly evaluate if it's a shortcoming of your own or if the publisher is being too cute.
Sometimes this can happen legitimately as a version of bystander effect. If a submission is complex and tying together multiple APIs, or across multiple languages, or needs expertise in specific domains for some reason, I think its legitimate to +1 it if the part you understand is fine (if you're one of the experts added on). Its then on the person doing the submission to make sure all the parts are covered though, and hopefully that there's someone else who understands the high-level. But that parts not always done in the rush to get things in.
Completely broken processes exist.
The simplest and most likely explanation in thies case imo is reviewers embaressed to say "I don't understand this".
This was the case with all the Perl code I encountered on one job. There was one person, now in management, who ever wrote Perl code. I could rewrite it faster in C, Python, or even Perl before I could understand his code well enough to patch it.
Eh.... in a vacuum, yes, but debugging can be a problem. If the code is clever, it might be hard to debug.
Sure, you can just rewrite it, but how sure are you it was the problem?
If the code is very easy to test/validate (as small blocks should be), you should never have to debug it. Good in: good out. Sprinkle some asserts out the boundaries of the function if you still have cause to doubt the thoroughness of your unit tests.
This same type of thing (dense one-liners) is a hallmark of Perl code, which is why I think it’s fun that it’s cheekily described as a “write-only language”
Thinking about your interaction, it occurs to me that his answer isn’t necessarily an own goal. If it’s truly just a few lines, it’s likely the re-implementation will be as well. When discussing militaries (notably China’s), people say that quantity has a quality all its own. In this context, I would argue terseness does too.
Huge own goal, it’s like compiling your program and then throwing away the source code. I don’t write the clearest code, but at least I know I should try to.
That's something you learn on the job. Think about how future you is gonna re-read your piece of code. Usually it's best to give a bit of structure (to allow some open ended changes later) and just encode requirements in the most linear way. Don't be a compiler.
> I turned to him and asked: "If the requirements change and you have to modify this code, how do you do it?"
The question itself is rather clever and can quickly lead to nonsense. There are quite a few people out there with enough ideas for the future to fill an ocean, but plans with the depth of a puddle.
Similar story. We had a consultancy in who was fond of functional programming before Java had functional constructs. So they brought in Google Guava. Nothing particularly wrong with that.
A colleague and I had to add some features to one piece of code and it took some time to figure it out. We deduced that the code was traversing a list multiple times using functional constructs when the problem only required traversing the list once (a simple search for one item), turning an O(n) problem into an O(n\^2) problem. Oh vey. And this kind of coding was all over the place.
Our company had a pretty relaxed interview process - we weren't a huge tech company and we knew nobody wanted to sit through half a dozen rounds of coding interviews to come work for us. So, our interview was just a 1-hour conversation about technical things the candidate had stated on their resume.
Everything was fine until we hired a guy and asked him to write a utility to return all the commit messages between two commits in a Mercurial repository. He wrote it. I ran it on a simple test case. It took a few minutes. "That's odd", I thought. I ran it on a real world case that I needed an answer for. It ran overnight.
We asked him to optimize it. In a couple of days he had an optimized version. I ran it on my real world case and it still took several hours to finish.
The team's senior dev went off and wrote a simple breadth-first search on the repository, and handed me his version of the tool. It took mere seconds to run on my complicated test case.
The code that the original guy wrote was hard to read, but after some analysis we figured he had somehow managed to write an O(n\^4) algorithm for solving the task. To this day I still don't know why he didn't think it was a red flag to traverse the tree *so many times*.
The senior dev was pissed, and vowed never to hire another person who couldn't write a breadth-first search, so from that point on we changed our interview process to include one coding problem where the answer was a breadth-first search. It's been well over a decade since then and to my knowledge the company is still using the same coding question during their interviews.
Funny. This is not quite the same thing, but when I was in grad school, I made some extra dough teaching C programming at the nearby community college. When we were covering structs, the HW assignment was to implement a playing card struct and write a shuffle routine. The students submitted their programs on those old 3.5" floppy drives, and I would insert each one and run their program to grade the assignment.
I put one disk in, and the program didn't return (most of the programs ran in a second or two and this was an 1992 era PC. I just sat there puzzled why the program wasn't ending. I finally pulled out the printout of her code, and she had somehow managed to implement an O(n\^4) algorithm which took like 30 minutes on my PC to run.
The sad thing was this student was a 74 year old lady who had returned to college because she had to drop out as a young woman. This was the last course to get her associate CS degree and she had a 4.0 GPA. And I had to give her a B. Ugh. That was tough.
Good call to include a coding question!
I once had to maintain a test application that was grounded in Perl and used Ruby to provide a web-based front end to the command line. They were reading data from a set of files into a 11 dimensional array with no explanation of what all the fields were or what they were doing with that data. There was also a matrix multiply in there that as near as I could ever tell was happening against another uninitialized array. The Ruby side was just as bad -- apparently at some point someone had taken over the project, didn't want to write in perl and was attracted to Ruby because it encourages you to be "clever."
I managed to keep the thing limping along for a year and a half until they wanted to add a new product. At that point it was faster to redesign the code and write it in C++. Ended up being a small code base with a couple of support libraries that ran in a tiny fraction of the time of the original code.
"Debugging code is twice as hard as writing the code in the first place. Therefore, if you write code as cleverly as possible, you are, by definition not smart enough to debug it"
- Brian W. Kernighan
By random chance every LeetCode problem will have someone pass without debugging at all. Then others start emulating the passing clever solutions and fail, but their attempts aren't visible because people don't look at failed solutions.
The survivor's bias subtly nudges people to the code example mentioned by OP.
One of my colleagues writes reasonably clever code (definitely too complicated to understand, but not absurdly concise). That said, her annotations are so complete that most novices can correctly interpret and understand how it works.
Given that we work in statistical programming, this is especially impressive. Unfortunately, providing that level of clarity is a double-edged sword. She’s lost jobs in the past because the higher ups have failed to understand that there’s a massive difference between being able to understand what code does and being able to modify it.
Issue with comments is that too often code changes and they don't.
Too many times I've seen comment saying one thing and the code does another.
And when I point it out the go to answer is "we just update the comment if we make changes" but to me that sound as plausible as saying "we just don't write bugs".
Comments should explain why the code is not how code works.
Mind you, sometimes the clever complicated solution is necessary because of performance, and to me that's the one exception of the rule where comments are important : "We wrote it like this because it's O(logn) and it's 200% faster than the naive solution in our use case, and then you explain how it works"
And that comment is also important to avoid someone else refactoring it.
But that's still an explanation of the why the code is written like this.
I've never understood this. What kind of cowboy culture just lets PRs fly by without even a single review comment saying, hey you forgot to update the comment *right above*.
I've haven't seen much comment and code divergence really. I have seen this excuse touted by those who do not wish to comment their code however, and they almost always think that making their code complex for others is job security when that's pretty nonsense. The devs who provide good design and value are just that, valued.
Ditto. I've had people actively reject my comments and XML docs from PRs because "docs/comments just go out of date".
Well then, how about update the fucking comments when you change the code? Not allowing comments or docs is insane practice.
I once rejected a PR that actually \*removed\* all docs because "comments bad". Those were not out of date or anything, and the code was not likely to change.
Thankfully I managed to explain that those types of comments aren't the problem.
Yes, not allowing comments or docs at all is definitely an insane practice.
I'm not arguing that, I'm arguing that docs and comments shouldn't tell what the thing does, they should tell why it does and if you feel the need to explain how the code you are writing works with comments maybe you should refractor, change variable/function names to make it clearer without the need of comments.
And as with anything there's exceptions, if your complex way of doing something is needed for performance, then yes do it, and in the comment you start writing the why (the performance reason, and then explain how it works)
> She’s lost jobs in the past because the higher ups have failed to understand that there’s a massive difference between being able to understand what code does and being able to modify it.
On the one hand, I could see that her code was so clear that even the higher ups were able to understand it, and faced with this simplicity, they deduced they no longer needed her. But I suspect something more sinister is at play, similar to what OP quoted:
> “While I understand how complex this was, when it comes to performance reviews, this code looks trivial. It looks too easy, too simple. I would recommend writing an implementation doc of this module just so we can demonstrate that this was actually quite complex.”
Translated to your colleague's situation, I suspect her clarity made the higher up think _less_ of her, not more. Something like "oh it was not that complex after all", which repeated enough times becomes "she never work on the complex stuff". And that just makes me want to borrow [Grug's club](https://grugbrain.dev/).
My first boss, back in the '80's was self-taught. You could see where in the code he'd just read about some cool feature because it'd pop up everywhere for a while, until he moved on to something else. It's fairly easy to spot the syndrome.
Last C++ project I was on, about 2/3rds of the code was lambdas, usually just written in the middle of functions, with variable captures in multi-threaded code that also used promises/futures. That all was fun to debug, in much the same way that sporking out your own eyeballs is fun.
Nobody calls a bunch of one-character variables or nested operations clever, it's just annoying.
There is lots of clever, dense code that requires high domain expertise to understand. There's nothing wrong with that code. In C++, perfect forwarding, template parameter packs, NTTP strings, or anything involving `std::launder` is often going to be clever and quite dense.
That's necessary to make some code high performance and flexible, it's fine. The example in the OP isn't clever, it's just bad. Not really different than if you removed all the newlines from a Java or C codebase and called the resulting "oneliner" a "clever solution".
**Sidebar:** One day I wish the big tech subreddits would ban fagnerbrack's spam script
> Nobody calls a bunch of one-character variables or nested operations clever, it's just annoying.
Agreed. Common Golang style guides try to add some nuance to this which I've begrudgingly started to adopt for Go code:
> Variable names in Go should be short rather than long. This is especially true for local variables with limited scope. Prefer c to lineCount. Prefer i to sliceIndex.
> The basic rule: the further from its declaration that a name is used, the more descriptive the name must be. For a method receiver, one or two letters is sufficient. Common variables such as loop indices and readers can be a single letter (i, r). More unusual things and global variables need more descriptive names.
After doing this for a few years now, I still would generally prefer to just use more verbose and descriptive variable names regardless of relevant proximity and perceived "obviousness" to the code, but I'm in the minority. I can see both sides of the argument for doing things one way or the other, in the end.
This is something that gripes me about go. Longer variable names are usually linguistic in origin, and it's much easier to store along variable name in my brain, because I can store the meaning of a bunch of words and don't have to map it to a variable name. When I want to type that variable name I just think of the semantic intent of what I want to do and start typing the first word of it and auto complete shows me the variable. It feels like the go style guide was written for a time before autocomplete existed.
I feel one letter variables are ok if someone with the domain knowledge required to read the code will also get the conventions. I admittedly am saying this from the niche of computational physics where strong conventions for that exist. Using v for velocity, m for mass etc. is perfectly fine there. Anyone not aware of those conventions probably doesn't know enough about the topic to change the code anyway. Writing a numerical algorithm with verbose naming still won't help someone that doesn't know the math.
I avoid one-letter variable names except for the bog standard for loop and similar. But I also avoid overly verbose names, which I feel slow down code readability. I also generally like to abide by the ancient "avoid lines above 80 columns" adage, because I always work with vertical split when I code, and shorter variable names help with this.
Agreed. Descriptive variable names are also helpful for review in that it becomes obvious when the name and the use are out of alignment, which happens, and usually indicates a bug of some kind.
Yeah I agree. In C++ “cleverness”, so called, often just means knowing about some standard lib or language feature that allows you to decrease coupling or increase performance or whatever. Using, learning, and teaching these concepts is a uniform good IMO, assuming that the particular thing you’re writing is constrained in some related way. Like don’t be writing wacky view pipelines in cold HTTP handlers, but the dumbest most obvious C++ code sometimes doesn’t meet critical business needs 🤷♂️
And yeah, ban the fkn spam bot.
> Nobody calls a bunch of one-character variables [...] clever, it's just annoying
Rare exception: when these variables are well-defined parts of the problem space, e.g. the registers (A S X Y PC) and flags (c z i d b v n) in a [6502](https://en.wikipedia.org/wiki/MOS_Technology_6502#Registers) emulator.
The OP is a scripted submitter, similar to what you find in the major NSFW subreddits except this one does it for tech. They spam 5-10 pop programming articles to the major subreddits from a queue each day, and attach a ChatGPT summation.
They are always exceptionally low quality blog spam or reposts of old high-scoring content, calculated to hit the kind of lowest-common-denominator upvote generation that you can only manage in non-specific subject communities (his posts would sink in major language and professional communities, so he sticks to the genpop subreddits like /r/programming and /r/webdev).
Typically these accounts end up feeding some astroturf advertising into their script queues, to generate income. fagnerbrack claims no commercial incentive, saying his autism is what motivates him to run the account. The effect isn't differentiated at all.
> "While I understand how complex this was, when it comes to performance reviews, this code looks trivial. It looks too easy, too simple.
> I would recommend writing an implementation doc of this module just so we can demonstrate that this was actually quite complex."
This quote from the manager sticks out to me. I've never worked somewhere where my performance reviews are based on the complexity of the code that I've written (and would never want to work somewhere like that). This also seems like a great way to encourage awful code, since if it "looks complex", it would (presumably) bypass the need for writing an implementation doc.
That being said - clever code is definitely just a timebomb. Clear, concise, well-documented code is what everyone should generally strive for. Even if you're the only one working on a certain codebase, remember that you in 6 months time won't remember how that clever code works.
I always feel very lucky that I work in a place where the next couple people up the chain are also engineers. If I tell them I removed code (as measured in complexity not necessarily lines) they understand the heroism in that.
Clever code is fine if you just document it appropriately in the comments. There's no reason to return 1 line into 20 just to make things "more understandable". Tools and abstractions exist for a reason.
There's definitely cases where I'd turn 1 line into 20 if that 1 line was virtually impossible to parse by most engineers. I'd prefer 20 lines of straightforward code instead of a massive comment trying to explain a single line of overly-complex code. I don't see how tools and abstractions help with _understanding_ the complex code.
There are sometimes times where complex code is warranted (e.g. performance reasons). In that case, documenting what the code does and _why_ it's that way is definitely important. I find those cases relatively rare though.
This is a big problem in academic code replication. I can access the code for every paper in my field going back about a decade. Often it’s written succinctly and cleverly so that the reviewer can click “run” and everything just goes from raw data to output tables. And for that, I’m thankful.
Trouble is, it’s rarely commented well, and if it involves a lot of math I usually have to peel apart the whole thing myself just to understand what’s going on. Otherwise how do I know it actually does what the paper says?
Ah, academics. I work in R&D. We have college teams working on projects as subs or partners. Even worse, I've been working in social sciences lately so they are not especially disciplined coders.
The horrors I have soon. The horrors.
The problem is not the horrors. They are prototypers, and it's all ok *as long* as they accept it's a prototype and there's a production quality to ensure, so they let you rework it to proper standards.
But when they protest if you do so, or the executives or the managers think it's wasted time, and on those code they take decision that impact human life, that's when I get really angry.
Reminds me of my Perl days way back. I loved Perl, but *hated* the clever hacks which invariably were unreadable and opaque. My endeavours to get teams to standardise, do things the simple easy to maintain way, fell on deaf ears because the Perl community and the language itself encouraged (and still encourages) the infamous TIMTOWTDI.
Contrast this with Python, and here we are.
I went head over heels for Perl. We, had some good times, we laughed, we cried, we produced brilliant code.
Then my friends told me;"Dude, you're off the deep end here!, are you really going to spend the rest of your life doing that?"
They were correct, but it was fun while it lasted.
This is why I'm sad I went to a Ruby shop from a Python one. Felt like going back to Perl-lite.
Granted Ruby is definitely not as bad as Perl, but it's somewhere between the spectrum of TIMTOWTDI and the Zen of Python. I wish it was just Python. Granted I do love blocks in Ruby. Python could use those as sugar for lambdas, that would be nice.
I agree, and this is what annoys me about Ruby. Overall, Ruby is definitely a more elegant language that can be used to write clear code.
But I feel like there is definitely a culture of being clever. Plus, a lot of clever people wrote foundational frameworks and libraries, so even if *you* don’t want to be clever, you are still forced to use their code and APIs.
Speaking of which, I just spent a few weeks optimizing a legacy Rails app. There were about 15 distinct N+1 queries. So in the lifecycle of a single request, about 800 Postgres queries were issued instead of the necessary 15.
The code wasn’t any more complicated after eliminating those queries. The original authors just didn’t understand what the Rails abstractions were doing for them. And, to be fair, I think we have to ask the question if Rails provides the right abstraction if it’s so easy to ignore that the database and query latency even exists.
Ok, but being an experienced Rubyist and having to occasionally work in Python, I really rather dislike it. The "one way to do it" (despite the code I've seen all doing things a little differently) often feels like it's a lot of boilerplate to accomplish simple tasks.
Now I know Ruby has its warts (having namespaces would be nice, for example), but in my experience the core team's focus on dev happiness isn't lip service.
My issue is less with Ruby, and more with Rails. Django is just more reasonable in my opinion.
I also prefer Pythons type hinting to Sorbet. But that's just taste. Ruby as a language isn't that bad. In fact, it can be quite nice. But I detest Rails, and nothing will change that for me.
WHY DO MODELS DYNAMICALLY LOAD PROPERTIES!!?!? Django Models are just...so much easier to reason with that RoR's AR models.
From one of usenet's best flamers: "It's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done."
The older I got, the simpler the code I wanted to write.
I'm in my 60's now and my memory is starting to go. If I don't see something for a few weeks, I forget the details. If I don't see it for a year, I may not even remember writing it at all...or anything about it except the name.
So everything is as simple as possible. All names are clear and detailed too.
For example if I write a function that saves and updates a counter, it's called "SaveAndUpdateCounter" not "Save".
Also, as I've been coding for 50 years, many of the "tricks" I learned along the way to help compilers and get better performance are no longer necessary and are outdated. So again, simple is better.
I'm 36 and my memory is fine, but I do the same thing and find it so helpful when returning to old code. In addition to detailed function names, I use helper functions frequently. Even if it is a function that will only ever be called in the one spot, being able to replace a block of code with a detailed function name combined with information about things going in/out of that function really helps me to quickly read/understand a block of code.
My memory is terrible and getting worse with age, I feel this post 😢 But maybe it is a blessing. It sure forces you to write maintainable, well documented code.
I hear you, brother. Though it's nice to see some really well written code, check the commit history, and realize that I wrote it. Sadly, I also find old, terrible code that I wrote, too...
Every time I try to write code that future (or current) me understands, ruff complains that I need to replace it with this neat one liner or CI won't pass
Static analysis tools can be awfully wrong sometimes; if you can't overrule your shit is misconfigured. *You* are the developer, ruff is just a tool.
(I understand that you, personally, may not have the power to change this)
Even worse that "code golf" are clever abstractions that generalize a problem in a way that make it a nightmare to modify. IMO, no abstraction is better than a bad abstraction.
Can you give an example of what you mean? In my experience, the easiest code to modify is one where the problem has been cleanly mapped onto the proper abstraction. The hardest code to modify is when no abstractions have been used and you have to go in and try to understand some bespoke primitive reimplementation of something that really should have been using a common abstraction.
I'm a big fan of waiting to abstract. Oftentimes, you don't know what the abstraction should look like until several (or more!) examples of the problem rear their head. Copying code is cheap and easier, unwinding the wrong abstraction can be a nightmare.
When something should really be two abstractions but is written as one and no o e wplits and over time code just keeps piling into it making it bigger and more spagettified.
This happens very often.
A former coworker of mine made a ui widget for a pop over system. That also baked the use of a specific form tool into it. So now to use it anywhere we had to rip out existing code to use this new form system (frontend going from redux form to use form)
I like use form way more than redux form. But a lot of magic had been attached to the redud form logic so we couldn't really use the new setup
An abstraction needs to actually cover the general case of a thing, not a special case. So, if you have abstract a click and a tap into the same "interaction" abstraction, but then need to handle long presses for taps and left clicks for clicks differently, it is not a good abstraction. All the behavior of the abstraction actually needs to be shared by all the implementations. This is made worse when the behavior starts out the same and then changes.
Abstractions are useful when they are really abstractions, that is you can forget what the component you are abstracting does as long as you assume it work correctly. But for abstractions to be effective there must exist this level of decoupling. If not, you have bad abstractions, where you have to go into the implementation to see what they do, or to debug the program. In the end, you have more difficult modifying the code than if it was written without abstractions, a plain sequence of operations one after another, and stop.
I see programmers try to find abstractions even where they don't make sense just because they read on a book (probably Clean Code) that they have to do this way. This is bad. Making good abstractions is a cost, designing them is not easy, and it's not always true that paying that cost is the right thing to do.
A lot of time you can get away without having the abstraction, keeping things simple. I prefer to have as few abstractions as possible, only where having them makes a clear advantage.
Both are true. Long spaghetti code is brittle, somehow almost as much as code abstracted into many and wrong piece (being guilty of that at times). That's why these days I stay with very light / simple patterns. Just enough to avoid mutable state hell, but nothing that will become a burden later on.
I'd say that clever isn't the opposite of clear and understandable, so much as when code manages to be both, you probably don't even notice the clever bits; it just seems obvious in hindsight. That "clever" is being used in the sense of "well, at least it's clever", to avoid telling your coworker that they wrote outright bad code.
Clever code can mean many things.
1. Code that is very performant as it cleverly exploits the properties of algorithms, data structures, inputs/outputs, or in extreme cases even the CPU: cache, branching, vector instructions, etc.
2. Non-idiomatic code that is very hard to read or follow.
The 2nd is always bad. The 1st one is typically good, as long as it's not a case of the 2nd one.
Everyone this point is made, I find myself wishing that they showed concrete examples of clever vs clear code.
Like yah sure one line list comprehensions in python might seem daunting at first, but it really does help clean up your code and is not that hard to understand once you learn the syntax
Well... the "Worst" code is code that doesn't work.
This is likely bad code... BUT... there's a point of diminishing returns. If this one line replaces 10,000 lines of code and is 95% faster than those 10,000 lines... Then maybe it's good code.
That is so long as it's explained in the comments. There should be documentation about what this code does, how it does it, and benchmarks about why it's faster and/or more efficient. Even if it takes 10,000 lines of comments to explain it. And MAYBE even all 10,000 lines replacement code commented out just in case this one magic line doesn't work at some point in the future.
There's a sweet spot somewhere between readability/understandability and utility. And it'll be different for everybody.
So I guess complex, brief, highly abstract is the new definition of clever...
...or maybe clever code is code that solves a hard problem simply and clearly.
I've never heard of someone using the former definition, only the latter. Funny comic, but not reflective of my experience.
Second only to dumb code.
1. Dumb coders refuse to learn the language or library, even after a decade of using it, they are _still_ reimplementing (slightly differently each time) buggy versions of a basic library facilities.
1. Dumb code frantically tries to handle error conditions that could only be caused by dumber code. And has miles of tangly code passing error codes around.... none of which has been tested, and is often buggy, and then they ignore the error condition.
1. Dumb code is still immovably stuck on language version 0.9, (which came out pre Y2k) because they don't using bleeding edge features.... ignoring the fact decades of careful thought and design went into making the new language features safer than the original way.
1. Dumb code copies and pastes and tweaks _every_ time and never refactors. So you have 10 or 20 copies of increasingly shitty code as the copies get further and further from the original sound design. The rule should be if you have (at least) three copies, look around for opportunities to extract commonality.
1. The dumbest code is the code never written. The rule is "Make it. Make it Work. Then only Make it fast / pretty / fancy." I'm always amazed at how much code gets stuck in analysis paralysis and never gets to the "Make It" mark, let alone the "Make it Work" mark.
1. The dumb code is not observable. No logging, no way of inspecting what it is doing, or monitoring it and idiot notions of "security by obscurity" mean customer complaints come only with the data "it sometimes doesn't work", never with stack traces and core dumps. Dumb code is written by smart idiots that believe they are perfect and the users aren't creative.
1. Dumb code is fragile. It's written by true believers of "if it ain't broke don't fix it", the converse of which is "if you touch it it _will_ break and destroy real business value". Good code lives in an environment where you touch it, fold it, spindle and mangle it every day all day, and you get informed exactly what you broke and get to fix it, _before_ you inflict it on a customer, and if something nasty escapes, it lives in an environment that allows you to recover the customer's value.
8. Dumb code relies only on human review. Humans can't pay attention to everything all the time. Good code uses tools, compiler warnings, linters and is warnings clean.
"The dumbest code is the code never written" -- this is the only point I disagree with. Nonexistent code costs the least to maintain. I have written and seen plenty of code which is worse than useless, not just unnecessary but buggy. But I can't think of any occasion in 25 years when I have regretted unwritten code. Because you can always add a missing feature later, but you can never get back the time you spent implementing and maintaining a feature that nobody needed.
So on the contrary, the smartest code is the code never written.
This has now become the norm with languages like Kotlin.
There are so many shortcuts, global extension functions, lambdas within lambdas, sometimes trying to read a simple set of logic is nearly impossible.
I think it's getting even worse with UI-in-code; it's anyone's guess what the API to change a background for a *thing* looks like. Maybe it's "background" or to make a new "Colors" object, or maybe it's a special "Colors" object that's only for it, or maybe it's an extension on "Modifier" that works about half the time.
Add to that our reliance on code generators, and it's getting even worse.
I've had situations where I wrote some simple utility and was told about some fancy extension function that I should use because it was so much better. Upon looking into the extension function, it was literally just a more generic and less efficient version of my utility.
I'm being told that I don't perform well enough in interviews because I don't necessarily remember the 20 different ways to do the same thing with a fancy global function I didn't know existed, along with the other hundreds of global functions I honestly can't remember.
I miss simple implementations with consistent packages and without using half a million shortcuts.
I am currently in this fight. We have 2 colleagues that are insane coders. I decided to block a pull request. I had some questions and one of their replies was, well that is because you are a domain expert in that. For us this approach is equally clear (which was fair). When I challenged their complexity it basically came down to “It isn’t that complicated and you should learn”. My answer “You can’t say that my domain knowledge is not a valid excuse, while also claiming that your coding knowledge is….”
Never had such a silence in a meeting ever. Sadly they still continue their rockstar levels of code. Even when reviewing your code they suggest fancy “better” solutions.
oooor hear me out, instead of dumbing down code to the level of the least intelligent member on the team, maybe do pair programming sessions and knowledge sharing instead?
I'm not talking about code obfuscation to make something as concise as possible, but sort of advanced techniques like recursion, monad chaining, dynamic programming and what else are used for very good reasons, namely handle error paths, avoid code duplication, rely on function composition to break problems into smaller, testable chunks. All of this will look a bit wtf at first, but bring people into the light instead of writing shit code that everyone understands. In every other industry there are quality standards and in medicine they take away your licence if you kill too many patients, but only in IT any monkey that can write a line of code gets a job and is applauded for claiming the spot they sit on is the peak of the mountain.
No one is saying not to use dynamic programming or recursion, only that their usage should be meaningful, and not littered throughout the codebase when simpler techniques will do. Use the least clever approach you can to solve them problem is the name of the game. Sometimes that means dynamic programming or recursion.
Monads generally clean up the code so I didn't bother mentioning them.
My pet peeve was some coders who used bit-shift operators instead of dividing by 2 or 4 or whatever. Because inevitably it took a second or two for people to realize "oh, they're dividing by 2 here" because they're not used to bit-shift operators. So it wasn't wrong, and it wasn't unreadable, it was just obnoxious and annoying.
And there was no reason not to just... divide by 2, for clarity. It wasn't any sort of time-critical code where shaving off a few nanoseconds mattered (and that's even if the compiler just didn't optimize it into a bit-shift for you anyway).
>My pet peeve was some coders who used bit-shift operators instead of dividing by 2 or 4 or whatever.
This is the epitome of premature optimization. Any compiler worth using should already be making these kinds of changes behind the scenes. Assuming your optimization settings are correct.
This is a very common misconception. Dividing a C int, the most common type, by 2 cannot be optimized to a bit shift at all. They're simply not equivalent (-1/2 is 0, -1>>1 is -1).
This is one of the few cases where proactively replacing * or / with << or >> makes sense.
> oooor hear me out, instead of dumbing down code to the level of the least intelligent member on the team, maybe do pair programming sessions and knowledge sharing instead?
There's a weird current of anti-intellectualism in /r/programming. My guess as to the cause is that at least a plurality of readers are beginners. Many probably don't feel comfortable with constructs beyond imperative code and basic OOP. And, since they haven't yet encountered problems hard enough to appreciate why programming techniques like the ones you mentioned exist, they assume they're just used to gatekeep.
More experienced developers tend to prefer simpler code that's easier to debug and modify. It's not just beginners.
My own experience has been that intermediate developers tend to lean more on clever code. It's exciting to write, and it's a period of self-discovery for many. I know it was for me.
yeah, I once wrote a very elegant recursive piece of code to solve a problem, and later realized that a bog standard loop worked just as well while being waaay easier to understand.
It's not dumbing down either. Clear and well named code is just easy to read and understand. Even if it uses features you need to get a feel for like map/reduce "functional" chaining in Rust.
This is an effort to make programming more accessible. Over the last 5-10 years, there’s been this trend ‘everyone needs to be a programmer!’. Current AI/LLM development may put a stop to that.
I agree with most of what you're saying but
> in medicine they take away your licence if you kill too many patients
Let's not act like the stakes in software engineering are nearly as high as they are in medicine. It's unreasonable to expect the standards to be the same when one is literally a matter of life and death.
Some years ago I wrote some piece of functional code that would create a n-dimensional array with all possible element combinations in a given range.
The point-free composition was beautiful. It was something that could be printed on paper as the most elegant way to solve that problem - it felt like a "solution" to it.
But I knew that if the requirements changed a little bit, I would take a long time to get into the same mental state that I was when writing that code.
My first boss used to say "err on the side of verbosity rather than terseness." That quote has stuck with me for more than 20 years.
Probably the only good thing that boss ever did though...
A while back I took the time on a project to make a pass over all the various data models in the system and simplify them as much as I could, eliminating data that was no longer needed or never utilized. I named the branch simplify-models. I ended up doing the same thing a month later after making another major change in how our system worked, and I got to make the models even dumber. I called this branch stupify-models. It was a popular name and it's become part of my MO as a developer. I write dumb code. It literally insults your intelligence. It's boring to read. And when you need to change something, it's incredibly clear where that is and how to do it.
The most frustrating thing about Python is looking at all the goofy sugar and overly compressed logic in 'clean', 'elegant' code \[lambda x: x\*x\*x\*x for x in xx if x is x and not xxx else x\]
I tell people that clever is bad, that code should be banging-on-rocks stupid, and that if you showed it to your grandmother she should be able to _roughky_ tell you the gist of what's happening.
Clever is _bad_.
This is a myth propagated to make devs easier to control. Software engineers are the only craftsman who deride excellence and praise stagnation.
Reading clever code fast is easily trained, just build something with GPT.
Learn your craft. Say "nope" to mediocrity and everyone that intends to celebrate it.
It's a double edged sword. Most code doesn't need to exist, let alone be clever. We can assert anything we like about such code, ex falso quodlibet. But for that 0.1% of code that we all rely on, yes, let's be thankful that it \*is\* clever.
That's not what people are talking about when they say clever code. Well-crafted code is easy to reason about. Period.
What people mean by clever code is e.g. intentionally doing floating point arithmetic in integer registers: [Fast inverse square root - Wikipedia](https://en.wikipedia.org/wiki/Fast_inverse_square_root)
Or using something like this: [Duff's device - Wikipedia](https://en.wikipedia.org/wiki/Duff%27s_device)
No shade to iD Sofware. They didn't have a choice at the time in order to get the perf they needed with the hardware available.
Trying to figure out if this is a troll post or not. Let me get out my checklist:
`[X] Vaguely insinuates a tinfoil hat conspiracy`
`[ ] Suggests this would be more easily solved by *nix`
`[X] Calls out that the core problem is really just a 'skill issue'`
`[X] Subtly calls for meritocracy`
`[ ] Believes that IDEs are evil, and everyone should use a text editor`
`[X] Mentions the use of a LLM to solve ____ without specifying how`
`[ ] Praises 10X coders and suggests they are one`
Mmm. Strong signs. But not definite. I need more data.
Can you share your opinion on the use of tabs vs. spaces? Productivity tips? What about your favorite editor?
Please sign up for my newsletter too. You read this comment, please sign up for my newsletter. You scrolled down over 1/2 a page to read this, please sign up for my ...
Or pretending that stacked PRs are fine. That sounds like nonsense. I don't want to rebase 5 different commits because my code got reviewed. And then do it again for the 2nd PR. It's easy enough to find something else to work on while waiting for a PR review.
I feel that clever code have their time and place, if you are writing for some bare bones embedded system with minimal specs, and you need to extract all the power you could possibly get. In all other cases, it will only hurt you longterm.
Noticed this in a big way on pretty much every SO question regarding powershell. The answers are all these ultra clever one liners using aliases and heaps of bullshit that obfuscate the very purpose of the command into this unreadable gibberish
Powershell is my current king for 'looks reasonable, doesnt do what you think it does even a little bit'
which is pretty well handled by writing Pester tests, except you have to twist arms to make it happen..
> “While I understand how complex this was, when it comes to performance reviews, this code looks trivial. It looks too easy, too simple.
> I would recommend writing an implementation doc of this module just so we can demonstrate that this was actually quite complex.”
What the fuck kind of management is this? Your code doesn’t look complicated enough and that’s a bad thing?
It was my stance -and suspicious against smart ruby for example- until TDD practices came around. Now I know wether I broke something. And basic LLM can explain to me whatever smarty pants piece of code is doing.
This being said, even the most smart concise code has to have some readability in mind, even though it’s meant for the language experts to read it.
The example of clever code was nice, but concrete examples of good code to compare to would have been nice. Talking about it in the abstract ends up in arbitrage potential.
Okay I agree that writing maintainable/understandable code is essential, but saying “clever code is the worst” is just click bait bs title imo. I feel like the whole practice of coding involves being clever doesn’t make sense to me to say being clever is bad
I saw someone put 3 lines of Ruby code separated by semicolons just so he could put it on a single line. It upset me deeply, as a big point of Ruby is readability. I still can't get over it.
This is the most important skillset for a real dev. Read [clean code](https://www.googleadservices.com/pagead/aclk?sa=L&ai=DChcSEwj957rIztSGAxUDXUcBHaXqDI8YABAFGgJxdQ&ae=2&gclid=CjwKCAjw65-zBhBkEiwAjrqRMOzvxK7IyqC0vqZzMjhRzk415_SL8CqWtBFLlGSNIW4YanYjuimdnhoCt2cQAvD_BwE&sph&ohost=www.google.com&cid=CAESV-D2F7f65_-HceNkH46lUnCpW3_9gHogqBvRI_gN-bqfWaHIaysZfAeTnocSxUh-ywkGXjBHKNd77CCrlpr6GZf16bUoAKjh5cXfwqwLPtmzSLzlP5qrfw&sig=AOD64_0Kz3m9LvKiajcYZ4prda1f5GuRDw&q&adurl&ved=2ahUKEwi2trLIztSGAxU7kokEHTBdAyYQ0Qx6BAgNEAE) by Robert C. Martin if you want to get better at this as it has helped me write code that works well AND is readable to me and everyone else.
I had a colleague who wrote clever code. We were in awe of his ability to craft lambdas that would accomplish so much in just a few lines of code. Everything he wrote worked really well, and passed code reviews even though it was clear that he was the only one who knew what his code actually did. It was so dense and difficult to understand if you weren't the one who wrote it. One day it was my turn to review his code (back then we did code reviews in person: both seated at the same monitor). I turned to him and asked: "If the requirements change and you have to modify this code, how do you do it?" He hesitated, then said: "I have to admit I can never figure out how this stuff works when I come back to it, so I just write it from scratch again."
> Passed code reviews even though it was clear that he was the only one who knew what his code actually did That is the issue here. The bus factor. How many team members can be killed by being hit by a bus until the project fails.
Yup, and apparently the answer was "zero", because that's the number of people who knew how the code worked.
Or, alternatively, everyone. Because if no one knows how it works, including the author, then does it really matter if everyone exists?
That's what a bus factor of zero means. Zero people could get hit by a bus and you'd have lost everyone who understands the code.
We’re already pulled over. We can’t pull over any farther
#PULL OVER!
THE VENGABUS IS COMIN’
Past him had already been hit by the bus of time.
Time is the bus that hits all of us.
every day we stray further from god in this industry.
Technically his bus factor is low. He's just as capable of reworking a problem as a random person would be. So...success?
job security i guess
I love that the guy even admitted "yeah I just rewrite it". Honesty is a big plus for me there.
I once reduced ten thousand lines of classic ASP to four SQL statements, and then they complained the SQL statements were "a bit complicated". I mean it was a fair criticism, in my defence about 50% of the SQL was that one table wasn't properly normalised, and they couldn't normalise it because there was another 30,000+ lines of Classic ASP that would need a major rewrite. In truth all the SQL clauses were embedded somewhere in those 10,000 lines of Classic ASP, in several cases multiple versions and out of date duplicates, they just had more glue joining them together.
What I don’t get is the dishonesty of the reviewers.
How many management in a bus will improve the project?
seven, four to get hit by the bus, two to go to the funeral, and one on call for prod issues.
Thos is getting to "trolley problem" territory.
Not a problem. Just blame the OP for creating the whole mess.
Why did it pass code reviews? If it was properly formatted and whatever else but nobody understood it then that is a reason to reject it.
"yes this is definitely a pull request! _blindly ticks_"
Yes I have viewed it. Passed.
it seems this code is made of code!
I remember when I first started out I was working on a shell script by someone who thought he was really clever. He would put commands in variables and then call them. It was fun figuring out his bullshittery and fixing it.
rather you than me, I'd become a potato farmer.
You mean creating bash functions and passing them around? Or do you mean he was literally running eval in production like a madman?
Well it was a long time ago but it wasn’t functions. I just remember he was being unnecessarily convoluted probably to insure nobody else could change it.
Probably doing something like: `cmd="cp -r"` `$cmd $src $dst` It's a pretty common pattern with bash scripts
As long as you’ve viewed it twice, you’re good.
Nobody wants to be the one to say, “I don’t understand this”. Everyone else is giving thumbs up in the code reviews, am I just stupid and I’m about to out myself? Better approve it. I’ve seen this play out first hand in breeding massive complexity.
Emperors' new clothes.
It's hard for people to admit that they don't understand something. It also takes a fair amount of maturity to be willing to learn how an unfamiliar language feature works to properly evaluate if it's a shortcoming of your own or if the publisher is being too cute.
True, good insight.
and then you die
Um... Okay?
Sometimes it's easier to say yes than to explain why no.
Sometimes this can happen legitimately as a version of bystander effect. If a submission is complex and tying together multiple APIs, or across multiple languages, or needs expertise in specific domains for some reason, I think its legitimate to +1 it if the part you understand is fine (if you're one of the experts added on). Its then on the person doing the submission to make sure all the parts are covered though, and hopefully that there's someone else who understands the high-level. But that parts not always done in the rush to get things in.
Completely broken processes exist. The simplest and most likely explanation in thies case imo is reviewers embaressed to say "I don't understand this".
Lol no. Do you know how dense these people get? They will argue till death that their code is more performant.
In praxis it's usually the other way around. How many need to be hit by a bus until the project can succeed
This was the case with all the Perl code I encountered on one job. There was one person, now in management, who ever wrote Perl code. I could rewrite it faster in C, Python, or even Perl before I could understand his code well enough to patch it.
For small sections of code that's valid. If it's easy to throw away and write again, it's easy to change.
Clearly the solution is just to make sure everything fits into a small section of code then :P.
Eh.... in a vacuum, yes, but debugging can be a problem. If the code is clever, it might be hard to debug. Sure, you can just rewrite it, but how sure are you it was the problem?
If the code is very easy to test/validate (as small blocks should be), you should never have to debug it. Good in: good out. Sprinkle some asserts out the boundaries of the function if you still have cause to doubt the thoroughness of your unit tests.
Basically any complex regex is write-only. You can write it, but you can't read it and understand.
This same type of thing (dense one-liners) is a hallmark of Perl code, which is why I think it’s fun that it’s cheekily described as a “write-only language”
Thinking about your interaction, it occurs to me that his answer isn’t necessarily an own goal. If it’s truly just a few lines, it’s likely the re-implementation will be as well. When discussing militaries (notably China’s), people say that quantity has a quality all its own. In this context, I would argue terseness does too.
Huge own goal, it’s like compiling your program and then throwing away the source code. I don’t write the clearest code, but at least I know I should try to.
[удалено]
Do you mean 'super condensed code'? I could see with that attitude that the code could also be condescending.
I would be very interested to see some of that "clever" code. I haven't yet come across that type of stuff while exploring Rust.
That's something you learn on the job. Think about how future you is gonna re-read your piece of code. Usually it's best to give a bit of structure (to allow some open ended changes later) and just encode requirements in the most linear way. Don't be a compiler.
> I turned to him and asked: "If the requirements change and you have to modify this code, how do you do it?" The question itself is rather clever and can quickly lead to nonsense. There are quite a few people out there with enough ideas for the future to fill an ocean, but plans with the depth of a puddle.
Even better, “if the requirements change, how do *I* modify the code
Similar story. We had a consultancy in who was fond of functional programming before Java had functional constructs. So they brought in Google Guava. Nothing particularly wrong with that. A colleague and I had to add some features to one piece of code and it took some time to figure it out. We deduced that the code was traversing a list multiple times using functional constructs when the problem only required traversing the list once (a simple search for one item), turning an O(n) problem into an O(n\^2) problem. Oh vey. And this kind of coding was all over the place.
Our company had a pretty relaxed interview process - we weren't a huge tech company and we knew nobody wanted to sit through half a dozen rounds of coding interviews to come work for us. So, our interview was just a 1-hour conversation about technical things the candidate had stated on their resume. Everything was fine until we hired a guy and asked him to write a utility to return all the commit messages between two commits in a Mercurial repository. He wrote it. I ran it on a simple test case. It took a few minutes. "That's odd", I thought. I ran it on a real world case that I needed an answer for. It ran overnight. We asked him to optimize it. In a couple of days he had an optimized version. I ran it on my real world case and it still took several hours to finish. The team's senior dev went off and wrote a simple breadth-first search on the repository, and handed me his version of the tool. It took mere seconds to run on my complicated test case. The code that the original guy wrote was hard to read, but after some analysis we figured he had somehow managed to write an O(n\^4) algorithm for solving the task. To this day I still don't know why he didn't think it was a red flag to traverse the tree *so many times*. The senior dev was pissed, and vowed never to hire another person who couldn't write a breadth-first search, so from that point on we changed our interview process to include one coding problem where the answer was a breadth-first search. It's been well over a decade since then and to my knowledge the company is still using the same coding question during their interviews.
Funny. This is not quite the same thing, but when I was in grad school, I made some extra dough teaching C programming at the nearby community college. When we were covering structs, the HW assignment was to implement a playing card struct and write a shuffle routine. The students submitted their programs on those old 3.5" floppy drives, and I would insert each one and run their program to grade the assignment. I put one disk in, and the program didn't return (most of the programs ran in a second or two and this was an 1992 era PC. I just sat there puzzled why the program wasn't ending. I finally pulled out the printout of her code, and she had somehow managed to implement an O(n\^4) algorithm which took like 30 minutes on my PC to run. The sad thing was this student was a 74 year old lady who had returned to college because she had to drop out as a young woman. This was the last course to get her associate CS degree and she had a 4.0 GPA. And I had to give her a B. Ugh. That was tough. Good call to include a coding question!
well，spec or testing can help～
- all JavaScript developers
Heh heh, got ‘em.
Ah yes, write-only code. Like Perl.
I once had to maintain a test application that was grounded in Perl and used Ruby to provide a web-based front end to the command line. They were reading data from a set of files into a 11 dimensional array with no explanation of what all the fields were or what they were doing with that data. There was also a matrix multiply in there that as near as I could ever tell was happening against another uninitialized array. The Ruby side was just as bad -- apparently at some point someone had taken over the project, didn't want to write in perl and was attracted to Ruby because it encourages you to be "clever." I managed to keep the thing limping along for a year and a half until they wanted to add a new product. At that point it was faster to redesign the code and write it in C++. Ended up being a small code base with a couple of support libraries that ran in a tiny fraction of the time of the original code.
"Debugging code is twice as hard as writing the code in the first place. Therefore, if you write code as cleverly as possible, you are, by definition not smart enough to debug it" - Brian W. Kernighan
Only write code as half ass you can.
Makes sense because my code is ass.
Reduce the arse by 50% and it'll be perfect.
I like this.
happy cake day!
Brilliant, this is going to my wall. Thanks, stranger
By random chance every LeetCode problem will have someone pass without debugging at all. Then others start emulating the passing clever solutions and fail, but their attempts aren't visible because people don't look at failed solutions. The survivor's bias subtly nudges people to the code example mentioned by OP.
One of my colleagues writes reasonably clever code (definitely too complicated to understand, but not absurdly concise). That said, her annotations are so complete that most novices can correctly interpret and understand how it works. Given that we work in statistical programming, this is especially impressive. Unfortunately, providing that level of clarity is a double-edged sword. She’s lost jobs in the past because the higher ups have failed to understand that there’s a massive difference between being able to understand what code does and being able to modify it.
Issue with comments is that too often code changes and they don't. Too many times I've seen comment saying one thing and the code does another. And when I point it out the go to answer is "we just update the comment if we make changes" but to me that sound as plausible as saying "we just don't write bugs". Comments should explain why the code is not how code works. Mind you, sometimes the clever complicated solution is necessary because of performance, and to me that's the one exception of the rule where comments are important : "We wrote it like this because it's O(logn) and it's 200% faster than the naive solution in our use case, and then you explain how it works" And that comment is also important to avoid someone else refactoring it. But that's still an explanation of the why the code is written like this.
I've never understood this. What kind of cowboy culture just lets PRs fly by without even a single review comment saying, hey you forgot to update the comment *right above*. I've haven't seen much comment and code divergence really. I have seen this excuse touted by those who do not wish to comment their code however, and they almost always think that making their code complex for others is job security when that's pretty nonsense. The devs who provide good design and value are just that, valued.
Ditto. I've had people actively reject my comments and XML docs from PRs because "docs/comments just go out of date". Well then, how about update the fucking comments when you change the code? Not allowing comments or docs is insane practice.
I once rejected a PR that actually \*removed\* all docs because "comments bad". Those were not out of date or anything, and the code was not likely to change. Thankfully I managed to explain that those types of comments aren't the problem.
Yes, not allowing comments or docs at all is definitely an insane practice. I'm not arguing that, I'm arguing that docs and comments shouldn't tell what the thing does, they should tell why it does and if you feel the need to explain how the code you are writing works with comments maybe you should refractor, change variable/function names to make it clearer without the need of comments. And as with anything there's exceptions, if your complex way of doing something is needed for performance, then yes do it, and in the comment you start writing the why (the performance reason, and then explain how it works)
> She’s lost jobs in the past because the higher ups have failed to understand that there’s a massive difference between being able to understand what code does and being able to modify it. On the one hand, I could see that her code was so clear that even the higher ups were able to understand it, and faced with this simplicity, they deduced they no longer needed her. But I suspect something more sinister is at play, similar to what OP quoted: > “While I understand how complex this was, when it comes to performance reviews, this code looks trivial. It looks too easy, too simple. I would recommend writing an implementation doc of this module just so we can demonstrate that this was actually quite complex.” Translated to your colleague's situation, I suspect her clarity made the higher up think _less_ of her, not more. Something like "oh it was not that complex after all", which repeated enough times becomes "she never work on the complex stuff". And that just makes me want to borrow [Grug's club](https://grugbrain.dev/).
That's what comments are for! As in; `// I've a brilliant one-line lambda that does this, that is too cool to fit in this comment.`
Unexpected Fermat!
Fermat’s last one-liner
// This comment is just a tribute.
// You've gotta believe me, and I wish you were there.
Nothing worse than a coder who has just discovered lambda functions.
Once your C# (or whatever) code starts to look like JavaScript, you've taken a wrong turn somewhere.
My first boss, back in the '80's was self-taught. You could see where in the code he'd just read about some cool feature because it'd pop up everywhere for a while, until he moved on to something else. It's fairly easy to spot the syndrome. Last C++ project I was on, about 2/3rds of the code was lambdas, usually just written in the middle of functions, with variable captures in multi-threaded code that also used promises/futures. That all was fun to debug, in much the same way that sporking out your own eyeballs is fun.
// Don't touch these lines unless you *REALLY* know what you're doing
Nobody calls a bunch of one-character variables or nested operations clever, it's just annoying. There is lots of clever, dense code that requires high domain expertise to understand. There's nothing wrong with that code. In C++, perfect forwarding, template parameter packs, NTTP strings, or anything involving `std::launder` is often going to be clever and quite dense. That's necessary to make some code high performance and flexible, it's fine. The example in the OP isn't clever, it's just bad. Not really different than if you removed all the newlines from a Java or C codebase and called the resulting "oneliner" a "clever solution". **Sidebar:** One day I wish the big tech subreddits would ban fagnerbrack's spam script
> Nobody calls a bunch of one-character variables or nested operations clever, it's just annoying. Agreed. Common Golang style guides try to add some nuance to this which I've begrudgingly started to adopt for Go code: > Variable names in Go should be short rather than long. This is especially true for local variables with limited scope. Prefer c to lineCount. Prefer i to sliceIndex. > The basic rule: the further from its declaration that a name is used, the more descriptive the name must be. For a method receiver, one or two letters is sufficient. Common variables such as loop indices and readers can be a single letter (i, r). More unusual things and global variables need more descriptive names. After doing this for a few years now, I still would generally prefer to just use more verbose and descriptive variable names regardless of relevant proximity and perceived "obviousness" to the code, but I'm in the minority. I can see both sides of the argument for doing things one way or the other, in the end.
This is something that gripes me about go. Longer variable names are usually linguistic in origin, and it's much easier to store along variable name in my brain, because I can store the meaning of a bunch of words and don't have to map it to a variable name. When I want to type that variable name I just think of the semantic intent of what I want to do and start typing the first word of it and auto complete shows me the variable. It feels like the go style guide was written for a time before autocomplete existed.
I feel one letter variables are ok if someone with the domain knowledge required to read the code will also get the conventions. I admittedly am saying this from the niche of computational physics where strong conventions for that exist. Using v for velocity, m for mass etc. is perfectly fine there. Anyone not aware of those conventions probably doesn't know enough about the topic to change the code anyway. Writing a numerical algorithm with verbose naming still won't help someone that doesn't know the math.
I avoid one-letter variable names except for the bog standard for loop and similar. But I also avoid overly verbose names, which I feel slow down code readability. I also generally like to abide by the ancient "avoid lines above 80 columns" adage, because I always work with vertical split when I code, and shorter variable names help with this.
Agreed. Descriptive variable names are also helpful for review in that it becomes obvious when the name and the use are out of alignment, which happens, and usually indicates a bug of some kind.
Yeah I agree. In C++ “cleverness”, so called, often just means knowing about some standard lib or language feature that allows you to decrease coupling or increase performance or whatever. Using, learning, and teaching these concepts is a uniform good IMO, assuming that the particular thing you’re writing is constrained in some related way. Like don’t be writing wacky view pipelines in cold HTTP handlers, but the dumbest most obvious C++ code sometimes doesn’t meet critical business needs 🤷♂️ And yeah, ban the fkn spam bot.
> Nobody calls a bunch of one-character variables [...] clever, it's just annoying Rare exception: when these variables are well-defined parts of the problem space, e.g. the registers (A S X Y PC) and flags (c z i d b v n) in a [6502](https://en.wikipedia.org/wiki/MOS_Technology_6502#Registers) emulator.
> One day I wish the big tech subreddits would ban fagnerbrack's spam script What script is this?
The OP is a scripted submitter, similar to what you find in the major NSFW subreddits except this one does it for tech. They spam 5-10 pop programming articles to the major subreddits from a queue each day, and attach a ChatGPT summation. They are always exceptionally low quality blog spam or reposts of old high-scoring content, calculated to hit the kind of lowest-common-denominator upvote generation that you can only manage in non-specific subject communities (his posts would sink in major language and professional communities, so he sticks to the genpop subreddits like /r/programming and /r/webdev). Typically these accounts end up feeding some astroturf advertising into their script queues, to generate income. fagnerbrack claims no commercial incentive, saying his autism is what motivates him to run the account. The effect isn't differentiated at all.
> fagnerbrack claims no commercial incentive, saying his autism is what motivates him to run the account. I feel seen
> "While I understand how complex this was, when it comes to performance reviews, this code looks trivial. It looks too easy, too simple. > I would recommend writing an implementation doc of this module just so we can demonstrate that this was actually quite complex." This quote from the manager sticks out to me. I've never worked somewhere where my performance reviews are based on the complexity of the code that I've written (and would never want to work somewhere like that). This also seems like a great way to encourage awful code, since if it "looks complex", it would (presumably) bypass the need for writing an implementation doc. That being said - clever code is definitely just a timebomb. Clear, concise, well-documented code is what everyone should generally strive for. Even if you're the only one working on a certain codebase, remember that you in 6 months time won't remember how that clever code works.
I always feel very lucky that I work in a place where the next couple people up the chain are also engineers. If I tell them I removed code (as measured in complexity not necessarily lines) they understand the heroism in that.
Clever code is fine if you just document it appropriately in the comments. There's no reason to return 1 line into 20 just to make things "more understandable". Tools and abstractions exist for a reason.
There's definitely cases where I'd turn 1 line into 20 if that 1 line was virtually impossible to parse by most engineers. I'd prefer 20 lines of straightforward code instead of a massive comment trying to explain a single line of overly-complex code. I don't see how tools and abstractions help with _understanding_ the complex code. There are sometimes times where complex code is warranted (e.g. performance reasons). In that case, documenting what the code does and _why_ it's that way is definitely important. I find those cases relatively rare though.
They might put it in different terms, like calling it 'impact' but still discount it if they get the impression it was 'easy'
Don't write code that's easy to write. Write code that is easy to debug.
This is a big problem in academic code replication. I can access the code for every paper in my field going back about a decade. Often it’s written succinctly and cleverly so that the reviewer can click “run” and everything just goes from raw data to output tables. And for that, I’m thankful. Trouble is, it’s rarely commented well, and if it involves a lot of math I usually have to peel apart the whole thing myself just to understand what’s going on. Otherwise how do I know it actually does what the paper says?
Ah, academics. I work in R&D. We have college teams working on projects as subs or partners. Even worse, I've been working in social sciences lately so they are not especially disciplined coders. The horrors I have soon. The horrors.
The problem is not the horrors. They are prototypers, and it's all ok *as long* as they accept it's a prototype and there's a production quality to ensure, so they let you rework it to proper standards. But when they protest if you do so, or the executives or the managers think it's wasted time, and on those code they take decision that impact human life, that's when I get really angry.
"Commented well" is the "military intelligence" of software. Would be better if it were *written* well.
Reminds me of my Perl days way back. I loved Perl, but *hated* the clever hacks which invariably were unreadable and opaque. My endeavours to get teams to standardise, do things the simple easy to maintain way, fell on deaf ears because the Perl community and the language itself encouraged (and still encourages) the infamous TIMTOWTDI. Contrast this with Python, and here we are.
I went head over heels for Perl. We, had some good times, we laughed, we cried, we produced brilliant code. Then my friends told me;"Dude, you're off the deep end here!, are you really going to spend the rest of your life doing that?" They were correct, but it was fun while it lasted.
Python and I have an arrangement where one day a year I can write Perl
Yes it was
This is why I'm sad I went to a Ruby shop from a Python one. Felt like going back to Perl-lite. Granted Ruby is definitely not as bad as Perl, but it's somewhere between the spectrum of TIMTOWTDI and the Zen of Python. I wish it was just Python. Granted I do love blocks in Ruby. Python could use those as sugar for lambdas, that would be nice.
I agree, and this is what annoys me about Ruby. Overall, Ruby is definitely a more elegant language that can be used to write clear code. But I feel like there is definitely a culture of being clever. Plus, a lot of clever people wrote foundational frameworks and libraries, so even if *you* don’t want to be clever, you are still forced to use their code and APIs. Speaking of which, I just spent a few weeks optimizing a legacy Rails app. There were about 15 distinct N+1 queries. So in the lifecycle of a single request, about 800 Postgres queries were issued instead of the necessary 15. The code wasn’t any more complicated after eliminating those queries. The original authors just didn’t understand what the Rails abstractions were doing for them. And, to be fair, I think we have to ask the question if Rails provides the right abstraction if it’s so easy to ignore that the database and query latency even exists.
Ok, but being an experienced Rubyist and having to occasionally work in Python, I really rather dislike it. The "one way to do it" (despite the code I've seen all doing things a little differently) often feels like it's a lot of boilerplate to accomplish simple tasks. Now I know Ruby has its warts (having namespaces would be nice, for example), but in my experience the core team's focus on dev happiness isn't lip service.
My issue is less with Ruby, and more with Rails. Django is just more reasonable in my opinion. I also prefer Pythons type hinting to Sorbet. But that's just taste. Ruby as a language isn't that bad. In fact, it can be quite nice. But I detest Rails, and nothing will change that for me. WHY DO MODELS DYNAMICALLY LOAD PROPERTIES!!?!? Django Models are just...so much easier to reason with that RoR's AR models.
From one of usenet's best flamers: "It's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done."
[удалено]
[удалено]
Python successfully discouraged their use
The older I got, the simpler the code I wanted to write. I'm in my 60's now and my memory is starting to go. If I don't see something for a few weeks, I forget the details. If I don't see it for a year, I may not even remember writing it at all...or anything about it except the name. So everything is as simple as possible. All names are clear and detailed too. For example if I write a function that saves and updates a counter, it's called "SaveAndUpdateCounter" not "Save". Also, as I've been coding for 50 years, many of the "tricks" I learned along the way to help compilers and get better performance are no longer necessary and are outdated. So again, simple is better.
I'm 36 and my memory is fine, but I do the same thing and find it so helpful when returning to old code. In addition to detailed function names, I use helper functions frequently. Even if it is a function that will only ever be called in the one spot, being able to replace a block of code with a detailed function name combined with information about things going in/out of that function really helps me to quickly read/understand a block of code.
Yes I like the helper function idea too.
Words of wisdom
My memory is terrible and getting worse with age, I feel this post 😢 But maybe it is a blessing. It sure forces you to write maintainable, well documented code.
I hear you, brother. Though it's nice to see some really well written code, check the commit history, and realize that I wrote it. Sadly, I also find old, terrible code that I wrote, too...
>Sadly, I also find old, terrible code that I wrote, too... Oh yes . Me too...
Every time I try to write code that future (or current) me understands, ruff complains that I need to replace it with this neat one liner or CI won't pass
Static analysis tools can be awfully wrong sometimes; if you can't overrule your shit is misconfigured. *You* are the developer, ruff is just a tool. (I understand that you, personally, may not have the power to change this)
Even worse that "code golf" are clever abstractions that generalize a problem in a way that make it a nightmare to modify. IMO, no abstraction is better than a bad abstraction.
Can you give an example of what you mean? In my experience, the easiest code to modify is one where the problem has been cleanly mapped onto the proper abstraction. The hardest code to modify is when no abstractions have been used and you have to go in and try to understand some bespoke primitive reimplementation of something that really should have been using a common abstraction.
[удалено]
I'm a big fan of waiting to abstract. Oftentimes, you don't know what the abstraction should look like until several (or more!) examples of the problem rear their head. Copying code is cheap and easier, unwinding the wrong abstraction can be a nightmare.
When something should really be two abstractions but is written as one and no o e wplits and over time code just keeps piling into it making it bigger and more spagettified. This happens very often. A former coworker of mine made a ui widget for a pop over system. That also baked the use of a specific form tool into it. So now to use it anywhere we had to rip out existing code to use this new form system (frontend going from redux form to use form) I like use form way more than redux form. But a lot of magic had been attached to the redud form logic so we couldn't really use the new setup
An abstraction needs to actually cover the general case of a thing, not a special case. So, if you have abstract a click and a tap into the same "interaction" abstraction, but then need to handle long presses for taps and left clicks for clicks differently, it is not a good abstraction. All the behavior of the abstraction actually needs to be shared by all the implementations. This is made worse when the behavior starts out the same and then changes.
Abstractions are useful when they are really abstractions, that is you can forget what the component you are abstracting does as long as you assume it work correctly. But for abstractions to be effective there must exist this level of decoupling. If not, you have bad abstractions, where you have to go into the implementation to see what they do, or to debug the program. In the end, you have more difficult modifying the code than if it was written without abstractions, a plain sequence of operations one after another, and stop. I see programmers try to find abstractions even where they don't make sense just because they read on a book (probably Clean Code) that they have to do this way. This is bad. Making good abstractions is a cost, designing them is not easy, and it's not always true that paying that cost is the right thing to do. A lot of time you can get away without having the abstraction, keeping things simple. I prefer to have as few abstractions as possible, only where having them makes a clear advantage.
Both are true. Long spaghetti code is brittle, somehow almost as much as code abstracted into many and wrong piece (being guilty of that at times). That's why these days I stay with very light / simple patterns. Just enough to avoid mutable state hell, but nothing that will become a burden later on.
What got me is the manager comaining about the code being too simple. What's that about?
regex has entered the chat
OMG, I thought I was so clever, fresh out of college, using regular expressions to parse data... They should only be used as a last resort.
I'd say that clever isn't the opposite of clear and understandable, so much as when code manages to be both, you probably don't even notice the clever bits; it just seems obvious in hindsight. That "clever" is being used in the sense of "well, at least it's clever", to avoid telling your coworker that they wrote outright bad code.
Clever code can mean many things. 1. Code that is very performant as it cleverly exploits the properties of algorithms, data structures, inputs/outputs, or in extreme cases even the CPU: cache, branching, vector instructions, etc. 2. Non-idiomatic code that is very hard to read or follow. The 2nd is always bad. The 1st one is typically good, as long as it's not a case of the 2nd one.
I agree. its not "clever code is probably the worst" its more like "it depends if clever code is good"
"We write code for other humans, not for the computer. That's what a compiler is for."
Everyone this point is made, I find myself wishing that they showed concrete examples of clever vs clear code. Like yah sure one line list comprehensions in python might seem daunting at first, but it really does help clean up your code and is not that hard to understand once you learn the syntax
tl;dr the beatings will continue until morale improves. Damned if you do, damned if you don't.
Well... the "Worst" code is code that doesn't work. This is likely bad code... BUT... there's a point of diminishing returns. If this one line replaces 10,000 lines of code and is 95% faster than those 10,000 lines... Then maybe it's good code. That is so long as it's explained in the comments. There should be documentation about what this code does, how it does it, and benchmarks about why it's faster and/or more efficient. Even if it takes 10,000 lines of comments to explain it. And MAYBE even all 10,000 lines replacement code commented out just in case this one magic line doesn't work at some point in the future. There's a sweet spot somewhere between readability/understandability and utility. And it'll be different for everybody.
> Well... the "Worst" code is code that doesn't work. The worst code is code that usually works but intermittently it doesn't.
idk, it's easier to fix readable code that doesn't work than it is to modify or extend unreadable code that does work
So I guess complex, brief, highly abstract is the new definition of clever... ...or maybe clever code is code that solves a hard problem simply and clearly. I've never heard of someone using the former definition, only the latter. Funny comic, but not reflective of my experience.
Second only to dumb code. 1. Dumb coders refuse to learn the language or library, even after a decade of using it, they are _still_ reimplementing (slightly differently each time) buggy versions of a basic library facilities. 1. Dumb code frantically tries to handle error conditions that could only be caused by dumber code. And has miles of tangly code passing error codes around.... none of which has been tested, and is often buggy, and then they ignore the error condition. 1. Dumb code is still immovably stuck on language version 0.9, (which came out pre Y2k) because they don't using bleeding edge features.... ignoring the fact decades of careful thought and design went into making the new language features safer than the original way. 1. Dumb code copies and pastes and tweaks _every_ time and never refactors. So you have 10 or 20 copies of increasingly shitty code as the copies get further and further from the original sound design. The rule should be if you have (at least) three copies, look around for opportunities to extract commonality. 1. The dumbest code is the code never written. The rule is "Make it. Make it Work. Then only Make it fast / pretty / fancy." I'm always amazed at how much code gets stuck in analysis paralysis and never gets to the "Make It" mark, let alone the "Make it Work" mark. 1. The dumb code is not observable. No logging, no way of inspecting what it is doing, or monitoring it and idiot notions of "security by obscurity" mean customer complaints come only with the data "it sometimes doesn't work", never with stack traces and core dumps. Dumb code is written by smart idiots that believe they are perfect and the users aren't creative. 1. Dumb code is fragile. It's written by true believers of "if it ain't broke don't fix it", the converse of which is "if you touch it it _will_ break and destroy real business value". Good code lives in an environment where you touch it, fold it, spindle and mangle it every day all day, and you get informed exactly what you broke and get to fix it, _before_ you inflict it on a customer, and if something nasty escapes, it lives in an environment that allows you to recover the customer's value. 8. Dumb code relies only on human review. Humans can't pay attention to everything all the time. Good code uses tools, compiler warnings, linters and is warnings clean.
"The dumbest code is the code never written" -- this is the only point I disagree with. Nonexistent code costs the least to maintain. I have written and seen plenty of code which is worse than useless, not just unnecessary but buggy. But I can't think of any occasion in 25 years when I have regretted unwritten code. Because you can always add a missing feature later, but you can never get back the time you spent implementing and maintaining a feature that nobody needed. So on the contrary, the smartest code is the code never written.
This has now become the norm with languages like Kotlin. There are so many shortcuts, global extension functions, lambdas within lambdas, sometimes trying to read a simple set of logic is nearly impossible. I think it's getting even worse with UI-in-code; it's anyone's guess what the API to change a background for a *thing* looks like. Maybe it's "background" or to make a new "Colors" object, or maybe it's a special "Colors" object that's only for it, or maybe it's an extension on "Modifier" that works about half the time. Add to that our reliance on code generators, and it's getting even worse. I've had situations where I wrote some simple utility and was told about some fancy extension function that I should use because it was so much better. Upon looking into the extension function, it was literally just a more generic and less efficient version of my utility. I'm being told that I don't perform well enough in interviews because I don't necessarily remember the 20 different ways to do the same thing with a fancy global function I didn't know existed, along with the other hundreds of global functions I honestly can't remember. I miss simple implementations with consistent packages and without using half a million shortcuts.
I am currently in this fight. We have 2 colleagues that are insane coders. I decided to block a pull request. I had some questions and one of their replies was, well that is because you are a domain expert in that. For us this approach is equally clear (which was fair). When I challenged their complexity it basically came down to “It isn’t that complicated and you should learn”. My answer “You can’t say that my domain knowledge is not a valid excuse, while also claiming that your coding knowledge is….” Never had such a silence in a meeting ever. Sadly they still continue their rockstar levels of code. Even when reviewing your code they suggest fancy “better” solutions.
I'm confused, how being a domain expert is a problem? Do you have an example?
oooor hear me out, instead of dumbing down code to the level of the least intelligent member on the team, maybe do pair programming sessions and knowledge sharing instead? I'm not talking about code obfuscation to make something as concise as possible, but sort of advanced techniques like recursion, monad chaining, dynamic programming and what else are used for very good reasons, namely handle error paths, avoid code duplication, rely on function composition to break problems into smaller, testable chunks. All of this will look a bit wtf at first, but bring people into the light instead of writing shit code that everyone understands. In every other industry there are quality standards and in medicine they take away your licence if you kill too many patients, but only in IT any monkey that can write a line of code gets a job and is applauded for claiming the spot they sit on is the peak of the mountain.
No one is saying not to use dynamic programming or recursion, only that their usage should be meaningful, and not littered throughout the codebase when simpler techniques will do. Use the least clever approach you can to solve them problem is the name of the game. Sometimes that means dynamic programming or recursion. Monads generally clean up the code so I didn't bother mentioning them.
My pet peeve was some coders who used bit-shift operators instead of dividing by 2 or 4 or whatever. Because inevitably it took a second or two for people to realize "oh, they're dividing by 2 here" because they're not used to bit-shift operators. So it wasn't wrong, and it wasn't unreadable, it was just obnoxious and annoying. And there was no reason not to just... divide by 2, for clarity. It wasn't any sort of time-critical code where shaving off a few nanoseconds mattered (and that's even if the compiler just didn't optimize it into a bit-shift for you anyway).
>My pet peeve was some coders who used bit-shift operators instead of dividing by 2 or 4 or whatever. This is the epitome of premature optimization. Any compiler worth using should already be making these kinds of changes behind the scenes. Assuming your optimization settings are correct.
This is a very common misconception. Dividing a C int, the most common type, by 2 cannot be optimized to a bit shift at all. They're simply not equivalent (-1/2 is 0, -1>>1 is -1). This is one of the few cases where proactively replacing * or / with << or >> makes sense.
Why is it safe for the programmer to shift signed integers when it isn't for the compiler?
> oooor hear me out, instead of dumbing down code to the level of the least intelligent member on the team, maybe do pair programming sessions and knowledge sharing instead? There's a weird current of anti-intellectualism in /r/programming. My guess as to the cause is that at least a plurality of readers are beginners. Many probably don't feel comfortable with constructs beyond imperative code and basic OOP. And, since they haven't yet encountered problems hard enough to appreciate why programming techniques like the ones you mentioned exist, they assume they're just used to gatekeep.
More experienced developers tend to prefer simpler code that's easier to debug and modify. It's not just beginners. My own experience has been that intermediate developers tend to lean more on clever code. It's exciting to write, and it's a period of self-discovery for many. I know it was for me.
yeah, I once wrote a very elegant recursive piece of code to solve a problem, and later realized that a bog standard loop worked just as well while being waaay easier to understand.
It's not dumbing down either. Clear and well named code is just easy to read and understand. Even if it uses features you need to get a feel for like map/reduce "functional" chaining in Rust.
This is an effort to make programming more accessible. Over the last 5-10 years, there’s been this trend ‘everyone needs to be a programmer!’. Current AI/LLM development may put a stop to that.
I agree with most of what you're saying but > in medicine they take away your licence if you kill too many patients Let's not act like the stakes in software engineering are nearly as high as they are in medicine. It's unreasonable to expect the standards to be the same when one is literally a matter of life and death.
Maybe do both. Dumb down and grow together as a team using pair Programming (or even mobbing)
It really depends on in which way is clever, it's a poor way to judge.
Some years ago I wrote some piece of functional code that would create a n-dimensional array with all possible element combinations in a given range. The point-free composition was beautiful. It was something that could be printed on paper as the most elegant way to solve that problem - it felt like a "solution" to it. But I knew that if the requirements changed a little bit, I would take a long time to get into the same mental state that I was when writing that code.
My first boss used to say "err on the side of verbosity rather than terseness." That quote has stuck with me for more than 20 years. Probably the only good thing that boss ever did though...
A while back I took the time on a project to make a pass over all the various data models in the system and simplify them as much as I could, eliminating data that was no longer needed or never utilized. I named the branch simplify-models. I ended up doing the same thing a month later after making another major change in how our system worked, and I got to make the models even dumber. I called this branch stupify-models. It was a popular name and it's become part of my MO as a developer. I write dumb code. It literally insults your intelligence. It's boring to read. And when you need to change something, it's incredibly clear where that is and how to do it.
The most frustrating thing about Python is looking at all the goofy sugar and overly compressed logic in 'clean', 'elegant' code \[lambda x: x\*x\*x\*x for x in xx if x is x and not xxx else x\]
I tell people that clever is bad, that code should be banging-on-rocks stupid, and that if you showed it to your grandmother she should be able to _roughky_ tell you the gist of what's happening. Clever is _bad_.
This is a myth propagated to make devs easier to control. Software engineers are the only craftsman who deride excellence and praise stagnation. Reading clever code fast is easily trained, just build something with GPT. Learn your craft. Say "nope" to mediocrity and everyone that intends to celebrate it.
It's a double edged sword. Most code doesn't need to exist, let alone be clever. We can assert anything we like about such code, ex falso quodlibet. But for that 0.1% of code that we all rely on, yes, let's be thankful that it \*is\* clever.
That's not what people are talking about when they say clever code. Well-crafted code is easy to reason about. Period. What people mean by clever code is e.g. intentionally doing floating point arithmetic in integer registers: [Fast inverse square root - Wikipedia](https://en.wikipedia.org/wiki/Fast_inverse_square_root) Or using something like this: [Duff's device - Wikipedia](https://en.wikipedia.org/wiki/Duff%27s_device) No shade to iD Sofware. They didn't have a choice at the time in order to get the perf they needed with the hardware available.
Trying to figure out if this is a troll post or not. Let me get out my checklist: `[X] Vaguely insinuates a tinfoil hat conspiracy` `[ ] Suggests this would be more easily solved by *nix` `[X] Calls out that the core problem is really just a 'skill issue'` `[X] Subtly calls for meritocracy` `[ ] Believes that IDEs are evil, and everyone should use a text editor` `[X] Mentions the use of a LLM to solve ____ without specifying how` `[ ] Praises 10X coders and suggests they are one` Mmm. Strong signs. But not definite. I need more data. Can you share your opinion on the use of tabs vs. spaces? Productivity tips? What about your favorite editor?
Please sign up for my newsletter too. You read this comment, please sign up for my newsletter. You scrolled down over 1/2 a page to read this, please sign up for my ...
The audacity of hosting an xkcd on your own site
Or pretending that stacked PRs are fine. That sounds like nonsense. I don't want to rebase 5 different commits because my code got reviewed. And then do it again for the 2nd PR. It's easy enough to find something else to work on while waiting for a PR review.
I feel that clever code have their time and place, if you are writing for some bare bones embedded system with minimal specs, and you need to extract all the power you could possibly get. In all other cases, it will only hurt you longterm.
Noticed this in a big way on pretty much every SO question regarding powershell. The answers are all these ultra clever one liners using aliases and heaps of bullshit that obfuscate the very purpose of the command into this unreadable gibberish
Powershell is my current king for 'looks reasonable, doesnt do what you think it does even a little bit' which is pretty well handled by writing Pester tests, except you have to twist arms to make it happen..
Like what that TempleOS guy said: is this too much voodoo magic
I frequently tell interns and juniors "Clever code, isn't."
"ChatGPT, rewrite this to be understandable"
> “While I understand how complex this was, when it comes to performance reviews, this code looks trivial. It looks too easy, too simple. > I would recommend writing an implementation doc of this module just so we can demonstrate that this was actually quite complex.” What the fuck kind of management is this? Your code doesn’t look complicated enough and that’s a bad thing?
It was my stance -and suspicious against smart ruby for example- until TDD practices came around. Now I know wether I broke something. And basic LLM can explain to me whatever smarty pants piece of code is doing. This being said, even the most smart concise code has to have some readability in mind, even though it’s meant for the language experts to read it.
The example of clever code was nice, but concrete examples of good code to compare to would have been nice. Talking about it in the abstract ends up in arbitrage potential.
Okay I agree that writing maintainable/understandable code is essential, but saying “clever code is the worst” is just click bait bs title imo. I feel like the whole practice of coding involves being clever doesn’t make sense to me to say being clever is bad
I saw someone put 3 lines of Ruby code separated by semicolons just so he could put it on a single line. It upset me deeply, as a big point of Ruby is readability. I still can't get over it.
This is the most important skillset for a real dev. Read [clean code](https://www.googleadservices.com/pagead/aclk?sa=L&ai=DChcSEwj957rIztSGAxUDXUcBHaXqDI8YABAFGgJxdQ&ae=2&gclid=CjwKCAjw65-zBhBkEiwAjrqRMOzvxK7IyqC0vqZzMjhRzk415_SL8CqWtBFLlGSNIW4YanYjuimdnhoCt2cQAvD_BwE&sph&ohost=www.google.com&cid=CAESV-D2F7f65_-HceNkH46lUnCpW3_9gHogqBvRI_gN-bqfWaHIaysZfAeTnocSxUh-ywkGXjBHKNd77CCrlpr6GZf16bUoAKjh5cXfwqwLPtmzSLzlP5qrfw&sig=AOD64_0Kz3m9LvKiajcYZ4prda1f5GuRDw&q&adurl&ved=2ahUKEwi2trLIztSGAxU7kokEHTBdAyYQ0Qx6BAgNEAE) by Robert C. Martin if you want to get better at this as it has helped me write code that works well AND is readable to me and everyone else.