Bonus: good tests can also serve as technical documentation.

Though I have to disagree with the notion that documentation is as important or more so than code.
Documentation is certainly near the top of the list and often undervalued. I’ve worked on a project where documentation was lacking and it was painful to say the least.
Without documentation, changing or adding features can be a nightmare. Investigating bugs and offering support is also very difficult. But without code, you have nothing. No product, no users, no value.

There are (inferior) substitutes for documentation: specialized team knowledge, general technical expertise. These alternative pools of knowledge can be leveraged to create and improve documentation incrementally.
There’s no replacement for the actual functionality of your applications.

Ditto on the no text part. That is an accessibility failure that’s way too widespread.
Sometimes I’m afraid to even push a button: does this delete my thing, or does it do some other irreversible change? Will I be able to tell what it did? Maybe it does something completely different, or maybe I’m lucky and it does in fact perform the action I’m looking for and which in my mind is a no-brainer to include?

And it’s infected interpersonal communication too - people peppering their messages with emojis, even professional communications. It not only looks goofy, but is either redundant (when people just add the emoji together with the word it’s meant to represent - such a bizarre practice) or, worse, ambiguous when the pictogram replaces the word and the recipient(s) can’t make out what it depicts.
The most fun is when it’s a mix - the message contains some emojis with accompanying translation, some without.

I don’t share the hate for flat design.
It’s cleaner than the others, simpler and less distracting. Easier on the eyes, too. It takes itself seriously and does so successfully imo (nice try, aero). It feels professional in a way all the previous eras don’t - they seem almost child-like by comparison.

Modern design cultivates recognizable interactions by following conventions and common design language instead of goofy icons and high contrast colors. To me, modern software interfaces look like tools; the further you go back in time, the more they look like toys.

Old designs can be charming if executed well and in the right context. But I’m glad most things don’t look like they did 30 years ago.

I’m guessing many people associate older designs with the era they belonged to and the internet culture at the time. Perhaps rosy memories of younger days. Contrasting that with the overbearing corporate atmosphere of today and a general sense of a lack of authenticity in digital spaces everywhere, it’s not unreasonable to see flat design as sterile and soulless. But to me it just looks sleek and efficient.
I used to spend hours trying to customize UIs to my liking, nowadays pretty much everything just looks good out of the box.

The one major gripe I have is with the tendency of modern designs to hide interactions behind deeply nested menu hopping. That one feels like an over-correction from the excessively cluttered menus of the past.
That and the fact that there’s way too many “settings” sections and you can never figure out which one has the thing you’re looking for.

P S. The picture did flat design dirty by putting it on white background - we’re living in the era of dark mode!

The point is not the difference between a fake memory and a real one (let’s grant for now that they are undistinguishable) but the fact that positive experiences are worth a lot more than just the memories they leave you with.

I may not know the difference between a memory of an event that I experienced and a memory of an event I didn’t experience. Looking back on the past, they’re the same.
But each moment of pleasure that I only remember, without having experienced it, was essentially stolen from me. Pleasure is a state of consciousness and only exists in the present.

This works as a general guideline, but sometimes you aren't able to write the code in a way that truly self-documents.
If you come back to a function after a month and need half an hour to understand it, you should probably add some comments explaining what was done and why it was done that way (in addition to considering if you should perhaps rewrite it entirely).
If your code is going to be used by third parties, you almost always need more documentation than the raw code.

Yes documentation can become obsolete. So constrain its use to cases where it actually adds clarity and commit to keeping it up to date with the evolving code.

It's a big deal IMO, particularly because at login it doesn't do the same. From the user perspective, your password has effectively been modified without your knowledge and no reasonable way of finding out. Good luck getting access to your account.
When a bank does this it should be considered gross negligence.

If their password was actually good (18+ random characters) it's not feasible with current day technology to brute force, no matter how few PBKDF2 iterations were used.

Obviously it's still a big issue because in many cases people don't use strong enough passwords (and apparently LastPass stored some of the information in plaintext) but a strong password is still good protection provided the encryption algorithm doesn't have any known exploitable weaknesses.

El psy kongroo

Extra steps that guarantee you don't accidentally treat an integer as if it were a string or an array and get a runtime exception.
With generics, the compiler can prove that the thing you're passing to that function is actually something the function can use.

Really what you're doing if you're honest, is doing the compiler's work: hmm inside this function I access this field on this parameter. Can I pass an argument of such and such type here? Lemme check if it has that field. Forgot to check? Or were mistaken? Runtime error! If you're lucky, you caught it before production.

Not to mention that types communicate intent. It's no fun trying to figure out how to use a library that has bad/missing documentation. But it's a hell of a lot easier if you don't need to guess what type of arguments its functions can handle.

The point is that you’re not fixing the problem, you’re just masking it (and one could even argue enabling it).

The same way adding another 4 lane highway doesn’t fix traffic long term (increasing highway throughput leads to more people leads to more cars leads to congestion all over again) simply adding more RAM is only a temporary solution.

Developers use the excuse of people having access to more RAM as justification to produce more and more bloated software. In 5 years you’ll likely struggle even with 32GiB, because everything uses more.
That’s not sustainable, and it’s not necessary.

I’d say generally speaking it’s more likely that issues stem from extensions than from Firefox itself, so maybe try looking into that.

Btw tab reordering is only missing for private tabs on the latest ff on Android.
Unfortunately there is still no acceleration when reordering so the ux is not great when you have many tabs.

That does indeed seem like the hangup in this case, and it’s on me; I should have used a less vague word or else clarify.

To me fresh is anything that hasn’t been processed for preservation (except drying). So cheese isn’t fresh, heat treated milk/cream isn’t fresh, smoked and cooked meats aren’t fresh, pickled foods aren’t fresh, frozen foods aren’t fresh and anything with actual preservatives added is definitely not fresh.
“raw” would probably have been the better word to use.
Also, having thought about my own understanding of the word a bit more in depth, I’ll concede that some pickled veggies are pretty healthy, as well as yoghurt.

You were right with all three examples.

I’ve been trying to think of things commonly sold in supermarkets that are not fresh and that are more healthy than fruits, and after a few minutes I have to say I came up blank.
Maybe vegetable soup? Not sure if you can get a good soup at the supermarket.

Care to share a few examples?

Actually fruits are pretty great for us, if they aren’t highly processed.
Better to eat an apple than drink apple juice, also better to eat an apple than just about anything from the supermarket that isn’t fresh.
Of course, you still need a balanced diet, and you can’t get nearly all the necessary nutrients from just apples. Still, assuming an otherwise nutrient-complete diet, it’s a lot less healthy to eat a slice of frozen pizza than an apple or a banana. (the apple might even contain less available sugar than the pizza slice - people often overestimate how much sugar fruits really contain)

The “stuff removed” bit is more important than you seem to give it credit for. Take out all the fiber and water and sure it’s still the same sugars that are left over, but we didn’t evolve to consume large quantities of pure sugar, so it spikes our insulin and gets stored as excess fat.

Fruit juice is pretty unhealthy, because all the sugar is more available due to all the fiber being stripped out and you can consume a dozen apples’ worth in a few minutes, which you wouldn’t do with actual apples.

Sure, there’s not that much fiber left in raisins either. But in the context of musli they can be combined with whole grains and nuts, so you get enough fiber back to make the sugar less quickly digested and thus more healthy.

A third of the entire cereal mix being sugar is definitely worse than musli with raisins (which comes to about 10g of sugar per 100g), especially considering that a good portion of the rest of the mass in the case of musli is made up of fiber, proteins and healthy fats.

Adding sugar isn’t just “another big issue”, it’s the big issue. Eating fresh fruits is a non-issue, and usually so is eating dried fruits in moderation.

Many of the programming languages that are regularly the butt of everyone’s jokes don’t just allow you to use them badly, they make it easy to do so, sometimes easier than using them well.
This is not a good thing. A good language should

• be well suited to the task at hand
• be easy to use correctly
• be hard to use incorrectly

The reality is that the average software developer barely knows best practices, much less how to apply them effectively.
This fact, combined with languages that make it easy to shoot yourself in the foot leads to lots of bad code in the wild.