With the current crop of LLMs/agents, I find that refactors still have to be done at a granular level. "I want to make X change. Give me the plan and do not implement it yet. Do the first thing. Do the second thing. Now update the first call site to use the new pattern. You did it wrong and I fixed it in an editor; update the second call site to match the final implementation in $file. Now do the next one. Do the next one. Continue. Continue.", etc.
Because the systems are so complex and capable of emergent behavior that you need a human in the loop to truly interpret behavior and impact. Just because an alert is going off doesn't mean that the alert was written properly, or is measuring the correct thing, or the customer is interpreting its meaning correctly, etc.
Health probes are at the easiest side of software complexity spectrum. It has nothing to do with it and everything with managing reputational damage in shady way.
Cash flow is another facet of paying off your mortgage early, and I think it’s underrated. Eliminating thousands of dollars from your monthly expenses dramatically increases your flexibility. Since most people have “cash / reserve fund” and “retirement investments (do not touch)” as their major financial categories, it optimizes the one you interact with the most. You don’t need to always make the maximum possible to keep a comfortable amount of cash on hand, which gives you more flexibility to take time off between jobs, or tank a layoff, or take that startup job that pays less (but damn if it doesn’t look fun). Personally I recently bought a second apartment adjacent to my first in order to combine them into a 3br. Paying off the first mortgage years ago was the difference between being able to afford the monthly expenses and not.
Obviously you need to consider both net worth and cash flow when making a decision like that, but don’t underrate the difference that improved cash flow makes!
On top of that, the software world has changed dramatically since Bazel was first released. In practice, a git hash and a compile command for a command runner are more than enough for almost everyone.
What has changed in the past ~15 years? Many libraries and plugins have their own compilers nowadays. This increases the difficulty of successfully integrating with Bazel. Even projects that feel like they should be able to properly integrate Bazel (like Kubernetes) have removed it from the project as a nuisance.
Back when it was first designed, even compiling code within the same language could be a struggle; I remember going through many iterations of DLL hell back when I was a C++ programmer. This was the "it works on my machine" era. Bazel was nice because you could just say "Download this version of this thing, and give me a BUILD file path where I can reference it." Sometimes you needed to write some Starlark, but mostly not.
But now, many projects have grown in scale and complexity and they want to have their own automated passes. Just as C++ libraries needed special library wrappers for autotools within Bazel, now you often need to write multiple library compiler/automation wrappers yourself in any context. And then you'll find that Bazel's assumptions don't match the underlying code's. For example, my work's Go codebase compiles just fine with a standard Go compiler, but gazelle pukes because (IIRC) one of our third-party codegen tools outputs files with multiple packages to the same directory. When Etsy moved its Java codebase to Bazel, they needed to do some heavy refactoring because Bazel identified dependency loops and refused to compile the project, even though it worked just fine with javac. You can always push up your monocle and derisively say "you shouldn't have multiple packages per directory! you shouldn't have dependency loops!", but you should also have a compiler that can run your code just like the underlying language without needing to influence it at all.
That's why most engineers just need command runners. All of these languages and libraries are already designed to successfully run in their own contexts. You just need something to kick off the build with repeatable arguments across machines.
I mostly found TLM a disservice to people who reported to TLMs. They didn't have to earn a promotion as both an engineer and a manager at the same time, so many optimized for their own engineering promotion and any managing they did was out of the goodness of their hearts.
As a devil's advocate (I don't work in Google or in a similar role) but if the requirements for engineering promotion are similar for technical managers and engineers, while the first have to manage people then this is just how the system is set up. In this case I think blaming the system more than people is justified, and Google decided to dismantle the role for some reason.
I work for Hinge, the dating app. We use them for our "prompt feedback" feature, where the LLM gives constructive feedback on how to improve your prompts if it judges them as low-effort or clichéd.
It's optional and doesn't generate responses for you, instead just nudging you in better directions. So it's certainly not generating a bunch of indistinguishable profiles. Quite the opposite, it gives people a second chance to expand on their own views or experiences.
I asked an ex-Bloomberg coder this question once after he told me he used floating points to represent currency all the time, and his response was along the lines of “unless you have blindingly-obvious problems like doing operations on near-zero numbers against very large numbers, these calculations are off by small amounts on their least-significant digits. Why would you waste the time or the electricity dealing with a discrepancy that’s not even worth the money to fix?”
I am writing a newsletter, https://www.clientserver.dev. It started with the writing prompt “what if someone tried to make Money Stuff for software engineering?” My time is constrained since I have a kid, and I’m still iterating on the format a bit. But I recently crossed 250 subscribers and have made the Hacker News front page twice in the 6 months I have been running the newsletter, so I feel like I’m on the right track.
In the past few months, I've learned that (a) writing a bulleted outline is a cheat code for producing decent work quickly, (b) every newsletter is a reminder that people could unsubscribe, so skip publishing issues that you're not proud of, (c) people really like stories, and (d) it's okay to have a mix of formats.
If one gets any traction (like 10 upvotes or more), I wait a month or so. I know the site values pacing out content from the same source. If something was on the front page in the past week, I don’t post it. This eliminates probably 80-90% of my posts; “news + reaction as a staff software engineer” is my primary format. Beyond that, it’s mostly feel.
And what is your strategy regarding commenting?
I don't spam (like commenting "good post") but my logical arguments get downvoted sometimes, don't understand the culture of HN properly.
I have a light touch. I think it comes from the foundation of having confidence in what I write. My three goals are to be entertaining, to be educational, and to stand by everything that I write. I don't have any emotional stake in being right or wrong; I'll make a correction if I'm wrong or have a typo, but I rarely have to do that. I don't really care if people disagree with me, because again, I stand by everything that I write. If I notice a trend in negative feedback I'll respond to it once and then check the thread again 2 or 3 days later to see how it shook out.
"Don't argue about the definitions of words online" is my "Never get involved in a land war in Asia." If people know what you mean but ignore it in favor of picking a fight, they're arguing for sport and I don't want to get involved with it.
