Programmer. Likes Unix in its various modern incarnations. NetBSD (pkgsrc) developer
Dutch and more about non-tech: @sjmulder
| www | https://sjmulder.nl |
| codeberg | https://codeberg.org/sjmulder |
| github | https://github.com/sjmulder |
Here's the tool. This one is just 30% roff though!
https://codeberg.org/sjmulder/qs – build and extract query strings from the CLI
Codeberg whenever I push a small tool and try to document it properly:
"Programming language: roff"
I got laid off today. Eek!
I am looking for a role as a staff software engineer (backend focus) working on high-volume large-scale distributed systems.
Some keywords: backend / Ruby / Ruby on Rails / Go (Golang) / AWS / Terraform / frontend / TypeScript / React / full-time / remote-first
Some more details on what I offer here: https://denisdefreyne.com/notes/get-me-a-job-2025/
repost = ❤️
The final two presentations by Shirley Tarboton and @bert_hubert were nice complementary talks about respectively energy usage caused by our software development methods and actually inefficient software.
Bert had some seriously impressive graphs and examples on 1000x gains that can be made by focusing on making one's software more efficient.
We often talk about the scouting rule of “always leave the campsite cleaner than you found it”, or in a software context “always leave the code a little bit better than you found it”.
If you see duplication in the code, then remove that before you leave the method. If you see poor variable names then fix those before you leave.
What we don’t talk about as much is how a culture of branching and Pull Requests (PR’s) actively discourages making small changes for that purpose. If I want to rename a method to make it clearer and know that making that little change is going to require real effort to go through a review process and manual merges, then I’m more likely to decide to just live with the original name, even if it is is poor.
Whereas if I can make that little refactoring and directly check it into mainline then it’s a very low effort change that contributes to the quality of the product. It’s become easy to do the right thing.
How many things do we have like this, that actively discourage us from doing the right thing?
First time seriously using JetBrains Rider on my Fedora KDE Plasma system, and unfortunately not a good experience:
- Very bad font rendering on my mixed-DPI set up. Looks like glyphs are antialiased first, then scaled
- The IDE keeps getting in the way, autocompleting things without explicit intent, stuff that I then have to remove again. All configurable but it's a chore and annoying.
- What appear to be CPU spikes, and ballooning memory usage. Video started stuttering in my browser, eventually the system locked up until the kernel decided to kill the IDE worker process.
Typing is easy, naming an alias is hard
find . -name Makefile | xargs grep sjmulder | cut -d/ -f2 | sort -u | xargs tig
The final two presentations by Shirley Tarboton and @bert_hubert were nice complementary talks about respectively energy usage caused by our software development methods and actually inefficient software.
Bert had some seriously impressive graphs and examples on 1000x gains that can be made by focusing on making one's software more efficient.
If you're interested in any of these talks, AFAIK Joy of Coding puts these online every year.
Denis Defreyne
Socket
aerique
Mike Bowler