Comment by girvo 19 hours 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)
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.
Google is not fun and people that try to be funny from Google are cringe
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.
Better to reassign 'the new guy', rather than let him destroy the team.
Exactly. However, that would mean the boss thought the same, as he was hired specifically for that team. By the time it had happened the boss had not even noticed. Despite the team basically telling him every day in 50 different nice ways. In this case I did not realize it was controlling and manipulative behavior. But I learned and can spot it off pretty quickly now and will make sure it does not happen again.
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.
Not to mention even just this article exposed a just-for-fun API that ended up having a negative effect and had to be removed:
`isUserAGoat` ended up allowing any caller to determine if a specific app is installed on the system, which is a privacy violation and allows fingerprinting against the user's consent.
I get the desire to make the job more fun than just implementing a spec, but many of the things we work on are very important and very complex, with oodles of real-world consequences. That unfortunately means everything we do has to be well-considered and not off-the-cuff.
Well it was not an issue back then since any app was able to query certain arbitrary specific apps (and yes some apps used to query a big list).
They disabled the "fun" function in android 11 with the arrive of the QUERY_ALL_PACKAGES permission.
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 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.