codemonkey-zeta

I'm glad to see the first thing you mentioned was the value of purchasing software.

For some reason software developers are particularly averse to paying for software, even when it pays for itself.

My current company spent over $10k + at least a month of developer salary building an OKR app for the company, so probably in total $25k. One look at the SaaS landscape there would have revealed plenty of $5/mo/seat solutions that would take DECADES to break even with the investment we already made. To add insult to injury, the app was vibe-coded and barely works.

In my experience, software that wants to help you is cheap. Software that wants to _trap_ you (Salesforce, Oracle, the Cloud) is expensive, and any software you write yourself falls into the latter category by default (you own it, you maintain it).

Indeed, the article mentions Wikipedia experiencing similar scraping pains, even though they already DO have bulk data available.

The maps haven't changed at all, this is a feature at destructuring sites.

> The mess just moves

That's exactly the point. The author recognizes that people will extract components, and that is exactly why tailwind is attractive.

Plain CSS offers a componentization layer over (mostly) classes, but modern SPA frameworks offer their own componentization layers over functions. It's annoying and error-prone to keep these 2 layers, and lots of devs just abandon CSS for utility class mess. It's just a different choice.

I like the framing of organizational slack as immune system, instead of fat, and I emphatically agree with the author.

> ...“slack”: unbooked time that isn’t already spoken for. It’s always the first casualty, because it’s treated as a nicety... because it looks like waste...

> But that’s not what slack is. Slack is the only reason anything that comes up ever gets acted on. It’s what lets people take that signal that something is wrong, figure out why it’s happening, and then solve it... Without slack, the signal still arrives, everybody’s just too busy to pick up the phone or listen to the backlog of voicemails.

> [The AI playbook] gets this infuriatingly backwards: it treats slack as the thing AI lets you eliminate. If the tools make us faster, why do we still need buffer time?

> Getting rid of it at the time you’re flooding the system with machine-generated code you don’t fully understand removes the mechanism to absorb something we know will happen: it will surprise you.

> You didn’t cut fat. It was never fat. You cut your organization’s immune system.

Nope, splitting green wood is much more difficult than splitting dried logs, so I often cut a tree in the spring, stack the rounds, then split those rounds in the fall.

People overestimate how dry wood needs to be to burn correctly. Just have some ultra-dry kindling (seasoned for 2+ years) and you won't have any problems.

On the contrary, I know some folks who let all their wood dry too far, and it burned way too hot and ruined their stove (and almost burned their house down).

> for reasons that nobody can articulate

This is only true if you ignore the role of America's greatest ally, in which case, the motivations become very obvious.

You assume the stone is released along a circular path, but that isn't quite right. When you release the stone you extend your arm forward, changing the arc of travel.

Nice blog! However, when I hear timeline, I want to see a timeline. This is an article ordered by time, which is much less interesting, and very long.

I find that Lisps encourage this behavior more than other languages. Many (most?) of the lisp functions I read have the exact same structure:

  (fn some-function [args]
    (let [binding (transform args)]
      (an-expression binding)))

I find that this makes skimming lisp code much easier, because I can usually skip reading the bindings and just read the function name and ultimate expression and usually get the gist very quickly.

You might wonder how this is different than the example you provided, and the answer is because you could sneakily intersperse anything you wanted between your imperative bindings (like a conditional return statement), so I actually have to read every line of your code, vs in a lisp `let` I know for a fact there is nothing sneaky going on.

deps.edn is becoming the default choice, yes. I interpreted the parent comment as saying "you will see advice to use leiningen (even though newer solutions exist, simply because it _was_ the default choice when the articles were written)"

Can you describe how rsc allows you to avoid rest endpoints? Are you just putting your rsc server directly on top of your database?