iiinova — where your digital self keeps evolving

Egon Elbre @egonelbre.bsky.social · 05/10/2026

One cool idea in github.com/loov/layout for CLI graphs was using seam carving to compress the node layouts. It allows for nice compaction with relatively little effort. #golang

030

Egon Elbre @egonelbre.bsky.social · 03/10/2026

If someone needs to easily integrate some graph layouting to a Go project -- I conjured pkg.go.dev/github.com/l... to a usable state... and yes, it can also output to console. #golang

130

Reposted by Egon Elbre

Russ Cox @swtch.com · 05/08/2026

Experimental new tool from me. pkg.go.dev/rsc.io/cmd/m... is useful for cross-operating-system or cross-architecture Go development work. If your test machine is on the internet (or just your local network), you can use it as a 'go test' and 'go run' target and keep developing in your usual setup.

pkg.go.dev

mote command - rsc.io/cmd/mote - Go Packages

3537

Reposted by Egon Elbre

Roberto Empijei Clapis @empijei.bsky.social · 30/03/2026

I'm officially looking around, if anybody needs a Go software engineer with a very strong background in web security lmk. I also know a fair share of frontend dev and was a SWE/SE for Google and Microsoft. I'm looking for security-sensitive dev projects and security reviews.

1117

Egon Elbre @egonelbre.bsky.social · 27/03/2026

recording of last night's meditation with piano soundcloud.com/egon-elbre/h...

010

Egon Elbre @egonelbre.bsky.social · 19/03/2026

For a larger example see github.com/loov/gorelo/...

000

Egon Elbre @egonelbre.bsky.social · 19/03/2026

I needed to reorganize a bunch of Go code, so I ended up creating a tool for moving declarations between packages. It takes (mostly) into account build constraints, renaming, adding imports etc. github.com/loov/gorelo gorelo -r "Server Options -> ./server/server.go" ./...

100

Egon Elbre @egonelbre.bsky.social · 01/08/2025

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

000

Egon Elbre @egonelbre.bsky.social · 20/02/2025

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.

010

Egon Elbre @egonelbre.bsky.social · 20/02/2025

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

100

Egon Elbre @egonelbre.bsky.social · 07/01/2025

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/...

100

Egon Elbre @egonelbre.bsky.social · 07/01/2025

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.

100

Egon Elbre @egonelbre.bsky.social · 07/01/2025

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.

egonelbre.com

Learning Code Readability

Tips for developing your code writing skills.

100

Egon Elbre @egonelbre.bsky.social · 07/01/2025

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)

110

Egon Elbre @egonelbre.bsky.social · 07/01/2025

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 {`.

100

Egon Elbre @egonelbre.bsky.social · 07/01/2025

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++ { ```

100

Egon Elbre @egonelbre.bsky.social · 07/01/2025

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.

100

Egon Elbre @egonelbre.bsky.social · 07/01/2025

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?

100

Egon Elbre @egonelbre.bsky.social · 07/01/2025

Automate as much as you can by writing linters, checks, tests. Add checklists for critical things.

100

Egon Elbre @egonelbre.bsky.social · 07/01/2025

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-...

100

Egon Elbre @egonelbre.bsky.social · 07/01/2025

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...

100