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.

Anthropic launched a report about the impact of AI on the labor market. They will continue to gather usage data and make that public.

The big takeaway of today’s usage is:

Overall, we saw a slight lean towards augmentation, with 57% of tasks being augmented and 43% of tasks being automated. That is, in just over half of cases, AI was not being used to replace people doing tasks, but instead worked with them, engaging in tasks like validation (e.g., double-checking the user’s work), learning (e.g., helping the user acquire new knowledge and skills), and task iteration (e.g., helping the user brainstorm or otherwise doing repeated, generative tasks).

This is how I currently use these systems. We will have to wait and see if this continues to be the case, as they become more powerful and affordable.

Interesting post about, even in the world of tech, sometimes problems can’t be solved with automation. We have to spend the time and do some tedious work that no one is willing to do.

Sometimes, programming feels like magic: you chant some arcane incantation and a fleet of robots do your bidding. But sometimes, magic is mundane. If you’re willing to embrace the grind, you can pull off the impossible.

LLMs will simplify and remove some of our workloads, we see that already. But there will still be things that only we can do manually. And we must be willing to put in the work when that happens.

Being a successful startup founder means being very good at fund raising. This means being good at stroking the egos of powerful people with lots of money and making fantastical promises that they can’t resist. Elon is good at it but Altman is better.

• Dare on Bluesky

TechCrunch used to do Start Up pitch breakdowns and guides on how to present to investors. They all agreed with the above post (in much friendlier and more subtle ways).

TIL about Ciena.

We provide the technology that powers telecoms networks basically. For them to get that high-speed connectivity, Ciena’s technology goes on the ends of those fiber cables that allows the speed and throughput to continue to drive the capacity. …. think 96 percent of the major carriers around the world — are Ciena customers

They use  Wavelength Division Multiplexing to basically send more and more light data on the same physical network. That’s amazing.

WDM which is the fundamental technical innovation Ciena is built around. WDM is absolutely key to how the modern internet works, and most people have no idea it exists. The basic idea is that WDM uses multiple wavelengths of light to fit more data onto a single fiber optic cable, which allows those cables to deliver more and more information over time … With DWDM, vendors have found various techniques for  cramming 40, 88, or 96 wavelengths of fixed spacing into the C-band spectrum of  a fiber.

I first learned about multiplexers via the open source library StackExhange.Redis. We used this when we were setting up Redis over at accesso Showare.

But I never imagined that the same technique could also apply to the physical medium!