David Majda (@dmajda@mastodon.social) 78 Posts, 15 Following, 23 Followers · Software engineer and engineering manager with a passion for programming languages, web technologies, software craftsmanship, and sustainability.

I’m still a fan of Bluesky and its community, but for me, Mastodon is the place to be right now.

mastodon.social/@dmajda

2. Mastodon’s model of decentralization, despite its many flaws, is better and more sustainable than Bluesky’s. This is especially true in today’s political and legal climate (US–EU split, various age-verification laws, …)

1. Most tech people are on Mastodon, resulting in much more interesting content and conversations.

I’ve decided to stop using Bluesky and continue only with Mastodon after using both for a year and a half.

It’s quite simple:

The Cost of Leaving a Software Rewrite “On the Table” Rewrite talk lingers. Momentum fades. This post explores why unresolved futures stall teams long before code breaks.

“Once something is treated as provisional, people stop taking full responsibility for it. […] When engineers believe the system is temporary, they invest less in it. They stop fixing small things. They stop deepening their understanding.”

blog.planetargon.com/blog/entries...

“GPT‑5.3‑Codex is our first model that was instrumental in creating itself.”

I think this is the most important sentence of the GPT‑5.3-Codex announcement.

If you’re producing structured documents, need to generate PDFs from your application, or just prefer a markup format over visual editing, check it out!

You can think of it as modern LaTeX — with a cleaner design and without infinite layers of macros and cruft.

On the surface, Typst is a markup language similar to Markdown, just more extensible. But in its core, it’s a well-designed programming language optimized for creating and manipulating structured documents.

Typst: The new foundation for documents Typst is the new foundation for documents. Sign up now and experience limitless power to write, create, and automate anything that you can fit on a page.

I’ve been using Typst lately, and I really like it!

typst.app

Why I Still Write Code as an Engineering Manager I still code as an engineering manager. Not to stay busy, but to show my team what good looks like.

"I'm a manager now so I don't code anymore."

Is that because you genuinely can't, or because you've convinced yourself you shouldn't?

terriblesoftware.org/2026/01/22/w...

I’m not entirely happy with days 1 & 2 — I spent too much effort on error handling and resorted to a brute-force algorithm on day 2. But I course-corrected on day 3 and ended up with a solution I’m pretty comfortable with.

Let’s see how the next days go.

GitHub - dmajda/advent-of-code-2025: My solutions of Advent of Code 2025 puzzles written in Rust My solutions of Advent of Code 2025 puzzles written in Rust - dmajda/advent-of-code-2025

I’m posting my solutions on GitHub:

github.com/dmajda/adven...

I’ve decided to participate in Advent of Code this year, writing my solutions in Rust. It’s a good way to practice the basics of the language and keep my Rust knowledge fresh. Plus, the puzzles are fun!

The timeline is made using Vega, a declarative language for describing visualizations. If you’re curious, the code is available on GitHub:

github.com/dmajda/timel...

Perhaps surprisingly, the language I used for the longest period is JavaScript. I first learned it in 1999 and used it more or less continuously ever since.

The timeline includes only languages I learned well and used substantially. I omitted languages I used only for one-off projects and periods when I used a language only occasionally.

A timeline of programming languages I’ve used in my life

I’ve used a lot of programming languages in my life, so I went through my archives and created a little timeline — mostly for fun and for my own reference.

New blog post: "Fifty Shades of OOP." Put in a surprising amount of research for this one!

lesleylai.info/en/fifty_sha...

Last week, a speaker at the Prague Rust meetup created his slides using presenterm. It looks like a nice tool! I especially like how the terminal format constrains visual decisions, yet the result still looks great.

I think I’ll use it for my next technical talk.

mfontanini.github.io/presenterm/

Stop Avoiding Politics Most engineers think workplace politics is dirty. They’re wrong. Refusing to play politics doesn’t make you noble; it makes you ineffective.

Politics isn't manipulation and backstabbing. It's understanding how decisions actually get made and learning to navigate that reality.

Refusing to engage doesn't make politics go away. It just means you lose by default.

terriblesoftware.org/2025/10/01/s...

Our efforts, in part, define us

“What happens when something we enjoy doing that took effort becomes effortless? And what happens if that original effort was a foundation on which we saw value in ourselves?”

I have exactly the same feelings regarding AI writing code as the author of this post.

weakty.com/posts/efforts/

It reminds me of my favorite thought experiment: imagining a world where organizations with more than 150 members (Dunbar’s number) are simply not allowed.

It’s an interesting exercise to think through what the world with such a rule would look like and what the gains and losses would be.

This is currently #2 on Hacker News and is worth reading in my opinion:

mathstodon.xyz/@tao/1152599...

Nice post showing how to write a simple recursive descent parser in Rust:

jhwlr.io/intro-to-par...

The above is really just the first approximation: many other factors can sway the decision in one way or the other. But I still think it’s a good starting point for making the choice.

If you’re not in such a situation, but still need speed, Go is usually a better choice (unlike Rust, it can be learned in a week). In all other cases, it’s probably best to go with the language your team feels most productive in.

The main issue is that Rust is quite complex and takes time to learn. I believe this complexity, which is a result of making a fast language secure, is warranted only in specific situations.

Your decision tree should look like this:

▪ If you need raw speed and absolute control over memory (e.g., can’t tolerate GC pauses and/or memory overhead), go with Rust.
▪ If you only need speed, but can live with GC, use Go.
▪ Otherwise, use Python, Node.js, or whatever else your team prefers.

My recent talk sparked some discussion (both online and offline) on when to use Rust, especially on the backend. My take in mini-🧵 below.