basicallybones

It is remarkably easy to expose yourself to truly horrifying things on the Internet. Stories, images, and videos of deaths of all kinds, from videos of terrorists cutting off people's heads to people live streaming their suicides to Reddit stories about motorcyclists having limbs ripped off in traffic accidents. News sites, forums, and social feeds are a parade of horrors. You cannot get away from the Internet, even if you want to, because your job constantly pings you on email/chat/whatever.

It feels like the "learned helplessness" experiments where researchers randomly shocked animals, who could not stop or do anything about the shocks.

I wonder if we are all traumatized by what we have seen over the years on Reddit, Twitter, etc.

There is an incredible recent song "Oh No" by Wet Leg that captures some of this. Here are the lyrics (sorry about the formatting):

I went home All alone Checked my phone Oh no Oh my God Life is hard Credit card Oh no You're so woke Diet Coke I feel gross Oh no I went home All alone I checked my phone And now I'm inside it

On my phone All alone In the zone Oh no Hours pass Pizza rat I like that Oh no 3 AM I feel Zen Fucking Zen Oh no Suck the life From my eyes It feels nice I'm scrolling, I'm scrolling, ah

If you're going to the party I heard there's gonna be some arty People talking 'bout themselves Or whatever it is that you always talk about, ah

I went home All alone I checked my phone Oh no I went home All alone I checked my phone And now I'm inside it

If you want to get in very, very good shape at home in a set amount of time, do an exercise program like P90X3.

If you simply want to feel better and remain functional, I recommend cardio (pick your favorite) plus yoga/stretching/full-body core work. Your goal simply is to feel good, which means (1) most days, stretch thoroughly enough to relieve aches and pains, (2) go for runs to alleviate stress and anxiety. Focusing on feeling good also gets you doing low-effort, high-benefit activities like simply standing up regularly and doing a sun salutation or two.

Or you could do 12 sets of biceps a week and eat 30 grams of protein every three hours.

I will also add: I think the oft-repeated advice about "go do big lifts at gym" is bad for most people. Yes, it makes you stronger. However, those exercises are likely to cause injury at some point if done regularly for decades. They also do not really matter irl, unless you fantasize about deadlifting a car off someone in a moment of crisis or something.

You are not trying to become more eloquent. You are trying to communicate more effectively.

1. Be clear. Write down your complicated thoughts, then simplify them until anyone could understand them. (Hopefully you already do this with your code!) 2. Learn from the best sources. Warren Buffett has spoken highly of Dale Carnegie's public speaking course. I would start there.

I would consider paying $150-$200 / month for chat.openai.com access, especially if it continued to improve. It is an astonishing tool for learning and productivity. December 1, 2022 will be a day we all remember.

I have adopted this approach (somewhat out of failure!), and what I have found is this: being significantly above average in a lot of unrelated domains is both far easier than being world-class in a single domain and often can make you even more effective than someone who is a savant in a single domain.

These are very good points. A few responses:

- The monorepo tooling I prefer at startup scale (NX) does have a learning curve, but it has been pretty easy to maintain using automation (good linting, good build/test pipeline, etc.). For me, learning and leveraging the right monorepo tooling is way easier than having to enforce consistency across large numbers of repos with a small team or watch a low-tooling monolith decay into tightly-coupled spaghetti. I am also in a particular situation where the need for eventual scale is obvious, will come very quickly (clients are big), and the thought of having to rush a scale-inexperienced team (management and devs!) through a monolith-to-microservice migration on a tightly coupled codebase while meeting SLAs is so unpleasant that it makes me a bit sick to my stomach to think about it.

- The monorepo framework/tooling matters a lot. For instance, NX is small-scale friendly and largely can be overseen by senior Typescript devs. Bazel, on the other hand, requires a hefty context switch and has a very steep learning curve.

- You are right that releasing all services together does not scale past a certain point. My point is that microservice monorepos let you pivot quickly between all-together (monolithic) releases and individual app releases as appropriate for your scale. With good caching and parallel blue/green deployments, adding new services to an all-at-once build/deploy pipeline just uses a bit more compute for the pipeline without meaningfully impacting the pipeline run times.

- Having to release services serially in a certain order obviously indicates something is seriously wrong under the hood.

- You are very right about monorepo tooling/best practices, but I would extend that to any project that eventually will need to scale. Someone has to take ownership and enforce good practices. Spaghetti code can be harder to prevent in a feature-heavy monolith and certainly is harder to deal with for me if it is in many different repos (i.e., several monoliths).

- You can have more than one monorepo for teams that are very different or have specific needs (i.e., different languages, mobile apps, etc.).

- I wish I were in a situation where my team could commit to avoiding breaking API changes, but it just is not so because of aggressive development timelines. (I am sure this will change in the future as we scale.) All-together versioning/releasing helps deal with (planned, intentional) breaking API changes very efficiently, because (as long as you can tolerate a failed API call once in a while as a blue/green deployment switches traffic) you're basically performing the deployment as if it is a monolith.

Add: 1000% agree about db access. That is very easy to enforce at the architecture/team level.

Microservices vs. monoliths is a false dichotomy in the present day.

If you put microservices in a monorepo with a good build tool (like NX), put the common auth/logging/types/dtos/etc. functions in reusable libs, and version/release all the apps together, you get the best of both worlds.

At a small scale, you can deploy your whole containerized stack on two big HA instances (monolithic infrastructure, so much easier). You can leverage common libraries without versioning hell/cross-repo coordination. If you have mediocre developers on the team and very aggressive development timelines, the monorepo structure helps enforce modular organization. If you are a good developer, your workflow gets very, very fast, and you can manage a lot of complexity.

Add: additionally, if you have ever-changing requirements and some are obviously bolt-on one-offs that aren't going anywhere, you can limit damage to the code quality by splitting those features into a separate microservices (making it much easier to safely deprecate/remove them in the future).

Generics in Go are very helpful for my team. They allow us to create reusable functions in common libraries in our monorepo that are simple to reason about and easy to read.

For instance, we have an internal library that helps us create and perform common operations on concurrency-safe maps. Being able to pass and return arbitrary structs to/from those functions has made our codebase much cleaner and easier to work with.

Please take my response with a grain of salt, as we have not benchmarked or otherwise compared (via escape analysis, etc.) those generic functions against any non-generic equivalents.

Type "cookie" you idiot!

I'm not the original commenter, but see the 2019 update on this Dan Abramov article: https://medium.com/@dan_abramov/smart-and-dumb-components-7c...

I have been using Bazel (4, then 5) as the build tool for a small Go monorepo with ~10 (and growing) Dockerized applications importing a handful of internal packages. The initial setup was a bit of a learning curve, and it is overkill for our current stack, but builds are very fast.

At the same time, I have been using NX for a larger (though not huge) Javascript monorepo. Javascript is my strongest language, so take this with a grain of salt, but at my org's scale I vastly prefer the NX experience over Bazel. I think the reason is that NX feels like an optimized, natural extension of normal Javascript build tooling, while Bazel requires an entirely separate set of knowledge.

They tricked me. Now I will bend over backwards to never buy anything from them again.

Can't speak for the rest of the world, but my team has been using an NX monorepo with a standard types library that can be imported into any application in the monorepo. It is trivial to use the same interface, enum, class, or other type-enforcing mechanism across multiple frontend and backend services. The development experience has been quite nice, and refactoring/changing the data structures is a breeze. If you are in the Typescript world and haven't looked at NX...check it out.

By the way, echoing some discussion above, we migrated from Express to NestJS, and it was an excellent decision.

Several newer blockchains have made significant progress on transaction speed and throughput. Solana probably is the most notable example, but there are others. https://medium.com/solana-labs/how-solanas-proof-of-history-....