Hacker News

The Tinker Pledge

Hacker News - Sun, 06/07/2026 - 4:31pm

Article URL: https://tinkerpledge.org

Comments URL: https://news.ycombinator.com/item?id=48438247

Points: 1

# Comments: 1

Categories: Hacker News

Show HN: Hardbar – compile-time defined i3bar

Hacker News - Sun, 06/07/2026 - 4:27pm

A fast, compile-time-configured status bar for i3 and sway, outputting the i3bar JSON protocol.

I was worried about the performance of i3blocks due to the constant fork-and-execs, and I thought zig would make it easy to have a bar defined at compile-time.

I started on this idea a couple years ago but ended up somewhat stymied by lack of time to chase down some corners of zig syntax interaction. Recently I started playing with Claude Code, and I was curious as to how well it would deal with zig so picked it back up. It didn't take long to have something reasonably functional, and I thought others might like it as well.

Feedback welcome, Enjoy!

Comments URL: https://news.ycombinator.com/item?id=48438203

Points: 1

# Comments: 0

Categories: Hacker News

Ask HN: Job market for SDMs/Engineering Managers. Any reliable data?

Hacker News - Sun, 06/07/2026 - 4:24pm

I’m trying to find reliable data on the job market for Software Development Managers/Engineering Managers.

It’s easy to find broad tech hiring reports, but hard to break the data down by role, company type, location, or tech stack.

Anecdotally, it looks worse than the market for SDEs. Many companies are flattening management structures. Managers are taking on more teams and more direct reports. Coinbase is the extreme example.

Does anyone know of good datasets, job-board analyses, or reports that track this?

I wonder if I should go back to IC or maybe I should become Software Agent Manager ;)

Comments URL: https://news.ycombinator.com/item?id=48438187

Points: 3

# Comments: 0

Categories: Hacker News

Show HN: Nightwatch, The open-source, read-only AI SRE

Hacker News - Sun, 06/07/2026 - 4:24pm

nightwatch is a local-first, read-only layer on top of your monitoring. it groups alert storm into incidents, flags noisy checks and has an agent that can investigate for you live systems. You can e.g. jump from the incident into the agent directly.

the reason for this weekend project is that we had a kubernetes upgrade that went wrong, and at some point a rollback wasn't possible anymore, so it had to be fixed live during the night while several problems came together. We run a lot of different systems, on-prem and several Kubernetes clusters, and in a situation like that you spend most of the time just figuring out what is actually broken and where.

So i thought that it would be pretty cool to have eyes in the dark in each system that can talk to your "brain".

so the idea is to put a baby owl into each environment. Each owl runs where the systems live, keeps that environment's credentials local, and only dials outbound to a central brain, so there is no inbound hole into prod. It exposes a set of read-only skills, and the agent uses them to gather evidence and form a root-cause hypothesis, so the on-call engineer starts with a head start instead of from zero.

read-only for now, i don't trust it near prod yet and honestly neither should you.

llocal-first for easy self-hosting and to keep credentials on your side. the clustering and recommendations run fully offline with no llm at all. the agent needs a tool-calling llm, you can point it at a remote one, or self-host one (ollama etc.) if you want to stay fully offline.

for non selfhosters: before every remote llm call, nightwatch strips real secrets (unrestorable) and swaps identifiers like ips, hostnames and paths for reversible placeholders, so the model only sees masked data while real values are restored only in the proposed commands and tool calls

Would love if you try it in your Systems

Comments URL: https://news.ycombinator.com/item?id=48438180

Points: 2

# Comments: 0

Categories: Hacker News

Ask HN: Debugging failure in large interconnected back end systems

Hacker News - Sun, 06/07/2026 - 3:53pm

I’m trying to understand how teams actually debug production issues in systems made up of multiple services and external integrations (e.g. Stripe, Twilio, internal microservices, queues, webhooks, etc.).

In practice, when something breaks, it seems like the workflow is usually:

an alert fires (Datadog/Sentry/CloudWatch/etc.)

or a customer complains

engineers then start checking logs, traces, dashboards across multiple systems

and eventually manually reconstruct what happened across services

What I’m curious about:

How do you actually trace a single failed request or transaction across multiple services today?

What tools do you rely on most in practice (not in theory)?

Where does it usually break down — logs, tracing, instrumentation, or just missing context?

How long does it typically take to go from “something is wrong” → “we know exactly why it broke”?

What part of this is still mostly manual stitching together of information?

Trying to understand what the real pain points are in practice, especially in systems with lots of external integrations and async flows.

Comments URL: https://news.ycombinator.com/item?id=48437942

Points: 1

# Comments: 0

Categories: Hacker News

Pages