amdelamar

I also really enjoyed reading this; the mix of computer science & history was well balanced and kept my interest.

It makes me think there should be a CompSci history class taught in college.

The amount of salt in photo #6 is too much salt. Its very easy to over-salt anything and ruin it. Better to under-salt until you gain enough experience with judging how much you actually need.

As for putting the meat grinder in the freezer, I'd like to know if restaurants do that or not. Because I highly doubt it. Seems very silly.

A 25% restocking fee seems like a better solution.

Physical NFTs! Sounds like a cool idea for a website...

> 4. Fail small, reducing blast radius

One more thing not mentioned here, is that using a microservice architecture can naturally help isolate outages to small parts of your app/website. Rather than take it down entirely.

My team supports a large microservice system, and while there are definite drawbacks to the architecture, one of the major benefits is that its never 100% down at any given time. Usually a prod incident will make one particular button flakey or one view/page fail to load. Some users won't even notice theres an outage. Oncall is paged and can quickly rollback the squeaky microservice to a previously deployed version, and let an engineer investigate the root cause in a test environment later.

I think there's a good analogy to a wedding ceremony I read from DDIA.

"Do you take X? I do. And do you take Y? I do. I now pronounce you X+Y".

A year ago I had a coworker build a CRUD app with an API that required GET with a body. Something simple like:

    GET /api/query
    Host: example.org
    Content-Type: application/json
    
    {
      "a": "valueWith$pecialChars",
      "b": "valueWith$pecialChars",
      "limit": 100
    }

It worked fine for him because he used curl, which allows GET with a body. But I was using Paw (similar to Postman) which refused to send it. I mentioned the issue to him to which the reply was along the lines of "its a non issue, just use curl". I kid you not, 1 week after this coworker left for another job I fixed the service to accept POST requests.

If QUERY was around I'm sure I could've made a stronger case to fix it sooner.

My team had migrated about 35 codebases from a mix of Play, Scalatra, Ruby, and Python, to Akka HTTP. The unification definitely made it easier for juniors to start work on unfamiliar codebases, but the same could be said if we unified on something else. That being said, a portion of the services did make use of Akka streams & actors and we’ve found a lot of success there that otherwise would’ve been complex code with locks or synchronized blocks. Stuff that I’d rather not have to onboard engineers with or review their PRs and miss an unlock(). It’s probably a steeper learning curve by teaching them about actors and futures, but it means they’ll be writing safer code by design, and reviewing their PRs becomes easier for me.

Just make sure the actors are small and have one focus. When they get too large and do too much is when they become unwieldy and difficult to maintain.

I've had a similar phase and just switched back to Ubuntu a week ago after having used a number of different distros since 2011. As a software developer myself, I think there is a mix of two emotions that lead to this; fear of missing out (FOMO) and imposter syndrome. I was trying to learn as much as possible for a while, adding skills to my resume, thinking my peers were doing the same. (They were not). All that time I ended up suffering from some pretty poor UX issues (Audio/Bluetooth/Wifi) that I tried fixing unsuccessfully or ignoring for the longest time, that I forgot what it was like to use a system THAT JUST WORKED out of the box.

> The best part is that the cubicle doesn't have tall walls so I can literally see/hear everything, including other people's monitors.

Open offices are awful. In my experience most people end up wearing headphones all day, and I did too. My ears would get red and irritated after a while. But I'd keep them on because it was like an unspoken social rule; that if you looked busy and had headphones on, people won't interrupt you as much.

Monolith, sure.

Microservices, no.