Egon Elbre

My new favourite thing is to let LLM explain a technical topic like a drunk person.

cmd/compile: slow escape analysis in large package in the typescript compiler · Issue #72815 · golang/go Go version go version go1.24.1 linux/amd64 Output of go env in your module/workspace: AR='ar' CC='gcc' CGO_CFLAGS='-O2 -g' CGO_CPPFLAGS='' CGO_CXXFLAGS='-O2 -g' CGO_ENABLED='1' CGO_FFLAGS='-O2 -g' ...

Awesome work by @thepudds.bsky.social github.com/golang/go/is...

Compiling the typescript compiler went from 70s to 30s !

Wrote small post about an optimization story storj.dev/blog/two-mul...

Should be fine in your case.

The main difference is that you don't get the gradual adding/removing of service methods. e.g. you add a service method and now need to gradually implement it in multiple servers and clients.

Ah yeah... in that case, maybe, MQTT? And protobuf/msgpack if you need structured messages.

Hot take: storj.github.io/drpc/

Also there are plenty of books to read about good code design. My main recommendation is "A Philosophy of Software Design". For concurrency it's "The Little Book of Semaphores".

Also few additional posts about code-reviews for other tips blog.palantir.com/code-review-... and dev.to/codemouse92/...

This approach forces people to write code with much more care and without relying on "I can fix the bugs that come up".

Any beginner coding problem or kata is a good exercise. One year I tried part of advent of code with this approach. 13 successes, 20 failures.

A hands approach could be "Cut the Red Wire" exercise (egonelbre.com/learning-cod...)

The basic premise is that your goal is to write fully correct code, without any help from your editor, tests or language server etc. You have a single attempt to run code per coding task.

Ideas for teaching the skill:

* let people read bug-fixes
* let people read lists of common mistakes
* let people read posts about code bugs
* share new interesting, bug finds in a slack channel (or mailing list)

Good naming is hard, but it's a good way to avoid mistakes.

Bad naming can easily hide bugs, make design less obvious and code intent less clear.

Also avoid negation in naming, whenever possible. `if !incorrect {` is harder to processs than `if correct {`.

Embrace consistency.

Having different variations of the same thing is an easy way to introduce mistakes that can be otherwise obvious

```
for i := 0; i < N; i++ {
for i := 0; N > i; i++ {
for i := 0; N - 1 >= i; i++ {
for i := 0; i <= N - 1; i++ {
```

If you find one mistake in code, it's quite likely there's another place that the exact same mistake happened. Hence, search for other instances of a mistakes, that came up in code-review or during debugging.

Make a docs of common mistakes or places where issues can easily happen... and re-read occasionally.

e.g. `go func()` and `chan` are a common source of errors, hence take extra time to consider logical races. What if you inserted `time.Sleep(time.Hour)`, would something break?

Automate as much as you can by writing linters, checks, tests.

Add checklists for critical things.

Review code by reading bottom-to-top. If you read top-to-bottom your brain is more likely to "automatically fix mistakes".

Works for regular text as well. e.g. try on www.sciencealert.com/images/2018-...

Get patch sizes below 500LOC. Ignoring maybe tests (if they are comparable in size). Separate trivial patches to separate changes.

Over 500 LOC reviewer fatigue kicks in and review quality drops.

Numbers based on smartbear.com/learn/code-r...

Sweet dreams.