brianpan

These names are not just for engineers.

Why is it ok for engineers to have confusing names and ways to interact with something?

How am I supposed to decide between these options: https://imgur.com/a/bXHWowL

How am I supposed to keep up with the changes every few months?

This is what finally made email useful for me again. I use hey.com email and the Screener whitelist is probably the most important feature. (Selective notifications being the second most useful for me.)

I think this could work for text messages, too. All new texts could go to a screener and don't notify until you opt-in.

Dang, it's THE Carson Gosu? :D

Evidence-based assertions are a good thing, but some things are so obvious that a "comparison" or "research" is not needed. This is already an obvious problem in so many places from high schoolers turning in assignments they don't understand, coders submitting code changes they don't understand, blog posts, and certainly to scientific papers.

100% disagree. The more you don't know an area, the more LLMs will lead you astray.

Explaining difficult topics or summarizing to you is fine. But that's a world of difference from having an LLM write for you. You THINK the LLM is helping you write above your level, but that's because you are not in a position to tell it's bad.

Is this actually clickbait? The title is in the form of many clickbait title, but I'd argue it delivers; the article is more interesting than the title.

I suggest readers spend the click and the five minutes.

Defacement is not the point of graffiti. It's fundamentally visual, not fundamentally destructive.

Video:

https://imgur.com/a/UDDDgFz

Sorry for meta comments, but are we writing blogs like tweets now? I got 2/3 of the way through before getting overwhelmed by the lack of paragraph groupings to help me follow the stream of consciousness.

Interesting post though.

And the dishwasher, the laundry washer/dryer...

There's also plenty of examples where technology creates something very different than the thing that humans were doing: photograph vs painting, car vs horse/bike. It would be silly to say that we have all this horse infrastructure and saddle UX that we don't want to break compatibility with.

Maybe the lesson is that humans are adaptable but machines/manufacturing is not? It's easier to make a great new thing that humans will use than it is to make a cost-effective production thing that exactly replaces what humans did.

There are different ways to create an iceberg. You are probably thinking of a hard chunk of ice breaking off into the ocean, but probably a more common way is glaciers running into the ocean. A glacier is basically a "river" of snow and ice slowly flowing down a mountain. It would generally not be very compacted.

Fun fact: smaller chunks (less than 15m) are called "bergy bits".

Yes! Clean code (which is more readable and maintainable) should be a stop on the way to higher performance code. Otherwise, you are optimizing too early.

A food processor is a kitchen tool even though it does many things.

A computer is also a tool that does many things and the OS is arguably the important part of how a user wields that tool.

Growing up I definitely noticed the wobble.

But I'm also so used to it that I didn't realize a lot of examples were videos.

Really interesting investigation!

Jurassic Park had a Thinking Machines CM-5.

https://www.starringthecomputer.com/computer.html?c=15

"The lights flash just like they do normally, although it's hard to understand why a theme park needs a supercomputer."

:D

3/4/5G/LTE networks and 802.1x predate their 8 years in aerospace. I worked on some of those 25 years ago. If you're not an EE, maybe you also didn't consider the lead time of working on HW to its adoption.

You should not be touting magical health benefits on a sample size of one either way.

There are already plenty of studies available to be found.

Like a person playing the piano.

If your arms are resting, then your fingers and wrists are doing the maximum amount of reaching as you type. If you use a wrist rest you are encouraging your fingers/wrist to reach up (bend in your wrist) instead of neutral or reaching down (more natural position).

Optimal line length is a thing.

This is a way to tell if something is social media or attention media.

"Surfacing the best comments" is only a problem at scale. And attention media demands scale whereas your social circles break down at scale. Commerce sites (like Yelp or Amazon) also demand scale, so they also have a "surfacing the best" mechanism.

It's a cost-benefit analysis like many other things. There are limited resources, they should be spent on investigating cases that have a chance of getting closed.

Cold cases might get reopened because of advances in technology or other changes over time.

Late reply, but did your colleague go from ICE BMWs to an EV Model 3? For me, zero maintenance and no more stopping at gas stations (you need a charger at home) were HUGE advantages to switching to an EV. So I also really liked switching from ICE to Tesla EV.

But I also much prefer my EV BMW to my previous Teslas. Nicer to drive, nicer features (better sound, HUD, sunroof), hardware controls, door handles that you can open with either hand, better in weather (no rain in the trunk).

My family complains the i4 has a smaller cabin, but the driver's seat feels just fine to me. :D

Not saying please or having to be polite is often simpler.

Knowing and using etiquette is often more effective.

If we're comparing notes, I traded in my Model 3 for a BMW i4 and I couldn't be happier. It's a nicer car and more fun to drive!

JD Power and Consumer Reports both rate BMW above average.

BTW, my impression of BMW maintenance from prior decades is expensive and not great reliability. I care about it less now with EVs because there is so much less regular maintenance. No oil changes, no brake pad changes, etc.

You said: alcohol can be an amazing way to clean screens.

It's still true that: alcohol is a very good way to destroy the old glossy screens.

"Universal design" or "design for accessibility" will give you lots of examples of constraints that are not "commonly" needed ending up having much wider application and benefiting many other people.

Some oft-cited examples are curb cuts (the sloped ramps cut into curbs for sidewalk access) and closed-captioning (useful in noisy bars or at home with a sleeping baby).

There are many examples from the web where designing with constraints can lead to broadly more usable sites- from faster loading times (mobile or otherwise) to semantic markup for readers, etc.

I felt really silly that the answer is just adding a "-i".

But then I tried it and...WHAT?! Git is an endless rabbit hole of complexity.

I think you're thinking about git as a separate thing from the IDE.

I love using IJ + git because there are no seams in between edit and commit. For instance, with IJ, I could easily split every other line of a change into separate commits.

Maybe there's a way in git to stage only certain parts of a diff, but I'd have to go an learn another flag or command that I'm going to forget by the next time I need to do it again.

Also with IJ, I just glance at my main branch tab and the highlighting tells me what commits aren't in my checked out feature branch.

Two small examples but there are many more and it adds up.

You're right. A good postmortem/root cause analysis would START from "unwrap" and continue from there.

You might start with a basic timeline of what happened, then you'd start exploring: why did this change affect so many customers (this would be a line of questioning to find a potential root cause), why did it take so long to discover or recover (this might be multiple lines of questioning), etc.

The diffs are the biggest reason I use it (beside the 3-way diff, I can't live without: blame, optimize imports, all the editor functions inside the diff, diff files/commits/branches).

Beyond that: separating into change lists (staging changes by line inside a file) and the graphical presentation and filtering of the commit history (highlighting what commits are in/out of your branch, show the git history of a section or line of code, show repo files at a commit)