There are two open questions about the future of software engineering:

• Do frameworks still matter?
• Does my work still matter?

While it’s hard to predict what things will look like in a year or two from now, in this moment, my answer to both is: Attention. The time spent on a task in the past and present helps us build great things.

Sure, an agent can vibe code a UI framework, or a linter, or a bundler. But you still have to spend your time prompting an agent to build new features and use your attention to verify it actually does what you want it to do. That’s exhausting, and because attention is finite, it’s expensive too. This is ok for a small project run by one person, but doesn’t scale to large organizations and millions of lines of code.

Right now - and to be clear this might, and likely will, change in the future - I prefer to use frameworks that are established, feature-rich and fast. Tools that keep getting better because they are maintained by a group of people who spend their attention so I don’t have to. There is also incredible value in the attention spent by a community on a specific tool.

There are some things that are changing, though. It’s dramatically easier to maintain custom forks of basically anything. It’s easier to rewrite stuff in another language. In many ways it feels like we are finally fulfilling the true promise of open source: Fork a project and keep maintaining your version forever. Maybe we don’t need plugin systems in software anymore - just fork it! But all that still needs your attention.

I grew up watching Formula 1 and listening to loud metal music from a huge stereo in our living room. I obviously didn’t like the loud metal music as a kid, and also eventually got bored of F1 (“20 cars drive in a circle and then Schumacher wins”).

Now, at 37, those two seem to be my only real remaining connection to my dad. 21 years ago, when I was 16, I built a social network for blogging for me and my friends. I wrote the first post about the week that led up to shipping it, another post explaining what the website was, and just a few days later, the third post I wrote was titled “My Dad is Dead!?”

Reading that blog post now helps me understand my younger self, and is what motivated me to post notes this summer. I wrote so much about practical things and logistics and definitely recognize using problem solving to avoid dealing with emotions. It’s good to see how I have and haven’t changed.

I grew up in the same house for so long, but now there is very little that I remember about him. There are few photos and recordings. I watched one recently, for the first time in more than 20 years, and I was shaken: I’d forgotten what his voice sounded like.

On September 13th 2026 I became older than my dad.

It’s incredibly hard to come up with novel and sticky ideas for video games, and it’s even harder to create new core mechanics that won’t just be copied by other games quickly.

It’s also hard to compete and make your idea stand out. There are over 20,000 new video games released each year on Steam alone. The reality is an inverse situation where you’ll care about your video game (or startup) so much, but nobody else cares about you or your game. It’s challenging to get a critical mass of people excited about new indie games.

Making a successful video game feels closer to winning the lottery - except it also requires a years-long grind to build, iterate, and test gameplay ideas.

Programming used to be the slowest part of game development. As building games becomes easier, more games will compete for less total attention. The slowest and hardest job is now game design.

In 2011 almost all User Interface Engineers (UIEs) at Facebook were on a single team, and there was a simple monthly team meeting. However, the leaders of the group found that it was more effective and scalable to embed UIEs directly with product teams - and so over time frontend engineers became distributed across the company. Many teams only had one, or at most two, frontend engineers, which led to many of them feeling isolated.

This was the origin of the annual UIE Summit. We tried to bring all UIEs together for an offsite and talks to build a shared identity within the company. Unfortunately, it was discontinued for a few years due to lack of organizers.

At the time I was responsible for frontend hiring in London and a few internal hackathons, and I somehow stumbled into reviving this conference. Luckily, people loved it! Each year, about 120-150 UIEs, which was roughly two-thirds of all UIEs at the company globally, attended in-person.

I've since been asked many times what I thought made this conference special. Here is my take:

• Exclusivity: This is a weapon best used sparingly, but quite often building an identity goes hand in hand with some sense of exclusivity. Only frontend engineers were meant to attend, as it was for them.
• Vision: We did ask people to propose talks, but I defined a vision related to company or high-level UI goals and asked people across the company to talk about a specific topic.
• Broad & Deep: I tried to pick topics that were broadly relevant, but deep in design, tech or UX. For example, we'd seamlessly move from a talk about React's core to a talk about how the Messenger team made gradient backgrounds work in chat bubbles before browser support was available. Attendees could learn about deep tech while simultaneously being inspired. I always tried to have one talk that was "out there", and one talk related to "good engineering".
• Preparation: I spent weeks preparing for this single day. Speakers presented their talks to a committee a week beforehand. We then gave feedback to ensure each talk fit into the conference and that all talks flowed together.
• Memorable Moments: We tried to give attendees memorable moments and some genuine connection to the event. For example, I started a silly tradition to make a video intro about how I got to the event just on time to moderate it. This became a tradition that was kept and expanded by future organizers – one time they even rented a DeLorean for it!

Finally, I kept the event low-budget and a bit scrappy. In my experience overproduced conferences all just kind of mix together, while a few tiny mistakes (made with love) make it more meaningful.

It wasn’t so much about telling people to use a specific browser API or new CSS prop, but rather about capturing the energy and shared sense of purpose that cannot be reproduced through recorded talks. It felt like a real community.

Usually an internship program finishes hiring 6-9 months in advance. Somehow I was put into a full-time recruiting pipeline for Facebook back in 2011 and when I explained to the recruiter that I was still at university, they pushed me into their intern hiring pipeline.

I had two coding interviews over the phone. This was before video calls and I was too far away for an in-person interview. We wasted ten minutes trying to call each other, and once we finally had the very important international phone connection figured out, I was too nervous to pause and plug in my headphones. I ended up holding the phone between my head and shoulder, and sat like that for 30 minutes while solving JavaScript and CSS questions.

Working at a company like Facebook felt so unreal to me that I concluded I wouldn’t prepare for the interviews - either I was good enough or wasn’t. At the end of the interview, I was assured that yes, interns get access to the code and don’t just prepare coffee for the real engineers.

I couldn’t believe I actually got the offer. The start date was less than two months away, so we had to race to get the visa in time.

I got access to the codebase on the third day of onboarding. I was on the UI team - there were about 20 engineers who worked on all user interfaces and UI infra for the entire company. My first task was to fix a silly JavaScript bug: for browsers that didn’t support the input placeholder field (Internet Explorer and Firefox at the time), we had a JavaScript polyfill.

The polyfills for this behavior commonly worked by setting the input field’s value to the placeholder and changing the color of the field while the field is empty. The polyfill at Facebook treated typed text that matched the placeholder the same as a placeholder. If the placeholder was “Write a comment…” and you typed that exact phrase, you couldn’t submit it. This didn’t have real user impact, but it was still a bug.

Once I fixed it, the “diff” (PR) was accepted quickly. I realized this polyfill was used on almost every input field on Facebook and I actually remember becoming extremely nervous. My first change to the most visited site on the Internet could potentially break every text input field!

It was the only time I tested a change in every possible browser I could. I even got VMs for IE8 and IE7. But it felt great to do real work - it taught me to always give new engineers a challenging and real task from the get-go.

The change was pushed to production a few days later and I was so happy to have made a change to facebook.com that I emailed myself the commit hash: ad4a870eee97d7a380b76ac858f71b5aaf867348.

When I was 13 I got two Game Boy Advance games for Easter: Golden Sun and Advance Wars (I was only supposed to get one, but I guess I was convincing - or persistent). I was in Salzburg for the week and I spent every minute that I wasn’t sightseeing playing these two games. They are still among my favorite video games of all time (Elden Ring is the best) and have stuck with me all this time. I loved Golden Sun because of the story, Advance Wars because of its pixel art and both obviously because of their awesome gameplay.

I first attempted to build a multiplayer browser game like Golden Sun one year later, but the amount of art, story and map making required was too much to handle. A year later I attempted to build an Advance Wars clone, but I didn’t yet know how to code some of the core algorithms required.

That all changed with a final-year high school project. I was still responsible for all the code, and at this point I was able to actually build an Advance Wars clone. I still vividly remember when I discovered the A* algorithm on a piece of paper at the snack tables at school during a lunch break, without knowing it existed.

We shipped it but it didn’t have animations, sounds, single-player or any other basic feature of a real video game. Still, it was a huge accomplishment for me at the time and I learned a lot.

This was one of the reasons I wanted to build Athena Crisis. I wanted to figure out how to make pixel art, music, AI, a single-player campaign and elevate the genre with novel gameplay features such as invasions.

While I focused mostly on the tech and learning experience, the one thing that never sat right with me about all this is that Athena Crisis still effectively is a war game. When you make a video game, you usually pretty quickly get to beating your opponent’s head in as a gameplay loop. In the end, I tried to give the game a strong anti-war message. I don’t like making war games.

About ten years ago Facebook was incredibly open internally. As an employee, you had access to all code and internal comms. You could ask questions to Zuck every Friday. You could file tasks for any team and tell them to fix their product. You could even send Pull Requests to change any product code.

One team built a hook system called Butterfly. It allowed you to listen to events within the company and trigger certain behaviors. For example run a CI job for any code changes matching a specific path, or post a comment in your team’s group every time a deploy finished.

I used it for lots of things. Over the years the signal-to-noise ratio for company-wide posts worsened. The “FYI group” turned from “this is company defining news” to “you can ignore this except one post every two weeks”. Butterfly allowed me to filter notifications based on who wrote them or keywords in the post. I used Butterfly to notify me when people were messing with my code or to automatically comment if a bad pattern was spotted in code.

There was one use case that was more interesting than any other. As I mentioned, employees back then had access to lots of internal comms. The Tasks tool, Facebook’s internal issue tracker, let you see what every team was working on.

People leaving the company followed a specific process to keep their company-issued phone number and transfer it to a private line. They had to fill out a form that created a task in the Tasks tool, all using the same title template.

With Butterfly, I set up a rule to send me a Facebook Messenger message anytime someone was transferring their phone number. I got one to three messages a day. This was so fun! It didn’t capture everyone leaving, and a few people genuinely wanted to transfer ownership of their phone number. I’d discuss with my team and peers who I thought was leaving days, weeks or sometimes months ahead. My team couldn’t believe how often I could predict who was leaving across the company - until I told them about my butterfly rule.

At one point I noticed the CPO had initiated a phone number transfer. I messaged my manager, skip and skip-skip manager to tell them all about it. All of us were like “No way he is leaving!”. Sure enough, two months later he left Facebook - though he came back a year or two later (not something my Butterfly rules could predict ;) ).

It was fun until HR found out and got mad at me, even though I was just looking at data everyone at the company already had access to through internal tools. I’m not sure how they found out, maybe because Butterfly rules were public within the company, too.

Around the same time “private tasks” were added to the Tasks tool for handling sensitive issues. It was a sensible feature to add, but sparked an employee backlash. Many people saw the culture “trending from open to closed”. Shortly after, tasks to transfer phone lines were made private and it became a lot less fun to use Butterfly.

Last year I was in Okinawa, at a hotel bar, furiously coding the core of fate.technology that an LLM concluded couldn’t be done the way I wanted. LLMs just couldn’t get a lot of the core algorithms right at the time.

The next day, I did the same at a matcha café in Ishigaki City and again at night at the hotel bar until closing time. I thought that with the core figured out, I could hand it back to the LLM. Unfortunately it kept writing too much code that didn’t work.

The flight back was supposed to be three hours long - but it took five. Normally I get headaches on flights, can’t concentrate, and the kids need attention. However, this flight was in the evening, kids fell asleep and I was feeling great. I spent two hours wired-in, coding without Internet or LLMs and I got the initial version of fate working end to end. It felt amazing, and I put the laptop away. A thunderstorm over Tokyo kept delaying the landing and we had severe turbulence which led me to throw up several times. We were diverted to Nagoya - I was in a bad state but fate was working!

I spent the next month finishing together with an LLM. I’ve since used fate in every web/UI project I’ve worked on. This happened less than a year ago, and it sounds unreal (Imagine how unreal this story would have sounded just three years ago!). I was about to give up on LLMs, thinking they couldn’t do what I wanted them to do. But now in 2026, the magic computer writes all my code.

It feels strange to say goodbye to something I used to do for so long, but I also can no longer imagine writing code when something else can do it faster and better than me. fate will always be the last framework I built.

Metro’s original name was “JSAppServer” with a vision not too dissimilar from what Vite+ is today. When I started working on JavaScript bundling, it was called “React Native Packager” but the team working on it was no longer part of the React Native team.

It was odd when I heard the team talk about what they worked on in terms of another team: “React Native... Packager”. There was clearly an identity problem, especially as we looked at deploying this bundler for Instagram on the web.

I set up an internal poll at Facebook, promising swag for the new product to the participants. I asked people to come up with transport-related names and was pretty sure it would yield a new name.

That poll went extremely poorly. The top-voted answer with about two hundred votes was “Choo Choo McChooface” - instigated by somebody who was working on the team! There were about 50 options that all sucked, and I gave up on the poll completely until my colleague Tim and I had a 1:1 and he said: How about this option “Metro” with one vote?

It was the perfect name, but it turned out Microsoft had a trademark on Metro for user interfaces and our legal team at the time was extremely defensive. We had to settle on metro-bundler.

Still, the team got its own identity, its own repo, and was able to chart its own course (only to be disrupted by a terrible reorg two years later).

Down the road, I was pinged when somebody else had asked for approval to use the “Metro” name for their one-off business tool, and received it. I swooped in, said: “Sorry but I already asked for this a few years ago - can I have it” and finally, we could drop the “bundler”. Just “Metro”.

The Athena Crisis AI is a more conventional video game AI - based on math, algorithms and heuristics - instead of neural networks (LLMs are currently extremely slow and poor players of most turn-based strategy games). I never built a video game AI before, and I also didn't have any idea on how to actually build such an AI at first! I looked at a few tutorials but I'm a learning by doing kind of guy, and concluded I had to just write the code.

I based the Athena Crisis AI on three main algorithms: The existing pathfinding algorithms used in the game, k-means clustering, and greedy action selection. I modeled the heuristics roughly after how I would play Athena Crisis, and picked a completely stateless model for the AI: The AI completely rethinks everything after taking a single deterministic action. A deterministic AI is generally easier to test, and players preferred it too as they could optimize their strategies in games against the AI. The only downside is that it makes the gameplay slightly more boring, so while the goal is for the AI to be mostly deterministic, it does make a few intentionally limited random decisions.

The initial version of the AI took about 2-3 seconds to calculate all the actions for a single turn. The animations for such a turn would take 10-20 seconds, so it would have been completely acceptable to generate the first few actions, animate them, and continue computing the AI's actions in parallel with the animations. Instead, I optimized the AI to be at least 10x faster – calculating all actions for the entire turn on the server while the user is still seeing the turn-transition animation.

I kept optimizing the AI based on player feedback for months. When Athena Crisis launched the player base, much to my surprise, concluded it was the best AI in its genre – even though I never built an AI before!

I still remember how much everyone at Facebook hated Jest back then. It was awesome when it launched, but the JavaScript ecosystem moved so fast – and engineers working on it moved on so quickly as well – that it kept falling behind, and there was nobody who wanted to fix it.

When my manager asked me to work on it, I refused initially. I did eventually explore the codebase and make a few initial fixes, after which I realized: There are a few thousand engineers here, code quality and production bugs are becoming a massive problem, and somehow nobody is working on this. It ended up being a massive opportunity!

I initially focused on making Jest good for Facebook. That meant actually providing great testing APIs and improving Jest's performance. It was so bad that it was actually possible to make Jest 100x faster! (When somebody makes software more than ~5x faster, it usually means the existing implementation was bad, not that the new solution is so amazing.)

Another advantage of working on a testing framework over other developer tooling is that you can usually just run the full test suite to see if your changes are working or not. This made me - and a bunch of other folks I was able to recruit from across the company - feel like we were moving super fast!

Next, I turned my attention to open source. There were several serious JavaScript test frameworks in the community by this time, and each of them had one or two standout features that were better than their counterparts in Jest. While I felt that Jest wasn't good enough yet, it was definitely close. One major gap was the initial setup: At Facebook, Jest only had to be set up once, by the JS Infra team. Every other engineer could simply write tests. In open source, the story was different because even though the framework was great, few people knew how to set it up correctly.

create-react-app was starting to become popular, and it didn't yet come with a testing framework. At the same time, Dan Abramov and I spent a few nights in London hacking on Jest together. Some folks contributed Mocha as a default, and Dan wanted me to add Jest for comparison. I honestly didn't even consider creating a PR like this - he literally had to drag me to do it. Understandably, this led to a lot of pushback and gave me the greatest opportunity of all time to change the perception of Jest, in PR #250: https://github.com/react/create-react-app/pull/250#issuecomment-237098619

This led Jest to become the most popular testing framework for almost a decade. And while it is no longer the most used testing framework (as it was a testing framework for a different era), it still has about 46 million downloads a week!

It was a lot of hard work to get there: Jest had to be good, fast, stable and feature-rich. But what I learned most is that defaults matter.

I spent most of my life as a programmer, yet much of my professional career working as engineering manager (or tech lead manager – a role I wrote about in the past that I believe is perfect for the new era). If I'm being honest, I was a bit burned out and disillusioned about management when I started my own company, and didn't think I'd want to become a manager again.

Yet, through some career detours, that is exactly what happened. It's somewhat poetic too, as the first team I managed was JavaScript Infrastructure and the current team I work with is focused on much of the same.

At first, I felt a bit rusty and it led me to re-read everything I previously wrote about management. I was surprised how many of the principles I wrote about back then have held up well – despite all the changes that AI has brought about. The only material difference is that I believe in an even more aggressive form of async work, and fewer meetings. One other thing that may be hard to believe: my tolerance for bullshit is even lower than before. I have to admit, it's very fun. There and back again.

I learned so much from entering the gaming industry. Even though I had made games before, I never did it professionally until I worked on Athena Crisis. Beyond creating the game itself, I was most interested in learning how to build and market a game. There were many things that went great, but also a lot of things that didn't (including the time a Romanian pixel artist tried to extort me - a story for another time).

For one, marketing went poorly. Signing with a publisher was awesome as they took care of much of the marketing efforts, but given that they were a new publisher, they hadn't built out their processes and industry reach. I'm not blaming them - I knew about it upfront, and they did a great job with what they had available. I'm mostly reflecting on my own ability to market Athena Crisis. What I didn't appreciate at the time was that selling an entertainment product is completely different from marketing a developer tool or other software.

While I love being open, the gaming industry works the opposite way. In gaming, it's best to hide as much as possible until launch and focus exclusively on generating hype and selling an experience that might not even exist by the time you go out and talk to users (unfortunately, many games fail to actually ship the experience they promised). Instead, I deliberately open sourced the game before launch and shared the game's current state throughout development.

There were other things that I strongly believed in that ran counter to players' expectations. For example, I shipped new versions of the game up to ten times a day. Many players were annoyed that the game updated (and shipped free new features!) every day.

Yet another "issue" was that I focused too much on loading times. Athena Crisis starts in about a second – unlike most other video games that take 10+ seconds and show a bunch of logos each time you start them. Instead of giving people the feeling that this game was hyper-optimized for performance, it gave some people the impression that it was cheap – how good could a game really be when it doesn't spend a lot of time loading assets into memory?

True to my uncompromising nature, I will never overpromise and underdeliver – but I would do things differently next time. I learned a lot.

It’s kind of funny to think much of my career working on DevX was basically just focused on reducing human brain token usage. I always enjoyed building frameworks and tools that enable people to move faster. If we are sitting in front of our computers all day, we might as well get a lot of enjoyment out of building things!

Lately, however, I'm no longer sure what Developer Experience means. It's always been somewhat of a soft topic, and good metrics for it were hard to identify. Sure, performance, reliability, and features always mattered but beyond that it was often really just how software made the user feel. That part was often not quantifiable, and reached beyond computers into community and a shared sense of purpose. Does all that still matter?

DevX is kind of splitting into optimizing for humans on one side, and agents on the other. I’ve made it a point to improve tools for humans and agents at the same time. After all, improving performance, making the output of a tool better, and errors more actionable is beneficial for both humans and agents. Currently, text seems most efficient, but in the future there might be a better machine-only “language” for DevX.

There is also a class of features that have - at least temporarily - become orders of magnitude less important to me. HMR is a good example: I spent so much time getting React Native’s HMR to under 50ms to see live updates as I was typing code, yet I have not needed HMR at all for the past few months. Of course, faster tools mean faster agent turnaround times, too, but HMR is not really part of the agent loop at this time.

I’m sure there will also be new DevX paradigms. Maybe even something like HMR in production - which didn’t make sense previously - is now worth building. I wonder what else will matter when it comes to improving “AIX”.

In Athena Crisis, games can be played in fog. When fog is enabled, each field on the map can either be visible or hidden, based on the vision radius of a player's units. What is visible changes when the units move across the map. This is a fun mechanic as you have to play more tactically than with an open map, and sometimes you get surprised.

When you are playing as a team with others, vision gets combined - and this feature made me realize how similar it is to privacy controls in a social network such as Facebook. In Athena Crisis, you have to compute which fields are visible for each user based on their team, only show those fields, and hide everything else. In a social network, you have to compute which posts are visible based on the privacy settings of all the people in your network, and hide everything else.

A bug in either system is severe: in a social network it exposes posts to people who weren't intended to see them; and in a video game it invalidates the whole feature. And even more so, these connections only reveal themselves after having worked on many different systems over time. At the beginning, it’s all fog.

This note is a reference. It's the kind of text I needed at every company I've worked at. Here are some rules to avoid wasting other people’s time in a professional setting:

• Don't Say Hi: Never DM someone with a "hi" or an "are you around?" and wait for a response. Your first message must include all the context necessary for the other person to reply.
• Meeting Agendas: Meetings must always have an agenda. If you are setting up a meeting with someone you haven't interacted with before, send them a message explaining the context and purpose of the meeting. Also, the meeting might not be necessary. Most meetings aren't.
• 1:1 Cancellations: Never cancel 1:1s less than 24 hours before, unless it is an emergency. No-shows are unacceptable, especially when the other person made time outside their work hours.

Send it to people at your workplace. Please respect other people’s time.

I’ve always had endless ideas for how I could optimize my workflows - many just far-fetched dreams. I had to choose between optimizing workflows and actually building products. But let’s face it: Most software just never felt that great to begin with. Apps are either too complex, too simple, or don’t support the exact workflow I want. Sometimes they have just one or two tiny UX issues that annoy me to no end.

With agents, it’s become incredibly easy to build specialized apps for individual use cases. In the past few months, I’ve built two apps that I use for hours every day: a code review app and a markdown app to keep track of notes, meetings and people.

Sure, there are plenty of code review tools and note editors - but none worked the way I wanted them to. Up until recently it wasn’t feasible to build these types of apps from scratch - on my own, on the side. Even six months ago it would have taken months of full-time work to build “the app of my dreams” for any category.

I’m still astonished at the rate of change. These apps no longer take months or years to ship, and a single user is a valid “addressable market”. I can build truly personalized local software now - it’s incredible. Build specialized apps.

I started coding when I was 12 with a website about Nintendo. At first I previewed, then reviewed Nintendo GameCube games. I quickly became obsessed with building the site over writing the content. After four iterations of the site, I dumped it and replaced it with a hand-coded social network back in 2005, complete with blogging, friending, commenting and privacy controls. At the same time I also built many turn-based browser games. Text-based at first, and with pixel art later.

All these early apps had users, but I shut them down quickly and moved on to the new thing. For example, just before I started at university, I shut both the social network and the most recent game down.

Understandably, this made many people, including close friends, angry. At the time, I didn’t appreciate enough that the social features meant that even though I had ownership over the code and product, they had a sense of ownership too – over the content they created to fill the sites with life.

Past projects always weighed on me, slowed me down, and it felt like they held me back from becoming a better engineer. I felt terrible for shutting the sites down, but saw no other way. At the time, it was just me, doing my best.

It took me years to understand that I owed the users more. I could have found new owners, open sourced everything, and handed the sites over gracefully. I still believe I needed to let go of those projects to grow. What I didn’t understand then was that letting go didn’t mean I also had to tear down.

I like collecting health metrics. They are great indicators for how things change over time. Even if most metrics that an Apple Watch collects are not entirely accurate, it is great at measuring the relative change of a health metric over time.

However, what I hate is when technology - especially Apple Watch - keeps telling you what to do and how to live your life. "You have to stand up now", "Are you doing a workout???", "Good morning", "Walk at least this much to reach your daily goal", "Say three prayers for Steve Jobs to collect your badge and keep your streak alive".

Apple is by far the best consumer technology company, but the paternalistic behavior of their software is one of the most outrageous things they do. I wish Apple would stop treating adults as if they are five years old. Apple is not my mom.

Disagreements are natural in large organizations. You may be asked to "disagree & commit" in contentious discussions, and it will be celebrated as good leadership.

In my experience, the explicit introduction of disagree & commit appears to happen at a certain scale once leadership no longer thinks the organization can be as effective as it used to be. To me it has always felt like a sign that the organization has peaked - after all disagree & commit is rarely what led teams to success in the first place.

Disagree and commit makes visible disagreements disappear temporarily, but it keeps the underlying differences unresolved. People fundamentally still disagree because it’s hard to internalize something you don’t agree with. It often leads to members of the team becoming indifferent about the work, and over months and years it causes rifts.

That doesn’t mean avoiding disagreements. I'm known to be strongly opinionated and to defend those opinions. I enjoy working with people who operate with a similar conviction. I don't want others to have the same opinions, I just want to work with people who feel strongly about what they are doing.

This is explicitly not "strong opinions, weakly held" either – yet another poor big-tech leadership principle. If your opinions are weakly held, you might not need to have opinions at all. You should have strong values, be able to justify your opinions from first principles, and be open to changing your mind - sometimes in heated arguments.

It's ok to disagree at first, but if you want to truly build great things you have to work hard to get agreement early, and then work together as one unit. Don’t disagree & commit.

When I first started managing JavaScript Infrastructure at Facebook back in 2016 I made a huge mistake: I split the team into three groups: One focused on Yarn, the package manager, another on Jest, the testing framework and the last one on Metro, the JavaScript bundler.

This was great in the short-term. I was able to bring people together to make these tools great individually. However, two things started happening:

1: When we were asked to take on additional responsibility, or solve an ambiguous problem, the team tried to fit it neatly into one of those projects. When something related to package management required changing Facebook infra, the team threw their hands in the air and said "Sorry, we can't build this into Yarn - it's an open source project!"

2: The people made those open source projects their identity. They would do talks and represent the project on Twitter. They felt heavily invested, and it made it even harder to motivate them to solve problems that Facebook needed to solve internally.

It wasn’t their fault, it was mine. I set up the team that way, and encouraged them to take ownership. Through this experience, I learned that teams have to be structured around the problems they are solving instead: Package Management, Testing, and Bundling – instead of the concrete implementations to solve those problems.

It's much easier to make a roadmap focused on how to achieve a goal and say "Currently, Jest is the right solution for this problem, but maybe in the next quarter we'll migrate to something else". Don't tie your identity to code and when you set up a team, focus on the solutions to problems.

When I get a soccer ball in front of the box, it always feels like time slows down until I make a decision: dribble, pass, shoot, or do something else?

Even though it still feels similar as I make that decision in that moment today, it’s no longer the same as it used to be. I'm 37 now, the blink of an eye that I spend thinking is too slow, and gives my opponents enough time to take the ball.

High-performance athletes across tennis, Formula 1, or soccer all lament that reaction times fall away in their late 30s and early 40s. There is all this talk about longevity, much of it focused on superficial things. I’m worried that decision-making becoming just a bit slower has negative ripple effects on everything else. But, I also just wanna play as fast as I used to. Is anybody researching how to get back closer to decision-making in real time?

When I joined VoidZero back in January I prepared a list of 30 DevX paper cuts across the JavaScript tooling stack. It was everything that slowed me down while I was coding, and I was determined to fix every one of them.

At around the same time, a friend asked why I still had Sublime Text installed next to my IDE. It used to be my main text editor and I told him I still enjoyed the convenience of opening and editing a single file quickly. However, he was right to question it. I no longer needed Sublime Text and got rid of it.

A few months later I stopped writing code by hand. Consequently, I didn't end up fixing a single paper cut. These little issues used to annoy me to no end, and now I barely remember a single one of them - a class of problems I no longer experience - and one I focused much of my career on solving.

I deleted the todo list, and I’m about to delete VS Code. IDEs are done, and they are not coming back.

The JavaScript framework I was most attached to was MooTools, back when I was a teenager. We wrote all code by hand: Not just the syntax, also the spaces, semicolons and newlines – there were no code formatters!

MooTools was the first open source project I worked on with others, and the team had a huge impact on my career - and English skills!

Our shared values were about building the perfect JavaScript framework and working on it felt like expressing myself artistically. The framework was beautiful. As it turned out that’s a terrible way to manage open source. Our attitude towards beginners, and how we integrated with JavaScript were.. not ideal.

What was once used on 7% of websites ended up being dropped by everyone. This was tough for me to take. I disassociated with the project and open source for a year or two. Other maintainers kept working on it, and I ended up directing my anger about what I perceived was a failed open source project towards them. I told them "Why do you guys still work on this?" after I had landed a shiny job. That sucked and I’m sorry.

I approached every project after MooTools differently: I'm doing my best here given the constraints, I'm not tying my identity to this project, and if something better comes along – please, let's dump whatever I did and align on the future together. Value your work, but don’t value the attachment.

I’m sitting here on the grandstand looking out over the valley before me. It’s a quiet rural valley, if it weren’t for the cars going past me at 300 km/h.

I feel like I can name all the little towns I see down in the valley, and the peaks of the mountains on the other side. The mountains are full of trees, the taller ones with a visible tree-line are behind me. It’s a cloudy and rainy, yet humid, summer day. Everything down in the valley is green as far as I can see: grass, fields, trees.

But of course I don’t know all the little towns and mountains. I’m 10,000 km away from where I grew up! I’m at Fuji Speedway, watching Super Formula, not Formula 1, and instead of the Austrian Alps, it’s Mt. Fuji towering over everything behind me.

Yet, this spot feels exactly like the valley surrounding Knittelfeld, looking down onto it from the Red Bull Ring. Not exactly how the Austrian countryside feels to me today, but how Austria felt to me growing up in the 90s.

I’m at Fuji this weekend, and in a few days’ time I’ll be at the “same” spot in Austria. I don’t really know what makes the Japanese countryside, and the Gotemba valley in particular, feel so familiar to my home. I guess it’s kind of a Happy Valley.

I used to work with an engineer who didn't want anyone to touch his perfect JavaScript code, so back in 2012 he isolated it into a separate folder in Facebook's monorepo called static_upstream.

The official reason of course was different: Refactor Facebook's core JS library code (including React) into an isolated folder so that it can be shared on sites other than the desktop site, such as on mobile. That kinda made sense.

However, it was implemented in a way that static_upstream was then synced into downstream folders – one copy of every core JS file per project. Once we had three projects, the duplication had already reached millions of lines of code.

In 2016, I set out to get rid of this duplication. Get rid of static_upstream, the downstreams and just have a single html/js folder that every site inherits. It turned out the technical change to make that happen was literally one line of code! We should have never even created this elaborate system for syncing the same code across the repo!

The only problem was we had to actually move static_upstream and delete all the downstream folders while thousands of people were committing conflicting code and Mercurial (a Git that nobody uses) was constantly under massive load.

I was in Japan then, and worked with an intern based in the US. We wrote scripts, but given the amount of files it was still a highly manual process that took us both about 10 hours. We deleted more than 100,000 duplicated files – it was beautiful! I had to "hg push" and fake the approval (which at the time was verified by putting "Reviewed By: <username>" into the commit message) because the diffs became so large that our merge infra couldn't handle it. I watched it ship to production, everything looked good, and then I went to bed.

The next morning I woke up to dozens of messages. The engineer owning web JS infra sent many insults my way, off our work chat: “What the hell are you doing, you should have known better.”

As it turned out, I didn’t know any better. Moving this many files completely wiped away the JavaScript bundling cache – which was based on file paths instead of unique module ids like every other system at Facebook – and it led the ML based bundling system to think all those files were new, resulting in facebook.com sending each file individually. Kind of like how Vite works in development, and it made facebook.com over one second slower for every user. I don’t even wanna think about how many millions of dollars that was.

A three-person team in New York spent 12 hours reverting our changes – using the same hg push method in reverse – and failing constantly because other people kept pushing changes to the files they were reverting.

I’m more of a fix-forward kind of guy, so I shut up that day planning how to do the same thing again - and make it stick. I remember trying to lighten the mood. I said: "No no no this cannot be happening" in the incident channel and when the engineering director for web infra asked what I was talking about I said: "Pokémon Go was just released".

Anyway, the team reverted the one-million line change, and a week later the same intern and I wrote another set of scripts to fully automate the migration – this time with the correct updates to file paths in a random PHP file to make sure we didn't wipe away the intricate machine learning bundling cache setup. Every second counts.