Comment by londons_explore
Comment by londons_explore 19 hours ago
Notice how pretty much none of these are added in the last 10 years?
Android's become 'more mature' - ie. Boring, and the joke to code ratio is dropping rapidly.
Comment by londons_explore 19 hours ago
Notice how pretty much none of these are added in the last 10 years?
Android's become 'more mature' - ie. Boring, and the joke to code ratio is dropping rapidly.
> humor is highly contextual.
This is key. Writing jokes is easy, but it is much harder to guarantee that your joke is only displayed in appropriate contexts in the future. When what the author thought was a witty joke shows up in a new and inappropriate context, they no longer look very witty, but instead like a fool. What is funny in developer documentation on a normal Tuesday might not be funny in a negative article on the front page of the Wall Street Journal.
Good, I hate ‘funny’ code. Just get to the point, I’m not here for someone’s notionally hilarious inside joke from 18 years ago.
Ah I see you're one of those who would enable `UserManager.DISALLOW_FUN`!
I personally quite enjoy a bit of whimsy in code. What we do (mostly) isn't that serious (modulo those, including me once upon a time, who work on literal life and death software)
I think that's a big line between people who work as software engineers becuase they enjoy the work and want to build something and folks who go there to punch the ticket and run back home as soon as possible.
The second group doesn't want to deal with "all the fun crap" and "distractions" that stand in the way of them marking a bug fixed (or, god forbid, actually getting extra bugs/work assigned because some "fun" code might break or cause confusion).
As teams and companies grow, the second group usually outgrows the first and the first group moves on to reform into smaller teams working on something else again.
Things that seem fun when they are written are often not much so a few years later, without the initial context, when trying to actually "build something".
Fun is good when it is fresh. Fossilized fun is not that fun. It is more like that uncle who heavily tries to be fun at family parties.
I have had my share of fun things I added to code/environment. Yet then we add 'the new guy'. They spend a long time arguing why that humor should not be there. One project it was a single line comment about new beginnings on the main procedure. That created a 2 hour rant about how unprofessional it was and months of unwarranted verbal abuse. It was literally the only piece of humor in the entire codebase. Super petty. Turned a fun functioning team into a slog of even wanting to go into work and all the rest of team reassigning themselves to other work. I use it as a litmus test these days of what I want to work with. Kind of tempted to add it to interview questions but have not found a proper way to do it.
I agree with you. The dinosaur game in Chrome is the classic example; turned off because schools threatened to not buy Chromebooks if kids could play a game in the browser. At least it seems to be a setting now, so your individual locality can decide if fun is allowed.
That’s quite different from what we’re talking about though. That’s adding games or fun into your product whereas in this specific sub-thread we’re talking about naming code concepts (functions, classes, variables, enums, etc) funny things.
I don't mind either personally, but I've had a few occasions where such things have caused issues with engineers that didn't have English as a 1st language.
A fair bit of time was wasted on trying to understand some joke/pun code and variable names, and on another occasion, spending the best part of a day working on something because they took some sarcasm in code/comments literally.
I couldn’t agree more. I work in a codebase that has a handful of these “fun”-named functions/concepts and I hate it. It wasn’t funny the first time I came across it (just very confusing) and it’s not fun having to explain to new hires why a few things are named the way they are.
It needlessly complicates reading/following the code. Even if you explain the naming back at where you define the function/variable it add an extra click-through/hover to read that and an extra translation you have to do in your head when you read the “fun” variable name in the future.
One example is we have a flag called “dinnerbell”. What does that do? It tells the server receiving that flag to “come and get it”, “it” being the full data object instead of just getting a delta. It could have been called a whole slew of other things that would make more sense.
Live a little. When you've passed away, was all the seriousness paid off?
That said, funny code should still work
There's a middle ground for sure. I've left a few witty comments and loglines in my time.
But I've also had to debug a Delphi unit which returned error codes inspired by the magical supercomputer Hex from the Discworld novels.
"Divide by cucumber error" is not a decent enough representation of a module's internal state, no matter how funny you think you are.
"Divide by cucumber error" sounds like a great string to grep for - so actually helpful for developers to find the place in the code that threw it.
Not having to understand someone's goofy inside joke gives me more time to spend on the things that matter the most to me. So: less funny code == living a little more.
Who cares what happens after you’ve passed away.
Every single person who isn't you.
You are aware there are other people besides you, right?
I remember when the Steam "login from a new computer" auth flow shoved a big "Hi there!" in user's faces the moment it blocked access to their entire online functionality until they left to get a code from their email and came back. Sometime later they removed it and now it's just "please look for the confirmation code sent to <address>".
I think in the push to make computing "friendlier" by dressing up error messages, past a certain point they began to come off as condescending. I wish modern UX could focus on working for me instead of trying to be my friend all the time.
I've noticed that modern life is in general less fun than it was 10 years ago. It might be me getting older, but I'm sure there are bigger societal changes too. BTW I used to browse tcrf.net and it was so interesting that video game developers would leave pieces of themselves in their work. Love letters, old memes, angry letters, random shit, whatever. Meanwhile modern programming is all about pRoFeSsIoAnALisM and MaXiMiZiNg PrOdUcTiViTy at all costs.
Yes, it like a rite of passage from a startup to “mature” company. It’s like Google’s or Reddit’s April Fools jokes. Actually, the novelty of April fools jokes can probably be a KPI of how corporatized a company is.
> BTW I used to browse tcrf.net and it was so interesting that video game developers would leave pieces of themselves in their work. Love letters, old memes, angry letters, random shit, whatever.
This is quite dependent on the games you play. Modern games are becoming larger, which makes the project overall more serious and makes it harder to hide easter eggs. That being said, Indie games with small teams still contain a lot of fun and even AAAs can still contain some goodies.
I think it really is up to us to make things as fun as we want to see... There may be more minefields as we grow old (Can a senior pull a harmless prank on newly joined juniors without coming off as mean/threatening?), but at the same time these little joke comments/commit messages, pranks etc.. are what brought people closer together in every place I worked at so far...
I mean what other choice do we really have? let the fun police win?
If you're 10 hours into debugging something, or you're swamped with a horde of bug reports and bad reviews, and after digging in you find the bug is in upstream code laced with humor, it comes off as if upstream isn't serious about software development or is making light of the responsibility. Lots of things start small, but X11, Android, etc etc are now used by millions, in lots of different situations, and humor is highly contextual.