Was gonna write that it pays dividends only from a certain project size onwards, but in fact it could be true from a certain org size instead. So yes, it has some component of bureaucracy-as-code, and I agree with the author that that can be a good thing.
... and then they ignore it?
It triggers me when someone calls hidden swipe gestures intuitive. It's the opposite of affordance, which these designers should be familiar with if they are worth their salaries.
Funnily, 1.5 decades after Golang popularized formatters, in 2024 it is the only language that I work in that requires me to think about formatting. Mostly line length, but super annoying.
They have tons of commuters and business travelers. Didn't look into the methodology, but my first guess would be that those are included in the numerator, but not in the denominator.
Do it. I recently built a beefy machine, the first time in years that I have something I can play on, it's Linux only and it's great. Deepening on the games you play, check protondb first.
In the intern's place, I probably would not have bragged about copying that company's idea.
Then again, as the company, if I felt a former intern could threaten my business like that, I'd ask serious questions about my value proposition and moat (which could be premium features, sales, or an attractive/viral free tier - not too familiar with what they do).
On a personal level, I can see how it could feel unfair, but the idea does not seem that original.
In the second example, buffer is still a pointer? If so, when does free run, and who decides that? When buffer goes out of scope, could do_stuff store the pointer some place else?
I find this an interesting thought experiment, basically types that you'd opt in to RAII. Just have a feeling that you'll need to define some notion of ownership to make it work.
Try-blocks with ~one line are best practice on code based I have worked with.
The upside is that you can bubble errors up to the place where you handle them, AND get stack traces for free.
As a huge fan of Result<T, E>, I have to admit that that's a possible advantage. But maybe that fits your definition of lazy :).
Some of the in-house stuff was built before alternatives were available or scalable, and now there'd be a high cost and friction to trying to change it. Happens in many big companies that have been around for a few decades, it's not because of bad intentions.
Interesting. Though "ein Paar" is singular, "ein paar" is plural, making it clear from the context in many cases. Curiously, it's not clear in the case where it matters most: "please bring [ein [pP]aar Socken]".
As an engineer, I'd say "please bring ein Sockenpaar" when I mean ein Paar, for clarity, for the low price of people thinking I'm weird.