One upvote is not enough.

I once wrote a commit message the length of a full blog post comparing 10 different alternatives for micro optimization, with benchmarks and more. The diff itself was ten lines. Shaved around 4% off the hot path (based on a sampling profiler that ran over the weekend).

Ew no.

Abusing language features like this (boolean expression short circuit) just makes it harder for other people to come and maintain your code.

The function does have opportunity for improvement by checking one thing at a time. This flattens the ifs and changes them into proper sentry clauses. It also opens the door to encapsulating their logic and refactoring this function into a proper validator that can return all the reasons a user is invalid.

Good code is not “elegant” code. It’s code that is simple and unsurprising and can be easily understood by a hungover fresh graduate new hire.

Yes. I’ll read the content, but I try to avoid interacting.

Mind you, db0 himself is a tankie, although he doesn’t seem to insist on imposing that on the users or communities on his instance.

Anything using Blind as a “verified industry source” is going to be skewed to the type of person who uses Blind. Beyond that, it’s low sample size, and there are suspiciously round fractions for some of the larger companies. Worse, because Blind is blind - this doesn’t represent current employees, but merely people who worked at some point in the past at those companies.

Not saying it’s not good - just saying not to get overly excited over a badly done survey

Holy propaganda batman!

The list of articles on that website is…extremely focused on one subject only.

There’s a fine line between disrespecting a fallible opinion and disrespecting the person. In writing, it’s easy to cross that line. It’s ok to disagree with people, but it’s important to sometimes take the step back and remember that the person is larger than any singular decision. There’s likely context you’re missing that lead them to that decision.

The biggest thing to remember is that more likely than not, if you really and truly fuck up your job, chances are the worst you do is create extra work for your team. They probably won’t even be in danger of losing their jobs if you truly screw up. It’s not likely that people will die. The blast radius of most software engineering jobs is incredibly small.

Good luck with it!

It is “fun”, and there are lessons that Ruby has that should be taken elsewhere, like the principle of least surprise. The most important one is MINASWAN: Matz is nice and so we are nice.

Matz described Ruby as Lisp with C semantics, and Perl convenience.

There’s a reason the CLI flags can put it in “perl mode”

Larry’s webpage

The actual SEC report is relatively short - and surprisingly accessible.