bojo

I love this anecdote. It highlights what our industry continues to forget: The end user doesn't care.

Don't get me wrong, tech is why I am here. But if it works, Alice and Bob don't care one bit about how the product exists.

While neat, I don't get consistent scores if I retry it a few times. If it leads with a series of greens first, my score is more green oriented, and vice versa.

This is what I have been doing. I don't think I've made any amazing breakthroughs, but at the same time I can't help but feel like I've come across some white paper-worthy realizations. Being able to correlate across a lot of domains I feel like I intuitively understand but have no depth of knowledge has been a fun exercise in LLM experimentation.

That's a solid point.

I knew my flake setup could be better but never bothered. Then one day earlier this year I threw Claude at it. Not only did it improve everything, it fixed a small bug that had been bothering me.

My confidence in doing this came from exactly what you said: If it blows everything up I can just rollback.

Perhaps? I just used it to analyze one of my 96k Zig codebases using Claude Code and here is (part of) what came back. (I snipped out the deeper analysis above as it exposes my private project - but it was all correct).

  Head-to-Head

  ┌──────────────┬─────────┬─────────────┬────────────┐
  │    Metric    │  Opty   │ Traditional │   Ratio    │
  ├──────────────┼─────────┼─────────────┼────────────┤
  │ Input tokens │ ~13,500 │ ~39,408     │ 2.9x fewer │
  ├──────────────┼─────────┼─────────────┼────────────┤
  │ Tool calls   │ 21      │ 61          │ 2.9x fewer │
  ├──────────────┼─────────┼─────────────┼────────────┤
  │ Round trips  │ 5       │ 9           │ 1.8x fewer │
  └──────────────┴─────────┴─────────────┴────────────┘

I had it run a separate analysis using traditional vs. opty and count the actual tool calls and input token counts. My prompt was basically, "do a full analysis of this entire codebase."

I appreciate the feedback. I have been talking to a lot of people about the very same point you make and had a lot of good brainstorming sessions.

I introduced functionality to do it once per week, or specific days, and not just every day to partially alleviate the process if it gets tedious.

More importantly, I see two things:

1. If people have a constant score over time, that should lead to a discussion. I'm not sure what, but it aligns with the goal - get them talking to each other and asking if everything is truly ok

2. If a manager doesn't invest themselves in the process, then yes, it just turns into a "keep the lines aligned" game. I have no fix for this, but those people probably weren't the target of this product anyways

I keep going back and forth on it. In certain lights it genuinely seems useful. In others, hard to say.

It was fun to build. I'll keep tinkering with it for now and see where it ends up later this year.

Humetrical ( https://humetrical.com ) -- A wellness platform that puts people's mental health first by showing work metrics that matter. Because burnout blindness leads to exit interviews.

It wasn't until we had a leadership retreat at my day job with a fantastic speaker (Woodrie Burich) that the idea for my platform spawned. She talked about how the $50B wellness industry is doing it wrong. Your company is giving you useless yoga stipends, when truth is they should be paying attention to your overall well being. One idea she presented that resonated with me was using a traffic light-like system to gauge where your employees are mentally at.

I took that to heart and verbally applied it to my team. Then I realized that a platform would give better visuals of the data and be easier to incorporate into everyone's day to day. A couple months later I finally released it.

Sorry to be that guy. I love nix, I want to read more about how people use nix.

The font presented under NixOS + Firefox is near unreadable on this website.

What kind of costs are you thinking?

In case anyone is curious, here was my epiphany project from 2 weeks ago: https://github.com/boj/the-project

I then realized I could feed it everything it ever needed to know. Just create a docs/* folder and tell it to read that every session.

Through discovery I learned about CLAUDE.md, and adding skills.

Now I have an /analyst, /engineer, and /devops that I talk to all day with their own logic and limitations, as well as the more general project CLAUDE.md, and dozens of docs/* files we collaborate on.

I'm at the point I'm running happy.engineering on my phone and don't even need to sit in front of the computer anymore.

I've been an EM for the last 10 of my 25 year Software Engineering career. Coding is, frankly, boring to me anymore, even though I enjoyed doing it most of my career. I had this project I wanted to exist in world but couldn't be bothered to get started.

Decided to figure out what this "vibe coding" nonsense is, and now there's a certain level of joy to all of this again. Being able to clearly define everything using markdown contexts before any code is even written has been a great way to brain dump those 25 years of experience and actually watch something sane get produced.

Here are the stats Claude Code gave me:

  Overview                                                                                       
  ┌───────────────┬────────────────────────────┐                                                 
  │    Metric     │           Value            │                                                 
  ├───────────────┼────────────────────────────┤                                                 
  │ Total Commits │ 365                        │                                                 
  ├───────────────┼────────────────────────────┤                                                 
  │ Project Age   │ 7 days (Jan 20 - 27, 2026) │                                                 
  ├───────────────┼────────────────────────────┤                                                 
  │ Open Issues   │ 5                          │                                                 
  ├───────────────┼────────────────────────────┤                                                 
  │ Contributors  │ 1                          │                                                 
  └───────────────┴────────────────────────────┘                                                 
  Lines of Code by Language                                                                      
  ┌───────────────────────────┬───────┬────────┬───────────┐                                     
  │         Language          │ Files │ Lines  │ % of Code │                                     
  ├───────────────────────────┼───────┼────────┼───────────┤                                     
  │ Rust (Backend)            │    94 │ 31,317 │     51.8% │                                     
  ├───────────────────────────┼───────┼────────┼───────────┤                                     
  │ TypeScript/TSX (Frontend) │   189 │ 29,167 │     48.2% │                                     
  ├───────────────────────────┼───────┼────────┼───────────┤                                     
  │ SQL (Migrations)          │    34 │  1,334 │         — │                                     
  ├───────────────────────────┼───────┼────────┼───────────┤                                     
  │ CSS                       │     — │  1,868 │         — │                                     
  ├───────────────────────────┼───────┼────────┼───────────┤                                     
  │ Markdown (Docs)           │    37 │  9,485 │         — │                                     
  ├───────────────────────────┼───────┼────────┼───────────┤                                     
  │ Total Source              │   317 │ 60,484 │      100% │                                     
  └───────────────────────────┴───────┴────────┴───────────┘

I feel like a grandpa after reading that comment now.

My team still has 8 year old Haskell systems in production. We pivoted away from the language a few years ago, which I discuss here a bit: https://news.ycombinator.com/item?id=37746386

I personally love ML languages and would be happy to keep developing in them, but the ecosystem support can be a bit of a hassle if you aren't willing to invest in writing and maintaining libraries yourself.

I have a similar sentiment. While attending university and learning Maya on SGIs, I recall finding Blender in 1997 and chatting with Ton a little in their IRC channel. Was never able to make a career out of it, but I sincerely miss how kind and helpful everyone was.

This was my thought as well. Back to dumb devices and call it a day.

I recall that one of the primary reasons they built Go was because of the half-day compile times Google's C++ code was reaching.

I don't work here but have some insight. It's difficult for a lot of companies to vet the proper labor and tax laws required per state, and even city, to hire an individual. Some states even require that their rules be blanket applied to your entire corporation, which may not always be feasible.

I assume most HN job posts are from small startups. Even if they are established companies with a sizable head count, it seems weird seeing the same exact job post month after month for a year or two straight.

> you can't let teams who have not hired for 2 years come up with their own process

Perhaps? We're a 9 person backend department inside a 250 person ISP. Not the typical type of team we talk about here on HN. I doubt small startups need a pipeline either, they just hire on demand.

I'm pretty sure Stripe was a heavy user of this for a while. They used it due to their write-heavy system, if I recall.

I fondly remember writing a Go driver for it. Was a good experience: https://github.com/riaken/riaken-core

I asked that same question here a while back.

One of the answers was (paraphrased), "because we're constantly recruiting for that title, but maybe not the same team." I'm not sure if that was a good or bad sign. Growth? Or constant turnover? Really makes you wonder.

I manage a highly stable tier 2 software team embedded in enterprise, and only recruit maybe once every ~2 years, if that. Hard to relate to what is going on these days.

> Striking during election week is kind of a crappy move to pull.

That sounds like an anti-union stance to me.

There's no better time to strike than when your opponent can't afford to look bad.

This is pretty cool. I manually put my budget for a month into a sankey generator just to see last year. Nice to see someone run that idea a little further.

Was curious if a comment about fish would be here.

With fish's own autocomplete I get most of what I need. Add fzf to search the history (ctrl-r), and it's highly comparable to the post topic.

This is a fairly common idiom, "X has its warts." Or do you mean something else?

I think the point is that California, a sizable and notable state, implemented a law that affects everyone regardless of federal law.

Yeesh, sounds like you dodged a huge bullet. What an insanely narrow minded individual.

I want to see good engineering practices, I might be curious about your language decision, but I'd never tear you apart for your choice.

I wholeheartedly agree with where you were aiming your goals. Other thoughts I've had:

- What if access is time critical but your backup people are distributed across timezones? Or they aren't available for some reason? Could be hours to days before you could recover your account

- Adding/removing people as they enter/exit your life could make it a challenge to maintain (PGP + trust vibes)

I had the same idea about a decade ago but never bothered to try to implement it. I felt like it would have suffered from the same problem all other technologies have in security: overly complex user interactions. The concept makes sense, but getting N other people to commit is overhead the average user probably doesn't want to deal with.

One must be physically present and eligible to work in the US.

Remote is fine. I think that's a consequence of how HR posts it.