dkubb

The emdash and ellipsis used to be my bread and butter.

I just hope the LLMs don’t come for parenthesis for aside comments.

You could probably combat this somewhat with a skill that references to examples of the code you don't want and the code you do. And then each time you tell it to correct the code you ask it to put that example into the references.

You then tell your agent to always run that skill prior to moving on. If the examples are pattern matchable you can even have the agent write custom lints if your linter supports extension or even write a poor man’s linter using ast-grep.

I usually have a second session running that is mainly there to audit the code and help me add and adjust skills while I keep the main session on the task of working on the feature. I've found this far easier to stay engaged than context switching between unrelated tasks.

I can totally understand where you are coming from with this comment. It does feel a bit frustrating that people are rediscovering things that were written in books 30/40/50 years ago.

However, I think this is awesome for the industry. People are rediscovering basic things, but if they didn't know about the existing literature this is a perfect opportunity to refer them to it. And if they were aware, but maybe not practicing it, this is a great time for the ideas to be reinforced.

A lot of people, myself included, never really understand which practices are important or not until we were forced to work on a system that was most definitely not written with any good practices in mind.

My current view of agentic coding is that it's forcing an entire generation of devs to learn software project management or drowning under the mountain of debt an LLM can produce. Previously it took much longer to feel the weight of bad decisions in a project but an LLM allows you to speed-run this process in a few weeks or months.

I think that might be the key here.

All those small micro decisions, discussions, and dead ends can be recorded and captured by the AI. If you do something that doesn’t make sense given past choices, it can ask you.

Gradually, over time, it can gather more and more data that only lives in your brain at the time you’re building. It’s only partially captured by git commits but mostly lost to time.

Now, when you change code, the system can say, “Jim wrote that 5 years ago for this reason. Is the reason not valid anymore?”. You might get this on a good code review, but probably not. And definitely not if Jim left 2 years ago.

The three most common things I think about when coding are DAGs, State Machines and parsing. The latter two come up all the time in regexps which I probably write at least once a day, and I’m always thinking about state transitions and dependencies.

A lot of the time they are selling themselves as influencers on the subject. It’s often a way to get views or attention that they can use in the future.

I love having generated code in the same repo as the generator because with every commit I can regenerate the code and compare it to make sure it stays in sync. Then it forms something similar to a golden tests where if something unexpected changes it gets noticed on review.

I wonder if the more we use LLMs the more our written patterns will begin to match them. Those of us who work with them the most are likely to be affected earliest.

I don’t know too much about about the TS ecosystem but do these new systems you talk about do it via a “Smart Constructor”? That is the pattern I typically use to solve this problem in Haskell and Rust code.

I once found a confirmed bug in SQLite one time, and it’s the highlight of all my OSS bug reports.

Interestingly enough I found it while fuzz testing a query builder and cross testing it against PostgreSQL, MySQL and an in-memory filtering engine I wrote.

Has anyone ever implemented a schema where you define a view to return the latest instance of each resource, and it maps INSERT, UPDATE and DELETE to an append only table underneath?

I’ve done some of this with an event sourcing system, but not the query rewriting. All my reads use the “latest view”, but the app uses functions to write to the underlying scheme rather than doing “simple” DML.

I wondered if keeping the storage as append only under the hood would keep the app layer simple.

Its usually leadership who are the problem if a whole department is failing. If they started firing from the top down they'd eventually reach competent people who stayed with the department out of loyalty or because they felt responsibile to hold things together. Seems such a waste to fire those people too.

I think the point the GP message is making is that, prior to review/merge you extract atomic commits from your WIP that tell a clear, concise story of how the change was made. The reviewer has less built up context so by chunking it like this they can step through each commit one at a time.

IMHO the expectation is that each commit would 100% pass CI, so if you decided to extract some commits and merge that early you can. This is especially useful when a 6 commit PR is reviewed, and the first 3 commits are fine but there is more feedback on the last three. The reviewer can split the first 3 good ones out, get them merged and whittle down the PR to the remaining three. The subsequent follow up will be less.

IME team velocity goes up with this too, and it encourages small and easy to review commits like a Remove to be extracted and merged early.

Since PRs are always as large or larger than commits, I would much rather have a specific commit flagged than have to wade through the whole PR diff. If the PR is not familiar to me, I want to increase my effectiveness narrowing down the cause, so I can fix it faster.

This might be a dumb question, but is it possible to take something like WASM and make it run on HVM?

I mentally change schema to namespace when thinking about the postgresql feature.

If it helps anyone, at work, I open sourced the UUID v7 postgresql function that I wrote: https://github.com/Betterment/postgresql-uuid-generate-v7

We've seen some amazing benefits, especially around improving the speed of batch inserts.

> billionaires tend to get more hate because they simply have more negative impact

Not just billionaires, the specific type of billionaire that seeks out fame.

There are plenty of billionaires with names you'd not recognize.

Also, why don't they share the lists with each other? They don't need government help to do this.

If there are privacy issues then they could just share a list of hashes and if someone's legal name hashes to something on the list then you deny them.

Reading this code I can't help but try to evaluate it in my head.

Question: is there a bug for the assignment of party_not_at_fault? Would you want party2 to be selected if the condition is true?

Other languages I've used have the first part be the true branch, and the other the false branch.

This is where you'd choose the .gif version hoping it was interlaced.

My current team does it, and it is so enjoyable.

We practice atomic commits that change only one thing, and in one way. We separate Fix, Refactor, Change, Add, Move and Remove commits from each other. Our commit summaries begin with those keywords so we can tell what "type" the change is. Each commit must pass CI 100% on it's own.

There are specific characteristics we've noticed. For example, for us, a "pure Refactor" commit either touches code or tests, but not both at the same time. If we touch too much we try to split it, or we call it a Change and it gets even more/different scrutiny.

Reviewing by commit allows me to give my full focus to each without having to keep all state in my head at once. I can step through and understand the series of changes. It's like telling a story, once I've stepped through each commit I am better able to understand the whole picture. If I only look at the summary some of the finer points are missed.

Also we've found we can extract commits more easily and get those merged early while we work on our main branches. If we see a Refactor, we can just do it, extract it and then keep our main PR focused.

Its interesting that Netflix built their systems in a way that assumes the underlying platform is unstable. With Chaos Monkey and other systems they made sure things are resilient to flakey behaviour.

I think the next generation of ORMs will be built on top of this approach. Being able to query and receive an entire object graph in a single round trip has changed how we develop apps at my company.

Your comment is being downvoted, but IME working at a few startups where the owner went from making 2M to 10M, then 50 and 100M+ a year I rarely saw founders who had a good work/life balance. Sure, they could afford to pay people to take care of all their domestic needs, their life consisted mostly of working 24/7. Even their vacations were often working vacations.

I think your characterization is accurate.

One idea might be to focus on trying to convert monthly subscribers to yearly.

You could offer a subset of monthly subscribers a one-time upgrade to a yearly subscription at a prorated discount.

So people one month into their subscription could get the remaining 11 months for the annual cost minus the 1 month fee they already paid.

If one could be made to shoot fine sand, it could be used outside I bet.

This is pretty efficient. She lazily sorts them on first access. They are stored in a thunk and then lazily evaluates them. After that repeated access is efficient.

The only correct answer to this is now. Right now. No one knows if this is the top of the market and tomorrow everything will come crashing down, or if this is the very bottom of a 10 year bull market. On average you do better not trying to time the market and just contribute on an automated schedule. Set up monthly contributions and buy regardless of whatever is happening in the market and then try to forget about it for most of the year.

I agree in this specific example the inner sort is meaningless. There are valid cases where a subquery can use an ORDER BY, such as when a LIMIT or OFFSET is specified.

I'd go to far to say that unless a query has an ORDER BY it is likely a bug to use LIMIT or OFFSET. In the absence of an ORDER BY the database is free to sort the rows any way it likes, and this could change between versions or based on any number of implementation details. If it appears to sort determinsitically with no ORDER BY it should not be relied upon.

I would recommend SQL and Relational Theory by CJ Date.

It completely changed how I use SQL. Before reading it, I had about a decade of experience with SQL. I didn't really understand the theory underneath. I also didn't understand how to write SQL in a way that adheres to the theory.

You can think of this book as being the closest we have to "SQL: The Good Parts".