There is no lack of coverage on AI Engineering, and how to build AI applications, which is fantastic.

Where do you go to understand the ever changing landscape, up to date news, interviews, community, and events that cover how developers can use AI tools and services to be as productive as possible as this revolution occurs in front of our very eyes?

This is where we hope ainativedev.io to come in!

We have a big vision and are building out a rich site to match the vision, but to get started you will see us posting regular news and interviews, developer success stories, and much more.

We announced the AI Native DevCon, Spring Edition. Grab your ticket, submit a session, check out the content from the last DevCon, and finally join the AI Native Dev community in Discord to join the convo.

AINativeDev.io is born was originally published in Ben and Dion on Medium, where people are continuing the conversation by highlighting and responding to this story.

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.

NOTE: This was originally posted on my own corner of the Internet.

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 team

I 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 codebases

Maybe 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”:

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 completion

Code 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!)

Keeping your A-Team together with developer AI was originally published in Ben and Dion on Medium, where people are continuing the conversation by highlighting and responding to this story.

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

NOTE: This was originally posted on my own corner of the Internet.

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:

Dion Almaer on Twitter: "Don't fire Kevin for Devin just yet. Augment Kevin with super powers!https://t.co/0NdT80JGLe / Twitter"

Don't fire Kevin for Devin just yet. Augment Kevin with super powers!https://t.co/0NdT80JGLe

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 development

I 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 team

I 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 24x7.

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 Augment

Joining 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!

Introducing Augment: a company dedicated to empowering developers with AI was originally published in Ben and Dion on Medium, where people are continuing the conversation by highlighting and responding to this story.

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

NOTE: This was originally posted on my own corner of the Internet.

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!

What I wish I knew before getting LASIK a month ago was originally published in Ben and Dion on Medium, where people are continuing the conversation by highlighting and responding to this story.

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.

Blocks

Lego 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.

Sets

Starting 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.

Kits

There 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.

Piece Together Your Platform with Lego Blocks, Sets, and Kits was originally published in Ben and Dion on Medium, where people are continuing the conversation by highlighting and responding to this story.

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.

NOTE: This was originally posted on my own corner of the Internet.

Let me explain via a recent experience: a web app framework migration.

Framework migration: switching between Next.js and Remix

LLMs are helpful for tasks such as porting. I have used this often, especially working between Python and JavaScript for some recent AI projects. I wanted to explore taking a web application using Next.js and have it ported to use Remix, or vice versa.

Out of the box, with ChatGPT, it would get some of the high level changes correct, but it would be very surface level. For example, actions and loaders may be created, but imports would have the form of @/components/foo and next/image.

Our LLM friend has a galaxy of information, but we don’t know what’s actually in there, and software keeps evolving so the information that may be there is probably outdated to some degree. This is where us humans come in. We can use that juicy context window to share:

• The latest information from documentation that maps to our versions. Querying embeddings from this content can be plucked into context.
• Rules and reasoning for translations. What are the steps that someone knowledgeable of both frameworks would write?
• Quality examples of before and after. If you go through these steps what are solid mappings where patterns can be learned?

Depending on the quality of this work, you will see a massive upgrade in the results. They go from “some nice hints but wow so much is wrong” to “this is kinda usable out of the box!”

At the end of this process, “What are the steps that someone knowledgeable would write?” stuck with me. Someone else was going to go through the same migration, and it doesn’t make sense for them to have to build out all of the mappings. This is a waste of effort!

Time for the knowledgable turtles, already!

I have some knowledge of Next.js and Remix, but I am hardly The Expert. What if true experts (core team, folks from the community, etc) were the ones to package the relevant information about their frameworks?

Lee Robinson on Twitter: "Gonna live stream at 4pm PT (in 2 hours) and migrate an older Next.js application over to the App Router.Will be just coding and playing tunes (strictly bangers) if you wanna hang out.https://t.co/LGZDMJiYzw / Twitter"

Gonna live stream at 4pm PT (in 2 hours) and migrate an older Next.js application over to the App Router.Will be just coding and playing tunes (strictly bangers) if you wanna hang out.https://t.co/LGZDMJiYzw

Lee does a great job showing a conversion from one version of next.js to another (to App Router land). This knowledge can be codified for anyone else doing this.

Picture an app developer creating a new project and installing all of their dependencies, and this time each one of them comes with hints from the projects themselves. And it’s turtles all the way down as each dependency comes with it’s own dependencies.

In this world you are building with a world of expertise funneling information into the amazing reasoning engine that is AI via LLMs.

What knowledge can we funnel?

Amjad Masad on Twitter: "A `.chat` file in every repo prompting AI assistant (e.g., Ghostwriter) to be most helpful in this project. / Twitter"

A `.chat` file in every repo prompting AI assistant (e.g., Ghostwriter) to be most helpful in this project.

Each project has an ai-hints.json file, which is the router to correct information. It is a simple configuration that links out, or contains some inline information, for the given project.

It contains items such as:

• URL to the source of the library (e.g. GitHub URL)
• URL to the home page of the library
• Description for the library
• URL to issue tracker of the library. Given the variability of quality in here, pinches of salt are included, and can map to answers from trusted folk / voted up
• URL to forums (e.g. StackOverflow / tags)
• URL to documentation site(s)
• URL to high quality community content (e.g. great blogs, YouTube, etc). Popular libraries often bring in examples, and other projects that use them, and run their test suites as a great way to catch regressions that your consumers will run into. We can follow this pattern to get wisdom from customers not just official content
• Versioning scheme: One current issue is that LLMs aren’t aware of the differences between versions and thus you sometimes get feedback that is tied to an old version, which is frustrating!
• URL or direct inline prompts that can be used to generate great tests
• URL, or inline docs, to prompts and reasoning. This can become a store of knowledge. E.g. it can be where conversion knowledge goes
• URL to project settings such as package.json in node / js ecosystem to start to find all of the turtles
• Polymath services: URL(s) to polymath services that have knowledge of the project
• Embedding stores: URL to a store, or a local placement of embeddings that can be used and aggregated. This way we can share embeddings versus recreating them time and time again

Speaking your full language

There have been some moments where my AI pair has been a true partner. A pattern in most of the best moments has been how the back and forth can be so much more concrete. Often, if you are building something for your own application, you end up following a path of translation.

You want to do concrete thing X using library Y. This would often resort with finding the documentation in various places and learning the abstract thing closest to X (which may not be easy to even find!) and then working out how to translate this information into what could work for the concrete task.

Now, you can *explain* the concrete task, explain that you want to use it with your set of tools, and the initial answers can be speaking in that language. And you may not even know which library to use, and you can ask for thoughts and implementations with those thoughts too!

Being able to aggregate the dependencies is huge.

One of the reasons I enjoy working on Polymath is it’s federated nature. If I am working on a project that uses Remix with Preact I can write a query that asks for information from both the Remix polymath and the one for Preact.

More knowledge? More context

Magic.dev on Twitter: "Meet LTM-1: LLM with *5,000,000 prompt tokens*That's ~500k lines of code or ~5k files, enough to fully cover most repositories.LTM-1 is a prototype of a neural network architecture we designed for giant context windows. pic.twitter.com/neNIfTVipt / Twitter"

Meet LTM-1: LLM with *5,000,000 prompt tokens*That's ~500k lines of code or ~5k files, enough to fully cover most repositories.LTM-1 is a prototype of a neural network architecture we designed for giant context windows. pic.twitter.com/neNIfTVipt

As we build out larger knowledge sets, we need new ways to feed our AI’s creativity. Fortunately, we are seeing various models get significantly larger capacity for prompt tokens.

We are also getting smarter with how we can chain reasoning together. Instead of firing off one prompt as a shot, you can do multiple, and ask various questions to drastically improve quality too.

E.g.

• Ask questions differently in parallel: Use different prompts, with different settings (e.g. multiple temperature values), with different context
• And even different models entirely
• Using the output from above, ask for a critique
• Feed the critique AND the options from above, and ask for a unified solution.

Ecosystem scratches it’s own back

Gvntr 零 on Twitter: "Trying out @sourcegraph's Batch Changes to sunset a GitLab CI configuration across bunch of repositories at once. This is trully magic! pic.twitter.com/aWtm72TlIA / Twitter"

Trying out @sourcegraph's Batch Changes to sunset a GitLab CI configuration across bunch of repositories at once. This is trully magic! pic.twitter.com/aWtm72TlIA

By coming together and curating the information, we not only scratch the backs of all developers using our products, but in turn we are helping ecosystem health.

If you have worked on a platform, you know that one of the most important things to do is setup incentives to keep the platform evolving and healthy.

This is hard to do, and often goes wrong. You have probably worked with tools where updates break things more often than not. What does that teach you to do? Lock in to a particular version that is working, and only do upgrades when you have the time to deal with it.

If instead, upgrades work well? Then you should be game to continuously keep up to date. Doing well would look like:

• Clear understanding of what’s in the upgrade
• Codemods that can run to help you update. We will soon be in a world where our nano bots will see an update, create a PR, run all of our tests, and you will have a strong starting point, or maybe even more. I’m ready for my nanobots to be cleaning things up for me, handling updates, performance improvements, checking for security, for accessibility, etc etc. We will just need great UX so we don’t feel swamped with this work. I don’t want a poor open source maintainer to be slammed with PRs in a way that it feels like spam. Categorization etc on GitHub will be a big winner here 🙂

An entirely revolution is happening when the world of developers and shared knowledge combines with the new world of LLMs.

We don’t want LLMs to use the overall corpus of code that is out there, because if the surface of the code is small, it may not have any great answers, and when the commons is huge, you can end up with a lowest common denominator such as:

antony  on Twitter: "Copilot always knows exactly what I'm about to do. pic.twitter.com/iewWWbg0kq / Twitter"

Copilot always knows exactly what I'm about to do. pic.twitter.com/iewWWbg0kq

When it comes to code, hallucination is the enemy not just because it is very unhelpful, but also due to side effects such as security:

LLM Security on Twitter: "* People ask LLMs to write code* LLMs recommend imports that don't actually exist* Attackers work out what these imports' names are, and create & upload them with malicious payloads* People using LLM-written code then auto-add malware themselves https://t.co/Va9w18RpWu / Twitter"

People ask LLMs to write code* LLMs recommend imports that don't actually exist* Attackers work out what these imports' names are, and create & upload them with malicious payloads* People using LLM-written code then auto-add malware themselves https://t.co/Va9w18RpWu

It’s not just about the quality of the code and the ease of use. It’s also about the speed at which we can learn, adapt, and grow as developers. With a wealth of knowledge at our fingertips, we can quickly understand new technologies, make informed decisions about the tools we use, and stay ahead of the curve in an ever-evolving industry. This revolution in software development is empowering us to build better, more efficient, and more innovative applications than ever before.

I’m very much here for it.

/fin

ai-hints.json: how the ecosystem will help the bots was originally published in Ben and Dion on Medium, where people are continuing the conversation by highlighting and responding to this story.

NOTE: This was originally posted on my own corner of the Internet.

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.

swyx 🔜 NYC 🗽 on Twitter: "i'm sure @Mappletons can do better but this is what i see in my head every time i see "devs just go back and forth in endless cycles" comments pic.twitter.com/PcVhiNViIF / Twitter"

i'm sure @Mappletons can do better but this is what i see in my head every time i see "devs just go back and forth in endless cycles" comments pic.twitter.com/PcVhiNViIF

One 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

Gary Lineker on Twitter: "Well, lcfc's managerial bounce lasted 5 minutes. / Twitter"

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

The Pursuit of Taller Hills: Lessons from Football and Product Management was originally published in Ben and Dion on Medium, where people are continuing the conversation by highlighting and responding to this story.

NOTE: This was originally posted on my own corner of the Internet.

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 layer

Modern 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 layer

Next 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 layer

Some 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 Proofing

With 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 Layers

Some 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

Building a modern design system in layers was originally published in Ben and Dion on Medium, where people are continuing the conversation by highlighting and responding to this story.

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

NOTE: This was originally posted on my own corner of the Internet.

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

Google A/I/O 2023: In Person Matters was originally published in Ben and Dion on Medium, where people are continuing the conversation by highlighting and responding to this story.

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

NOTE: This was originally posted on my own corner of the Internet.

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?

Understanding the use cases

We 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.

Building enough of the new platform

We 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.

Having everything in place to help evolution

We 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!”

Sharing early

Show 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:
2. future: { v2_routeConvention: true }
3. 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.

Starting the deprecation clock appropriately

Don’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.

Staying close to the platform

Favor 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.

Do 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 time

Let’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

Help Mario Reach The Next Platform! was originally published in Ben and Dion on Medium, where people are continuing the conversation by highlighting and responding to this story.