Thought Eddies - Garden

Building With AI

Fri, 12 Sep 2025 19:13:17 GMT

Everyone these is building with AI. Or wants to be. Or telling their employees they need to build with AI. Or shipping with AI. Or putting AI in their products.

But what are people even talking about when they say you should build or ship with AI? I can think of at least three different approaches that make use of “AI” the proverbial way it is being referred to most of the time today and I think they’re worth discussing because I rarely hear the difference discussed.

Interacting with AI to figure things out

Let’s say I want to build a website but I’ve never built a website before. I can have a conversation with a language model based chatbot and learn more about how to write HTML, style my site with CSS, and add interactivity with JavaScript. I can learn about hosting options like WordPress or Github Pages, depending on my needs and the type of content I want to publish.

The language model can take my prompts and feedback and steer me in a helpful direction.

This doesn’t work for uncharted territory but it works pretty well for Solved Problems. Many people know how to build websites and you can learn to. With a language model, you don’t necessarily need to read a book on how to build a website, you can start wherever you want to in the process and the language model can help fill in gaps.

If you try out the model’s suggestions, you’ll find a lot of suggestions work and some don’t. Experimenting like this is a great way to develop an intuition for what the model you are working with can do.

Using AI to make things

Coding agents like Claude Code and Cursor and “vibecoding” products like Lovable and v0 have become popular ways to build software. Using these tools significantly lowers the barrier to entry for building software. You may not build great software, bug-free software, or performant software, but you’ll probably build more than you would have without them.

I also find the coding agents helpful for collaboratively building software. If you know how to code, you can use the agent to quickly scaffold boilerplate code, implement architecture patterns, refactor code, and more.

I think there is a wide range over which you can use these tools to build software. Not everyone agrees.

Either way, this is a second way to “build with AI”.

Building software with AI that does something as part of the product

ChatGPT is an example of a product that uses the AI in the experience itself. You send a message to ChatGPT and OpenAI uses your input as the input to their model. They run inference with their model and stream the output to your browser.

The product experience itself is made possible using the language model or AI (previously more commonly known as machine learning).

Teams building chatbots on top of knowledge bases, Slack bots that answer frequently asked questions automatically, and agents that read your emails and schedule meetings are all examples of products that use AI in a way that is core to the product experience.

Said differently, these products are made possible using the emergent capabilities of the language model. The prior two examples of “building with AI” actually just use AI to do things we did before, but faster and with less friction than before (to say nothing of the tradeoffs of learning how the software works and not understanding your code).

So the next time someone says “we’re building with AI”, ask them what they mean. Getting on the same page will help save a lot of time, energy, and confusion.

Thanks for reading via RSS!

The AI adoption chasm in software engineering

Thu, 22 Aug 2024 00:08:56 GMT

I’m seeing a pattern in AI discourse among enthusiastic adopters:

You’re cooked if you don’t use LLMs to write code

This is counterproductive and not helpful.

I believe that all technologically minded folks, regardless of their stance on particular tools, have things they can learn from each other.

There’s more value in working across these groups, inside and outside technology, rather than isolating ourselves.

The unproductive discourse

To be specific, discourse gets unproductive when adopters project that other software practitioners are “cooked” or “not going to make it” because they’re not adopting AI.

As someone who has enthusiastically adopted several different applications of AI, most notably using AI as a coding partner and often as a coding driver, what I find most perplexing is the divide in experiences. For every person who finds these tools incredibly useful, there are many who tried them and found them frustrating, tiresome, irritating, or ineffective.

I am genuinely curious about what is different in the approaches and contexts of those folks that leads them to find something I think is really useful to be not that useful at all.

Tools and preferences

In part, I wonder if it’s a bit like a Vim versus VS Code/full-fledged IDE divide. I’ve never been able to be productive with Vim; it doesn’t fit how my brain works. Plenty of folks swear by it, and I don’t deny its benefits for them.

Nor would I say a Vim user couldn’t be a successful software engineer. There are examples to the contrary, as there are examples of successful engineers who use more fully featured IDEs.

To me, deciding whether to use AI to write software is similar to Vim vs. an IDE. I find AI an incredibly powerful and useful tool, but it’s not uniformly or universally better than a person in every capacity.

The impact of feeling the pain

You build new paradigms when the current ones block you. For folks coding with language models today, one notable pain is parallelizing agents without them interfering with each other, performing more inference, and finding ways to agents to run independently for longer.

I don’t see a ton of folks writing new programming languages using language models that meaningfully change the programming paradigm, at least not yet. They don’t feel the same pain as someone struggling through writing in the language.

A long-term perspective

We don’t know how all this will evolve, or which skills will be most conducive to enduring success. That’s fine.

If you plan to build software for decades, think long-term about craft, mentorship, and culture. A posture of animosity toward non-adopters is not a durable strategy.

Let people work how they think is best. This technology is going to be around for a long time.

What will best serve us right now is to understand why current tools don’t resonate with people who aren’t excitedly adopting them.

I don’t yet have a good explanation for why one person finds AI compelling and another doesn’t. To understand it, we need to keep telling and hearing more specific stories: what you tried, what hurt, what felt like magic, and what felt like a waste of time.

Tell me where AI has failed you or saved you. The specifics are how we close the gap.

Thanks for reading via RSS!

Ongoing thoughts

Tue, 20 Aug 2024 01:26:08 GMT

It is currently kludgy and time consuming to iterate on a prompt for a language model to integrate some kind of inference into an engineering use case in a microservice environment. This is specifically difficult because it’s not yet clear where productive separation of concerns should be.
Many frameworks are under development, but they typically get you off the ground quickly with a basic use case at the expense of scaling well with your use case.
It’s not entirely clear what the most productive prompting approach is for a task or if you (prompt engineering) or a model (DSPy) should improve the prompt.
We don’t always know whether we should try and use a single inference with approaches like Chain of Thought, multi-shot and structured outputs or if and how we should use multiple turns in a conversation.
When we do pick an approach, it’s not clear how we test or monitor. We can write evals (ground truth prompt+output pairs that we validate), though it is only really easy to do for single-message inferences and usually structured output.
How can we observe (especially to debug) the prompts/context and inference outputs across a conversation with a model? When we get a bad or wrong response, what were the inputs, how can we understand them and how can we improve the model performance for the use case? What if we can’t improve the performance and no prompting, fine-tuning or existing model seems to work well?

Thanks for reading via RSS!

Equity

Sat, 01 Jun 2024 00:00:00 GMT

Note: This is not financial advice. I wrote this in 2021 as I tried to reason about, understand, and document some of the patterns I was seeing in tech startups/scale-ups. I think much of this thought process is still relevant for private companies offering equity as part of their compensation packages. I mostly discuss my thought process through the lens of RSUs as that is what I am most familiar with. Some of this may apply to options, but I can’t say with confidence that all of it does.

Receiving an offer with startup equity

Tech startups often offer stock options or RSUs as part of their compensation packages to make up for the fact that they (generally) want to pay lower cash salaries than other (usually public) companies competing to hire from the same pool of candidates. This practice makes some sense. The company is typically trying to grow quickly and has raised investor capital to do so. Instead of giving you that cash, they want to invest their cash in the business and if the business is successful, you’ll (hopefully) be rewarded many times over with the value of your equity when you have the opportunity to sell it.

There’s nothing inherently wrong or devious about this practice. It’s a value tradeoff: less money today for a chance at more tomorrow. However, the way these companies deliver these offers, particularly to junior engineers who don’t necessarily have experience with equity-based compensation, leaves a lot to be desired. It usually looks something like this.

Hey Dan, we’re excited to offer you the role of software engineer at NewCo. We think you’ll be a huge addition to our team as we scale to additional markets. We’d like to offer you a base salary of $123,456 per year and 3,700 RSUs vesting over 4 years. We think this is a generous offer and above market rate for similar roles. The offer expires on Wednesday, so be sure to get back to us soon!

Best,

Bart from recruiting

While it’s a privilege to be offered a job, the way in which an offer like this is presented is extremely frustrating. The recruiter has offered some number RSUs, knowing (or even worse, not knowing) that I now have to ask follow-up questions just to begin to understand the value of the offer. I find this disrespectful.

This practice is akin to a store placing a price tag on a t-shirt that reads ◆82. What is the value of ◆? I don’t really want to have to go to the register just to understand the dollar cost of the item I’m thinking about purchasing. Bart is leaving me to do all the work to determine the worth of these RSUs. There might be some public information available that help me infer the value of this equity, but most of the time, everything is left to you, the candidate, to navigate and figure out on your own, often under the pressure of an offer with a deadline (sometimes referred to as an exploding offer). When I visit a store, no one expects me to check the market value of a t-shirt so I can estimate the actual dollar price of ◆82 in monetary terms I can comprehend.

In reality, after all the time invested in sourcing candidates and conducting interviews, NewCo may want to hire me far more than the store wants to sell me a t-shirt. So why are they making it so hard for me to figure out what’s in it for me if I work there? Having gone through this dance multiple times, I usually give the benefit of the doubt and follow up once, or maybe twice if I’m really interested in the role. But for folks without as much experience and/or in a tough job market (like in 2024 when I am posting this), you may not have better alternatives or the time to do this legwork.

What is the equity worth?

So, what questions do you ask to figure out what the RSUs are actually worth? You could reply “Hi Bart, what are the RSUs worth?” but Bart’s incentives aren’t aligned with yours. He wants to close you and will give you the biggest number he possibly can at which to value the RSUs. The number you’re after is your percentage ownership of the company calculated from the number of RSUs you are being offered.

If you can’t get that number specifically, you need to do some math. The math isn’t hard, but getting the numbers might be. The numbers you should ask for are

total number of outstanding shares
last 409a valuation of the company
last preferred valuation of the company

If you know the total number of shares, you can calculate percentage ownership

offered RSUs / total number of shares

Now you can make your own determination of what you think the RSUs are worth. Multiply percentage ownership by the amount you think the company is worth. That’s the hypothetical of your RSUs (after they vest and minus taxes, sorry).

I hear you, you have no idea how to value a private company. The VCs are historically not great at this either, but we can use their behavior and investment terms to help us get a ballpark idea of what our shares could be worth.

The preferred valuation of the company is the most recent value at which some group of private investors bought shares in the company. Take that valuation and multiply it by your percentage ownership (really big number times a very small one) and that’s one number to look at when valuing your equity.

Do the same thing with the last 409a valuation, keeping in mind that this value per share will likely be lower than the preferred share price. A 409a valuation is a theoretical valuation calculated by an independent auditor which aims to estimate what the company is approximately worth at that point in time. Investors are usually thinking about what the company could be worth in the future, when the business is more mature.

If the company raises more money, it’s possible the preferred valuation could change. If the company receives another 409a valuation, that could change as well. Ultimately, these numbers are all hopes and dreams. You’ll only ever receive money from your equity if you can find someone to buy it from you.

Selling startup equity

You can monetize your startup equity in several ways (this is not an exhaustive list):

You’re given the chance to sell your shares through a “tender offer”. External investors approach your company with the intention to acquire shares. Instead of issuing new shares or selling unallocated shares, the company allows employees to sell their (vested) shares to the investors, providing an opportunity for employee liquidity. The investor sets the price at which they will buy your shares. You can either accept or decline, and it’s typically a one-time event with restrictions on the number of units you can sell.
The company is bought by a public company and your equity converts to shares of the acquiring company. You can then sell those converted shares in the public markets. The conversion of your equity to shares of the new company stock is unpredictable. It depends on the deal your leadership negotiates.
Your company goes public (IPOs) and, after what is usually a 6-month employee lockup, you can sell your shares in the public market during an allowed trading window at the current market price.
You can sell equity on secondary markets. However, there are several caveats. You need to check if there are any restrictions in your offer against participating in secondary market sales (some companies explicitly prohibit it and many have the right of first refusal for a sale). Most secondary market bids are for options only. RSUs typically have conditions that make them unappealing for purchase on secondary markets. Also, RSUs are not shares of the company. They only become shares after they fully vest and in the case of most private companies at the time of this writing, that only happens after a liquidity event.

Where to go from here

At this point, you might be justifiably overwhelmed by the entire process of valuing startup equity, and that’s understandable. When accepting equity in a private company, there are no guarantees. Be aware of what your opportunities for liquidity might look like and keep in mind that the “value” you perceive your shares to have may end up being pennies on the dollar and could even diminish to zero.

This whole discussion is not to suggest that you shouldn’t work at a private company. Such companies can be some of the most exciting places to work with incredible opportunities for growth. Like anything, there are tradeoffs and where there is higher risk, there can often be the opportunity for greater returns. If you do accept an offer like this one, go in with your eyes wide open, understanding the risks, hoping for the best, and preparing for the worst.

Thanks for reading via RSS!

Social Capital

Tue, 07 May 2024 21:41:55 GMT

At my first engineering job, I was introduced to the idea of social capital in the context of how to ask for help from other engineers and the consequences of spending one’s social capital ineffectively. I don’t love the textbook definitions of social capital but I think the following example is a good illustration.

When you contribute positively to a social group by respecting shared norms, shared values, trust, cooperation, and reciprocity, you cultivate your social capital. When you violate these norms and values, you squander or exhaust that capital. Misusing social capital can lead you to lose trust of the group.

Since moving on from this role, I’ve never heard the topic mentioned explicitly in the same way in a workplace again but I think it’s one of the more important things you can learn as an engineer. The concept of social capital has become central to how I aim to operate as a positive individual contributor within a broader engineering organization (though much of this applies for any group of people).

As an engineer, you consistently encounter unfamiliar things that you need to learn to do your job effectively. If you’re lucky, there may be good documentation or existing examples, but eventually you’ll come across something you can’t quickly figure out or understand.

There are several paths forward in this situation. You could start reading code until you reach a deep understanding of what is happening. Under time constraints, this approach could be too time consuming. You may need to ask someone with more experience for help with your specific issue.

When you ask for help, it’s important to demonstrate you value the time of the person you are asking. My aim is to display I’ve made a good faith effort to solve the issue myself and exhausted the resources I was able to find. It’s likely the person who ends up helping me will have their own responsibilities that my question pulls them away from. I aim to do the following:

make it easy for them to help me or answer my question
display my current level of understanding of what I am working on
avoid wasting their time, by bringing everything I think is relevant to the beginning of the conversation (see No Hello)

This approach helps the responder use language that I understand (since I’ve shown my level of understanding with my question). It also can reveal areas where my understanding is flawed that can be corrected, which is exactly the kind of help I need.

If you’re posting a message in a community channel, you may not even know who that person is when you’re articulating your question. My approach in this situation is to concisely request for help with the following structure:

a brief introduction of who I am
what I am trying to accomplish
what I have attempted so far and what the results have been, including errors

If I have lengthy explanations or examples, I will either try and link out to them or prepare the entire message first then write a short message to start and post a longer follow up message in a thread to avoid taking over the entire conversation of a channel. In addition to valuing the time of the person answering your question, you want to value the time of your peers who may have questions and ongoing conversations of their own. Recognize that you’re not the only person trying to get your job done and do your best not to monopolize conversations.

Examples

The above might be more theoretical than you’re comfortable with. If that’s the case, here are some examples of what I would deem to be good and bad ways to build social capital rather than squander it.

Good

Hi, I’m Dan from the Risk team. My team is working on onboarding to the new Streaming Platform. From the documentation, I understand that I need to create a new Kafka topic for each of my services that currently calls the RPC in $old_service. Is it possible to create these topics in bulk? I need to create topics for 10 services, but the instructions only seem to support onboarding a single topic at a time. Thanks!

Why?

The person reading this can understand what you are trying to do and what you have tried so far. If there is documentation you missed, they’ll likely happily link it and might even recognize it’s not as discoverable as it might be since you clearly made an effort to find it but couldn’t. I would expect a positive interaction to result from this starting message.

Bad

How can I bulk onboard topics?

Why?

It’s ambiguous what you are talking about, so the person providing help may need to ask follow up questions to figure out what you are trying to accomplish. Follow-ups for clarity are inevitable sometimes but this attempt has made a poor attempt at clarity. You’ve not explained what you’ve tried if anything, so the person responding will need to ask something like “have you checked the docs?”. They could link you to docs directly. They could assume you already know where the docs are and suggest you read them. They could need to go search for the docs themselves to then link to you. Generally, this cursory approach displays disregard for the time of the person you are hoping will help you. I aim to display respect for this individual’s time, energy and effort because I need their help to be successful.

When it goes wrong

At their worst, these types of conversation first require you to establish common understanding through follow-up questions. In a chat-based environment where it can be easy to get pulled away from one conversation into another or a meeting, these lengthier exchanges become increasingly difficult to manage and can often trail off and require reminder pings from both sides to answer the last request. In my experience, the longer a conversation goes on, the more complicated it typically becomes and the less likely all participants are on the same page. Sometimes a long conversation is needed, but if one is, all the better if you establish as much context up front. It makes it more likely you’ll get the useful information you are looking for before the conversation trails off.

Your reputation

I’ve been on both sides of asking and being asked for help. I value it tremendously when someone asks a question with preparation. Unfortunately, those who ask the least prepared questions are often the most memorable and frustrating. As the individual providing help, you come to recognize regulars. With a finite amount of time and energy, you may need to prioritize some asks over others. In these situations, I prioritize people who use their social capital effectively because I appreciate their efforts to value my time and do my best to reciprocate.

Thanks for reading via RSS!

Craft, constraints and software in the real world

Sun, 21 Apr 2024 10:25:33 GMT

This article, I love programming but I hate the programming industry, is a lively addition to the conversation on the expectations placed on software developers in corporate environments. My experience working at medium-large software companies has been that there is always a give and take between building features that make money and satisfy business needs, and having a sense that you’ve built software thoughtfully, that can endure and scale — software built with craft. The balance between these two can vary widely but is a necessary tension in a business environment.

I’ve come to view the dissonance one feels as an author of software in a money-making environment as a mismatch in what success looks like between an author of software who cares about the craft of writing software and a business operator who is responsible for engineering user behavior in service of an organization’s goals (usually making money).

Maybe it’s trite, but I think the comparison of a table made out of high-quality wood and a mass-manufactured table made out of press board is apt. There is a large overlap in function but only the one made with quality is likely to stand the test of time. However, a lot of people need tables and lower quality table can be made quickly, purchased more cheaply, and sold in larger volumes.

It can be easy to convince yourself that the cheap things you get today are going to work well enough for now and into the forseeable future. In practice, there is a tradeoff between resources in the present and the future, time and money often being some of the most often considered.

Businesses typically operate in highly competitive environments where there is a strong push to do things today because the future isn’t guaranteed. Software developers for a business are not always aligned with this mentality. Someone writing software might want to dedicate more time to considering whether a system will be maintainable or scalable because if the business requires that, it’s often easier to plan for it upfront rather than trying to retrofit into a live system for a business whose systems are having scaling growing pains.

This area is one where software developers and business operators often find themselves at odds. Business operators frequently want to ship the minimal viable product because the sooner something goes to market, the sooner you will know if your ideas work and what to try next. Business operators also aren’t directly responsible for making software scale, so they’re much more likely to push for the thing they are responsible for — growing the business.

Software developers are responsible for the systems. This is includes designing architectures, building systems and shipping products to users and making sure they scale (don’t break when a lot of people use them at the same time). If the business they are a part of runs out of money and can no longer operate, there won’t be anything to scale. If the business does succeed, the developers and the business may pay a cost for corners they cut to get to where they are.

One common difficult growing businesses encounter is when a single SQL data store starts to fail under the load of too many use cases. These types of databases can only scale vertically, meaning you can increase the size of the machine you run your database on, but if you can’t find a bigger machine, you will struggle to scale further without making larger changes to your application architecture. Adopting a different type of database (like a NoSQL database^[1]) earlier requires a certain amount of foresight, but also is a tradeoff in flexibility. With a NoSQL data base, you can’t run arbitrary queries against all your data at the same time. You usually need to design your tables to support known query patterns. This preparation for “scale” may end up being unnecessary if you never actually need to scale the product because it doesn’t achieve success but it preparation for scale will likely slow down the pace at which you can change the product in response to feedback from customers.

You need to consider whether this tradeoff will undermine your ability to succeed at building the product. I’ve seen teams struggle with quantifying these tradeoffs, especially when the long-term existence of the business is in question. Saying “we don’t know if we’re going to exist in the next N months” often wins the day when advocating against investing in software scalability in favor of a leaner MVP. However, playing the “this will never need to scale” card is also dangerous if it’s not necessarily true. Not taking any time to consider technical challenges you might encounter in the future can lead to a lot of pain and lost time down the road. Time is finite and you want to spend it doing the most valuable work you can.

In the ZIRP era, this phenomenon occurred quite often. Companies deployed billions in capital to start or compete in industries that (nearly) disappeared after just a few years. In 2018, Bird (among many other companies), began deploying thousands of electric scooters in major cities around the world at single-digit dollar rental prices. The startup achieved multi-billion dollar valuations at paces never seen before. Bird captured the attention of many in the technology world due to the breakneck speed at which they were building, scaling and deploying. They were re-writing the rules for how quickly a company could scale. At the time, Uber, the incumbent king of blitzscaling, felt threatened enough by this business that it decided to acquire the electric bike share company, JUMP and launch an electric scooter service under that brand. These companies were punting products out the door as fast they could get employees to build something customers could use. These are not the types of environment conducive to building with craft. The goal here was to get customers to use a product as quickly as possible, then figure out everything else later. Whether it was effective is a separate conversation — it was a business strategy.

On the other side of the argument, building beautiful, scalable systems for a business that never acquires any customers may be an exercise in craftsmanship, but software developers can only work for so long without needing money to support themselves and getting paid typically requires you work for an organization that can afford to pay its employees^[2].

Business is messy and a competitive business environment imposes demands on companies to produce in ways that are often at odds with high-quality craftsmanship. Spend five minutes reading about how difficult it is to make a living as an artist and that will be made clear.

While the demand for skills in building software are high, the demand for software craftsmanship less so, at least in the explicit sense. For most businesses, software is a means to an end to deliver a product to users.

Users do recognize craftsmanship in software^[3], even if they don’t exactly know why they prefer well designed experiences to lean MVPs. It’s the feeling of ease you get when you use something that just works. Or the absence of the frustration you all to frequently experience in an age with countless mediocre, carelessly constructed products. Apple built its empire or things Just Working^[4].

I think demands of faster-than-ever pace placed upon businesses (both internally by executives and externally by markets and investors) make it difficult to invest in craftsmanship. This is not to say no one does it, but it requires more upfront investment to continuously make decisions that prioritize the quality of your product given the constraints of running a business. It requires vision for why craftsmanship is essential to your business’s success.

Craftsmanship implies quality — something that is difficult to preserve as one does more of a thing. Craftsmanship takes times — if it were easy, it would be undifferentiated. This is also not to say it’s impossible to scale something of high quality, just that’s it harder than scaling if one doesn’t focus as much on quality or makes too many compromises prioritizing scale or speed. Many more businesses seem to prefer the pursuit of the largest possible total addressable market over the highest quality product. I imagine this is because they perceive this approach as the best way to make the most money.

Writing software in a corporate setting, to some degree, does always reduce a software developer down to a cog in a machine. You’re employed to empower the organization to make more money. Hopefully your expertise is valued, but it might not be. You may have been hired merely because someone with a budget was able to staff a team to work on a project that recently was given funding. You likely will be asked to do a lot given difficult constrains resulting in lower software quality than you aspire to write.

If what your doing has implications in the real world, it’s more complicated than just software and it’s messy in one way or another. As someone who studied Physics, I often find myself searching for simple and elegant solutions to software problems that uniformly capture designed behavior and edge cases alike. The author’s articulated desire resonates with me

I want every how - from the programming language and paradigm, architecture, down to every line of code and piece of syntax - to be informed by the why of the system that is being built. And I want that why to be a reflection of a genuine existing need, not some bullshit business metric which pretty much exists for its own sake.

I would argue that many small companies begin with this somewhat idealist approach and goal in mind. The “genuine existing need” to be addressed are the business’ customer needs. If a business is successful enough, it may try to do more of what it is already doing or expand to do more related things. From these ambitions it invents and borrows from prior art, systems to implement the execution of its goals at a greater scale. Success in business seem to lead to the proverbial “bullshit business metric”.

It’s difficult to maintain a culture of building with craft. It many not be flashy or attention grabbing and it inevitably will require compromise. A great outcome would be if you can build something excellent, sell it at a fair price and earn enough to live and continue to run your business.

After writing this, I saw Karri’s tweet and felt like he expressed a lot of similar sentiments in his comments:

What I talked about at Stripe Sessions:
Craft and Quality, and professional grade software at @linear pic.twitter.com/HFpN4GTIkj
— Karri Saarinen (@karrisaarinen) April 26, 2024

A distributed database that can distribute and query data across more than one machine and scale beyond the constraints imposed by a single machine that SQL struggles with. ↩
During the ZIRP era, companies often paid employees with investor dollars rather than company profits, because the companies weren’t actually making any money. This was the model of the last decade in tech which has rapidly disappeared with the increase in interests rates. ↩
This requires contributions not just from developers but everyone participating in the product lifecycle. ↩
Though there are times where it has failed to meet the quality bar it has become known for. ↩

Thanks for reading via RSS!

Edit Links

Thu, 01 Jan 1970 00:00:00 GMT

Why I have “edit” links on my site:

I use my site’s search page as a public second brain in certain ways. When I write something up as a TIL it was probably useful enough to be something I’ll come back to again. Because of this, occasionally I have updates or notice changes that need to be made to a particular page. When I realize this, it is almost always the best time to make the change. The fastest way to do that is to make a quick file edit in GitHub, a tool with a reasonable experience for quick and minor changes. It opens in the app on my phone and as a logged-in session on my computer. I make the edit, commit, the build runs and it’s live. If you click it, it will bring you to a page to create a PR to the site. If you’re making a correction, thank you! It’s an honor to have you as a reader. I hope you’ve gotten something positive out of my work or that it saved you time.

Thanks for reading via RSS!

Structure

Thu, 01 Jan 1970 00:00:00 GMT

My blog has the following sections:

Search

/search

Search functionality across all the content on this site.

Posts

/posts

I view these as complete or polished pieces. They are of varied quality, but most have been edited by me several times over and occasionally by a few others.

TILs

/til (short for “Today I Learned”)

I’ve seen several other folks write these types of posts. I sort of view them as notebooks. I write ideas and things I learn in them, but they’re only a medium level of refinement at most, and some are just simple. straightforward things. They usually have a medium amount of editing but quality varies.

Logs

/logs

Logs are short notes, thoughts, links, and occasionally tweets. They capture fleeting thoughts from the day. Sometimes, they lead to writing in other sections but are generally unrefined, unedited, incomplete, and sometimes wrong.

About

/about

Brief and general, high level things about me.

Projects

/projects

Some of the more complete projects I’ve worked on.

Garden

/garden

A place for thoughts, ideas and essays I tend to.

Uses

/uses

The software and hardware I use.

Now

/now

What I am up to “lately”.

Activity

/activity

Recent activity and updates on this site.

Thanks for reading via RSS!

Links

Thu, 01 Jan 1970 00:00:00 GMT

Thanks for reading via RSS!

System Prompts

Thu, 01 Jan 1970 00:00:00 GMT

Prose only. No lists. Format the output as follows

a tl;dr summary of the body (Titled “Summary”)
a thoughtful and measured response (“Response”)

User

your question!

assistant

the response!

with a prefill of “Here is your response:” for Anthropic models

Thanks for reading via RSS!

Ways I Use

Thu, 01 Jan 1970 00:00:00 GMT

Code generation

I use language models to generate code following specific instructions. Usually, this involves a short prompt. I typically generate 30 lines of code or less. I may use the model to write an script starting with nothing. I more frequently use models to amend or augment code in an existing code base. For example, I may highlight a list then prompt “write a function to remove falsy values then sort in descending order by field date”

A web search alternative

Instead of Google or alternative search engines, I use a language-model-first search engine like Perplexity, You or just a model playground. For a while I used the OpenAI playground. Since the release of Claude 3, I’ve been using the Anthropic workbench. I also use the llm CLI to quickly invoke models, though I’m still building muscle memory for this approach. The latter is nice because it maintains a local sqlite database of all model interactions.

To scaffold examples and demos

Whenever I need sample data for a demo or example, I’ll use a language model to either generate the sample or write a script to do so. This my take the form a prompt like

Write a creative menu for a barbecue restaurant

which is an approach I’ve used to generate unstructured data to separately demonstrate the model’s capability to extract structured data.

As a thought partner

For me, writing about something helps clarify my understanding and highlight areas where I lack understanding. I use a model to probe my understanding of topics with instructions to identify areas I might have overlooked. This is useful when researching,

Proofreading and refining my writing

I use language models to proofread my writing and suggest improvements based on my goals and audience. I also use models to help refine specific sentences or paragraphs. If a sentence doesn’t sound right, I’ll ask the model to suggest a clearer way to express it, then I’ll refine it further if needed. It’s about as useful as getting a cursory pass on a first draft from a peer reviewer, but doesn’t take up a human’s time and I can run it as often as I want. It’s pretty good at identifying issues. I still need to find a good and fast way for a model to automatically propose fixes without needing to regenerate an entire document.

Thanks for reading via RSS!

Caveats

Thu, 01 Jan 1970 00:00:00 GMT

Give yourself a break when you don’t hit all your goals for yourself and your team. Even though we work with machines, people aren’t machines and shouldn’t be treated as such. Lack of success today is opportunity for tomorrow. Try and view setbacks as stepping stones.

Thanks for reading via RSS!

Architecture

Thu, 01 Jan 1970 00:00:00 GMT

Avoid unproductive complexity

It can be fun to play with new technology, but be thoughtful when picking spots to try something new. Consider who will need to support the system and whether the additional complexity unnecessarily increases the burden on your teammates.

Know what your systems cost to run

If you use cloud providers’ infrastructure, it’s easy to lose track of what you spend to run your systems. Periodically audit your spend as an engineering team. Knowing what you spend on infrastructure and why will position you well to answer any questions about your teams’ costs.

Adapt your code to be vendor-agnostic*

*Loosely held. Design your system to agnostic to vendors wherever possible. Avoid adopting nomenclature of a third party throughout your systems. Keep this at the system’s edges. For example, at the edge of your system, you may have a DynamoDB record. In the internals of your app, map to a different type.

Design self-healing systems

Expect things to break when you design them and decide how your system will behave when they do. Use queues and retries to avoid involving your oncall for as long as tolerable by the business. When broken systems are restored, all the system to proceed without requiring oncall intervention. If oncall must get involved, proactively write admin tools to assist with mitigation. If you find you’re missing tools that would have helped after an incident, build them for next time.

Thanks for reading via RSS!

Helpful Habits

Thu, 01 Jan 1970 00:00:00 GMT

Take breaks

When I’m struggling to solve a problem, I can get pretty wrapped up in it. Historically, it’s not been uncommon for me to spend several hours, stubbornly grinding through some annoying code issue I’m running into. More often than not, the moment I decide to take some kind of break, I come up with a new approach or the solution outright.

Keep an open mind

Being for or against some technology or approach under all circumstances is very rarely a thoughtful position. Pattern matching can help you move quickly but working from first principles or the baseline requirements needs to be in your wheelhouse as well.

Thanks for reading via RSS!

Oncall

Thu, 01 Jan 1970 00:00:00 GMT

Page only if actionable

Have oncall available and ready to respond if a customer is affected. If an issue can wait until business hours, don’t allow it to page outside business hours.

Invest in runbooks

Make it as easy as possible for an oncall engineer to make the right decision when responding to an incident. These are often high stress and pressure events where we are more prone to make mistakes. We do not want the oncall engineer to need to be a hero to mitigate an issue. We want them to be an effective executor of a predetermined plan.

Escalate when it will make an impact

On the best teams, members have each other’s backs. If an oncall engineer needs help mitigating an issue they were paged for, they should feel comfortable escalating to another engineer who can help. This approach requires a delicate balance. Engineers, particularly more junior ones, need to feel comfortable escalating to ensure issues are mitigated effectively and in a timely manner. However, if escalations are happening too frequently, it can put too much strain on more experienced team members. If escalations are occurring too frequently, you may need to increase your focus on training all team members to be effective at performing oncall duties.

For larger incidents, appoint an incident coordinator

If an issue is high impact enough to declare a broader incident, have a (pretrained) incident coordinator who is responsible for reporting status and pulling the needed group of stakeholders together. The coordinator is directly responsible for determining whether an incident is ongoing and who is participating based on mitigation needs. The coordinator should rely on mitigating and engineers to communicate who and what they need, then makes this happen. The coordinator should also ensure an incident does not drag on past the point that mitigation is still occurring. Knowing how and when to close out an incident is as important as knowing when to open one.

Thanks for reading via RSS!

Ramping up on a new language

Thu, 01 Jan 1970 00:00:00 GMT

Koans

Whenever I start a project in a programming language with which I’m not familiar, I try and find “koans” to do in the language along with my daily work. I’ll spend maybe an hour a day working on these until I complete them (assuming I’m liking the exercises and structure). I think I worked edgecase’s ruby_koans when I first learned Ruby back when I joined Chime. I found it by searching for “ruby koans”. I couldn’t remember if it was this repo at first but then I recalled the “path to enlightenment” metaphor. I personally found Ruby a very unapproachable language for how much “magic” there is — it just doesn’t resonate with me — but these exercises made me someone who can write (and read) Ruby. You can find Koans in many languages easily with a search for “{language} koans”.

Sort of related: Code Koans.

Exercism

I used Exercism a bit. I liked it and was a fan of the experience but the exercises could be a touch too technically involved for me. I generally learn a language better on easy exercises and then separately learn how to apply the language in project work with it. Doing both at once slows down my high-level fluency because I don’t see enough language constructs as quickly as I need to to get familiarity.

Thanks for reading via RSS!

Code

Thu, 01 Jan 1970 00:00:00 GMT

Encode your standards

Make your code look how you would want future contributions to look. Documentation of standards and scaffolding both help, but a lot of code is copy-pasted. With this approach, when your code is copied, new contributions will adhere to your standards by default. Supplement with a code formatter or linter that enforces rules automatically through an IDE, version control or builds. This approaches also helps avoid discussion about style and formatting in code review.

Deploy often

Deploy code when it merges. If your deploy introduces an issue, it will be easier to identify the offending change. Deploy automatically on merges if possible, but limit these to business hours to avoid unintentionally creating issues after hours. An oncall engineer can always deploy manually if they need to.

Thanks for reading via RSS!

Things I used to believe

Thu, 01 Jan 1970 00:00:00 GMT

These are some things I believed about software engineering and personal development that proved not to be as true as I thought they were. Most of this is written from the perspective of my experience working as a software engineering professional.

I’m not the type of person who is good at `X`

This mentality held me back. I may not be a person who is good at X yet, but this type of thought process has usually ensured I don’t get good at X for longer. You’re generally the worst at a skill when you get started. As you learn and apply a skill, you get better. This is how you go from not being good or feeling confident to becoming more skilled and effective. There are no shortcuts, only more and less effective ways to use your time. Figure out what works for you, how you best learn, and what excites and motivates you. Lean into that.

There is generally one good way to build a backend microservice

My first job as an engineer building production software was at Uber in 2016. Uber engineering had a highly opinionated approach to developing microservices that had been “battle tested at scale”. It was heavily inspired by the Clean/Onion architecture, and there was a well written internal document on how to apply approach and reason about structuring an application such that you’d be flexible to scale and rapid change. I internalized this approach as the one true way to build. I’m lucky it was a relatively good approach, but having had several more professional experiences since then, I no longer believe in applying such a one-size-fits all approach. This type of architecture remains my favorite for production microservices, but it requires enough investment that if you’re prototyping or extremely time constrained, it’s likely more effort than it’s worth. It’s a versatile pattern, but not one to be applied thoughtless. Being willing to be less rigid in applying this pattern everywhere helped me grow as an engineer.

If we’d only had the right requirements, we could have built it right the first time

This statement is true but also near impossible to accomplish in the real world. If you work in a dynamic business, you will likely never have all the requirements you’d want to build a software system that will ship in several months. Just as you as the engineer are figuring out how to design the system, the business is figuring out the business model, product and design are figuring out the user journey and experience, and other contributors are figuring out how their responsibilities fit into the greater whole of the project. A change or new learning from any part of the team could trigger necessary adjustments elsewhere. The team can either ignore these new learnings and ship a less effective product, or incorporate it and make adjustments to the initial plan as needed. Unfortunately, a change like this can require many teams to rework existing assumptions and plans and this may feel wasteful, but if the goal is to build the best product possible, it can this be the right decision. I’ve never seen a straight line journey to getting through a complex project. Becoming comfortable and expecting changes to plans will save you frustration and help you design better, in anticipation of inevitable changes to original plans.

You need 100% unit test coverage

At Uber, I was a member of a team with a 100% unit test coverage policy. I didn’t have prior examples to compare to, so I just wrote tests for all my code. Sometimes, getting to 100% required unusually testing approaches, and occasionally I would need to nocover lines to ensure the build wouldn’t flag a decrease in coverage percentage. There are pros and cons to this approach, but like any “best practice”, it’s not to be applied without consideration. There are also diminishing returns to unit testing every line of code. This is not to say you should skip testing edge cases or exception paths, but that not all tests are created equal. If it takes you two hours to get that last line of test coverage, those two hours might have been better spent elsewhere. I still am a proponent of 100% test coverage, but only to highlight unintentionally missed covered lines. I support the use nocover to make this approach more realistic along with comments as to why the test wasn’t worth writing, especially if you went down a rabbit hole trying. This practice helps future you and future contributors.

Dynamically typed languages are better than statically typed languages

The first language I wrote code in was Java in college. Several months later, I learned Python, and it was like a breath of fresh air. Writing code was all of a sudden far easier. I could mostly focus on logic without getting bogged down in types. I was encountering so many new things at the same time that removing types from the picture allowed me to get more comfortable writing and running code. What I didn’t have an appreciation for at the time was that a lack of compile time type checking introduces an entirely new class of errors to a program. I couldn’t have an appreciation for this because I barely had a concept of the difference between an error at compile time versus an error at runtime. By avoiding types, writing code became easier. Maintaining the code would be harder, but I needed to learn that from experience. For what it’s worth, Python is often still the first language I reach for when I need to code something up quickly.

Thanks for reading via RSS!

System

Thu, 01 Jan 1970 00:00:00 GMT

My criteria for note taking

Fast idea capture
Flexible organization system that requires low maintenance or thought about where content should live
Good search
Plaintext

My current setup

I use Obsidian because everything is Markdown. It has a plugin ecosystem, but I find many of these difficult to work with and time consuming to configure. I use Omnisearch for searching notes. I use an iOS shortcut to call the lumberjack plugin to quickly create new notes to capture an idea to be dealt with later. I use the PARA method to organize my content, with an additional of an Inbox. My top level folders are

00 Inbox
10 Projects
20 Areas
30 Resources
40 Archive

I mostly like this because it minimizes the time I spend organizing and has a builtin structure for cleanup. I am reasonably happy with this setup, but I find I don’t benefit much from the time I spend improving it. It seems to be good enough for now.

Workflows

Capture an idea on mobile, quickly using a shortcut app icon
Create notes on Desktop with Obsidian
Search notes on Desktop, mapped to hyper+space
Edit blog drafts on mobile, synced via my Desktop using unison from a local git repo

Current complaints

The Obsidian mobile app is slow to load
Omnisearch occasionally seems to miss some matching files — maybe an issue with its index
Sometimes, I fall behind moving things out of Inbox, but I prefer this to dealing with the overhead of classifying something when I just want to write an idea

Desired improvements

Solve the complaints
A better blog post creation and editing processes for mobile, that doesn’t require sync between the git repo and Obsidian vault

Thanks for reading via RSS!

My writing goals and systems

Thu, 01 Jan 1970 00:00:00 GMT

I wrote this on a plane reflecting on my experience becoming a more consistent writer over the past decade. I intuitively knew writing was something I wanted to be doing, but I had to rearrange my thought process and habits to make it happen.

Goals and systems

My goal is to write about my ideas and things I learn. I aspire to do this and value it because it motivates further thinking and often provides the spark for new ideas and projects I will undertake.

My brain does this thinking whether or not I write. Writing both focuses that thinking process and creates some amount of order from my internal monologue.

I also enjoy working on projects because I find it enjoyable to see ideas come to life and even when things don’t turn out exactly how I had hoped, usually I learn something, which is intrinsically enjoyable to me.

For a long time I’d had the impulse to write and engage in a cycle of thinking and experimenting, but my systems held me back.

Creating a blog

My first challenge was I didn’t have a lens through which to write the work. Independently journaling never resonated with me. There were times over the years where I’ve been able to journal consistently, but the systems that made that possible never seemed to put me in the frame of mind to think about interesting things.

My focus was often what I was doing or more self reflective.

Creating a blog was the first step to solving this challenge. My blog is technical in focus, so it’s the obvious place for my writing about tinkering to go. I created the first version of my blog about 12 years ago but if you look at my post history, just having the blog wasn’t enough to create a system where I was writing, experimenting, and learning.

Actually writing

I’ve personally been quite influenced by the orange website and folks who share their work, projects, and interests. I aspired to contribute my own thoughts and work to a community in a similar way.

When I started writing on my blog or trying to, I often was faced with the Catch 22 of not feeling like I had anything to write about. Occasionally, there would be projects I would do in personal time or at work that yielded interesting results, but I was often keenly aware and self-conscious that what I had to contribute to the conversation was either uninteresting, naive, or potentially wrong.

I’ve since learned that no one reads your blog. This is never more true than when you start, so what you write hardly matters to anyone but you. Just doing something is the best path forward.

If I could go back in time, I would have focused on writing Today I Learned posts consistently starting in 2013. This type of writing and work has several positive functions. It serves as a note to future you on how to do something, either for reference or to be superseded if you learn a new and better way. It also serves as a solution for someone in the future with the same problem you had. Most of the traffic my site receives is to these Today I Learned posts, presumably from people who want to do things like

No one reads your blog

This is no longer literally true for my blog. I get mostly Google traffic with the occasional ChatGPT/Claude/Perplexity/Bing/LinkedIn/etc. but mostly for “how to do X posts”.

Almost zero people have read my post on language models or how to use them. In a way, this is liberating. I have no audience and no expectations to fulfill.

For some reason, having the blog and continuing to write on it and publish is part of a system that makes my process of writing and experimenting continue to work. I write something and then I send it off.

I don’t have to agonize over editing and refining if I don’t want to. I can play with the thought and then move on.

Making more buckets for content

When I first created a blog, the site had posts. This was a bigger problem than I realized for about 10 years.

A post felt like it needed to be formal. A post needed to be well edited. A post needed to say something interesting. A post needed to be worth someone’s time.

These internal preconceptions are the reasons I wish I’d started writing TIL posts earlier. Something I learned today is not obviously interesting or useful to you. It was for me. That was the point I missed for a while.

I write for myself

I don’t write this blog for you, I write it for me. I don’t mean that to be an insult if you are reading, but I’ve tried to write for other people or with a sponsorship focus and it doesn’t satisfy me in the same way.

Once I realized creating additional content sections was helpful for making it easier to just write stuff and not worry about for whom or why, I added several more sections to the site. Logs are like a digital pile of sticky notes with quotes from others and fleeting thoughts or exploration. Garden contains longer essays that I am not finished working on and may never be. Link blog is a collection of thought provoking things I’ve read.

This multi-bucket system has grown organically to help me allow myself to just do stuff and have somewhere to put it if I want to. Logs have been especially helpful for this and I’ve built tools that make it trivially easy to write a log entry from my machine. Running

just log

from within my site project creates a new log entry for the day if one doesn’t exist already and opens it. Then I just write.

Thanks for reading via RSS!