The Pragmatic Engineer has a guest post from Birgitta Bockeler, Distinguished Engineer at Thoughtworks, where they talk about the evolution of the AI ecosystem in developing software.

It’s a really good overview of how we got from “autocomplete on steroids” in 2021, to “autonomous background agents” in only 4 years.

This really clicked for me: generative AI tooling is not like any other software. To use it effectively, it’s necessary to adapt to its nature and embrace it. This is a shift that’s especially hard for software engineers who are attached to building deterministic automation. It feels uncomfortable and hacky that these tools sometimes work and other times don’t. Therefore, the first thing to navigate is the mindset change of becoming an effective human in the loop.

This is spot on. It’s hard to trust the tool when it doesn’t always work, but Burgitta provides some ways to improve this:

• Custom instructions about coding style and conventions, tech stack, domain, or just mitigations for common pitfalls the AI falls into.
• Break down the work first into smaller tasks so that it’s easier execute the right changes in small steps, and you have a chance to review the direction the AI is going in and to correct it early, if needed.
• It’s much more effective to start new conversations frequently, and not let the context grow too large because the performance usually degrades.
• A concrete description which will lead to more success is something like, “add a new boolean field ‘editable’ to the DB, expose it through /api/xxx and toggle visibility based on that”.
• Use a form of memory: A common solution to this is to have the AI create and maintain a set of files in the workspace that represent the current task and its context, and then point at them whenever a new session starts. The trick then becomes to have a good idea of how to best structure those files, and what information to include. Cline’s memory bank is one example of a definition of such a memory structure.

I’ve read this online in multiple places, but it’s great to have it all laid out in one spot.

Will has an interesting idea about how authors can still thrive in the age of LLMs.

Instead, I’ve been thinking about how this transition might go right for authors. My favorite idea that I’ve come up with is the idea of written content as “datapacks” for thinking. Buy someone’s book / “datapack”, then upload it into your LLM, and you can immediately operate almost as if you knew the book’s content.

This is a not necessarily a new idea. Kevin Rose has an article where he creates custom ChatGPTs based on specific books .

What’s interesting about Will’s idea, is the role of the author. Instead of having people upload your book to a chat bot (which most likely has already been illegally trained on), you provide a legal way of doing that.

What is our competitive advantage as authors in a future where people are not reading our work? Well, maybe they’re still buying our work in the form of datapacks and such, but it certainly seems likely that book sales, like blog traffic, will be impacted negatively.

Samurai Jack was one of my favorite shows and this article from Animation Obsessive goes in depth, as to what made it so special (and so avant-garde).

That was a core inspiration for his original Samurai Jack (2001–2004). “There are so many sitcoms, especially in animation, that we’ve almost forgotten what animation was about — movement and visuals,” he told the press after the show debuted. The Samurai Jack crew aimed to “tell the stories visually… tell a very simple story visually.”2 Talking was kept to a minimum. Instead, Samurai Jack would need enough richness and variety in its look and movement (and its filmmaking) to keep people gripped without words.

The very limited talking made it so that you had to pay attention during every single second. I don’t think I’ve ever watched a show, before or after, were that has been the case.

Samurai Jack never reached that level. It was popular, though. And that, according to the cynical view, shouldn’t have been possible. Even with its robots and samurai and demons and zombies, Samurai Jack didn’t really fit with the mass culture of its time.

Time for a rewatch.

Do I program any faster? Not really. But it feels like I’ve gained 30% more time in my day because the machine is doing the work. I alternate between giving it instructions, reading a book, and reviewing the changes. If you would have told me even just six months ago that I’d prefer being an engineering lead to a virtual programmer intern over hitting the keys myself, I would not have believed it. I can go can make a coffee, and progress still happens. I can be at the playground with my youngest while work continues in the background. Even as I’m writing this blog post, Claude is doing some refactorings.

Armin Ronacher

I always love getting to see how movies and tv shows are made. There’s something about how the work of hundreds/thousands of people gets orchestrated into what we see. I find it fascinating. Anyways, with Andor season 2 wrapped up (I love this show), here are a few links about how it got made:

• http://www.youtube.com/watch?v=4EWCzic9z_M
• http://www.youtube.com/watch?v=q2WW2emgxRI
• http://www.youtube.com/watch?v=mO1FZB-Rnxk
• http://www.youtube.com/watch?v=PrAWHkGLn7g
• https://www.youtube-nocookie.com/channel/UCBtHgTjADDZ6D2sFFUyH41A

Quoting Justin Garrison

It takes you about the same amount of time to read this post as the amount of downtime you’d be allowed per week with 99.999% availability

I predicted that software engineering as a profession is bound to decline and be replaced by less technical people with AI that are closer to the business problems. I no longer think that will happen, but not for technical reasons, but for social reasons.

What Changed

I saw people code.

I wrote the initial piece after using Cursor’s agent a few times. Since then the tools have gotten even more powerful and I can reliably one-shot entire non-trivial apps. I told a PM buddy about how I was doing it and he wanted to try and… it didn’t work. Not at all.

What I learned:

1. I’m using a lot of hidden technical skills
2. Yes, anyone can do it, but few will

- Tim Kellog

Today has been an eventful day for the Apple AppStore. John Gruber has an excellent summary of it, but TLDR; Apple cannot charge a commission to developers, for telling users to purchase an in app purchase or subscription from outside the AppStore.

At Scribd, I work on the team that’s responsible for all things subscriptions. Before that, I dabbled in AppStore payments for Bitwise. So I’ve spent countless hours trying to understand if it was possible for us to use our web payments processor, that we already integrate and support, for everything Apple or Google. And the answer was always no, until today (there was a ruling in 2021 that allowed developers to do this, but Apple’s restrictions effectively rendered it moot).

From a user perspective, I like subscribing via the AppStore. It’s easy to keep track of my subscriptions, I trust my payment information is secure and I like Family Sharing. But as a developer, it’s such a pain sometimes. Documentation isn’t always the best (Google’s is a bit better), customer support is harder since we don’t have a lot of control, and it’s really easy to make a mess of your subscription groups. But the fact that we have to create a specific integration to each AppStore is expensive to do and maintain. It’s much easier for developers to handle subscriptions via the web (there’s plenty of paid or open source platforms that help you with this now, or if you’re adventurous to roll your own), and have all platforms subscribe via it. Then you just have to devote your resources to a single platform.

Plus the commission on every purchase is such a hard pill to swallow. I do think that they should take a cut, the AppStore does deserve it since they provide a platform for subscriptions, purchases and processing payments costs them money. But charging such a high fee (30% for the first year if your business makes more than $1MM) is expensive for a business, on top of the team needed to maintain it.

Either way, I’m excited about this ruling. We as developers and consumers, want more options. We can continue to use AppStores (at a more reasonable fee) or use something else.

Amazing post by Marcin Wichary about a 135 year font “called” Gorton (he assumes that’s what it’s called because it doesn’t really have a proper name).

Once you see it, you’ll realized how we use it everywhere.

But what’s outstanding about this post, is the level of dedication Marcin has, to document the history of it. Hats off to you.

I’m not an engineer manager (and I’ve come to realize that I don’t want to be), but one thing I’ve learned is how there’s different ways of supporting engineers.

In a blog post, Ben mentions some learnings about being a new manager, but the part that resonated with me is:

Instead of “don’t micromanage,” the advice I wish I’d gotten is:

1. Manage projects according to the owner’s level of task-relevant maturity.
2. People with low task-relevant maturity appreciate some amount of micromanagement (if they’re self-aware and you’re nice about it).

One thing that really helped me calibrate on this was talking about it explicitly. When delegating a task: “Do you feel like you know how to do this?” “What kind of support would you like?” In one-on-ones: “How did the hand-off for that work go?” “Is there any extra support that would be useful here?”

Over the last 10 years, I’ve had to support many engineers and this advice is spot on. Some people require more guidance than others: they don’t know the codebase, they haven’t done that type of task before, they’re not good at it, etc.

Knowing how to tailor your mentoring and feedback based on their skillset on that particular task is crucial. It can be the difference between everyone having a good time, and chaos and disappointment.

Keeping up with the Google Docs theme, Jacob Voytko goes into detail how they once debugged an (initial) nondeterministic bug in Google Docs.

It was a fatal error. This means that it prevented the user from editing without reloading. It didn’t correspond to a Google Docs release. The stack trace added very little information. There wasn’t an associated spike in user complaints, so we weren’t even sure it was really happening — but if it was happening it would be really bad. …. I do it a few more times. It’s not always the 20th iteration, but it usually happens sometime between the 10th and 40th iteration. Sometimes it never happend. Okay, the bug is nondeterministic. We’re off to a bad start

Errors like this are always fun to debug /s

I really like the way they did it though. Using their automated tool and just constantly having it repeat something tedious over and over again.

As for the resolution, you can clearly see the benefit of working at such a big company where they also built the platform where the bug is happening.

While reading the Hacker News post: Show HN: Nash, I made a standalone note with single HTML file, one of the discussions centered around how the linked site used

   <div id="editor" contenteditable="true">

to do most of the heavy lifting.

To which Steve Newman, one of the cofounders of what became Google Docs replied with:

This one line was like 90% of the original implementation of Writely (the startup that became Google Docs; source: I was one of the founders).

The other 90% was all the backend code we had to write to properly synchronize edits across different browsers, each with their own bizarre suite of bugs in their contenteditable implementations :-)

Checking the contenteditable documentation, it’s been available since 2008. I always assumed that Google Docs were using JavaScript to dynamically render a textarea when the user focused on an element, then render that into HTML elements when the element lost focus. Like we used to do with WYSIWYG editors around that time. But the fact that it was “simpler” than that and that attribute launched a multimillion dollar product (and I’m going to assume Microsoft Office, Notion, etc are built similarly?), makes it more beautiful.

A few weeks ago Armin Ronacher wrote a post about Ugly Code and Dumb Things, where he expands that you can’t always build real life products on top of clean, sparkling codebases. You have to sometimes just do the ugly dirty hack, to be able to launch.

Perfect code doesn’t guarantee success if you haven’t solved a real problem for real people. Pursuing elegance in a vacuum leads to abandoned side projects or frameworks nobody uses. By contrast, clunky but functional code often comes with just the right compromises for quick iteration. And that in turn means a lot of messy code powers products that people love — something that’s a far bigger challenge.

This is something that I’ve been discussing with my team lately. If we’re going to run a quick experiment, let’s do it fast and dirty (without compromising security and too much performance). If it succeeds, we will be able to build it in a more scalable way. But the key thing is that we could launch something much faster, so that we can realize if it’s worth it to focus on it long term.

This is in contrast to when you’re building a framework or foundry that other people will depend on:

But it took me years to fully realize what was happening here: reusability is not that important when you’re building an application, but it’s crucial when you’re building a library or framework.

And the final conclusion:

At the end of the day, where you stand on “shitty code” depends on your primary goal:

• Are you shipping a product and racing to meet user needs?
• Or are you building a reusable library or framework meant to stand the test of time?

Both mindsets are valid, but they rarely coexist harmoniously in a single codebase. Flamework is a reminder that messy, simple solutions can be powerful if they solve real problems. Eventually, when the time is right, you can clean it up or rebuild from the ground up.

The Typescript team just announced a rebuild of the typescript compiler in Go. It promises close to x10 speed improvements However, the internet being the internet, took to complaining about why they used Go instead of C#, that Microsoft was abandoning .NET, etc.

Here’s a GitHub Discussion thread about this, but the highlight is Anders’ comment (buried under all the noise at time of posting) about why Go made the most sense:

Our decision to port to Go underscores our commitment to pragmatic engineering choices. Our focus was on achieving the best possible result regardless of the language used. At Microsoft, we leverage multiple programming languages including C#, Go, Java, Rust, C++, TypeScript, and others, each chosen carefully based on technical suitability and team productivity. In fact, C# still happens to be the most popular language internally, by far.

The TypeScript compiler’s move to Go was influenced by specific technical requirements, such as the need for structural compatibility with the existing JavaScript-based codebase, ease of memory management, and the ability to handle complex graph processing efficiently. After evaluating numerous languages and making multiple prototypes - including in C# - Go emerged as the optimal choice, providing excellent ergonomics for tree traversal, ease of memory allocation, and a code structure that closely mirrors the existing compiler, enabling easier maintenance and compatibility.

In a green field, this would have been a totally different conversation. But this was not a green field - it’s a port of an existing codebase with 100 man-years of investment. Yes, we could have redesigned the compiler in C# from scratch, and it would have worked. In fact, C#’s own compiler, Roslyn, is written in C# and bootstraps itself. But this wasn’t a compiler redesign, and the TypeScript to Go move was far more automatable and more one-to-one in its mapping. Our existing codebase is all functions and data structures - no classes. Idiomatic Go looked just like our existing codebase so the port was greatly simplified.

While this decision was well-suited to TypeScript’s specific situation, it does not diminish our deep and ongoing investment in C# and NET. A majority of Microsoft’s services and products rely heavily on C# and NET due to their unmatched productivity, robust ecosystem, and strong scalability. C# excels in scenarios demanding rapid, maintainable, and scalable development, powering critical systems and numerous internal and external Microsoft solutions. Modern, cross-platform .NET also offers outstanding performance, making it ideal for building cloud services that run seamlessly on any operating system and across multiple cloud providers. Recent performance improvements in NET 9 further demonstrate our ongoing investment in this powerful ecosystem (https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-9/).

Let’s be real. Microsoft using Go to write a compiler for TypeScript wouldn’t have been possible or conceivable in years past.

However, over the last few decades, we’ve seen Microsoft’s strong and ongoing commitment to open-source software, prioritizing developer productivity and community collaboration above all. Our goal is to empower developers with the best tools available, unencumbered by internal politics or narrow constraints. This freedom to choose the right tool for each specific job ultimately benefits the entire developer community, driving innovation, efficiency, and improved outcomes. And you can’t argue with a 10x outcome!

No single language is perfect for every task, and at Microsoft, we celebrate the strength that comes from diversity in programming languages. Our commitment to C# and NET remains stronger than ever, continually enhancing these technologies to provide developers with the tools they need to succeed now and into the future.

Ben Howdle has a good post talking about this.

Over the years, I’ve spotted a pattern: all engineers exist on a spectrum between speed and accuracy.

This spectrum isn’t about skill or seniority—it’s about how engineers naturally approach their work. Some lean towards speed, optimizing for fast iteration and progress, while others prioritize accuracy, ensuring long-term maintainability and scalability.

Neither end of the spectrum is “better” than the other, but knowing where you sit—and understanding what kind of engineer your company actually needs—can be the difference between thriving in a role or feeling completely out of sync.

This is an interesting insight. I feel that my role requires both of these. Somewhere in the between what he calls the “Scaling Startup” and “Enterprise”, which is where Scribd as a company is at right now.

I need to look at the current goals that we have and see if we can deliver them fast without introducing tech debt. If it’s a quick experiment, doing it fast and breaking some things is fine. We work with subscriptions, so breaking them is a no-go. But launching quick AB tests around other parts around checkout is OK to do fast. We can clean them up based on the results.

At the same time, because we’re talking about subscriptions, plans and features, I’m always thinking about how to support those in a maintainable and scalable manner. This includes dealing with tech debt from the past few years. Which requires moving slower on some things to make sure we’re making the right architectural tradeoffs.

And I enjoy this. Living both worlds. It’s not easy and it has a lot of challenges, but I find it rewarding.

Simon James spent from 1997-2015 manually animating Star Wars Episode III in ASCII. You can play it straight from your browser at different speeds. You can even rewind!

His FAQ explains the process and here’s what his frames look like

Here are two frames from the encoded text file.  
1                                                                  
                                     /~\                           
                                    |oo )                          
                                    _\=/_                          
                    ___            /  _  \                         
                   / ()\          //|/.\|\\                        
                 _|_____|_        \\ \_/  ||                       
                | | === | |        \|\ /| ||                       
                |_|  O  |_|        # _ _/ #                        
                 ||  O  ||          | | |                          
                 ||__*__||          | | |                          
                |~ \___/ ~|         []|[]                          
                /=\ /=\ /=\         | | |                          
________________[_]_[_]_[_]________/_]_[_\_________________________
5                                                                  
                                     /~\                           
                                    |oo )                          
                                    _\=/_                          
                    ___         #  /  _  \                         
                   / ()\        \\//|/.\|\\                        
                 _|_____|_       \/  \_/  ||                       
                | | === | |         |\ /| ||                       
                |_|  O  |_|         \_ _/ #                        
                 ||  O  ||          | | |                          
                 ||__*__||          | | |                          
                |~ \___/ ~|         []|[]                          
                /=\ /=\ /=\         | | |                          
________________[_]_[_]_[_]________/_]_[_\_________________________

What an insane idea, but even a greater execution!

It’s notable that the key innovation in AI reasoning models is that you can either choose to get a fast, inaccurate answer from an LLM or a slower, more accurate answer from a reasoning model applied over it.

Lots of parallels from other aspects of life.

• Dare Obasanjo - Bluesky

From Gergely Orosz over on Bluesky

One of the biggest mind-bends is this: Atlassian, the creator of JIRA, founded 23 years ago is NOT profitable. This is despite generating $4.6B in revenue (!!)

Linear, founded in 2019, building “the modern JIRA for startups/scaleups” IS profitable.

Make it make sense

This is clearly a dig at Attlassian. However, thanks to the comments, Gergely realizes that Attlassian is playing a different game:

Looking closer, when going public in 2015, Atlassian turned a small profit for 2 years.

Then it started to aggressively invest in growth (and making a loss)

The result? Revenues up 15x over 10 years. Valuation also up ~15x the same time as well.

Atlassian valued at $75B (!!) which is ~20x its current revenue. Thanks to the stable growth rate it shows to investors (I assume at least)

Just a quick reminder that things are not always what they seem (except for those times where they are lol).

Great read into how a Diablo speedrunner player, got caught cheating, years after having the Guinness World Record.

I also never though of how random level generation works. By using a timestamp as the seed, you can make sure that each run is unique.

This quote in the comment killed me:

So based on reading this, had his run been legitimate then there existed not only a “god seed” but a specific point in time when the that run could be completed naturally.
Imagine buying a game and it came with a label:
“This game best completed on May 11th at 10am, 40 years after publishing.”

Quoting Peter Eisentraut, on the challenges of adding trailing commas to SQL.

can see a few possible approaches:

1. We just support a few of the most requested cases. Over time, we can add a few more if people request it.
2. We support most cases, except the ones that are too complicated to implement or cause grammar conflicts.
3. We rigorously support trailing commas everywhere commas are used and maintain this for future additions. These are all problematic, in my opinion. If we do option 1, then how do we determine what is popular? And if we change it over time, then there will be a mix of versions that support different things, and it will be very confusing. Option 2 is weird, how do you determine the cutoff? Option 3 would do the job, but it would obviously be a lot of work. And there might be some cases where it’s impossible, and it would have to degrade into option 2.

He continues to say, that even other popular programming languages support this feature, they have fewer syntactic constructs than SQL. Making it easier to support this on those languages.