jeremydeanlakey

To make this more concrete:

If your service layer method requires data to be saved and the results to be sorted, you want to call a data layer method that saves it and a library method that sorts it. You do not want any of that saving or sorting functionality in your service method.

Combining different layers and different tasks so that your module is "deep" rather than "shallow" will make your code much higher cognitive load and create a lot of bugs.

The central idea around cognitive load is very good, central to writing good code.

But it's deeply mistaken to oppose smaller (or more correctly: simpler) classes/functions and layered architecture.

Layered architecture and simple (mostly small) classes and methods are critical to light cognitive load.

e.g. You should not be handling database functionality in your service classes, nor should you be doing business logic in your controllers. These different kinds of logic are very different, require different kinds of knowledge. Combining them _increases_ cognitive load, not decreases.

It's not mainly about swapping out dependencies (although this is an important benefit), it's about doing one thing at a time.

> The bottom line is, a non compete is not something that springs on you.

It's pretty standard now for employers to spring on you a previously-unmentioned non-compete clause at the time that you're onboarding. I've learned to ask for it before accepting an offer but I don't think most employees know to do that.

I'm a capitalist and I think non-competes have a very valid purpose in a limited set of circumstances. But the ubiquitous use right now is to make it harder for employees to leave.

The desire for social connection at work might be dependent on phase-of-life.

My first job out of college had lots of socializing. In fact, that's where I met my wife.

Now I have kids. I don't really want to socialize with coworkers.

Socializing with coworkers was low before COVID. Now it's even slightly lower and I'm okay with that.

Edit: Also the impact of social connection on productivity might depend a lot on role and personalities involved.

"when a company has a monopoly on a network it... basically becomes a government."

A monopoly functions like a government.

Or inverted: a government functions like a monopoly.

I find both angles interesting.

I like the refactor bot idea.

I'd be a little nervous to lean on Copilot to refactor, but I'd love a bot that just implements the changes that IntelliJ can already recommend to me.

A bot that did other logically straightforward refactors (like extracting mapper methods from big functions) would also be nice.

> $530 million bet

> long puts against 800,100 shares

I find the title misleading. Unless I misunderstand, Michael Burry has not actually put $530M of his money at risk. He's made a much smaller, leveraged bet. $530M is just the notional value.

Ever since I first started working as a developer, I've wanted to preach the idea that code UX is important.

Some issues I found: 1) It took me years to clearly specify what clean code is. 2) I still haven't learned to effectively articulate its importance. 3) Except maybe onboarding time, I don't know how to measure its importance. 4) Cleaning up code is not rewarded. 5) Writing dirty code is often rewarded with promotions.

A thesaurus is one of my favorite dev tools.

> tech will change everything, but once the dust has settled the questions that matter will mostly be retail questions, not tech questions

I'm not disagreeing but how will we know the dust has settled?

I might have thought the dust had settled with music when you could download mp3s. But now streaming services are the thing.

I created this after trying to use Finicity's API for my personal project. This handles authorization, endpoints and parameters, paging, mapping responses to typed objects.

Note that Plaid has a similar but official Python API library. But so far as I know, it only handles the authorization and endpoints, not the paging and mapping responses to objects.

I'm a little confused why companies whose product is an API don't create robust client libraries as they can do so better and more cheaply than their customers (and only once). If anyone can shed light on why they don't, I would be interested to know.

This is a really great resource! I'm planning on using it in the coding lessons I give my kid. Thanks for the link!

When I was a student, buying lattes would have significantly hurt my freedom. My stress level would be higher and I may have struggled to graduate before running out of money.

After building a career, worrying about lattes was a waste of effort. But buying a nice car would have limited my freedom. For example, I would not have bought as much investment real estate and I would probably be >$500K poorer.

But worrying about buying new cars probably won't make sense for me soon.

Avoiding lattes and new cars was, in fact, very important for my finances (in the past, but not now). The article acknowledges the importance of individual circumstances:

> What should determine personal spending is the totality of the buyer’s financial circumstances.

But the headline risks misleading people.