dwmkerr

Some practical techniques - 20 mins each morning and evening with Fable running through the day: Goal setting and SOWs, exploration loops, interactive specs, talk don't type, anchor to idioms, manage the blast radius with burner environments

Less of a shameless self plug than a collection of hopefully useful patterns.

I've been wanting to do terminal recordings via LLMs for testing my projects and dropping in videos etc to PRs - this is like Playwright but for the shell. Would love feedback. Recording the LLM closing Vim was satisfying.

LLMs have been helping me code more rapidly but are instucted at the system level to often be overly helpful, making changes without discussing, adding code withotut removing stale code, trying to anticipate future needs and so on.

You can prompt your LLM or use the MCP server to get it to read this guide that instructs it to follow a 'plan / implement / review' cycle, and has some common patterns and stanards that should be near universal.

I've been using this for a few months and it's greatly improved my productivity, but would love any suggestions.

Some ideas I'd been noodling with a while back and just updated. Would be very curious for any feedback.

love it, tracking now

Tracking now https://github.com/dwmkerr/hacker-laws/issues/448

thanks for the heads up, just fixed!

on this list to go in: https://github.com/dwmkerr/hacker-laws/issues/446

just saw this, fixing at the moment

"The biggest lesson that can be read from 70 years of AI research is that general methods that leverage computation are ultimately the most effective, and by a large margin." - Richard S. Sutton (2019)

For those closer to the edge of research in AI, especially over the last five years, I'd love to know whether you believe this to be valid and whether it is still the case.

...design your system assuming that your opponents know it in detail.

The more unusual or interesting the data, the more likely they are to have been the result of an error of one kind or another.

"The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer." - Ward Cunningham (possibly)

Thanks to those who've commented with corrections/suggestions, I'll go through them try and get the content fixed up where possible. Will need to have a lie down and possibly an epidural before going through the comments again to pull out the changes needed.

Hello, this is dwmkerr the author - your comments are all spot on - the earlier in the book you go the more work it needs, I've learnt a lot along the way TBH probably the entire first part needs a rewrite, that's actually going on at the moment as I'm working with a publisher.

I've linked to this post/comments on the repo (issue #210), they should all get addressed but it might be a while before the online version gets sorted, I'm closing out the final chapters online, once I've done this I'll likely go back to the beginning and rewrite/edit/put in a more consistent style (more code snippets, fewer screenshots etc).

Love it :) I think the "consistently connect to a projector" is similar. Moyle's Law seems popular here and has generated a great conversation, I'll raise it as a suggestion on the repo and see what people think!

That's awesome! Hyrum's Law is one of my favourites in the repo and one I share the most often :)

I've been working on a number of microservice projects and have found them to at times be wonderful, at times frustrating. All in all I think it's just a case of YMMV, that with or without can be fine, as long as the decision making is sane :)

Hi Adam,

Thanks for the point! In this case I meant more the situation that the same service (single service, single DB) might be running with more than one version concurrently (during a rolling deployment, or a canary deployment etc) which can lead to issues. The other case is that if services depend on an old contract there could be times where teams might run multiple versions of a service to allow different APIs to be used, rather than a single version of the service which exposes all current compatible APIs. Although to be honest, this is an issue with any service.

Thanks gfiorav for the comments!

1. I think here I was going for 'death' more in terms of the end of the hype, rather than the approach! 2. Agreed. As people get more familiar with the patterns, tools and code and so on it does get easier. The point is more that it can be a hell of a journey :)

I see what you mean. What I was trying to say is that regardless of whether you have combined devops or separate dev/ops, there is a lot of complexity in managing an orchestration cluster. I kind of muddied it by suggesting the devops approach is important to be building good software (which I think is actually arguable).

However, I don't actually think a central team is always necessarily the best way to handle the cluster, it depends on the setup in the org and how many people are using it. In some cases it might be best to have the team who use it most heavily handle it, and share their best developers with other teams on rotation. But there's lots of options here. I agree the points are a bit unclear!

Definitely a good approach, I'd like to update the article to mention this as a recipe for success. The only challenge I've seen is when the old app is still doing work behind the scenes, such as running crons or dequeuing messages or whatever.

Thanks for the comments. When I was writing the article I kept on thinking that really this is just the same old fundamental problem in a new guise, which is in many ways just how to manage component boundaries and dependencies, particularly when you are looking at a system which is being handled by more than one person.

Hi Daniel,

It's weird you mention that, I was just chatting to a colleague the other day on this topic, and I rooted out this old article which I loved:

www.slideshare.net/ScottWlaschin/ddd-with-fsharptypesystemlondonndc2013

I was lucky enough to work on a big F# project a while ago and really enjoyed the experience, it was the first time I'd done any functional programming in a professional context and I miss it now that I'm doing more JavaScript and Node.js!

Thanks for the kind words on the article, much appreciated!

That's hilarious, never seen it before :)