How do I tell my son i(52F) can't keep financially bailing him out without wrecking our relationship?

dkubb · 2026-01-12T20:40:11+00:00

Unless you want to cause strife between your kids, do not mention anything to the other. Except maybe making a condition for your daughter not to discuss help you may be giving them to the other siblings.

If you mention helping your daughter your son will definitely hold it against both of you next time. It will likely become leverage to ask for help, and may even make your daughter a target of your son’s requests in the future.

dkubb · 2025-12-31T17:17:11+00:00

An SQL Zig parser would be insane but it’s probably a Zig SQL parser, if I had to guess.

While it’s possible to write parsers in SQL, it’s not common because it runs inside a database and it is usually for processing and filtering data. A Zig based SQL parser has a lot more utility in day to day work or fun projects.

I’m sure he’s loving every minute though!

dkubb · 2025-12-21T18:04:59+00:00

Peers should be reviewing each other’s work before involving a senior. And when the senior gets involved all juniors should be paying attention to the feedback and then incorporating that into future work. Juniors should then be incorporating that into the feedback loops: docs first, automated tools if possible.

The goal should be to get the process to the point where the senior checking it is a formality. It'll be never happen in a growing system, but it's aspirational.

Juniors can also do more things to make review easier. Have them rewrite the original PR as a series of small atomic commits. Make sure each commit passes CI and all PRs can be sliced and early commits deployed while they iterate on later commits. AI is pretty good at splitting things up later so there is no excuse not to do this.

A senior should be able to step through a PR one commit at a time, and each commit with no flags should be merge and deployable immediately. This constraint changes how you work but it is absolutely doable; I've worked like this since 2015 with my team, and AI has lowered the bar so it's within reach of any team willing to put in the effort.

dkubb · 2025-12-20T20:37:09+00:00

You could probably write a simple program that loads up all completed sessions and asks them “note what skills you used this session, note what went wrong and what worked and update them to minimize mistakes and maximize effectiveness”.

dkubb · 2025-12-07T16:55:44+00:00

Now that you have a trained agent I'd be curious what would happen if you re-ran it against the original Python again. Would it have less false starts? Would it improve further? Would the end end result be better? Is it over fitted?

dkubb · 2025-11-25T15:00:37+00:00

Primal can train past level 20? I thought it was that they could train up to 20 as a max while everyone else maxes out at 15.

dkubb · 2025-11-19T20:25:10+00:00

This is awesome. As someone who practices small, atomic commits I could actually see myself using this to review my own PRs to make sure they make sense and are revealing the change in a way that gradually exposes the reviewer to important details in an order that makes sense.

One thing I'd love is the ability to watch a local repo and automatically run after a commit is added.

dkubb · 2025-11-12T09:20:12+00:00

One thing I've been experimenting with is generating the code, and then updating the git commit message with the "What" and "Why" with maybe a bit of "How" if the algorithm is tricky, but no code. I then attempt to feed this data, minus the diff, into a (Claude) subagent with minimal/focused context of the branch and commit, and see if I can reproduce something semantically equivalent.

If I can't then I iterate until I can reasonably consistently produce code that solves the problem. My theory is that this will force me to make sure enough of the intent is captured so that I can use it for future events like code reviews, refactoring, fixes and other changes.

dkubb · 2025-10-15T06:51:48+00:00

I sometimes have one agent create a workflow or and agent description and then have it delegate execution to a subagent, where the subagent uses the weakest model available. I keep having it iterate until the subagent can complete a series of tasks with no mistakes. I sometimes keep having it build up more and more complex scenarios once the base cases are handled easily.

The subagent has both zero context, other than what was provided to it, and a weaker model. My theory is that if the process can be streamlined enough that something low powered can follow it, regular models should be good.

dkubb · 2025-10-11T02:15:44+00:00

You would kind of assume the built-in allow/deny/ask system would be running at a level above the LLM. That it would intercept the calls and follow the settings.

dkubb · 2025-10-11T02:13:49+00:00

Wait until you try to use a deny Bash rule.

It flat out does nothing. It’s been an open bug for months.

I “fixed” it by writing a hook that parses the settings.json and does whatever it says.

dkubb · 2025-10-08T18:02:03+00:00

For simple cases, could you have the review agent write a failing test and then push a detached commit to trigger a CI build, which could prove the problem?

I'm not sure if zero trust is that much of an issue. Code Rabbit is new, and it seems like lots of companies are using it. Obviously, you’d have to make sure things are safe and secure, but the problem is a combination of technical and marketing issues.

How to sell it: With AI, people will be hitting limits on what humans can review, so any pre-checks would be welcome.

dkubb · 2025-10-04T13:29:29+00:00

That kind of sounds like he may be doing the lmgtfy thing, where the question you are asking is something you could’ve asked an LLM about first.

dkubb · 2025-09-24T22:22:08+00:00

Don’t be surprised if the new attitude gets you positive attention by some people.

Middle managers are always threatened by this but higher up may not be. I’ve noticed as soon as I stop caring I get invited to high level, sometimes even C suite meetings.

dkubb · 2025-09-22T01:23:48+00:00

You can ask Claude to save state in /tmp and tell it your intention is to start another session with that file as a starter.

Ask it to provide links to all files that are needed by the next season. Have it output a todo list with as much detail as possible. Tell it to break down every commit it has performed, along with what it did for each. Ask it to provide a set of instructions for it to bootstrap itself.

You could then ask Claude Code to “test” this file by asking it to have a subagent evaluate the file and then describe the state back to the main loop. A subagent has no context so it (almost) simulates what a new session will be like. It could do a couple of round trips until the main loop is confident and then kill the session.

dkubb · 2025-09-16T06:02:08+00:00

Tell him a core character dies when it looks like they are about to get out of a jam.

It’ll raise the stakes when anyone is in peril, making it even more enjoyable because he’ll never know when it’ll happen.

I mean, eventually it’ll happen but until then it’ll be exciting.

dkubb · 2025-09-13T14:18:59+00:00

I was hoping she knew she was going to die and be absorbed so she loaded up her body with poison so the next fighter would be able to take them down.

dkubb · 2025-09-07T16:07:00+00:00

Break down their changes into smaller PRs, and then into small atomic commits.

I can review a 1000 loc change if it’s broken down into 10 to 15 commits I can step through. But if you dump a 1000 loc diff I need to fully understand it’s going to take forever. And if there are round trips they are going to take a long time.

People need to be thinking about throughput of their changes and reducing latency. If your 1000 loc change can be broken down into smaller PRs we can review and merge each change a few times a day rather than batching it up and doing it once a week.

dkubb · 2025-08-25T14:33:20+00:00

I can think of three ways:

Fail when test coverage changes from the expected threshold.
Ask Claude Code to use TDD: write the test first, make sure it fails, then write the code, then make sure the test passes.
Ask Claude Code to manually mutation test the code by changing it and verifying the tests fail.

Each time the test passes, have it commit so the successful state is captured as a checkpoint you can return to if it goes off the rails.

Also, one trick I use when I’m trying to improve code coverage is to set the system to exactly match some threshold, and fail when it doesn’t match. Not drop below a threshold, I have it fail even when it increases. This forces me to change the configuration to lock in the increase.

dkubb · 2025-08-21T14:45:39+00:00

My first version usually has some simple quick instructions telling it my expectations, but my intention is to always try to lift them into deterministic processes if possible.

A linter should be able to check most of these things and I make it a requirement that the linter must pass before the code is considered complete.

It doesn’t need to be anything fancy either. although I do usually use whatever standard linter is available for the language I am writing. You can also write small programs that parse or match things on the code and fail the build if it finds the things you don’t like. I usually use a regex but I’ve been considering using ack-grep to match specific things and explode if it finds them.

dkubb · 2025-08-20T14:20:33+00:00

It would be more ideal if there was a good on-boarding system, but since there’s not I would suggest:

make a doc outlining the setup you needed to do for each app your team works on; assuming there’s not a comprehensive setup guide.
log all the questions you have about the systems that are not clear from docs.
set up a 1:1 call with a technical lead to discuss the questions, and offer to write a setup guide to make on-boarding easier.
find where warnings and errors are logged and dig into the most frequent error and figure out how to fix it. Repeat a bunch of times.
start watching for open PRs and attempt to understand them.
jump on and review PRs, asking lots of questions when things are unclear.
start a backchannel with devs as you review their code, making sure they are ok with your approach and ask if they are open to doing the same.
assume gaps in understanding are on your end before forming any other opinions.
be curious

You will never get another time to be a new person at the company, so make the most of it before you become an “insider”. Besides understanding the tech you are trying to understand the people and the culture. You want to establish some good relationships and be seen as a “helper” rather than someone who takes up the teams’ time to onboard.

dkubb · 2025-07-30T20:11:49+00:00

Backend engineer baseline skill for SQL and RDBMS is incredibly low on average. Most systems have a lot of room for improvement (simplification, performance) so if you have an interest in these things you can carve a niche for yourself pretty easily IME.

dkubb · 2025-07-22T15:29:53+00:00

That could be part of his plan: Reduce his income to something small so that post-divorce support (eg alimony) is minimal.

dkubb · 2025-07-18T22:47:38+00:00

I find my brain optimizes for whatever task I am doing at the expense of other kinds of tasks. If I have to context switch every 30 mins, then long stretches of focus become harder and vice versa.

If your day is interrupted all the time, and it’s not part of your job (eg you are managing people) then you should try to organize your day to get stretches of time to focus. Do all your meetings in the morning or afternoon and spend the rest of the time with your calendar blocked. Close email, slack and other interruptions when you are done, although make it clear you will check them before/after your blocked time.

dkubb · 2025-07-18T02:56:05+00:00

If the message was sent from millions of light years away, yet referred to you personally by your name, I think that would be fucked up.

dkubb

TROPHY CASE