darkandbrooding

Did you intend to reference "It's a wonderful life?" When I read your comment I imagine a tiny child in Jimmy Stewart's arms, exclaiming the joys of capitalism ;-)

My employer fits your first criteria precisely. Turbo and Stimulus provide exactly as much interactivity as we need. The appearance is that we're trying to avoid Javascript. The reality is that we are (successfully) minimizing context switching when working on the code base.

I freely admit that I pulled numbers out of a hat, just to help me visualize the problem.

I was curious and did some math. A five minute zoom call is not realistic; you probably need 15 minutes per person. If my math is correct, and if no one was even a minute late, it would take 225 hours to lay those people off sequentially, assuming 24/7 meetings. If you had 15 managers making those calls, it would still take 15 hours to complete all calls. Let's call that three business days, during which no other work gets done anywhere in the company.

I once worked at an employer who performed five rounds of layoffs in the space of a few months. I cannot recommend that method.

I agree with you, the 900-wide bandaid was the only practical option.

You and (other person) started your lives on different dates, in different places, in unique circumstances; you are statistically unlikely to end those lives at the same time and place. If the two of you appear to be following the same path for a portion of those lives just enjoy the company while it lasts. There is no single, universal measure of success, so the fact that one person's achievements exceed your own in one area is cause to celebrate that other person but not a reason to feel bad about yourself. Be better than you were yesterday, be kind to those around you. Your story (hopefully) has decades left to tell. It probably includes major characters that you haven't even met yet.

Apt sidesteps this problem because Debian-based releases are not rolling releases. Unless you install a custom PPA, if you are running Ubuntu 18.04 and you "apt-get install postgres" you will always get version 10.x. The major version number will not get bumped for Ubuntu 18.04.

If want to use a version of postgres other than 10.x, you can either use a different version of Ubuntu or install a custom PPA.

Apt's target audience is systems administrators. Homebrew's target audience is independent developers who might need to have four different versions of Postgresql installed simultaneously on their laptop, because they maintain Rails/Django/Node apps for four different clients who are each unwilling to upgrade for whatever reason.

IMO homebrew is "messy" because it is trying to solve a harder problem. If there is such a thing as an average enterprise software developer, I would argue that homebrew is trying to solve problems that the enterprise developer does not have.

There is one single feature of homebrew that regularly bites my coworkers. You can refer to software by name@version ("brew install postgresql@11" or "brew install postgresql@12") and there is no confusion about what you are installing; or you can refer to software by name only ("brew install postgresql") and the version number is calculated to be "most recently released." (v13 at the time this was written.)

Hypothetically I have two machines that I want to build out and give to developers. One machine arrives on Monday. My script runs "brew install postgresql" (no version), because of when I ran that script postgresql@10 gets installed. Tests pass, I hand that machine off to a new developer. The second machine arrives on Wednesday. I run the same script, but because v11 of postgres was added to homebrew on Tuesday, the second machine receives postgresql@11 even though the first machine received @10. Same script, two days apart, different major version of postgresql.

Yes, I can write my scripts carefully to avoid this. But consider this scenario: a new developer encounters a problem, tries to solve it themselves, finds a seemingly helpful blog, and ends up with postgresql@13 and node@15 when everyone else in their team is using postgresql@11 and node@12. Now tests are failing, but only for this one developer and only locally...

Just adding to the choir. This is a great tool. I prefer using open source software when possible, but I also like to pay for the tools that makes my job easier. The developer is aiming at corporate, volume licensing and I understand how a Patreon account would run counter to their business strategy. I wish there was a 'small dollar donations' channel, though. I like this tool enough to throw them some regular money.

I won't presume to answer for the OP, but my (remote conference attendance) pet peeves include: I have printed out important information (but forgotten to email it); let me use the whiteboard that is mounted on the same wall as the camera to illustrate a concept; I will speak exactly loud enough so that only people in the room can here me; I will use the free tier of some conferencing service, and start the call fifteen minutes early so that the connection drops halfway through the meeting.

Almost thirty years ago now, driving around on a hot summer day with a couple of friends. One guy puts a punk mix tape in the player, and the guy with a college music scholarship was aesthetically offended. "Anyone could make this music," he complained.

The other guy nodded in agreement and replied, "that's the point."

A .psd file is not an end-user asset. I can think of no use case where someone would point a browser at a hosted .psd and expect that binary file to render as an inline image.

A .psd file was, for a good chunk of the past twenty years, the "de facto standard" file format for teams or entire departments of graphic artists who spent all day, every day in Photoshop. I once worked for an online ad agency and Photoshop was used more often, by more people, than MS Word and Excel combined. The Network Effect was in full force. Graphics teams at three different companies cooperating on the same campaign would assume that their counterparts were using Photoshop, and would expect to send and receive .psd files. Man, Adobe must have been printing money in those days.

If you worked in print publishing, digital publishing, advertising, marketing, there was probably a graphics department of people who spent all day in Photoshop... and an IT department that was constantly trying to add new server capacity as fast as those artists were consuming it. Back when we measured server storage in GB, not TB, fifteen different versions of the same massive PSD file could cause real heartburn.