jakub_g

You completely missed the point.

The OP is arguing that something should work by default without any configuration needed, and you're talking about building a bespoke tool.

In Instagram you can't really even put links at all. It's on purpose to keep you scrolling inside the walled garden.

> it's lot easier to add new capabilities, than rethink existing capabilities. So each product becomes a collection of abilities, without actually having unified point of view.

This is a a very good and succinct summarization.

What I'm also observing recently also is that pretty much every product tries to expand to do things that completely different products used to do, and become a mega-product-for-everything. It's like a Zawinski's Law on steroids.

The real question is: could someone explain me why anyone would want a smart coffee maker?

What kind of functions it has that can't be replaced by:

- walking a few meters and pushing a physical button

- waiting a whopping minute for coffee to brew, instead of triggering it remotely

In the past few months, there were several huge data leaks also:

- in Poland (from private medical companies used by doctors) with estimated 20M affected people (half of population)

- in France (from tax office), 678k people affected

With AI getting more capable, and with Russia escalating things, I unfortunately expect more to come.

Packt has been known to be slop even many years before AI. Very little proofreading / editing, authors rarely being well-known experts etc.

AI Labs doing unsafe things in the wild in production follows a long trail of predecessors, like Google and Facebook "not having enough resources" to prevent scam ads and getting stashes of money off it without anyone blinking an eye.

"We're doing things at such a scale that we can't monitor it anymore" became a universal get-out-of-jail card.

I'm looking forward to reftable to become the default. It solves many problems with branches, like branches with weird characters created with non-standard clients making a fetch impossible; case insensitive branches with "same" names doing the same; or impossible to create branch FOO because FOO/Something exists.

All those problems just go away when branches are no longer files on disk.

I enabled it in setup script of one large repo I maintain; the main issue is the incompatibility with some people's personal tooling based on libgit2 (some git status tooling in oh-my-zsh), but people do find workarounds.

Yup, having _two_ active devices which are logged in to Google (and possibly other services that you rely on that opt you in to app-based 2FA) + with backups of 2FA is a must at this point. When I buy a new phone, I make it a "primary", and keep my old phone as "backup".

If you're not into cloud-based password/2FA syncing, Google Authenticator supports local export/import across devices via a QR code. For passwords, I use KeePass Portable / Keepass2Android + syncing between devices from time to time through a USB-C pendrive (The source of truth KP DB is on pendrive, and both phones work off a local on-device cache).

You don't need to have your phone stolen for things to get messed up. If your screen breaks, you can't type in a PIN anymore, can't unblock with a fingerprint, and you effectively can't access anything on the phone. ADB won't connect because screen is off, and you can't unlock / accept a new external connection etc.

I dislike reduce because people sometimes do wild things in the callback that take a lot of mental effort to understand.

Sometimes people abuse .map as well to do things that are not obvious (i.e. instead of mapping elements of an array to another array, they modify global variables in a for-loop fashion, and discard the result).

But reduce is abused more often and you always need to think really hard if e.g. the initial accumulator is passed or not (it's optional in some languages!), if a correct one is passed (when a compound type is used) and so on.

One thing worth mentioning is that a law was passed around 2017 in France that as a tenant, if you want to install fiber, the landlord can't prevent you from doing so (because e.g. they don't want to drill holes in the walls or other excuses).

Also the vendors do not commercialize ADSL anymore since a decade ago or so if fiber is installed in the district.

Semi-related piece of advice for younger folks:

When you join a new team, don't try to change team tools, processes etc. starting in the very first week.

Most things are the way they are for a reason. Your "obviously better" idea may lack the full context. Start with observing the situation, talking to people to build understanding and historical context, and don't jump to conclusions too early.

Sometimes you'll be right, and things are suboptimal and based on long-outdated assumptions. Then, it's great to change them and improve! Freshman eyes are great for spotting such inefficiencies, and "new blood" is critical to make the team well-functioning and to improve the legacy stuff.

But improving and rewriting everything all the time has a cost. If you do too much of it too quickly, the team loses the understanding of long-stable processes and things. You may become a bottleneck as the "last person who touched this" in too many areas. People also have limited bandwidth to support your "rewrite everything" ideas every day, while trying to move on with their tasks.

Don't hesitate to suggest improvements, but please be mindful about the volume - especially in times of AI where everything can be vibecoded in an hour.

Finally, some "objectively better" things have no business justification. Improving performance of a piece of code than runs once a month? There's probably 10 more important things to do in your backlog.