Dion Almaer: Recent Episodes

View Details

Simon Willison wrote up his 1, 3, and 6 year AI predictions from his chat with the lovely Oxide crew. This is always a fun thing to ponder as you start a new year, especially since 2025 feels like such a futuristic number.

I found myself reflecting on this myself, and landing on a provocative thought. What if the most popular development language 6 years from now isn’t a back and forth between Python and JavaScript, or a “new” language such as Rust, but is something much more radical: English.

When I say “English”, I am using it somewhat as a short hand for natural language, so it can actually include many other languages such as Spanish and Mandarin.

This seems somewhat outlandish, right?

Maybe not so crazy given Karpathy having said this awhile back?

The hottest new programming language is English

— Andrej Karpathy (@karpathy) January 24, 2023

So, how could it come to pass?

• Computers can now understand natural language (and other inputs that humans do, such as images and sound)
• Computers can write code based on that understanding (including filling in the gaps)
• Humans already use English for large parts of the development process (documentation, comments, issues, PR conversations, group chat conversations, etc etc)

Let’s dive in.

Computers are increasingly grokking usWhen you look at the history of computing, we see a continuous rise in abstraction in how we are able to talk to computers. We started speaking at a very low level with punch cards, machine code, and assembly language. Only a few people had the capability and understanding on how to get computers to do things, and those things were fairly limited (yet still amazing!).

Over time, we taught the computers abilities that would allow humans to increasingly share intent at higher levels of abstractions. Why have the humans track the memory in the computer if we can make the computers do that work?

Part of the story is in building the abstractions, and the technology breakthroughs such as garbage collectors that are fast enough, or LLMs that can write code. Intertwined with this trend is the dramatic shift in raw numbers, as illustrated by Tailscale CEO Avery Pennarun in his piece on living in the numbers. The rate of change is hard to fathom. We are used to CPUs that get faster, and GPUs that can multiply matrixes increasingly quickly, and more memory, and larger faster disk, but OMG when you see the actual magnitude of the change… how computation is 200,000x faster than 20 years ago etc… it can sink in that we can expect so much more from our systems.

It’s not that we can have fewer instances handle a few more HTTP requests. Our computers can grok what we say, can see images and video, and can hear audio. How much improvement will there be in 6 years across all of these vectors? Today is the worst we have it, with repeated changes coming. Mind blowing.

The reason that we see so many applications pop up with a chat side bar is a signal that we are building bridges between the computers and the humans in natural language ways.

With development, we see this in almost all of the tools that we use. Coding assistants started with helpful auto complete, but we want to communicate deeply with the Borg connected pair programmers that we now have available 24/7. Chop chop.

Computers can write codeI mean, humans have always written code. Since the beginning of computing, we’ve created systems that translate human-written instructions from one format into another that computers can understand.

But now, we’ve evolved beyond that. We can use plain English as input and get not just code, but various other digital assets as output.

Writing code isn’t just about mastering syntax. It’s about understanding platform capabilities and technological ecosystems. LLMs possess a vast knowledge base of this information, and with deep context awareness, they can comprehend what truly matters – your code and all its dependencies.

Humans already use EnglishWhen you think about your development projects, you realize that a large amount of your time isn’t writing for loops, it’s understanding the requirements of your business and mapping them to the technology that needs to drive it.

You write requirements. You have conversations with your team in Linear and Slack and …. You have code comments. You chat with your coding assistant. We are already using English.

The difference in 6 years though, is that we will be able to switch to a spec-centric vs. code-centric way of development.

Guypo goes over this in this talk: What is AI Native Development:

Don’t think of this as a one time moment where all of a sudden all that every developer does is write specs.

It can, and will, happen gradually. This has always been the way with development.

Python rocks up and has the ability to link to C libraries and thus has access to the evolved corpus of well tested libraries that have been worked on for decades. The same can happen here. The wrapping will occur, and the lower level can evolve as makes sense. The great feature of this new approach is that the generation from English to implementation can always be re-run with the latest gains.

Compare the two paths:

Current: you open chat with your favorite coding assistant and go back and forth to get some code for certain functionality. When you are happy with it, it ends up in your codebase. You lose the context of the chat and the English intent, and you now have a base, based on the state of the art of that moment. You are left with the compiled output, so to speak.

Future: your English is the source, and as your computer systems improve, they can be regenerating new and improved implementations. It behooves you to invest in testing and validation in this world, but this is something that is actually really needed any way… we just sometimes get away without doing it.

Once we work out how to get good at this level of abstraction, more amazing things can happen. Because LLMs can understand many languages, both nature and programming, we are not truly multi-lingual. The flexibility that comes with this can be transformational, but it is also very different. Being able to fill in the gaps isn’t the same as inheritance and composition. When do we need to be more explicit vs. when is that more than makes sense to say? How do we prompt humans for more information so they can elaborate? Do we sometimes want to use pseudocode to explain something?

Popular doesn’t mean, solely!Notice that there are items that are not being said in this prediction?

“You don’t mean that everyone will just be writing English only, right?”

No. Most popular doesn’t mean only. There will be room for traditional code. It’s also important to remember that when we use the term “developer” we are doing a lot of work. There is a massive spectrum of people doing very different things, with very different skill sets.

There are engineers still doing very low level work, and everyone on top of those layers gets to benefit without having to do so (e.g. on top of an operating system, or using standard libraries, etc). As we wire up new platform capabilities, that wiring may be done via platform APIs are not in English.

So, while English will play a role for everyone, I think that it will best suit cases higher up the stack, with the app developers. It will be important to still understand the platforms you are building on top of, and programming languages. But this may become less important over time.

“Why did you say development language not programming language”

This is purposefully broader to represent the usage beyond the programming aspects of software development is all.

“Does this mean you think there won’t be the need for developers?”

The opposite. I think our appetite for software is insatiable, and I’m excited about how this can democratize development, and how the flexibility can allow the personalization of computing experiences for users. If there are fewer curly braces, that doesn’t mean that there isn’t any more development going on!

We have a lot to work on to make this all happen, and I will now set a calendar entry in Jan 2031 to re-read this and see how far off I am.

What are your predictions for how software development will change in 6 years?

View Details

How do you build products and platforms for developers in a world that contains probabilistic black boxes that surprise you with what they can and can’t do, and when they decide to show you.

From my own trial and error, I have found that most of my mistakes are in not understanding the two pieces: developers and AI systems.

Instead of merging them, the key is to understand what makes each different and building with that in mind. Then the sum of the parts, bringing great UX to the party with smart LLMs, does the trick.

I think it is easy to anthropomorphize computers now that they seem to understand our language. Our written words. The images our eyes see. The sounds our ears hear. They have become the robots we have read about and watched on the big screen in Sci-Fi for ages!

Thus, if building a coding assistant, it should feel like another human that you are pairing with, right? With the same UX? No. We can do much better.

The DeveloperFirst, let’s look at the developer, the human, and see how they operate, where they shine, and where they can use help.

Pat the developer:

• Has a variable set of skills and knowledge when it comes to building software. They are proficient in some programming languages, databases, libraries, frameworks, platforms, and domains. Some of their knowledge has faded over time while other sets are fresh. It’s a unique mesh.
• Only has a certain amount of time and energy to expend per day. They really don’t scale. Sometimes they feel sick, and other times they are in the zone and flowing.
• Hates toil, can get bored, and prefers creative work.
• Has some imposter syndrome.
• Is forgetful, and makes random mistakes all the time.
• Is able to deeply understand the context of their work environment, and the people around them.
• Knows what winning is all about, and cares about the user and business problems that need to be solved.

This is just the tip of the iceberg, but you can already see how important it is for your solution to:

#1 Get the important context that is hidden in Pat’s brain out of their head and available to other team members and the AI system itself. There is gold locked up there.

• Help Pat expand and elaborate with the system. For example, if you have a chat interface in your solution, end with questions for Pat to get more information, and teach Pat to keep iterating this way!
• Make sure that Pat can tell you important things such as “this is a golden PR, trust this way of doing things”, or “this part of the codebase is legacy, please don’t give me more like this… instead treat this other part of the codebase as The New Way ™”, etc.
• Secret side note: if this is done well, it also means that if Pat leaves the project or the company, more of the knowledge is left behind and available!

#2 Make sure that Pat is always unblocked, and in that flow state as often as possible.

• Many AI researchers I have worked with see a failure and their instinct is: “we will fix that in the model”. They run off and try to steer the model to solve that particular problem, and for it to always come out with the perfect answer. While it’s great to keep improving on real tasks, and building those datasets, there will ALWAYS be issues. This is an endless game that reminds me of Google Search and the whack a mole world of “search quality”. The answer is to not fight for perfection, but to have a forgiving UX for the developer. If I am stuck on a task, I get angry, and feel like the system has totally failed me and my only hope is to start from scratch. If instead, there are threads for me to pull, and things for me to try, I am happy to fight to get to the solution!
• I often think about the beauty of “the 10 blue links” with Google Search. If the best result is 3rd on the list, I don’t think of it as a failure at all… I am still very happy with Google. Contrast this with Google Assistant or Alexa… where there is one result. If it’s wrong, trust is eroded quickly. I spoke about this with Malte Ubl of Vercel, and how smart it was when the original v0 would show you multiple versions from a prompt so you could pick one. If 3 of the 4 were meh, but one was a solid starting point… great! Always have a next step for Pat.

#3 Take care of the toil so Pat can be doing the work that Pat can uniquely do best.

#4 Raise the level of abstraction: Let Pat talk to the system in a way that matches their skills, and allow translation. If Pat is expert with Rust and the backend, build confidence that they can dive into parts of the mono repo that are built with TypeScript because the guardrails are there and the details of syntax etc aren’t what is important here.

#5 Build trust with Pat. Show the sources and explain WHY the system is doing what it is doing and allow Pat the ability to jump around and learn more. Transparency is key. Let Pat change the context the AI has and re-run things so they can tinker and iterate to the best possible results.

The AI SystemNow we have the AI system you are building. Broaden the view here and think of it as the overall computer system that happens to have AI components:

• Think of this as somewhat infinitely scalable compute. You probably wouldn’t take an issue from your project tracker and farm it out to 6 developers on your team and then when they each send back a PR pick one you like to iterate from, but with AI you could decide to do that.
  • Now imagine how the UX of a system can change. It can go off and come back to Pat with multiple options and Pat can happily curate and pick a favored one to iterate from!
• Some developers complain that current LLMs are “only junior developers”. Let’s say this is the case… but LLMs are trained on so many domains of computing that they are junior developers who know EVERY programming language, library, framework, platform, etc. This is amazing. Oh, and they ain’t no junior developers to boot.
• By default they have this incredible broad knowledge but it’s like they are showing up on their first day and they know nothing about your domain. Fix this by connecting them with all of the context they need!
• AI has no feelings, and thus is happy to do toil. Do all the toil all the time.
• AI has no ego, so won’t be a jerk to Pat and is a safe space with no judgement (unless you make the AI act like a jerk ofc! Don’t.)

With this acknowledgement, you can make sure that your solution:

#1 Eval driven development: First, make it work, then make it fast and affordable.

Once you prove something out you can use synthetic data and fine tune models for particular tasks that are cheaper. Oh, and everything is getting cheaper month by month. There are new models all the time, so build a platform that can make use of multiple ones and run them against each other. You will always be surprised at which models are best for particular tasks. Don’t bet on one, bet on evolution and enjoy the ride.

#2 Tools: Give this LLM “brain” tools to wield.

Don’t rely on the model to do deterministic things when it can just use tools. We are now seeing some of the SoTA LLMs do internal calculations to decide when to use tools vs. just solve the problem directly. Great. But think about what tools are most useful and put them in reach of the LLM. Do the dance of working out when your system should be the meta-cognition agent vs. when to let the LLM do its thing. It’s a fun dance to learn.

Noam Brown, who worked on reasoning tokens and the system in o1, was talking about this for many years, such as this talk, that discusses how neural nets without special pathways are vastly inferior. Computers really got good at chess (and then Go etc) when they added search and started playing themselves.

#3 Data: Use large LLMs to generate great synthetic data. Your system should be saving data to learn from and feed back into the system to improve the AI all the time. What your AI and Pat are doing is gold. Learn from it. You will be very surprised.

#4 Smart Context: With large context windows and smart retrieval, you can make sure they have the best possible information to work with to get something done. Think about all of the signals you can give them… build output, runtime errors, you name it. And if you don’t have enough space to give them all of these signals what can you do? Run multiple parallel versions that have different signals passed in and let Pat choose the best results… or another AI judge!

And now we are seeing SoTA models looking to integrate external data via protocols such as Anthropic’s Model Context Proposal. It’s fun to see the experiments here.

#5 Cheap Experiments: you need to be able to run experiments all the time. I remember talking to one of my favorite AI researchers who worked with Dario from Anthropic back when they were at Google, and something stuck with me:

• “It wasn’t that Dario had the best ideas, although he had plenty… he just ran 10 to 100 times as many experiments as anyone else. That’s when I knew he would do amazing things.”
• If you hear yourself or your team saying “oh, it will be hard to try that” take a step back. Invest in a platform that makes it easy to try things.
• I’ve always been humbled to see the difference between how I think something will turn out vs. how it collides with reality. With LLMs, it’s even harder to know. Try things and allow emergence to be your friend. Imperical wins the race.
• Don’t be precious with your prompts either. Over time I have seen that models have gotten better at understanding plain language vs. magic spells and incarnations. Let people play with the prompts and have that be great because your eval framework will allow for that nicely. Don’t gate keep here.

So, here we are. We are building and iterating on a system that gets the best out of developers, and the massive scale of compute, with the new technology of transformers with the fluke of GPUs gives us an epic opportunity to build amazing things.

Shall we?

View Details

tl;dr I’m thrilled to announce that I’ve joined Tessl, a new company that’s pioneering AI Native Software Development. Founded by Guypo and fresh off securing Series A funding, we’re on an exciting mission to revolutionize how software is built.

I’m especially excited to be reuniting with Ben as we focus on the opportunity to create a platform that makes software development not just more efficient, but genuinely fun and enjoyable for developers at a time where everything has changed with the new AI tools in the toolbox!

It has been amazing to watch the progress that AI software developer tools have been making, and being part of the rise of augmentation for developers. I have seen first hand the impact on the lives of software developers as they are able to get so much more done with small teams, having much more fun to boot.

As I watch myself, and developers in general, use natural language to generate code… something has been bothering me a lil. It feels like the “source” of what you want to build gets lost as our tooling converts it expertly into our codebase.

What if we could keep this original intent, expand on it to specify what we want built… work hand in hand with our team and AI systems, and then regenerate assets as the LLMs get better at generating code? (which happens on a weekly basis rn!) What if we could separate concerns and have passes that make sure that the code is optimized for performance? Is accessible? Covers edge cases? Has rich debugging? Let me focus on clearly articulating what I want, and have systems that can do a lot of the toilsome yet important actions to make it work, make it right, and make it fast.

If we extrapolate on the improvements we have seen in the state of the art of coding models, and marry this work with systems that bring all of the guardrails and workflows that are needed to partner with the intuition that LLMs have, how far can we go?

I love coding, and when I think about why… It’s because I love thinking through building useful software. Back in the earliest days, after you think things through you start punching cards. Then we had machine code, and assemblers, and compilers, and linters, and IDEs, and all of the layers of tooling that we get to sit on top of today. We have always been changing the level of abstraction to allow developers to best specify, or take specifications from others perhaps, and generate working software.

Ben and GuypoThis is a huge challenge, and I got really excited about it after talking to Guypo and hearing his vision in this space. Ben and I were fortunate enough to invest in Snyk and see the sea-change in developer focused security that Snyk brought to the software world, so having the opportunity to jump on a rocket ship with something as large as the AI software revolution was a no-brainer.

The most fun I have ever had in my career has always been linked to partnering with Ben, and now we get to join forces with Guypo, and the incredible team he has assembled, to go change the world through leading AI Native Software Development.

It’s daunting and exciting, and the mission is larger than the products that Tessl will build itself. This is actually one reason why I was so compelled to work on this. I’m more drawn towards companies that are on a mission, where the company makes money in order to accomplish the mission rather than the other way around.

I hope that you join us in pushing the bar on what the future holds for software development. We have just begun, but with a great team and a war chest, we are ready to move mountains and do so fast. Time to build… with AI!

/fin

View Details

When I look back at my career, the most fun and fulfilling times I have had has been tied to impactful projects with a team that is clicking. This has often happened at a startup, but it has also happened in some magical moments where the team is able to move fast and with agency within a larger company.

How often have you heard, or thought, the following?:

Remember when we were small? We moved so fast back then.

What if you could stay small and nimble, but get so much more done?

One core philosophy that DHH has often discussed as a key part of The Rails Way, is how it scales from a single developer. From Hello World to IPO. The way to do that is to be able to do more with less, and keep as much of the system in your head as possible. Allow room for the important pieces, and keep complexity from taking up valuable space.

When we come up with new infrastructure that compresses the complexity, we see amazing scale such as what the WhatsApp team was able to build with a small team.

I believe AI native tools can help here in a slightly different way. For example, you can somewhat outsource some of the complexity to the system. The brain budget can be augmented, and some of it can be swapped in, in real time.

This is an area of AI that I am particularly excited about, and I am seeing it occur in practice every day with customers at Augment.

When talking to one customer that is startup sized, they said:

We are growing like a weed, and I was nervous that we would have to grow the team… which scared me. I love our tight-knit crew and how we have trust and minimal coordination issues. But since using Augment and other AI tools we are finding that our work isn’t scaling linearly… we are so productive that we don’t have to grow to meet feature demand. I hope this lasts as long as possible!

This resonates a lot! I have seen the coordination headwinds first hand, and anything that you can do to minimize them will result in HUGE productivity gains… and will also give you more joyful moments.

How are AI tools helping?I think that the following properties are compounding:

More than “faster typing”It’s easy to think about features such as code completions as a way to speed up typing. Speeding up typing is just the start. The next step is taking care of raw toil and tedium, but where savings really kick in are when the suggestion brings you something that you maybe didn’t necessarily know what to write. I love it when this happens, especially when it teaches me something new about the codebase or another way to do something.

No more “Reading the docs”The LLMs have read the docs for you, and much beyond. They have read your code, and that of all of your dependencies. They may have consumed knowledge from other sources (Linear tickets? Slack channels? PRs with comments?).

Instead of hunting down documentation, you can use features such as Chat to ask questions that map to your exact task at hand. You can personalize responses (maybe you want a terse reply, or the opposite?). And having help that maps to your context means you aren’t translating between the examples that happen to be in the docs.

Saving time not just for myself, but for my teamI hate interrupting my coworkers when I am stuck. Now the first line of defense allows me to stay unblocked by working with Augment. This can save a ton of “clock time” when my coworkers are busy… or on the other side of the world!

This doesn’t mean I don’t want time with my colleagues, but it can be focused on working together on more novel and creative problems.

Confidence working across unfamiliar codebasesMaybe you aren’t as experience in Rust and have been nervous to touch that part of the codebase. You don’t have to worry as much about the idioms of the language, and you can use these tools to help you learn as you use autocomplete functionality and chat to act more declaratively.

This flexibility is being noticed, and “full stack” is morphing into the rise of the “product engineer”:

Many argue that front-end engineering is fading due to AI tools, but I see a convergence of roles.

Front-end devs can now generate schemas with tools like @supabase’s https://t.co/ZWMGf6cVj5, while back-end devs can scaffold UIs with @vercel’s @v0.

This is the rise of the…

— Kenneth Auchenberg 🛠 (@auchenberg) September 18, 2024

This also works when your team has to interact with another team at a larger company. You may not have to wait for the work to be done by them, and instead can dive in and collaborate to get something done!

From code completion to task completionCode completions are still a favorite feature. I feel like I am dancing with my AI partner and quickly iterate and steer. But we are now seeing the ability to share your intent at a higher level, and have new UX that will quickly help you get a full task done. I’m very excited to share what Augment has been doing here.

Think you can keep your A-Team?Now, I may be biased… but I think the best way to keep the A-Team together is to have a developer AI platform that has the deep codebase and external context awareness to act like you are working with the experience of your entire team vs. a knowledgable engineer that knows the basics. The difference is night and day, and I get very happy thinking about smaller teams with super powers. I hope you do too!

And maybe you will have the type of outsized impact that 13 employees did at Instagram, or 55 at WhatsApp, or 50 at Mojang (Minecraft), or if you are truly lucky… Donald Knuth with TeX?

(I was thinking about TeX and Professor Knuth again when Matt Holden recently shipped TexSandbox, a tool I wish I had in my Math courses at Uni!)

View Details

Manchester City just became the first team in history to win the Premier League championship four years in a row, with the chance to win the FA Cup this coming weekend. They are a dynasty, with 6 premiership wins in the last 7 seasons and many other trophies including the coveted Champions League.

I enjoy looking at sports as an analogy to business, and watching Pep Guardiola manage his team to success whilst making constant changes definitely hits home with what I have seen at my companies over the years (and what I haven’t seen!).

Long Term SuccessI have seen two extremes when it comes to building a great team.

• Extreme 1: Hire the best people and let them do their thing
• Extreme 2: Build the right systems and the rest will follow

I have come to learn that the best long term results come from multiplying the two in certain ways.

When I look at what Manchester City have done for this long term success, it stems from a large number of ingredients, many of which are flywheels to each other.

RecruitmentThey are constantly bringing in amazing talent into an already high quality and substantial squad. They never rest on their laurels here, with the example of Doku coming in right after Jack Grealish to have strong backup and competition on the left flank. Always Be Recruiting.

The Money MachineRecruiting great players requires funds. The financial fair play system in the premier league is a joke, but requires that you are getting revenue in every possible way (sell those t-shirts!) as well as selling players wisely. Man City has the highest wage bill in the league, which means it has the best chance to have the best squad. How can you recruit top talent?

Setting The BarThe culture has to drive everyone to be the best they can be, as individuals helping the overall team. Senior players need to show new players what good looks like, and how they need to work to reach it. Manchester City players work their arses off on the field. They don’t sit there with ego and think they can do anything else, which happens with some clubs and players who think they are the bees knees.

The right mix of senior and junior is critical, and the changing room is where a lot of things get worked out. The manager doesn’t do all of the work, a lot happens through the senior players!

How is the bar set on or across your team?

Style Of PlayTeams have a “style of play”, and clubs such as Man City and Liverpool do a fantastic job of driving this though out all levels. When you have your academy driving this style into the youngsters, they have the best chance to break through into the first team. We saw this when Liverpool won the league cup this year with many of their academy players starting due to a huge number of injuries.

How are you defining and driving a style of development throughout the company?

Individual vs. Team TacticsWithout a style of play framework you still need room for tactical tweaks depending on the individuals in the team and their strengths, as well as the opposition that you are up against.

The style of play is so strong, that many admire the fact that even when Erling Haaland and Kevin De Bruyne were injured, Phil Foden and Julian Arvarez fit right in to continued success. They are very ers.different players, and Pep tweaked the system to make sure the overall team was setup with these players in those positions. This is where the art comes in.

How are you balancing a team that can flex as personnel come and go, and making sure that individuals bring their strengths?

Time to PeakA season is long, and just as the best trainers have their horses peak for the big races, you need to think about keeping the team healthy over the long term, and knowing when you need to peak. For example, when I was at Walmart, we knew that Black Friday and the holiday period wasn’t going to move for anyone. ~80% of all revenue comes in that period, and thus we need to be ready for that time. Elsewhere, you may have Conference Driven Development or other deadlines that you feel you need to peak for. Manchester City famously makes sure that they are close enough to strike in April, and finish through the posts really strong. What is your cadence and how do you stay a healthy team?

Aligned to the goalsHow do you stay hungry? After the third premier league how does the team get up for putting in all of the work that they know is required to start again? You need to align the purpose as much as possible. Does your team know why you are all gathered to do this work and why it is important?

Where I have seen things gone wrongI have learned through mistakes and observations where one of the extremes has been ignored to ill effect.

All people, no systemsAt Walmart, one of my regrets was how I didn’t make sure that certain systems were in place. This resulted in far too much hero culture, and when the heroes moved on, there wasn’t resiliency in place to be able to handle things. We hired great people, but didn’t have a system for the long term.

All systems, not thinking peopleI am now seeing many mistakes when it comes to layoffs that are far too much about systems and ignoring the fact that the humans involved aren’t all equal.

I recently spoke to an engineering director who had 35% of their team laid off, but with the “good news” that they have the HC back but only for hiring L4s in India. They didn’t have a say in who was leg go, and shockingly it included some of the most productive members of the team with deep knowledge locked in their heads.

Instead of giving full ownership to a team in India, they now have to deal w/ managing with a team across many time zones. Penny wise, pound foolish. I am so curious why leadership is giving “Strat Ops” teams spreadsheets to normalize wrt HC.

I know of other leaders who play with config files that allow them to change the wingspan of a manager to reports ratio. No nuance allowed.

I am excited to make sure that at Augment we grow at the right pace, and work to have the talent density that allows smaller teams do more, and cut out communication costs and hierarchy that massive teams often cause. One of the reasons I am so excited for what we are building at Augment is that I really believe it can help keep teams small by allowing the conscious creatures the ability to do what works best for them, with help from our 24/7 available computer systems.

Durable Success = The Best Set Of People * The Right Evolving Systems

View Details

I’m incredibly excited to share that Augment, the company I joined to help empower developers, has come out of stealth.

With a lot of FUD around AI taking all of the knowledge worker jobs, including those of developers, I believe it is important to get across the counter argument:

“Don’t fire Kevin for Devin just yet. Augment Kevin with super powers!”

Me

If you think about what software engineers actually do and what AI excels at, you should reach the same conclusion. It’s easy to anthropomorphize AI tools, especially when you’re chatting with them and considering their portrayal in science fiction. With that in mind, I believe in creating systems that resemble J.A.R.V.I.S more than HAL.

As we develop these systems, it’s essential to remember that humans and computers have unique strengths. The real magic happens when humans take charge, supported by ever-present, fully connected computer systems.

By doing so, we can not only improve life for developers individually, but also empower teams and organizations to accomplish much more with reduced toil and communication costs.

I’m passionate at doing my part to help here, and I want to share my journey to Augment with you.

Seeing the future of software developmentI love programming. Whenever I write some code, it tends to be a good day. There is something about the creative process that ends with something tangible that is good for my brain. Any platforms, tools, or services that allow me to stay in that certain flow of development become favorites. There is an art to taking an idea, breaking it down, and making progress.

The longer I am on the path to running code that works – or getting effective help back onto the path when it isn’t working – the better I feel.

On the flip side, whenever I am doing something that feels like toil, or I feel really stuck, the worse I feel.

There have been a couple of times when I saw how AI technology could dramatically help:

• I worked with a research team inside X at Google who built models (in the pre-LLM/transformer days) that could help the highly skilled SWEs keep up with the constantly evolving monorepo. This was often very boring work, ripe for a computer to help.
• I worked on a project at Shopify that uses LLMs to bridge the complexity of GraphQL for developers wanting to integrate with merchant data. This quickly taught me lessons, such as:
  • It’s easy to show a cool (somewhat contrived) demo
  • It’s hard to build something great that works at scale in the real world
  • One LLM isn’t the answer for all use cases
  • It’s not just quantity… quality data matters
  • Having a system that can really do well wrt evaluations is vital as you iterate

Projects like these gave me the evidence to see how software engineering is going to radically change in the future, and pairing AI technology with developers will be the driver.

Meeting the Augment teamI was sold on the opportunity that this AI wave could allow us to help developers in new expansive ways. I started to explore, and this exploration lead me to chatting with a couple old friends, Luke Wroblewski and Sam Pullara who are building companies at Sutter Hill Ventures, a pretty unique VC firm.

Luke and Sam grinned as I spoke about my desire to build for developers with AI, and quickly introduced me to the founders and team behind Augment.

I met Guy Gur-Ari, the co-founder leading the research efforts at Augment. He had already assembled a team of AI researchers and engineers who had many years of expertise with ML and how it can be applied to code. This was important to me, as I had found that to build something truly great, you need the ability to make changes across the entire stack. You want to be able to change the engine along with the other parts of the car!

Igor Ostrovsky, the other co-founder and pioneer of Augment, also gave me a lot of faith that we had the broad technical expertise to pull this off at scale. His proven track record with distributed systems as Chief Architect of Pure Storage, developer focused work at Microsoft, and his deep dive into AI as an entrepreneur in residence with SHV was inspiring.

Then I discovered that Scott Dietzen had joined as CEO. I first met Scott at the birth of enterprise Java, where he was CTO at BEA WebLogic, my favorite app server of choice.

As I met the broader team, I had a strong feeling that this was a team with the focus, experience, and skill to take a shot at building the best AI platform and ecosystem for developers.

The team had gone deep in building foundational technology that is needed to solve the meaty problems that developers have, especially at scale. These include building a system that:

Has an expert understanding of large codebases

There are solutions out there that feel like you have access to a system aware of core technology. They have a solid understanding of programming languages, and popular frameworks.

When using Augment, we want you to feel like you are working with the joint intuition of your most seasoned engineers at the company, and those with deep expertise on the dependencies that you use.

Any suggestions need to reflect the APIs and coding patterns in your company’s code so your team can use it on your actual day-to-day work.

Produces running code

The custom AI models and infrastructure are tuned for code and coding use cases avoiding frustrating hallucinations and focuses on improving code quality… not just productivity.

Operates at the speed of thought

There were many search engines before Google, but I remember trying it for the first time, and seeing how the experience was a step change. The quality of the results were next level AND the speed to return them felt different.

Working with LLMs can be a lil… slow, which massively degrades the experience and can keep knocking you out of flow.

The team had built a fast inference — 3x faster than competitors — built on state-of-the-art techniques, including custom GPU kernels, and I felt the difference in the experience.

Supports multiple developers & teams

Software development is a team sport. There are so many areas where technology can help scale and improve the use of best practices across a team, help you learn a complex codebase, and get new engineers onboarded faster.

The scale of computers allow a system to attend to do much more, and they are available 24×7.

I have learned the power of small teams. We have seen with early customers that the shape of teams can change when you deliver the right capabilities. If we can enable smaller teams to do more, and for teams to do more in parallel, we result in better software and happier devs to boot!

Includes strong IP protections

Your company’s source code is precious. Augment was designed from the first line of code for tenant isolation, with an architecture built to protect your IP.

Try AugmentJoining Augment has already been a blast. Moving at startup speed with a great crew all focused on helping developers is a dream come true for me. I feel very fortunate to have the opportunity to go after this problem space with a small (but growing! Join us?) team.

We are heads down delivering on our promise, working closely with early access customers, who have been a key part of our product development thanks to their fantastic feedback (thank you!).

We are furiously working our way to a public product launch that we can’t wait to share.

Until then, if you are interested in kicking the tires early, please sign up for the waitlist!

View Details

tl;dr LLMs give computers new abilities to be better partners for us humans, and if we build the right systems we can transform how we work together. I have learned some lessons on the building side, but also on how to do more as an augmented human to get the most out of this new world!

A dream stirred me from my sleep. I found myself on the set of ‘Dancing with the Stars,’ but with a twist: my partner was not human, but a robot. As I lay there, half-awake at 3am, I pondered the meaning of this mechanical ballroom dance. Then it clicked… it was a metaphor for the work I’ve been deeply immersed in at the close of 2023: creating computer systems that augment human capabilities, giving developers and their teams superpowers in software delivery.

The DanceI’ve always believed in the power of combining the best of both worlds: human creativity and computer precision. The best user experiences have always weaved brain and tool, these days including those that are digital.

LLMs have changed the game in that precision has a brand new capability: a new layer of intuition that we can tie to. A way to combine my Systems 1 and 2 brain with a mesh of combined thought. Back in the dream, my subconscious was painting a picture of the ideal partnership where the human mostly leads, and the machine follows in a tightly choreographed back-and-forth. Just like picking up a tool such as PhotoShop, it can still take time to master the steps, and the dance changes as the capabilities change. How can we best use the strengths and weaknesses of each partner so that they work as one?

Crafting the Perfect PartnerI’m currently iterating on a dancer that developers can shape into the best partner possible. Speed and skill are crucial. A slow computer is like a dance partner with two left feet, disrupting the flow and making collaboration frustrating. Skill, on the other hand, is about quality and finesse—leading without stepping on each other’s toes, sharing knowledge to maintain the rhythm.

The Car and the EngineI was excited to join a Sutter Hill Ventures startup for many reasons, and my expectations have been very much exceeded. Not only do we have a solid financial backing that allows us to really focus on building a game changing product and business, but the support that the Sutter Hill team has is special. I get to work with my favorite UX person there is. The enterprise sales playbook is ready to run. And on and on.

The team itself (founders, CEO, and everyone else!) is not only world class, but there is a strategic bet that I strongly believe in for building the absolutely best product. The heart of the team has AI researches who deeply understand every part of the stack.

It’s one thing to build a car using someone else’s engine; it’s another to be able to fully tinker with that engine or even build your own.

In 2023 we have learned so much as a community. First we had the transformational moment when developers got to poke at what could be done with OpenAI APIs (and then so many more). There was the prompt engineering, RAG’ing, and pushing the boundaries of what’s possible.

Embracing Constant ChangeThe model tier is just the beginning, and going from demo to a production system requires a world of work to be done around it.

New models and research are popping up on a daily basis, so how do you filter out what could be helpful? How do you determine its utility for your specific needs? How do you ensure your data is accurate and current? Are your evaluations truly reflective of quality, or are you just fitting the last piece of a puzzle?

MetricsMeasuring what matters here is hard. For example, with coding tools, I often see discussion around the amount of codethat is created, or the Completion Acceptance Rate, but when you watch this play out in practice with your users you realize…. wait a minute…

Do we want to always be creating code if it’s adding entropy into the system? If that code is iffy, and if the human can’t tell, then maybe we are adding problems. And, wouldn’t it be nice if we maybe could… delete code and simplify?

For completion acceptance, I can get very different results by changing the system to vary the amount of code that comes back, or the latency, and many of the habits that you build with the developers. The habits have been really fun to watch. Seeing cohorts that start by waiting for the system to do things vs. communicating more and moving quickly.

And when I do side by side comparisons, I see the huge difference where one system can have a hire acceptance rate that ends up with code that doesn’t run. Don’t I really want to be tracking time to running code that is high quality?

Here’s to 2024We are somewhere in the journey that is akin to constant improvements that we can see with other tools such as Midjourney.

I’m grateful for my team’s collective ability to build everything needed for the ultimate coding dance partner. We are building the platform that enables the building of this partner, to iterate on it, to take in the innovation from open source and our own research, and man I’m having a great time doing it.

I can’t wait to share it with more of you. If you’re a developer who spends most of your day coding, enjoys giving feedback the moulds a product, and are interested in getting early access, I’d love to hear from you.

Happy New Year, and may this become true!

Prediction: 2024 will feel like a breakthrough year in terms of AI capability, safety, and general positivity about its potential impact. In the longer term, it'll look like just one more year on an exponential that can make everyone's lives better than anyone's today.

— Greg Brockman (@gdb) December 31, 2023

NOTE: Of course, this article was written by both Dion Almaer and the dancer within Type.

View Details

tl;dr as a middle aged bloke with subtle near-sightedness, the juice may not yet be worth the squeeze getting LASIK!

I walked into a LASIK exam room just over a month ago and in a comically short time I walked out again with different curves in my eyes. If I could go back, I would probably not go through with it.

This isn’t the story of an operation that went shockingly wrong. I’m not blinded. The outcome was a success, but it oddly feels net neutral or worse.

I’m writing this as something I wish I had found when researching the procedure, as I feel a lil sheepish that I didn’t understand where I would be on the flip side. The information is out there, I just didn’t see it.

I will walk though:

• What was the state of my eye sight before?
• What was the state after surgery?
• What about now?
• What do I hope for?

NOTE: I am obviously not a professional and this is just one account from a layman on his experience in the hope that it may help someone go a lil deeper on their knowledge gathering!

What was the state of my eyesight before?I have been wearing glasses since I was a kid. I was nearsighted (right eye: -1.00, left eye: -2.25 at my worst) with a slight astigmatism to boot.

While I wore glasses, I was far from blind without them. If I wasn’t driving or reading I would be fine without them. On vacations I noticed that I would go without glasses for a significant amount of the trip.

My eyesight changed over the years, and most recently it improved when I lost weight. I would see changes that mapped to my blood glucose levels. I fluctuate here, but the range is much smaller so my sight has stabilized along with it. As a bloke in his later forties, I knew that I had a future where I would need reading glasses, before I hopefully get to the cataract period where I get lenses put in. Or by then maybe something even cooler? 🙂

I have had friends and family get Lasik surgery over the years, and they (almost) all raved about it. So many of them spoke on how much of a game changer it was to their life.

I was waiting for some stability with my sight, and then when yet another friend had it done and bemoaned why they waited so long I decided to look for a great surgeon and see if I was a good candidate.

After being checked out, I appeared to be a great candidate. The changes needed were minor, and I have a thick cornea which seemed to be a good thing (and would allow for potential fixes after the fact). Monovision was briefly mentioned, where one eye is correctly for long and the other for near. This seemed interesting, but I was somewhat pushed off of this as an option saying it compromises driving and other situations.

So, I ended up signing up. On the day of the surgery there was one concern that my brow projected and the neaderthal genes that 23andme told me about may mean that it would be hard to get the suction cup in place. I was told that if that was the case they could switch to PRK instead of Lasik, but I wasn’t ready to make an audible on that given the length of time it takes to recover from PRK. I do note that in the pre-op setting I was often told how many of the surgeons themselves opt for PRK and think that it’s a much safer option (no flap and all that). But still, Lasik or bust for me.

They were right about my eye socket, and had to really push it in there to get the suction. This was the only part of the experience that hurt at all… and it wasn’t that bad. 30 seconds of suction and then I got to see the light show for just a couple seconds… it was nothing! Then to the other eye. After taking the chill pills I found myself outside and ready to go home and sleep for a few hours as I had been instructed to do.

What was the state after surgery?After a lot of sleeping and eye-dropping I noticed that my long range eyesight was amazing already. My eyes were a lil scratchy but really not bad at all. Already! I was excited.

But then I picked up my phone and realized I couldn’t see a thing unless I used my arms to make the phone and my eyes be as far apart as possible. I also had the halo scattering around lights at night time. Oh well. It’s early. I went to my optometrist for the “day after” check in.

This one day check up told me that:

• My left eye was over corrected, and I may have to go back and have a change done in that eye
• It’s only day one, so be kind to myself, and let me eyes heal
• It’s dry in Colorado. Keep those eye drops coming!

I then started on the purchase of what would become many different eyeglasses. I got some readers, so I could …. read again. I then went on to order sunglasses, bifocals, progressive multifocals, halfmoon glasses, computer glasses… thank god for these websites with great cheap glasses to try, such as Zenni!

What about now?I am now just over a month into my new eyes. I have been to my one week, and one month appointments.

As my eyes healed, they have continued to change. My far range is like 20:10 and I feel like an eagle. My left eye changed and isn’t over corrected, so I won’t have to go back for any changes (hopefully!).

My short range? It’s improved, but it’s still a bit of a frustrating experience.

Before, I could pop out my phone and read it without my glasses. Everything was kinda OK, even if blurry, and then my glasses were progressive enhancements. When I go for a swim, I don’t need my glasses so I just swim away. I put on my glasses for the day and everything is good… until I fall on my arse playing pickleball and my glasses fall.

Now, whenever I reach for my phone I need to plop on some goggles. With progressives, I can flip back to wearing glasses most of the time, but then I am back to where I was? Ok.

I knew that I wouldn’t be done with glasses for ever, and that my age would soon resort in reading glasses. I just didn’t appreciate that my near-sightedness was helping here, and that DUH by getting that taken care of would zoom me into a future of not being able to see things close up as well as I could before!

So, I kinda wish that I had either:

a) gotten LASIK a long time ago and thus had more of the benefit before my eyes were old

b) not gotten it yet, and just kept going… and bumping up progressive lenses with age.

What do I hope for?It’s still one month in. Maybe my near sightedness will improve a lil (as it has done over the last month). I have ordered some killer progressives that I am excited to try… and will probably back up to wearing them most of the time, but also changing to readers and computer glasses when doing deep work, and at least I can go without when I play sports!

I will consider monovision in the future, either using my thick cornea… or maybe at that cataract time, and will learn more about the true pros and cons.

All in all, it’s obvious, but you really do often end up jumping between far and near… especially with phones in your pocket?

/fin

I will update this a few months in if something has changed!

View Details

I love my layer cakes, and recently spoke about layered design systems that allow for developers to jump in at the layer that makes sense for them, and allows for maximum emergence of value.

When building a layered platform, I often think of the world of Lego and how utterly fun and creative that universe is. I aspire to enabling developers in the same way.

I mentally split things up into the concepts of: blocks, sets, and kits.

BlocksLego blocks are the base level primitives that exist for the platform. They offer clear capabilities, and have interfaces that are as universal as possible.

On the interface side you have the way the the tubes on the bottom interlock with the studs on top of other bricks. This standard allows the composability of the majority of the blocks. It’s all about the interlock and the spacing.

For capabilities, you get the specialization on top of these interfaces. Think of the engines that can be connected to the car systems to make them drivable. That engine can also be composed in a multitude of ways to deliver force for many ideas.

In our world of software, we have the same thing, with interface glue such as props with React, JSON for formats, HTTP for networks, and so on. Then when you look at a platform such as Cloudflare, you see that these are composed with infrastructure blocks such as D1 for databases that speak the language of Workers, R2 for distributed object storage, etc.

Blocks compose with other blocks. Almost anything can be created from this, the lowest of layers. And when you create a new primitive that fits the interfaces, creatively can explode with the possibility.

SetsStarting from first principles, from the lowest level of blocks, can be overly complex. In practice, someone can build the next level of abstraction that solves a problem and can share it with others.

These are patterns, or recipes, or… Sets. With Lego, you most often see people buying sets with instructions on how to build a collection. I remember getting instructions with many ideas that I could reuse blocks to create with.

In software we often see this grouping of capabilities in various frameworks, that come with their own instructions on how to put things together. At other times you see templates, where you have a starting point of blocks to give you a strong leg up. Vercel does a great job of providing these, making it easy to start building on their platform.

KitsThere is a slightly different form of abstraction on top of blocks, and that is kits. These are meant to be for a particular purpose and are more restrictive that sets. The blocks and setup fit together much better (are less blocky!) and you wouldn’t take the parts of a kit and use them to make something different.

In software, an extreme case would be a proprietary language with components that only let’s you build extensions that look and feel like the platform they run on. A kit would make sense if you wanted to be very restrictive on extensibility, and you value making it as easy as possible to do certain things, and hard to break out.

You only really want to codify kits when you are very sure that they are very common and useful. If you have a scenario where many people will want to clone and tweak, you may be on to something with a kit.

There are many valid cases for kits, but it is also true that too often companies make the choice to over-invent. It is so very tempting to create a domain specific language, or even a custom programming language. But first, consider codifying constraints using languages and platforms that many developers have spent the time to learn already, where there is community, and answers, and where AI tools have something to have been trained on 😉

You can poke and make fun of English, in the same way that you can do so with JavaScript, but there is a reason it is still thriving whereas Esperanto isn’t.

Can you see the blocks, sets, and kits in your platforms? Are they well layered?

NOTE; My good friend and “one of the best platform engineers I know”, Dimitri Glazkov, has written about these layers from a slight different lens in his great piece: 4 layers.

View Details

As I use LLMs to help me build software I keep running into situations where there is a missing piece and leverage point, that if injected will dramatically raise the quality of creation: subject expert turtles. Let me explain via a recent experience: a web app framework migration. Framework migration: switching between Next.js and Remix […]

View Details

Management is a story of hill climbing. I started to reflect on this more while thinking about football management, a task that fits into more finite game theory.

With a Ted Lasso season running, and Manchester City winning a third English Premier League title on the trot, I hope you won’t mind a discussion of the best league in the world. It has triggered thoughts on how timelines and risk aversion ties to management.

The premier league has 20 teams, and this season a record 12 managers have been given the sack. The stakes are particularly high due to the workings of the hierarchy of leagues in the english soccer pyramid, as shown above.

ASIDE: The term soccer was in fact invented by the Brits! It came from associated football vs. rugby football. I’m not just being a yank!

The Premier League is known for its fierce competition at the top of the table. However, there’s more at stake than just the coveted top spot. The top four positions in the league standings grant entry into the prestigious and lucrative European Champions League. Additionally, teams that finish fifth through seventh may qualify for the Europa League or Europa Conference, depending on various factors such as winning the FA Cup or previous Champions League winners. While there are numerous edge cases, many top places in the league are highly sought after, making for intense competition throughout the season.

Then you have the bottom three positions. If that’s where your season ends, you are doomed to go down a division, known as the Championship. Financially, your lose out on all that the premier league offers (TV rights et al), and it’s such a sudden drop that you get an parachute payment to help soften the blow. This leaves a small middle of the division that doesn’t have to sweat too much. Things were in fact so tight this year that teams in positions of 12 to 20 were all fearing a drop. Hence the firings.

Compare this to franchise leagues such as the NBA, MLS, MLB, or NFL. If you have a bad season you get to regroup for the following year and, in fact, you may even have incentives to do worse if it means getting better draft picks!

↑↑↑ This is Graham Potter. He only lasted 9 months at Chelsea before becoming one of the 12 to go. He was heralded when he left Brighton and Hove Albion, where he had built an amazing system. The recruitment was fantastic, and he had a flywheel that would follow this pattern: bring in new players for ~cheap => bake them into the system => other teams buy them for !cheap => repeat. I can’t tell you how often they would sell a great player for great money, and you would fear that the team would struggle… yet it seemed to somehow get better as someone would stand to be counted.

He joined a Chelsea operation where they had spent hundreds of millions of dollars, with long contracts (to get around the fair play rules), but weren’t playing like a team at all. No system to be seen here.

Picture yourself in Graham’s position. The clock starts ticking on day one, and you need to climb your first hill. There is pressure to show results quickly, and you need to find which players work well together, and under which system. 4-4-2? 3-5-2? What are the patterns of play? Do you use a low block? It goes on and on. So much money has been spent on the squad, and the individual players have quality, so expectations are sky high.

↑↑↑ This is Alex Ferguson, the best manager in the history of the premier league (or is it now Pep Guardiola? 🤔). His first few seasons weren’t great, but times were different and the Manchester United owners stuck with him and his system.

He could take time to explore the hills. How can he get the most from his squad? How can he recruit to fill the gaps and mould the squad to the system he wanted?

Without this time, todays managers are stuck having to quickly pick a hill and run as fast as they can to the top, with a huge probability that it is a very local maxima.

Another topic that every new manager will have is: do you go against the traditional style of play of the club you join? change it to your style? or create one that maps to the players?

↑↑↑ This is David Ginola, who personified the traditional swashbuckling style of play of Tottenham Hotspur. Despite the team not having won any silverware for several decades, the fans have still been able to enjoy exciting, entertaining end-to-end matches.

The last three managers to join Spurs have not followed tradition, and instead employed a much more defensive base. When the team sees success with this change, the fans will grumble but hold their tongue, but as soon as it isn’t working… look out.

Ok, enough of this footy talk, how does this apply to management in tech?

Just as I fear for how little time football managers get to find the biggest impact, I often fear the same in corporate life. You often see a ~2 year re-org cycle, especially when there are trade offs around focus.

ok i couldnt resist pic.twitter.com/qGojGjcVkb

— swyx (@swyx) May 12, 2020

Pendulum vs SwitchbacksOne common example is: when do you centralize a function vs. when do you group functions in a business unit? If you are in a function that feels the pendulum you are always waiting for the change. When don’t wrong, you feel like you are oscillating between two very known states without any learning.

When done better, it is more like climbing a spiral case, or switchbacks as swyx would say. This is where you take the strengths of each approach and bake them into the learnings.

Let’s take Developer Relations. When I rejoined Google in 2015, there was a centralized function. All tech writers reported through a functional tech writing chain. The same was true for developer advocacy, developer platform engineers, developer programs, partnerships, and more. Time was spent into solidifying what it mean to be great at these roles. On the flip side, if you thought of yourself more a part of the domain that you worked on, you weren’t as attached to the product and engineering world there. Consider yourself an Android expert as a Developer Advocate? Now you are in a hierarchy of DAs. How do the Android DAs, DPEs, Tech Writers, PgMs all coordinate? There was a special role to try to help bring things together. It was a tough role!

One of the first things I did was to switchback, and have one Android DevRel team, and eventually it went back into the Android product area itself to attach and integrate even closer with the teams there.

When joining a team as a new leader or manager, you have to make some decisions. After taking some time (hopefully!) listening the team, you will be working out what changes are needed. If you feel a rush to show impact, you may rush up that first local optima hill.

Through my own errors, I have learned to:

• Listen to the natural feel for how orgs work at the company
• Listen to the core problems your teams are facing, and think about potential solutions
• Make some calls on what change solves real problems.

I am loathe to go against the grain of the company unless a) things are really broken with the approach, and b) I have a strong conviction that it’s time to actually create a new default for the company. I don’t want to flip flop, nor do I want to make changes that are surface level just because I am used to them.

If I was going into Spurs, I would very much lean into creating a Spursy team (hopefully breaking the mould of the losing!). When Manchester City got radically new management at the start of the 2000’s (and have allegedly done a fair amount of cheating I may add!) it was the perfect time to make a big change and create a new identity. The club needs to buy into this, and needs to allow the hunt for a better global maxima by giving the new leadership time.

The new manager bounce

Well, lcfc’s managerial bounce lasted 5 minutes.

— Gary Lineker (@GaryLineker) April 15, 2023

Well, lcfc’s managerial bounce lasted 5 minutes.
One of the other reasons for the flurry of sackings is the myth of the “new manager bounce”. The theory is that the players will have some hope, and maybe will fight for their places more with someone new in charge. If the old manager had run out of ideas and left the team with no confidence, and the incoming manager has a series of fresh ideas, this can work! It doesn’t seem to be the case in practice.

Maybe the same happens in the office. I don’t know about you, but I feel like most of the reorgs I have seen are too frequent, and don’t occur when the ideas are dry. In fact, whenever you have a reorg you spend a lot of time revisiting items such as the strategy, the plan, and how you work. You require time to do the forming of the new way, and it takes time to get into your new stride. At times, a reorg has happened seemingly RIGHT when things were starting to click and execution was cooking with gas.

Too often real life feels like the CEO and the three envelopes joke.

Be thoughtful as a new leader, or a boss to a new leader, and make sure that everyone has the time to make sure they aren’t climbing the wrong hill.

/fin

View Details

So often, when building a design system, we end up building something rigid that we will struggle with as time goes by. When this is done, we can try to evolve it well, and to make it so good that developers are somewhat happy with it even if they don’t like the rigid choices that were made.

This happens in all eras. Most recently, you will find many design systems that are React design systems vs. Web design systems that offer idiomatic React as an awesome option. As soon as you have made that choice you have locked in an audience and a lot of option value is taken off of the table.

Let’s consider that you are building a design system at a company that is on the path to becoming a 100 year company where you aspire to think long term. I contend that it makes sense to build your design system in layers that:

• Have the wiggle room to move independently
• A layer can even be replaced
• Developers can swap out layers, especially those higher up in the stack

If I were holding a React design system today, and I was offered the opportunity to go back in time, I would swap it out for a layered Web design system.

What would this look like?

Let’s quickly talk about these layers.

Design foundational layerModern CSS can do so much these days. Start building out as much of the design system as possible with HTML and CSS. Components that used to be complex nested can not be a with some sprinkles. If you want some inspiration, check out the fine work of folks such as: Adam Argyle, Una, Jhey, and Josh W. Comeau.

Here you create your helpful guardrails via design tokens, your low level primitives, and your higher level components. I would consider using something like Adam’s Open Props as a strong foundation.

With some exploration, you will probably find that this layer gets you quite far these days, and with a nice story book playground developers will love to tinker as they learn it.

Interactivity layerNext up you can loosely wire up the pieces via custom elements. This should be a relatively thin layer that brings to full life. You can choose a helpful tool such as Lit or Stencil to make it even easier.

These components run on top of the Web Platform, and are thus incredibly future proof.

Framework layerSome developers will happily take the custom elements and use them directly, but most will probably want to use some bindings that feel idiomatic in the framework of their choice. There is no need for a holy war of “Framework vs Web Components!” They can happily work together these days. In fact, tools such as Lit have wrapper tools to make it easier to take your components and vend them as idiomatic framework components such as React.

Reach, Value and Future ProofingWith this approach you have set yourself on a solid long term path. Your work can now reach web developers that are choosing a variety of frameworks. If there is one thing we know about the web, it’s that there is healthy innovation and evolution on this layer. We can’t predict the future, but we both know that there will be new frameworks with significant developer share AND there will be a ton of apps running React and jQuery and … for some time. Both are true, so why not support both?

Now, you may be thinking: “We aren’t resourced to support all of the items in the framework later!” This is often true, however you don’t have to support them all, you can choose levels of support, such as:

• First class / Well lit path: you make sure yourself that everything fully works end to end using code that you write and maintain.
• Community support: with a well lit path or two out there, the community can take a look at the end to end solution, along with the layer below that it relies on, and create their own idiomatic bindings. The more you document the first class stack, the easier it will be for the community to take high quality code, with tests, and a spec of sorts and build something of high quality themselves. Make sure to elevate the work and effort that they put into it!
• Individual usage: if there isn’t a library itself, a developer using their framework of choice can just use the custom elements to build on. Chances are one of these will jump up to the level of community support… especially if you incentivize and foster this.

I don’t know about you, but it feels like we are in a frothy time for the Web framework space. React has an army of developers, but there is some confusion on which direction to go. Will RSC fully pan out? When should you use Next.js or Remix?

This shines through when you see videos showing up putting forth points of view such as always bet on react! and I don’t hate react, i’m just moving on. It’s a time of change, right when there are amazing non-React options such as Solid, Svelte, Vue, Preact, and more. This is healthy, and having written web applications with more different frameworks than hot dinners that I have consumed, they can all help you deliver something great for users. So, it’s kinda win win.

It does make you think about…

Learn in LayersSome wanna-be-gatekeepers have poo poo’d developers who come in and learn React first, and often skim some of the knowledge of the Web platform. There’s no need for the gate keeping, and this can be a great starting point.

That being said, I have always been a believer in Glen Vanderburg’s philosophy that it’s very much worth your time to understand one layer of abstraction below and potentially above you.

This means that you should have a solid understanding of the Web Platform APIs, as well as the core technology of JavaScript, CSS, and HTML. Often this naturally bleeds through, and although we are sometimes taught that a good abstraction doesn’t leak, some of the best abstractions are known as onion skin APIs when ”leaking” becomes a feature, an escape hatch.

ActiveRecord is a great example, where SQL isn’t hidden from you. Git has long built layers where you have porcelain and plumbing.

My good friend Dimitri has recently written about porcelains in the context of how we changed the API of Polymath with respect to talking to OpenAI. Instead of abstracting all of the fetch calls, we embrace the fact that developers probably know fetch well, and may want to use advanced features. We instead vend an API that understands the service via a request and response, so you end up with something such as:

While there has been a lot written in the form of “Web Components vs. $FRAMEWORK”, you find that this is totally the wrong frame. There are a variety of Web Platform APIs in the umbrella of Web Components, such as Custom Elements and Shadow DOM. If you take the time to learn this layer, you may find reason to use it with your web framework of choice. And if you do so, this knowledge will be durable no matter what other frameworks you use now and in the future. The browser moves slowly, and these APIs are here ~forever.

I recently worked with a team that deliver a high quality design system that is tied to React. If I could go back in time I would switch to this layered system in a second. It pained me to talk to developers that used the platform that the design system was used for but hadn’t chosen React. They want to deliver the same look and feel for users, so what do they end up doing? Many would view source and copy HTML and CSS and add interactivity. That’s a LOT of toil, and they have to keep up with changes in a painful manner with lots of diffing. If they could grab the lowest level, or maybe the custom elements with it, they would be off to the races in a sustainable manner.

Others felt they had to use React for these pieces, and hired consultants to do that work. This ate into their profits, and in dire situations could change the entire ROI of their solution (for small apps with a one or two person team).

I believe this design system will iterate and change over the lifetime of this company, that aims to be a 100 year one. You could argue that they are big enough to always make sure the React version is solid and updated and that developers have resources to keep with it.

Or, the evolution could happen at each level of the stack. Long time developers would understand the lower levels, and as they changed the highest framework level, they would be able to reuse that knowledge, use a community layer, or maybe the company has changed the first class framework and can use that solution.

If you have a modern design system, learn from my mistakes, and build it in layers.

That way a developer that chooses a different graph of tools from the subset of the options as Kent shows here, versus your exact path (which you will change too in the future), can play too.

/fin

View Details

I’m flying to Google I/O at Shoreline Amphitheater, a place that holds many great memories of times with teams and developers.

I wanted to come in person (thanks for the invite from certain Googlers… you know who yo are 😉 and once again unite with everyone.

I was nervous about the pandemic putting a dagger into the heart of in person events. When forced to be online only, we learned a lot about how to make that experience great, embracing the positives, such as crazy high production values and not having the constraints of:

• “the person on stage” and often in one location (other than when we did Google Developer Day around the world on the same “day”)
• The phenomenal reach and accessibility
• The ability to measure
• The reduction in cost.

Yup, events cost a lot of money, however if you consider the entire cost, such as everyone getting ready and building content, it isn’t like online events are free! Far from it, I have seen online event budgets that surpass those of in person!

One of the problems with in person events is that it kinda is hard to measure their value fully. It is my believe though, that a great event, with the right people there, can have a massive impact.

Reach is online, but deep connection and trust building can be 10x in real life. I remember my early days of JavaOne and rushing back to the hotel to try something out and bring the learning and opportunity back to the company and community. I felt an incredibly tight community, with information sharing going a mile a minute.

It’s great to find new developers and bringing them in to your community, and that first time at a conference may do that for you. I was just speaking to a founder that went to their first conference and even did the “old fashioned” booth thing. They were incredibly skeptical that there would be a positive ROI, but when all was said and done they left with new developers excited about their offering, which they saw in a large increase in traffic to their website, and actual adoption of their product.

Bringing in new developers, making sure their onboarding is frictionless, and getting them ramped up, is important. But, it’s hard to overstate the importance of feeding the inner circle of your ecosystem. These developers are your external advocates. They are shipping and growing today. They deeply know how your platform works, often more-so than many of your internal hires!

Even in the pre-pandemic days, magnitudes more people would watch the content online than in person. It’s not about having huge numbers at the event, it’s about having the right folks there new and old.

Getting together to maintain a full trust battery all around is very much worth it.

I’m looking forward to filling mine up at Google I/O. See some of you there!

/fin

View Details

Don’t leave him behind, or with a jump that’s just too far!

Nothing is static. The world is moving, and it’s the job of a platform to help an ecosystem evolve at the right pace.

When the pace is good, as the screen moves right, Mario sees where he needs to jump next and can time it well. It’s fun to be in the flow jumping from improvement to improvement!

When the pace is too fast, Mario feels stuck and either disappears off screen, or does a Hail Mary jump without a real chance to land on the next platform, falling into fire in bowsers castle.

Platforms need to treat the time that developers have to spend on evolving alongside us as precious. They should strive to minimize their toil, keeping a high level of trust with the developer community.

What are the keys to success here? How should we, as platform owners, drive things? This post will detail:

• Understanding the use cases
• Building enough of the new platform
• Having everything we can to help you get there
• Sharing pieces early
• Starting the deprecation clock appropriately
• Staying close to the platform
• Do you need a new platform?

Researching use cases at the libraryUnderstanding the use casesWe need to understand Mario’s needs and why it will be better for him to be on the new platform

When bringing up a v.next of a service, the platform needs an understanding of what the current version is being used for. A new version is shipping for a reason, and there should be clarity on basic questions such as:

• How will developers be able to deliver the functionality they are offering?
• Are there any capabilities that are not offered in the new version yet and what is the impact?
  • When options are restricted, it’s obviously a different set of timing should be considered
• When will replacement capabilities show up (in the cases when they do)?
• What are the new capabilities that we will be bringing to developers and what will they unlock?

Seems blindingly obvious, but having deep knowledge here is far from universal, and past decisions are often lost, not allowing us to apply Chestertons Fence.

Gymnast landing on a platformBuilding enough of the new platformWe want the new platform wide enough that Mario can stick the landing

With a strong understanding, the new platform starts the journey of getting built and iterating. It’s vital to make sure that we have an appropriate amount of it built out before sharing it with the developer community. With a minimal surface area, you are at risk of not finding enough information and thus ending up making large changes in the future, and developers are left touching a small part of the elephant and extrapolating the rest.

The more we can get the new version in close range, the better the chance we have of enticing Mario, and having him get across to the other side with a cheer.

When building the new platform, we should also make sure to do a good job with our layering. As we do this, Mario will not have to learn new things for each part of his journey, and will instead accrue understanding. Great layering also means that we will be able to compose our solutions better, resulting in less churn as we make changes. This should result in fewer massive migrations.

Mario with a JetpackHaving everything in place to help evolutionWe want to give Mario jet packs and tools to make the leap

When making these platform changes, we are often placing toil on developers. Hopefully, there is much value too, but there will often be times where the changes we impose have a strong overall ecosystem value, but maybe not always the same value for the individual developer. The tragedy of the commons are real, and we can recognize this by going above and beyond with our help for developers.

What does the jet pack look like?

World class documentation on the why and the how. This is foundational, and includes great reference docs, tutorials & workshops, and samples & solutions.

World class tooling, where developers live all day long. Linters and codemods that give clear guidance and nudging on what changes are needed. With everything that it changing with development right now (e.g. AI copilots) imagine how far we could take this? Why can’t we have a future that has platform help in our developers code editors giving suggestions, and sending PRs to GitHub with changes that keep their projects up to date. If we did this right we could change the feeling from “ugh I feel like I am constantly being nagged to make some change! $PLATFORM understands that I have features to write and a business to run!!” to “Wow, $PLATFORM is helping me keep up to date and improving my app! I can see the improvements, and merchants are loving it!”

Mario looking into the futureSharing earlyShow Mario a glimpse into what’s coming up in the level so he can prepare

The window can be pretty small for Mario, and it can be helpful to offer a view of what’s coming, as long as we aren’t flooding him with information (see: building enough of the platform!).

Depending on what kind of changes we are doing, we may be able to allow developers to play with the future pieces early.

Remix does a great job of this. It allows you to opt into future flags, and then when the future becomes the present, you are ready for it!

How does that work? Let’s look at an example. Remix 2 is coming out soon, but the changes and new features are coming online in a way that you can opt in your Remix 1.* application today. The way that you name routes and their mapping with the file system is changing from this to a new system that includes flat routes.

Instead of waiting for Remix 2, today I can update my app with a couple simple steps:

1. Tell my v1 app that I am ready to use the new feature via a simple declaration in my remix.config.js:

future: { v2_routeConvention: true } 2. Update my directories and files to map to the new system

When the feature is ready, communicating it could ramp up over time. You can start small and see a few early adopters find it and offer feedback. Recently the dev server started to console.log the fact that it’s ready, reaching more developers, and more feedback can flow in.

When Remix 2 ships, those who opted in will be able to delete the future flags and everything will just work. Now picture this for a larger number of flags. I can opt in and then I will be fully ready, finding myself on the next platform without even jumping… I just kept walking and got there.

The two roads of deprecationStarting the deprecation clock appropriatelyDon’t disintegrate the current platform too early!

You know those blocks that fall away when Mario has been stood on them for a bit? I hate those. They mean I have to think really quickly, anxiety rises, and I make mistakes and fall to my doom.

While it can be great to share information on the new platform early, as discussed, we should be careful when choosing when the clock starts ticking on deprecating the existing platform.

NOTE: A recent example of this was OpenAI deprecating the Codex API where the team maybe didn’t quite appreciate that although other APIs had somewhat transcended it, the work to make changes is real. To their credit, they got feedback and changed the deprecation by at least allowing longer access in the research program.

The clock shouldn’t start until the entire new platform is built, and we have the jetpacks ready. There have been times in which we build piece A of the new and deprecate the equivalent piece on the old. The problem is that the developer can’t actually migrate everything over, and they can become stuck.

In general we should cluster our changes and have clear times for most of our developers to do upgrades (the ones who aren’t jumping early to changes).

And we should be very careful not to end up in the situation that the meme shows above, where the new platform isn’t ready and the old one is deprecated. It’s so common to as often be the norm, and we need to fight entropy to change this.

I always somewhat appreciated the fact that I could schedule time after a major iOS SDK release to update our apps. The business understood this, and we had the space to make this happen in one chunk, and get our new app into the app store ready for the consumer releases. Contrast this with a drip, drip, drip of being asked to make small changes constantly.

Very thin bricksStaying close to the platformFavor the lightest abstractions that aren’t proprietary. Developers should be spending their time learning the platform, not new technology for the sake of it. For example, before creating a proprietary layout system that every developer has to learn, can we use CSS with our own special variables and styles and a sandboxed container to limit it? Or instead of creating a custom abstraction to fetch content, how about using the standard fetch(), even if you have to monkey patch it to add in specific auth, just make sure it’s well tested! No uncanny valley here please. Let developers bring their skills, and StackOverflow and ChatGPT along with them.

Mario on a relaxing walkDo you need a new platform?Mario would be happy to walk along and maybe take some stairs?

Before falling for second system syndrome, double and triple check that the right path forward is a new platform at all, or if there are smaller steps that can be made that over time will get Mario where he needs to be.

Respecting developers timeLet’s treat the time that developers have as a precious commodity. It actually takes work to stand still, as there is no such thing as stable. Browsers are changing. Libraries and SDKs and tools are changing, and we add to that. The more we can do to minimize it by putting in work on our side, the more leverage we get across the ecosystem. We want them spending as much time as possible on amazing features for our merchants, and jumping their way to success along the way.

🍄 Let’s a go! 🍄

/fin

View Details

Midjourney hallucinates scissors and housesI used to be the type of chap who has one place for everything. The scissors are in That Drawer in the kitchen. It kinda worked, until I had to live with other humans that I didn’t have control of.

After years of fighting against the system of “one place for every thing” I went full in on the other direction, I think inspired by reading Algorithms to Live By, and Brad Fitzpatrick’s work with Perkeep. Since then, I have taken the opposite approach to a single source of object, and instead I put items in many places, ideally where they would be used. This is why I now have scissors all over my house, or screw drivers, etc. “All over” is going a lil far, I put them in spots where I think they will be used. This is akin to a CDN… caching a copy closer to where someone needs it.

Why am I talking about scissors?I went through the exact same kind of transition in the virtual world. Where do I keep my data? I would try to centralize it as much as possible. E.g. Google Drive as a source of truth, and then split off for types of content that weren’t a fit (e.g. I used Asana as a central database for a long time, and 1Password for passwords, and Active Recall for learning, and Type.ai for writing, etc).l

After years of trying new systems, and migrating data, I took the other approach:

• I embrace the fact that one system won’t be perfect, for now, and especially the future
• I don’t worry about migrating data as I try new things. I jumped around with Roam, Obsidian, Logseq as an example. Once a lil more settled, I may then do some migration
• I favor products where I can get to the data (yay owning your data)
• I favor products where there are strong integrations. Instead of a central merge, I can then connect all of the things and have the data show up in all of the places

But how about finding things? Integrating into one search to rule them all is vital when you have data in various spots. My latest foray here is, importing all of my second brain into my own local Polymath with access control.

Now I can use natural language to get semantic search results, each with links that poke me to where the data is. Often it’s in multiple spots so I can choose what I want to open up to see and use that data.

There is so much opportunity for us to get to a collective, with integrations, and allows us to evolve and connect our data.

View Details

Creativity & Constraints, Foundations & Flywheels

The developer community is buzzing around the new world of LLMs. Roadmaps for the year are getting ripped up one month in, and there is a whole lot of tinkering… and I love the smell of tinkering.

At Shopify we shared a new Winter Edition, which packaged up 100+ features for merchants and developers. Some of the launches had a lil Shopify Magic in them, using LLMs to make life better for our users.

I had a lot of fun, shipping something for developers that used LLMs, and I thought I would write about a few things that I learned going through the process of getting to shipping.

The mock.shop homepageWhat did we ship? mock.shopWe want to make it as easy as possible for developers to learn and explore commerce, by playing. We wanted to take as much friction as possible from being able to explore a commerce data model, and build a custom frontend to show off your frontend.

This is where mock.shop comes in, it sits in front of a Shopify store, but doesn’t require you to create one yourself. Just start playing with it and hitting it directly!

One thing we have heard from some developers is that they are new to GraphQL and/or new to the particulars of the commerce domain. We show examples, and the GraphQL and code examples of how to work with it, but could we go even further?

Gil seeing mock.shopGenerate query with AIWhat if you could just use your words and ask us to generate the GraphQL for you? That’s exactly what we did. And here’s what we learned…

Foundations & FlywheelsWe used OpenAI for this work, and when working with LLMs you are working with a black box. While GPT3 had some knowledge of GraphQL, and Shopify, it’s knowledge was out dated and often wrong. Out of the box you are working with anything that the model has sucked up, and you can’t trust this data at all.

You need to do all you can to feed the black box information so that it can come up with the best results. Given the black box, you will need to experiment and keep poking it to see if you are making it better or worse.

Here are some of the foundational things that we did:

Feed it the best inputGather all of information that you think will nudge the model in the right direction. In our case we gathered the GraphQL schema (SDL) for the Shopify storefront APIs, and then a bunch of good examples. With these in hand, we would chunk them up and create OpenAI embeddings from them. You end up with a library of these embeddings, which are vectors that represent the chunks of text.

With these embeddings we can take user queries (eg. “Get me 7 of the most recent products”), get an embedding from that query, and then look for similar embeddings from the library that you have created. Those will contain snippets such as the schema for the products GraphQL section, and some of the good examples that work with products. We call this context and you will pass that to the OpenAI completions endpoint as part of a prompt.

Customize the promptYou will want to play with prompts that result in the right kind of output for your use case. In our case we are looking for the black box to not just start completing with sentences, but rather give back valid GraphQL.

You end up with a prompt such as:Answer the question as truthfully as possible using the provided context, and if don’t have the answer, say “I don’t know”.\nContext:\n${context}\n\nQuestion:\nWhat is a Shopify GraphQL query, formatted with tabs, for: ${query}\n\nAnswer:

You can see how the prompt is:

• Politely asking for the answer to be truthful
• Nudging for the answer to be tied to the given context (from the embeddings) vs. making it up from full cloth, and saying that it’s ok to say “I don’t know”!
• Asking for a formatted GraphQL query

One other way that we try to stop any hallucinating from the model is via setting the temperature to 0 when we make the completion call:What sampling temperature to use, between 0 and 2. Higher values like 0.8 will make the output more random, while lower values like 0.2 will make it more focused and deterministic.

It’s quite funny to see how we do everything to try to get the model to speak the truth with this type of use case!

Feedback and FlywheelsNow it’s time for the flywheels to kick in. You want to keep feeding the context with high quality examples, sometimes show what NOT to do, play with different prompts, and start getting feedback.

You will see lots of examples where users are asked for feedback. E.g. in support systems and documentation: did this help? is it accurate? To train the model as best as possible, you can look for ways to get this information from the experts (humans!) and feed it on back.

Creativity & ConstraintsWe have the foundations in place, and the quality of data will improve through the flywheels. Now it’s time to get more constrained. We are doing all we can to nudge for truth, but you can’t trust these things, so what guardrails should you put in place?

We really want the GraphQL that we show to be valid, so… how about we do some validation?

We take the GraphQL that comes back and we can do a couple things:

• We would tweak it, when possible, to place valid IDs and content, for the given dataset that we have in the mock.shop instance.
• Validate the GraphQL to make sure the syntax is correct
• Run it against the mock.shop, since we have real IDs, and show the results to the user!

You can’t assume anything, so you often will have to have a guard step once you get results.

ChatGPT vs. StockfishThere was a lot of hubbub when someone pit ChatGPT vs. Stockfish in a game of chess. Many used it as a way to laugh at ChatGPT. This thing is crazy! It did all kinds of invalid moves! No doy! You have to assume that and build systems to tame it… a chess engine wouldn’t allow invalid moves.

DefensiveYou have to be incredibly defensive. You are poking a brain with electrodes. It comes out with amazing things, but you can’t trust everything that comes back. Making remote calls to OpenAI itself is flaky, and often goes down.

Now only will you be checking for timeouts and errors in results, but you should consider a feature flag toggle. In the case of mock.shop, the tool is usable without any of the AI features. They are progressive enhancements to the product.

We can add checks to automatically turn it off if something really bad is happening with OpenAI. Marry both:

const openAIStatusRequest = fetch("https://status.openai.com/api/v2/status.json"); and check the results for the type of incident:

openAIStatus.status.indicator === "major" It’s incredibly fun, getting creative with how you can use the power of LLMs, which are getting better and faster all the time. The black box nature can be frustrating at times, but it’s worth it.

I hope you are having some fun tinkering!

https://polymath.almaer.com/There are so many helpful libraries out there. I have been working with some friends on Polymath to make it simple to import and create the libraries, as well as query it all.

View Details

Don’t sit and wait, get tinkering!We are almost at the end of the first month of 2023, and you are working on executing on the year’s strategy, but we are witnessing an explosion, hopefully a Cambrian one, in front of our eyes… Generative AI.

I wrote about how it can be a helpful tool for us with respect to documentation and beyond and we are seeing changes every week as we learn what works and what doesn’t.

Gil making GraphQL more approachable!We are seeing developers jump on this, playing with ideas such as commit bots, app generators, ways to generate backends, IDEs, and so much more.

First Gear? Why Now?There is so much promise, people are already using these tools, so instead of sitting on it and being conservative, now is the time for us to jump in and get into first gear. There is always a fear of being too early into a hype cycle, but the reason I think the time is right is that you see people getting value today. I have been coding with tools like Copilot and ChatGPT and it’s helpful enough that I wouldn’t want to go back to the Before Times. Does it get everything right? No. Is it great for all of my development needs? No, it’s not as good as it should be.

Training all of my content, and being able to query itWhat does it mean to get into first gear now?:

• Be thinking about use cases that you can start trying. I have been building things such as:
  • Using embeddings to bring a chat/search interface to our docs and samples.
  • Discord bots to start answering questions
  • Super-codemods that help you upgrade, and generally help you build
• Build small experiments that one or two people can execute on and start to validate
• Build a core competence in the technology, so you can quickly go from ideas to experiments

In first gear you have the pedal down, and a driver is quickly accelerating. This is a technology that is changing fast, and is all about tinkering. Get tinkering.

When do we move to second gear?You will learn so much through these experiments. What actually works, what doesn’t, and what needs more tuning and tweaking to be valuable. If things are going well and we see how efforts are impacting our key results, you can ramp up and shift more effort into this work. That would be a sign we are seeing something somewhat revolutionary.

But wait, isn’t this a fad? Are we being sheep?Maybe it turns out that this isn’t as big of a sea change as many imagine. I have been very skeptical of recent webN hype in the past few years, and I don’t think that Gen AI is a silver bullet of any form. I am well aware that it hallucinates, and gives wacky answers at times. However, as mentioned above, I have already witnessed great value, and we have truly just started. I believe it can offer UX improvements for our developer community that are substantial. Sometimes you have to take a calculated risk. Worse case, you learn, and provide some much desired feature food along the way.

/fin

View Details

We can do so much to help tech writers scale their efforts and help developers learn!

I know, I know, the current hammer du jour is “GPT for X“. It behooves us to explore how a promising new technology can help us, and I believe there are two large reasons we should do so:

• We (industry wide!) need all the help we can get to scale quality developer docs, so using these tools to help anyone writing the docs be productive is hugely valuable.
• Developers are already looking at products like ChatGPT3 and asking questions of them. Currently the quality is variable depending on what is being used and the corpus that’s been available in the time window. We need to make sure that usage results in useful high quality output.

Helping produce quality developer docsEvery developer product or platform runs into the struggle of keeping high quality documentation up to date and comprehensive. It’s hard enough to execute on reference docs, let alone conceptual docs, tutorials, etc.

There is a resourcing issue at the heart of this:

• It is very hard to hire great technical writers, because they need qualities such as:
  • Highly technical like an engineer
  • Able to explain and teach concepts
  • Write well.
• Most (but not all!) engineers aren’t comfortable with taking on the writing aspects of their APIs
  • To scale, engineers, product managers, and developer advocates are needed to take on certain aspects of their docs (just can’t hire enough tech writers!)

GenAI isn’t a silver bullet, and no one would suggest we let the machines generate our documentation, but rather it can be a tool for the humans that do the writing!

• As you write the docs, you can get various examples from a GPT-like engine that you then refine. ChatGPT3 is able to do a solid job at some of these tasks already, and is only going to get a lot better.
• To take it to the next level, you can use techniques to refine such as few shot learning, fine tuning, or chaining so the engine can bias towards your view on best practice for whatever you are documenting. E.g. we can train on existing docs, sample code, etc.
  • Imagine including the ecosystem here too. Any great examples of content can be included in the training corpus. Just as some open source projects include the test suites from popular ecosystem libraries to make sure they aren’t broken in CI, you can do the same for content.
• It will be great to be able to bring in not just knowledge, but also style and tone. It’s fantastic to unblock writer’s block by throwing raw content down and having the tools work for you. There are already tools that let you do things like:
  • Summarize this for me
  • Give me a good heading / title
  • Make this more concise
  • Flush this out with code examples
• Boilerplate and grunt work… be gone.

These tools can give confidence to those who aren’t professional writers, which is huge!

Beyond docs, towards assistive learningHelping create fantastic docs is itself a huge win for developers getting the most from your platform in a productive way. I just saw Codesphere sharing some results after they took the time to tune their docs.

But this work goes even beyond improved docs for devs.

You are now able to use the LLMs that have been tuned to your platform in other ways:

• A chat interface for your platform knowledge
• Get questions that target the knowledge that developers can use to train themselves
• Integrate with popular IDEs so the information is there right where they are coding
• …

Every day we see new examples of this, such as docs search like this:

There are a lot of challenges to go along with the opportunity, but it isn’t hard to imagine a world where you are pair-programming with Shopi and working with the GraphQL APIs is so much easier because of it, or Hydrogen components are being written for you that you can take and tweak, or converting from tech A to B is made trivial, and sooooo much more.

The tech is only getting better, let’s get on board now!

What do the bots think of this idea?!?It felt appropriate to ask our robot friends for some of their thoughts on the topic, and here are a couple things that emerged:

Challenges of Automation in Technical WritingAs with any automated process, there are certain challenges that come with using GenAI in technical writing. One of the primary challenges is the potential for errors due to the automated nature of the process. While GenAI can help streamline the writing process, it cannot always guarantee accuracy. Additionally, GenAI may not always be able to capture the nuances and complexities of human language, which can lead to misinterpretations and errors.

Another challenge is the potential for bias in the automated process. GenAI relies on the data that is used to train it, and if the data is biased, then the output of the process can be biased as well. This can lead to incorrect or misleading information being generated.

Finally, there is the challenge of cost. GenAI can be expensive to implement and maintain, and it may not always be feasible for organizations to invest in the technology. Additionally, there may be a need for additional personnel to manage the process and ensure accuracy.

Benefits of Using Machine Learning in Technical WritingDespite the potential challenges, there are several benefits to using GenAI in technical writing. One of the primary benefits is the potential to increase productivity. By automating certain aspects of the writing process, GenAI can help streamline the workflow and reduce the amount of time spent on manual tasks. This can help to free up time for more creative and complex tasks.

Additionally, GenAI can help to improve the accuracy of the writing process. By leveraging the data used to train the system, GenAI can help to ensure that the output is consistent and accurate. This can help to reduce the amount of time spent on manual proofreading and editing.

Finally, GenAI can help to reduce costs. By automating certain aspects of the writing process, organizations can potentially save money on personnel costs. Additionally, GenAI can help to reduce the amount of time spent on manual tasks, which can lead to cost savings in the long run.

Integrating GenAI into Existing Technical Writing ProcessesIntegrating GenAI into existing technical writing processes can be a great way to increase efficiency and accuracy. By leveraging the power of machine learning, organizations can potentially reduce the time spent on manual tasks and improve the accuracy of their documentation.

However, there are certain challenges that must be addressed when integrating GenAI into existing technical writing processes. One of the primary challenges is ensuring that the data used to train the system is accurate and unbiased. Additionally, organizations must ensure that the system is properly managed and monitored to ensure accuracy and prevent errors.

Finally, organizations must also consider the cost of implementing and maintaining a GenAI system. While the potential benefits are great, the cost of implementing and maintaining the system must be weighed against the potential savings.

Overall, integrating GenAI into existing technical writing processes can be a great way to increase efficiency and accuracy. However, organizations must ensure that they address the challenges associated with the process and consider the cost of implementation and maintenance.

Measuring Success when Using GenAI in Technical WritingWhen integrating GenAI into existing technical writing processes, it is important to establish metrics for measuring success. This will help organizations to determine if the process is working and if any changes need to be made.

One of the primary metrics for measuring success is accuracy. Organizations should track the accuracy of the output generated by the GenAI system and compare it to the accuracy of the output generated by manual processes. This will help to determine if the GenAI system is providing more accurate results than manual processes.

Another metric for measuring success is efficiency. Organizations should track the amount of time saved by using the GenAI system and compare it to the amount of time spent on manual processes. This will help to determine if the GenAI system is providing more efficient results than manual processes.

Finally, organizations should also track the cost of implementing and maintaining the GenAI system. This will help to determine if the cost of the system is worth the potential savings.

Overall, measuring success when using GenAI in technical writing is essential for determining if the process is working and if any changes need to be made. By tracking accuracy, efficiency, and cost, organizations can determine if the GenAI system is providing more accurate and efficient results than manual processes.

Developing Best Practices for Using GenAI in Technical WritingAs with any new technology, it is important to develop best practices for using GenAI in technical writing. This will help to ensure that the process is efficient and accurate, and that the output is of the highest quality.

One of the primary best practices is to use data that is accurate and unbiased. This will help to ensure that the output generated by the GenAI system is accurate and unbiased. Additionally, organizations should ensure that the data used to train the system is regularly updated to reflect any changes in the industry.

Another best practice is to ensure that the system is properly managed and monitored. This will help to ensure that the system is functioning properly and that any errors are quickly identified and corrected. Additionally, organizations should ensure that personnel are properly trained in using the system and that any changes to the system are properly documented.

Finally, organizations should also consider the cost of implementing and maintaining the GenAI system. This will help to ensure that the cost of the system is worth the potential savings.

Overall, developing best practices for using GenAI in technical writing is essential for ensuring that the process is efficient and accurate, and that the output is of the highest quality. By following these best practices, organizations can ensure that they are getting the most out of their GenAI system.

And engineer and a robot working together to create better docs./fin

View Details

I often see the same debates occur, especially around web technology. One pattern I see repeated in these debates is how focus is often on the efficacy of a certain technical approach (or tool or library or…) and the practical effectiveness is ignored. What the eff are you talking about? Before we get into web […]

View Details

As I sit here watching WWDC, I get that same feeling. Everything is vertically integrated. The layering of the SDKs, with much that is shared, and then differences for iOS vs. Mac vs. tv, etc. You can’t hope but look at the Web and think “oh man, the paradox of choice over here… with so […]

View Details

I was excited to see Kenneth and his team ship the public beta of the Stripe App platform: I was excited to dive into it, as I know that the developer experience would be high quality, and I wasn’t proven wrong. Great CLI experience. Great docs. What you have come accustomed too. As I read […]

View Details

I have been working with a great friend on a learning tool that gives you super powers, and I am very excited for it to launch today. I have been dogfooding it for some time but it’s also just the beginning of the journey to help people succeed through learning and retaining knowledge. The tool […]

View Details

You hear about the developer who created Wordle, or who went on to found a large company, or contributed an open source project to the commons. You don’t often hear about the agency developer, and they are both important and often on their own journeys. The Value of Agency Agencies, and consultants, are out there […]

View Details

tl;dr By staying close to the Web platform, web developers can use all of their web knowledge, and use the latest features as they become available. There is a difference between using the web platform vs. web technologies, a subtle difference I have seen in the past. If we are doing it right, anyone can […]

View Details

From Hello World to IPO tl;dr We often talk about how Shopify supports entrepreneurs from the first day of their journey building a business all the way to huge merchants that grow to become unicorns, or go public, and are just plain successful. Now it’s time to show the role of developers in helping this […]

View Details

It’s my first Thanksgiving and Black Friday at a commerce company since my time at Walmart Labs. It’s always a reflective time and I found myself thinking about the initial months at Shopify. You never really know what a new place with feel like, no matter the process and time you get to spend during […]

View Details

I have been fighting for investment and focus on developer productivity for a large part of my career. Platforms often focus on the user side more, and think that the focus should be on solely economic opportunity. Understandably, if you can’t persuade a business that their effort will result in profit, you won’t get resources […]

View Details

I am excited to share the news that, after a lovely summer break post-Google, I have taken a new job at Shopify. My mission focuses on helping developers succeed at delivering amazing, diverse, commerce experiences. Why Shopify and this mission? It turns out that my career journey has set me up for this moment. I […]

View Details

What would do? 🤔 The Web can continue to evolve by taking the long term view and chipping away with adding necessary functionality, and eliding some of the mistakes (albeit hard). However, I have been pondering if we should be exploring some bigger bets: First, looking at certain verticals (content, commerce, apps) and […]

View Details

Progressive Web Apps aren’t reaching their potential at scale. I just spoke about how I think it’s important for the Web to push on its own vision as a platform, but as a universal app platform (one of the key segments, along with content and commerce) it isn’t hitting the mark, mainly on mobile. What […]

View Details

Alex wrote primarily about the role of the App Store in his opus on the pursuit of appiness. It has a lot of deep thinking, and I particularly like how Alex takes apart the distinct pieces that make up the App Store experience, as I find they often get glommed together: Security screens to prevent […]

View Details

I should have drawn it the other way so you can “Take the L!” I have seen a path walked repeatedly in platform land.

If you are fortunate enough to have a large spectrum of experiences running on top of your platform, you start to think about prioritization of the platform and you get caught.

Since you are a platform, it’s natural to focus on … you know… the platform! Isn’t it obvious that a platform is horizontal? Your levers are at that layer, and thus you should stick to it. Stay low. How low can you go?

But as experiences emerge that you hadn’t thought about in your wildest dreams, you start to wonder 🤔. You feel disconnected from the end users. There is a large gap, which is filled in by the experiences running on your platform, and you wish you had more influence.

I know, forget this horizontal jazz! It’s bloody hard to keep all of the plates spinning any way, and you have read enough Seth Godin to know to focus on your loyal die hard users…. it’s time to think vertical!

It feels good. A simple focus. Now….. which vertical do you pick? 🤔…. picking ONE is really hard, as there are several important verticals. You start to cross off a couple verticals that while interesting, aren’t the most aligned with the success of the platform and what you are great at enabling. It feels good to whittle it down a little, but then you get stuck.

You don’t want the future of your platform to just be a subset of these verticals. What do you do?

I’m sorry to say, that you need to do both. You need to think horizertically.

This means:

1. You acknowledge what your platform is uniquely good at, and you focus on horizontal functionality that grows your distinctiveness
2. You build out vertically in some key areas, working closer than ever with some key partners, using their needs and your joint experience to help prioritize some of the horizontal components
3. This is the work. No partner will hand it to you on a platter, and it’s unfair to expect that from them. They are naturally silo’d. You can learn from them and map solutions that work at a platform level to support them.

You end up doing less horizontal work, pack more into the needs of some of the verticals, and you differentiate your platform to boot.

View Details

We need to talk about taste on the Web. There has been a lot of talk about nutrition, and making sure that you have all of the tools you need to understand the nutritional content of your website, which we call Web Vitals.

Web Vitals numbers are certainly vital, but they don’t tell the full tale, just as a nutrition labels don’t tell the full story of the meal that a customer will consume.

These two extremes on the spectrum do not result in an appealing Web at all:

• The Web is fast (nutritious), but bland.
• The Web is tasty, but makes everyone sick.

I am excited about a fun, vibrant web that manages to offer a plethora of tastes, but takes users health seriously, too. I think that we have seen a Web that is fun and creative. Some of us even miss corners of the Web that were possible due to the ingredients of Flash and its editor tools. We don’t want a Web that is as bland as the constraints of some social networks (MySpace certainly had some crazy fun though! 🤪)

A tortured analogy of my health journey I have had quite a journey with my health. I thought I had cracked it, but have continued to learn a lot more, especially with access to smart tools that give me access to data. For example, I use a continuous glucose monitor that tells me roughly how much glucose is in my system. This is like running Lighthouse CI for human vitals, and frees me to run experiments on my body.

I have been able to test the effects of almond flour (doesn’t spike me, whereas regular flour does), or replacing sugar with allulose (also doesn’t spike me), or how exercise (even a brisk 10-20 minute walk) right after eating brings down the post meal glucose.

I can use many other tools to take other vital measurements, such as tracking if I am in ketosis or not via a breath monitor, tracking my heart rate variability (HRV) when sleeping with an Oura, and with integrations that bring together all of the data via Levels.

Continuous measurement is key I made some lifestyle choices, and the first one was to measure. If you aren’t tracking the health of your body or your website, you are destined for drift…. and trust me it can start slow and then you wake up having a large hill to climb again. I recently had to jump back and have lost 60 pounds with 10 more to go to reach my goal BMI (NOTE: BMI and weight aren’t great measurements, and I look at my blood work as the gold standard, but they are helpful proxies to progress).

Enjoy and live life! I grew up seeing the Jane Fonda aerobics era, and seeing many people in my circle basically starving themselves and eating rice cakes that tasted like cardboard. This isn’t sustainable, so it doesn’t work, and it’s a really tough way to live. Crash diets don’t work in the long run, so you have to make a choice on what you want your long term sustainable lifestyle to be.

I want to enjoy food. I want to enjoy the taste of food. If I am hungry all the time this is the sign that there is a bug in the system. This all lead me down the path of acknowledging that I fatten easily, and carbs don’t work with my body. They flip a switch that has me go into fat storage mode, and also put me in hungry mode all the time. I can’t have one chip….. I scoff the entire bag. Moderation doesn’t work for me. I had to own it.

Gary Taubes helped educate here many years ago with his books on Good Calories, Bad Calories, and he has a new one that hit home once again: The Case For Keto.

I am going to enjoy food, but use a well-lit path that helps me do that, and keeping out of a restrictive world of how much I can eat. I want to eat to satiety. This puts other constraints on me…. I can’t eat certain carb-heavy foods that I love. But then I remember that I CAN enjoy certain berries with heavy whipping cream. Not too shabby!

Once in mostly-ketosis, I am never hungry. This has enabled me to test out tactics such as time restrictive fasting (TRF). Keeping to 16:8 is simple, and I have also enjoyed simply one meal a day. I also kicked things into gear by taking on some prolonged fasting (3 to 4 day fasts) and was amazed with how, other than boredom, it wasn’t hard to do…. but it would be impossible for me to have done this in carb mode.

I mentioned almond flour earlier. Since I am tracking everything, it allows me the freedom to experiment and find the balance of: something enjoyable and tasty that contains the right nutritional profile. The Almond flour crepes and scones that I have had this weekend aren’t THE most yummy I have ever had, I will admit that, but they WERE enjoyable. That’s the bar for me…. get me 80% there. If the result isn’t enjoyable then why eat it? It’s off the list and I am on to the next experiment.

Back to the Tasty, Nutritious Web Let’s bring this back to the Web 😅. I know that it sometimes feels like we are always talking about nutrition, and shoving the label in front of your faces. I apologize if it comes across like this at times.

What I ask of you is to consider the balance of taste and nutrition. You are the chefs of your experience, and you should feel the creativity of making amazing meals that acknowledge users needs the hidden costs.

It’s a mind shift. Instead of “Eek, I can only use Xk of JavaScript, and I should keep the experience simple!”, think “I have some constraints, but I want to use all the tools and ingredients I have to deliver something tasty!”. Sure, maybe don’t shove a few MB of JavaScript and have it run on the main thread, but how about thinking about other loading strategies?

• Do work in a worker thread that isn’t as expensive for the UI (allulose bypasses the liver!)
• Delay loading some of that JavaScript (preload, prefetch, tree shaking, etc)
• Start fast (maybe server side render the initial payload), Stay Fast (using service workers and loading)

Constraints are always part of the creative process.

Now, what about the role of the Web Platform? We want to make our PLATFORM tasty and nutritious for you the developer! What does that look like?

• Give you new ingredients that are performant, and you can wield in new ways (e.g. new declarative primitives such as constraint layout, various worklets)
• Have some of the ingredients be low level (primitives) so you can put them together in new and interesting ways, but ALSO offer higher level ingredients (components) so it doesn’t feel like we are handing you a cow and saying “make a meal from that starting point… THANKS!”

This is where I am very interested in engaging as the broad and diverse web community that we are. We have a general purpose platform, but we have room in zooming in and delivering purpose-built solutions. You don’t need the same ingredients and tools to build a blog as you do building a rich productivity platform…. or a commerce experience…. or a game.

We have a broad tent on the Web… or maybe a broad kitchen. I am excited to see the tasty meals you build for users, and learn how you made them.

Have you seen or built something tasty recently? If so, please let me know… we want to highlight it!

Almond Flour Crepes… don’t look too bad, right?

View Details

tl;dr We need your help to improve the collective Web Vitals. We are putting as much weight as we can behind these vital metrics across our tooling, guidance, and much more.

I am really excited to see the introduction of the Web Vitals program today. The web community has seen the maturation of web performance metrics over the years, and this program brings clarity around the “unified guidance for quality signals that, we believe, are essential to delivering a great user experience on the web.”

How are your vitals? We want to be able to give you the best possible metrics that you can use to measure your user experience and how it maps to your business. The set of core web vitals is a great step in showing measures that tie well to the initial steps of a web journey: do your users perceive a fast load? can they interact with it? is it stable, or jumping around?

Why Vitals? We are used to certain metrics as markers for our health, such as resting heart rate, blood pressure, blood sugar, and BMI. Together, they can help tell a story around your health. You can experiment and see how they change. Over time we understand more about these metrics, some go out of fashion as we get new data, but we strive to find those that seem to have the best correlation to health.

All humans are not the same, and we add a layer of context on top of the metrics. A marathon runner will differ from a sprinter, just as a rich desktop web application that sits in the first tab differs from a piece of content that you tap to read and move on, but the metrics are useful to understand across the board, your weighting may vary.

Hitting the bar together A good experience is the sum of the parts, and the entire ecosystem has a role to play in making sure the web performs great for all users. From hardware though OS, network. web platform, libraries and frameworks, and finally the application code… we all have a role to play.

At the end of the day, it’s the web developer and team who deploy their app, and understands the particular context, that have final control of the outcome.

We want to make sure that everyone along the stack has the best possible information, tools, and guidance, and while we are far from being done, I am glad to see the following launch with the program today:

• The Chrome UX Report (CrUX) surfaces histograms for all of the vitals of real world usage from Chrome, and a REST API is in the works
• The small web-vitals JavaScript library is available for you to send metrics to your analytics provider of choice
• A new Core Web Vitals extension will let you browse the web with a real-time view on vital results for your browsing, and will show the aggregate results from the CrUX Report in the future. This is a unified and much improved extension compared to my own!
• Integration is coming to all of our tools: Lighthouse, Chrome DevTools, PageSpeed Insights, Search Console’s Speed Report

I hope that the ecosystem makes sure to measure and understand their effect on these vitals, and share how best we can hit them.

I remember a developer at a Chrome DevSummit asking for us to fix the performance problem:

“The web feels too slow and janky at times, and why do browsers take so much memory?”

– Web E. Developer

While we have some levers to help for sure, and will be pushing on as many as we can, we need all of the brains in the community to solve this problem.

If you (human) asked your computer you would be a centaur that would have gotten the answer!

Centaurs FTW!https://t.co/eZjx73bbJn https://t.co/AAUtAtFUCJ

— Dion Almaer (@dalmaer) April 19, 2020

I admit that it is tempting to think “let’s fix it in the platform!” but that isn’t the area with most leverage for this one, and if you read Range you will see that it is when generalists with varied expertise and life experience come together that you see the most creative solutions and real impact.

So, we have huge datasets in the wild, richer tooling, and goals to hit for each metric. Let’s work together to make a dent and hit them!