I miss thinking hard

For me, thinking about an extremely technical TCS problem, for example, is my version of actively, tirelessly thinking hard. I'm logging a ton of observations, trying new ideas and hypotheses, using a mix of computer simulation and math to try and arrive at a concrete framing and answer.

On the other end of the specturm, I have philosophy. It's definitely a different type of hard. Most of my "Aha!" moments come from when I realize I've been strawmanning some argument, and not actually understanding what the person is saying. Why is the person saying this, relative to what, why is this a new observation, etc. Things are so amorphus and you can tweak the problem parameters in so many ways, and it's really tempting to either be too fluid and pretend you understand the thinker (because it's a subset of some conception you already have), or be too rigid and dissolve the thinker as a category error / meaningless. I've never felt the same feeling as I did when doing TCS research, but the feeling was definitely hard thinking nonetheless.

In terms of extremely nitty-gritty technical things, like linker bullshit and linux kernel programming, I'm much more familiar with, and these things are more about reading documentation (because the tool won't behave like you want it to) and iteration / testing (because... the tool won't behave like you want it to, so you need to make sure it behaves like you want it to!). This is also a type of thinking - I would call it hard as in the physiological response I have is similar to that of research in the very bad moments, but in terms of my lofty ideals, I don't want to call this hard.... it's very "accidental" complexity, but it's what I get paid to do :/

At work, you have a huge idea space to consider, both problem and solution framings, mixing in "bullshit" constraints like business ones. You also throw in the real-time aspect of it, so I can't just either armchair on a problem for a month (unlike Philosophy) or deep dive on a problem for a month (unlike research). I'm technically doing the third type of programming right now, but we'll see how long that lasts and I get put on a new project.

I'm not even sure if there's a clean demarcation between any of these. These are certainly better than brainrotting youtube though.

That said, the framing feels a bit too poetic for engineering. Software isn't only craft, it's also operations, risk, time, budget, compliance, incident response, and maintenance by people who weren't in the room for the "lump of clay" moment. Those constraints don't make the work less human; they just mean "authentic creation" isn't the goal by itself.

For me the takeaway is: pursue excellence, but treat learning as a means to reliability and outcomes. Tools (including LLMs) are fine with guardrails, clear constraints up front and rigorous review/testing after, so we ship systems we can reason about, operate, and evolve (not just artefacts that feel handcrafted).

They’re destroying the only thing I like about my job - figuring problems out. I have a fundamental impedance mismatch with my company’s desires, because if someone hands me a weird problem, I will happily spend all day or longer on that problem. Think, hypothesize, test, iterate. When I’m done, I write it up in great detail so others can learn. Generally, this is well-received by the engineer who handed the problem to me, but I suspect it’s mostly because I solved their problem, not because they enjoyed reading the accompanying document.

There's no need to create another serialization format or a JavaScript framework. You now have more time to direct your focus onto those problems that haven't yet been solved, or at least haven't been solved well.

A question that might be hard to digest: was that "thinker" really a thinker, or a well-disguised re-inventor?