I totally get that: use the right tools and you’ll be okay. This applies to many technologies in this space.

With respect, I still take this advice like hearing “look out for rattlesnakes if you’re hiking there.” It might be safer to just hike where there are no rattlesnakes, instead.

I swear, overcoming fixed functional-ness is like a superpower when you can apply it.

I once shared a small office with a co-worker. I had the idea to move the desks away from the walls and place them back-to-back, diagonally, in the middle of the room. Other co-workers scoffed and remarked at how dumb and unconventional this looked. Then I explained that we each now had nearly full privacy from each other, much more personal space in our respective corners, no more glare from the window, and nobody could sneak up on us from the door anymore. Things got pretty quiet after that.

Useful? Not exactly. But you’d never look lazy or idle, that’s for sure.

/me goes back to get second folding chair.

Pascal went to military school.

I’m not in love with the idea, but a language that cuts out the BS has a sudden appeal when on a group/team project.

I take this as less of a “I can’t use this intuitive feature reliably” thing and more of a “the truth table will bite you in the ass when you least expect it and/or make a mistake” thing.

The worst ones are safety rules: those are (sometimes) written in blood, with stories to match.

Company: Provides amenities and services that would (technically) allow a person to live on premises. Pays you enough to retire early if you didn’t have to bother with rent or a mortgage.

Also company: “We can’t hire you without a permanent residential address.”

I also worked at multiple places that had fully decked out break-rooms: free food, game consoles, VR, and 60-inch TVs. Everyone was afraid to use them for fear of looking like they were screwing around. Except the interns. They used the hell out of that stuff.

I’ve seen this kind of thing too many times to count. First it was in high school, then the workplace.

1. Person notices there is no explicit rule for a thing, or maybe there’s a loophole somewhere
2. Does the thing
3. Annoys someone
4. Now there’s a rule for the thing

Some people just want to push the envelope. Other times, people can have a poor grasp of social norms, or they simply don’t respect others. But on the other side of the coin, people get annoyed for good and bad reasons; sometimes, no reason at all.

Bottom line: it’s a mess, so we get rules. But nobody wants to spend time writing these things and enforcing them, so there’s usually a reason/person/event why they’re there.

Software maintenance was seen as a necessary evil.

The most important lesson I learned about the economics of software is that sourcecode is always accounted as a liability and not an asset. Accountants will never let you code your way into more value. Everything else you see stems from that truth.

A times B times C equals X. If X is more than the cost of a failure or security breach, we don’t fix the software.

Are there a lot of these kinds of problems?

You wouldn’t believe.

Which Fortune 500 company do you work for?

A major one.

Also that’s likely a team that doesn’t use a branching workflow, has poor review on merges, and/or using Git like it’s SVN.

Same.

Wow, what a bro. Where was this guy when I was in school?

::re-reads comment and thread::

Oh. Yeah, that one’s on me. That makes a little more sense.

Also AMA about soda dispensing at bars.

It’s been ages since I worked in a restaurant. IIRC, I never saw that place purge or clean the soda lines. And there was a LOT of plumbing between the fountains and the back where the syrup was kept.

At the risk of making everyone re-think ever eating out again: how often do establishments do that kind of maintenance? And is that within the recommended manufacturer interval?

The problem is that requirements refinement has been unceremoniously dumped in your lap. The failure here is organizational; maybe you have a design person involved, maybe devs are expected to do this. Either way, your job now also includes communications.

One strategy I’ve used is to draw a low-fi example of what they’re going to get - Figma is great at this these days. Then I add it to the issue and push the whole thing back for early approval in order to suss out these finer points.

Not to come off as misanthropic here, but many people are hot garbage at describing what’s in their head. Most of the time, it’s all abstract concepts up there until you start asking the real questions. They really do need a whole-ass conversation to sharpen that mental image. Or in this case, what they want that feature to look like. Incidentally, this is also the reason why therapy is a thing, and why it takes people years to make sense of themselves, and that outcome is usually far more crucial than anything we’re doing at the keyboard.

Honestly I don’t mind the indentation since C isn’t going to give us many ways to address this with as little code.

That said, with compilers that are good at inlining trivial functions, I really do appreciate the “it does what it says on the tin” approach to using functions on things like this. Even if they’re only used once. Comments would help too.

The logic in these if statements is inscrutable on a cold read like this. To me, that’s a maintenance risk; imagine seeing a snippet this size on a PR. Having functions that name what the hell is going on could only help.

In a one-liner competition, sure.

In my codebase? I’d pull a “let’s linger after standup about your PR” and have the coder sweat through a 10 minute soapbox about nothing before laying down the law.

One nit: whatever IDE is displaying single-character surrogates for == and != needs to stop. In a world where one could literally type those Unicode symbols in, and break a build, I think everyone is better off seeing the actual syntax.

This is really the only sane way to do it. I have run into some wonkyness with the commit history of the target branch commits not resembling git log, but that’s usually for commits outside of what I’m trying to merge.

Edit: squashing commits down this way also helps reduce problems with replaying commit history on the actual rebase. In most cases you don’t need all your “microcommits” in the history, and fewer commits just takes less time to reconcile.

If you’re using “trunk-based development” (everything is a PR branch or in main), this works great.

If you’re using GitFlow, it can make PRs between the major prod/dev/staging branches super messy. It would be nice if GitHub would let you define which merge strategies are allowed per-branch, but that’s not a thing (AFAIK). So you’re probably better off not squashing in this situation.