Add to that I have worked on many projects that take more than 20 minutes to fully build and run tests... unfortunately. And I would consider that part of the job of implementing a feature, and to reduce cycles I have to take.

After the "green" signal I will manually review or send off some secondary reviews in other models. Is it wasteful? Probably. But its pretty damn fun (as long as I ignore the elephant in the room.)

> I've gone back to managing the context window in Emacs because I can't be bothered to learn how to deal with another model family that will be thrown out in six months.

Can you expand more on what you mean by that? I'm a bit of a noob on llm enabled dev work. Do you mean that you will kick off new sessions and provide a context that you manage yourself instead of relying on a longer running session to keep relevant information?

> Unironically learning vim or Emacs and the standard Unix code tools is still the best thing you can do to level up your llm usage.

I appreciate your insight but I'm failing to understand how exactly knowing these tools increases performance of llms. Is it because you can more precisely direct them via prompts?

There isn't a simple way but having some tooling to go from alert -> relevant dashboards -> remediation steps can help cut down on the process... it takes a lot of time investment to make these things work in a way that allows you to save time and not spend more time solving issues. FWIW I think developers need to be deeply involved in this process and basically own it. Static thresholds usually would just be a warning to look at later, you want more service level indicators. For example if you have a streaming system you probably want to know if one of your consumers are stuck or behind by a certain amount, and also if there is any measurable data loss. If you have automated pushes, you would probably want alerting for a push that is x amount of time stale. For rpc type systems you would want some recurrent health checks that might warn on cpu/etc but put higher severity alerting on whether or not responses are correct and as expected or not happening at all.

As a solo dev it might be easier just to do the troubleshooting process every time, but as a team grows it becomes a huge time sink and troubleshooting production issues is stressful, so the goal is to make it as easy as possible. Especially if downtime == $$.

I don't have good recommendations for tooling because I have used mostly internal tools but generally this is my experience.

Depends where you are and what level. I think you owe it to junior engineers to help guide them. It may be that someone 1 year in the workforce is a highly productive engineer and doesn't need growth, but I can't say that is the norm. They may be mostly productive but some experience must be learned, so I would say you should push them to get out of their comfort zone.

Some companies do up or out until a certain level, usually around senior engineer. I don't really agree with that completely as I think a codified system like that lacks humanity, but it makes sense more or less.

100 percent agree on the 6 month targets... feels like groundhog day, adds tons of stress, does not benefit employees.

For example, is a car company making the world a better place? I guess it depends on your world view... but it is pretty easy to answer yes or no.

But maybe you are asking to gauge how many people are working in a place where they know(think?) they are making the world worse?

The thing is, it always just works. I don't need to think about it. I write code in 5+ languages fairly regularly, with some frameworks that have really weird... "support" for dev tools.

But maybe I am just a bad developer with bad excuses. If anyone has been in my shoes and seen the light, would love to hear how you manage jumping in to multiple different languages and keeping a consistent debugging experience (or, at least, more consistent than print).

It is my understanding that a lot of current applications take a ton of training time / computing power and it's not so trivial to do in the moment. I guess this is less of a theoretical problem and more of a practical problem though.