Skip to content

What I wish I had known when I was starting out as a developer

As I get older, I wish I could reach back and give myself advice. Some of it is life advice (take that leap, kiss that girl, take that trip) but a lot of it is career advice.

There’s so much about being a software developer that you learn along the way. This includes technical knowledge like how to tune a database query and how to use a text editor. It also includes non technical knowledge, what some people term “soft skills”. I tend to think they are actually pretty hard, to be honest. Things like:

  • How to help your manager help you
  • Why writing code isn’t always the best solution
  • Mistakes and how to handle them
  • How to view other parts of the business

These skills took me a long time to learn (and I am still learning them to this day) but have had a material impact on my happiness as a developer.

I am so passionate about this topic that I’ve written over 150 blog posts. Where are these? They’re over at another site I’ve been updating for a few years.

And then I went and wrote a book. I learned a bunch of lessons during that process, including the fact that it’s an intense effort. I wrote it with three audiences in mind:

  • The new developer, with less than five years of experience. This book will help them level up.
  • The person considering software development. This book will give them a glimpse of what being a software developer is like.
  • The mentor. This book will serve as a discussion guide for many interesting aspects of development with a mentee.

The book arrives in August. I hope you’ll check it out.

Full details, including ordering information, over at the Letters To A New Developer website.

Corporations Already Showed Us How This Goes

I’m writing in response to Derek Thompson’s fascinating discussion about AI as normal technology.

I believe that we human beings are going to turn more and more things over to AI. There are four data points that illustrate this.

The first is my own personal experience. Like many, I have access to AI that can explain documents and RFCs to me, and I often use it to do so rather than reading these from first principles. It does depend on the length of the document and whether I’m reading it for work or for fun, though.

I also have a habit of asking AI to argue both sides of a particular decision I’m faced with. I still make the decision. But anybody who’s been a secretary in an organization understands that the person who writes down the notes frames the discussion. So I’m relying on AI to frame the problem. Again, my actions after AI suggests alternatives depend on the decision’s impact and how well I know the domain space. There are times I push back but there are times I do not.

The second data point is what we’ve done with the technology of computers as a society up to now. I remember reading Joseph Weizenbaum’s excellent book Computer Power and Human Reason, which I found while I was traveling. It talked about how much of the decision making in the Vietnam War was driven by computer systems. This is happening in 2026 as well.

There’s a spectrum between using AI to make more intelligent decisions (by doing more research) and outsourcing decision-making to AI (by asking it to act on that research). This is because of the framing I mentioned above. You make decisions only based on what you know. If AI is limited to certain data sets, or is making up points in some data sets, or is inclined towards certain data sets, that constrains the decision space, even if a human being is ultimately pressing the “go” button.

Finally, humans have outsourced decisions to non-human entities before. What do I mean by that? I’m not talking about chimpanzees or dolphins. I’m talking about corporations. (A point made by John Scalzi in 2017.)

Anyone who’s ever been laid off knows that there are decisions a corporation makes that an individual human being in that corporation would not necessarily make. Such decisions ensure the life of the corporation and are reflected in the incentive structure for the human beings who are part of the corporation (aka employees). That drives human beings to make decisions they would not make if they were independent. I’ve seen managers racked with guilt and frustration because someone was not a fit for the job, or they had to lay people off, or things weren’t going the way they wanted them to. But they still made the hard decisions, because that is what the structure of the corporation forced them to do.

How does that apply to AI? Anyone who says “AI can’t make more data centers and will be reliant on humans, leaving us in control” needs to answer why AI can’t force humans to do things in the real world the same way a corporation does. When combined with the previous two data points, AI can find humans who are willing to take actions against the interests of humanity.

It doesn’t have to be obvious. AI could split a task that individual humans, if they saw the full picture, would say no to. But with the split task humans can think “oh, this is innocuous, opening this is fine, because there are these other limits”, not knowing the AI has talked to other human beings about relaxing other limits.

The final data point is what we do to protect against any low-probability, high-impact calamity. When you have a very small risk of something very, very bad happening, people buy insurance. Yes, insurance costs money, but a small amount of money paid regularly means the negative impact of a large loss is lower. Why not, as Ezra Klein suggests, slow things down? It would be hard to enforce across every model builder, but certainly the major AI powers, the US and China, could agree to ban techniques like recursive self-improvement. Other entities would keep pushing AI forward, but they don’t have the resources, the money, the software, or the expertise to do so at the same pace. The costs of a slow down are a small price to pay to lower some of the existential risk.

There are two books that have been echoing in my mind about this aspect of things, and I highly recommend you read both. One is a pulp fiction thriller, Daemon. I read it a couple of years ago, and the premise is that a piece of software gains access to and control of the real world through the work of human beings. The other one is Genesis. I read it in the 2000s. It has an amazing twist I still remember. I won’t tell you more, other than that I still remember how powerfully the novel illustrated unintended consequences.

AI has aspects of normal, high-impact technology like electricity or railroads. But there are new aspects too. You cannot ask a steam shovel or a Word document what to do.

When is software done?

This is something I’ve been thinking about recently.

First, let me clarify that when I say software being done, I mean a particular feature. I don’t mean an entire package of software. A standalone application or SaaS software package is never actually done; there’s always new desires and demands from human beings, and all pieces of software must expand until they either send email or build their own messaging inbox because they can’t be bothered to interface with email. The most successful communications protocol in history; but I’m not bitter.

I’d argue that a holistic view of software success actually looks at the user and asks when a certain percentage of them — say, 7% or 15% — are using it. What that exact percentage should be is a matter of art and depends on the feature being built. Not everyone is going to use every feature of every piece of software. You won’t always use every feature of software you write for yourself.

But people are using this feature, and critically, they were able to discover it, and they’re happy that they discovered it, or at least not actively angry about it. Discovery, usage, and happiness. (Look ma, it’s a framework!). If you don’t have all three, you’re in trouble.

What people mean when they say software is “done” depends on where they are in this picture. If you’re a developer focused on a certain set of features, deep in a codebase, whether you’re writing code manually or using some kind of tooling or agents to write code, you might consider the software done when it’s merged to main, or more likely when it’s deployed. That is, when people can interact with it and learn the code the same way jessitron talks about in this beautiful piece. That’s deployment, but it’s only the first step. If you’re a marketing person, you might consider the software or feature done when you’ve launched it: submitted the press release, sent a bunch of emails about it or otherwise tried to engage people and teach them about it. If you’re a business person, you might look for the first deal that was signed because of this software feature, or maybe the first incremental bit of revenue you can point to. If you’re an end user, you might consider a feature done when you use it for the first time. Each of these is really pointing at one leg of the same framework without necessarily covering all three.

So let’s take the “discovery, usage, happiness” framework leg by leg.

Discovery. The cost of creating software has decreased drastically (ahem, AI, ahem). And when the cost of one component of something decreases, what happens to the other pieces? I think you can’t lose track of the ultimate source of value, which is: a user discovers this particular feature, whatever it is, uses it, and is happy about it. Discovery means you have to have users, which is why the go-to-market or distribution side of software is so important. After all if someone doesn’t have your entire software package, they won’t be able to find the cool new feature you just shipped.

Discovery also means your users need to be able to find the new feature of their software. Lots of options for helping them:

  • in-app notifications
  • email
  • a pop-up on a related feature
  • targeted communications because you’ve seen a user explore related features
  • hopping on the phone with them (if you’re a smaller company)
  • a face-to-face conversation and show people what’s new
  • release notes

There are a lot of different ways to do it, and the truth is that you aren’t going to be able to do just one of these. Inform folks the way they want to be told; everybody wants to be communicated with in a different manner.

Usage. After discovery comes usage, which means someone actually trying the feature out, at least a few times. At a base level, it needs to work the way they expect it to. No surprises. If it doesn’t, people won’t get past this stage no matter how well you nailed discovery.

But usage isn’t just about whether it works; it’s about whether it’s worth the effort. The friction of using the feature should be calibrated to the perceived value someone will get from using it. Not the value, the perceived value. And not value for you, the software provider, but for the end user.

For example, if you are adding a feature to enable better recommendations, don’t have a 100 question survey. Ask one or two questions.

Happiness. Happiness is a step beyond usage. It’s someone incorporating the feature into their normal workflow. People don’t use software just to use software; they’re using it to accomplish something in their lives, whether that’s communicating with friends, doing part of their job, or just amusing themselves.

Once something becomes part of how they actually get things done, that’s happiness. And that means it needs to not be a constant churn of change.

If you push too much churn on them (constantly pushing out features, changing interfaces, tweaking things, and not letting people turn new features off) you’re going to make them dissatisfied, and they’ll never fully incorporate it into how they work.

Maybe “happy” is too strong a word. Or maybe you just want people to be content, or at least not upset — it depends on the kind of software you’re using.

And it’s worth saying that people hate change. I hate change myself, so some percentage of your users are always going to be grumpy about it. Don’t want to measure happiness just at the moment they encounter the new feature; that’s usage. Some people, early adopters, will be thrilled to be exploring new areas, while others will be pretty pissed off. So you want to gather that data after a certain period of time has passed.

Have I ever worked somewhere that has this kind of maturity around it? No.

Would I like to? Yeah. I think that if you can close the loop on discovery, usage, and happiness, you can build software that people love, and that becomes a sustainable business.

It doesn’t matter how much your competitors churn out software because it’s cheaper to do; you’ll win if you make software that can be discovered, that people use, and that they like.

What I Learned From Playing “Spelling Bee”

I’ve been playing Spelling Bee for a few weeks now, where you guess words from a selection of seven letters, one of which must be used in every word. The letters are arranged in a hexagon with that primary letter in the middle. If you want to learn more about how to play it, follow the directions here:

For information on how to play, select the More in the top right corner of the game and then select How to Play.

It has surprised me. I have learned that “oleo” is a word and that you can tell how hard the puzzle will be by looking at the rankings.

But what I really wanted to talk about is the lessons I’ve learned from playing and how they can apply to your career.

Switch Things Up

There is a button that can flip around the arrangement of the letters around the hexagon. The primary letter remains in the center, but all the others are moved around randomly. When I first saw that, I thought it was silly. But I found it to be super useful over time. When I’m looking for words, I get stuck. Pressing the rotate button reveals new words because it changes my perspective. Just moving the letters around makes new words visible to me.

In real life, when you feel stuck, you can sometimes make progress by flipping things around. I’ve done this in my career.

I quit my first head of engineering job where I was trusted by the CEO, had loads of autonomy and worked on software that helped people find homes they loved. After, I enjoyed the freedom of lucrative contracting and learned a ton about other tech stacks.

I took a quarter life sabbatical when I was around 25. After months of leisure, I learned that, yes, I really did like reading about parsing XML.

I left the food-focused startup I’d co-founded (an area I’d dreamed of working in) which had just raised a seed round. Departing led me to an entirely different area of the software industry that I love and never would have explored at the startup.

There are of course other ways to gain new perspective than quitting jobs: changing routines, asking friends for advice, or even taking a new route to work. Before you give up on something, flip the script and see what the results are.

Just Try Something

Sometimes you just have to try things. I will often put in words that I know are not valid, just mashing different combinations of vowels and consonants, like “manu”. This is not an English word, nor will it ever be. Spelling Bee also disallows proper nouns and three-letter words, but I’ve definitely put in plenty of those. Even though these are all invalid moves, they are movement. This helps me not feel like an idiot just staring at a phone screen. Even better, it can trigger other ideas. It’s a lot easier for me to visualize a full English word when I see part of it, rather than staring at those seven letters in a hexagon. After typing “manu” I found “manual”.

There is value in just taking a step forward if you aren’t sure what to do. If you have some kind of goal in mind but aren’t sure how to get there, do something. Take a step towards that goal.

If you are trying to get a job in the software industry, especially right now, it can feel overwhelming: so hard, so difficult. But you can take concrete steps towards that goal that are smaller. These steps, when you’re looking at them, may not make 100% sense and won’t make you money. But they are helping you on the path towards employment, and will lead to other steps to take that will get you closer to the goal.

I’ve written before about how attending meetups is a fantastic career move. Doing so doesn’t have an immediate payoff, which is super frustrating when you’re trying to find a job, when your bills are piling up and your savings are draining. It’s super hard to think “I’m going to take an hour out of my day and go hang out with geeks talking about ruby“. But joining a meetup can open up other doors.

Just like typing “manu” reveals “manual,” going to a meetup repeatedly can help you get a reputation in a community, offer contract opportunities, let you understand the market, and may help you get a job. This is just one example. There are a thousand different steps you can take towards your goal. It can be hard to determine which step is the right step, but the lucky thing is that there are many right steps. You just have to start.

Double Down On What Works

I like to double down when I have a pattern that is working. In Spelling Bee, if you see a pattern of “ull” being a portion of a word, you should double down on that while you’re thinking about it, and make all of the “ull” words you can. Same with suffixes like “ed” or “ing”. When I see that, I know that I can spell both the initial word like “mint” and get more points by adding “ing” to get “minting”.

Even though I have 100% been guilty of a grass-is-greener outlook in my life, where I think, “oh, I’m frustrated with this company, or in this position, or with this situation, it’ll be better over <somewhere else>”. But after 25 years in software development, I know that every place has its issues. I was recently talking to a former colleague, and he was just hired at a super impressive top-tier company. He was talking about some of the issues they have and some of the burning fires. I would not have suspected it from the outside, because they look like they’re killing it.

Sometimes, you should look for the good things in your current position and double down on them. This isn’t the same as staying stuck; it’s the opposite of that. Instead, this is about noticing when something is actually working and resisting the urge to abandon it just because it’s familiar. Switching helps when nothing is working; doubling down helps when something is.

What does it look like? It might be working a bit extra, taking some free time to study for an employer-funded professional certificate, making small improvements to your team’s workflow, or just bringing your best self to work every day. All of these are taking what works and doing more of it. Double down on what is currently working for you, and it’ll make you happier and you’ll score more points.

Three lessons I learned from the Spelling Bee game: switch things up, just try something, and double down on what works.

Who knew that looking for words could be so educational?

What It’s Like To Lead An Engineering Org: Thoughts On “CTO In The Loop”

I just read CTO In The Loop by Balki Kodarapu. It’s free on Kindle through July 20th, so if you want to give it a read, go do that now.

It’s a narrative arc following a developer, “Sam”, who starts as a software engineer at a startup, and ends up a fractional CTO after a career that includes engineering manager, director of engineering and VP of engineering at a company that IPOs. The book was a fun read, and does a good job describing what it’s like to build a company and a software business from the early days to a more mature organization.

The realities of Sam’s growth ring true: he starts out focused on features and clarity, and then moves up levels of abstraction. He loses touch with tasks and areas that used to matter, but gains higher level views and more ability to influence the organization. As a director, if you’re still reviewing PRs the way you used to, you’re basically breaking your organization

We also see the evolution of several other characters, including Priya the project manager, Mei the UX designer and Jack the senior developer. Some of these folks stay with Sam across companies, while others pop in and out, just like real world colleagues.

Some details felt a little forced; for example, locking down a GitHub repo and preventing merges to the main branch are treated as a major effort, when most software shops do that pretty early.

I especially liked the portrayal of the thorny moments of management that Sam encounters:

  • firing a team member
  • multiple rounds of layoffs (and subsequent hiring)
  • changing his understanding of the constraints and goals of the engineering org he is in

I also really enjoyed the emphasis on integrity, and how the protagonist was repeatedly challenged to hold onto it through different stages of business growth. I think integrity is an easy thing to write about and much harder to actually live. In the moment, you tell yourself that just this one tweak that you might feel uneasy about will move the business in a positive direction. But doing this repeatedly only works in the short term.

The benefit is immediate and the cost is deferred, and avoiding these kinds of decisions is a constant challenge as an organization grows.

The hard part is that it’s rarely obvious where the line is. Most people agree you shouldn’t commit fraud. But there are dark UX patterns that benefit the business. For example, you could make it much harder to unsubscribe from a service than it was to subscribe; every organizational incentive points that direction.

Another example is the integrity in making it easy for a customer to leave: making it easy for people to export their data and take it with them. That’s a frustrating tradeoff for whoever’s job it is to sell the product, but it’s a pretty clear-cut example of integrity. You want to earn people’s business, not hold their data hostage.

There are other places integrity shows up over the course of a career, but the author does a good job of showing how it is hard to maintain, especially when you are focused on the day to day of building a software business.

CTO In the Loop is a fun, easy read. I read it on the Kindle app in about 2 days while on a vacation. I’d highly recommend it to people early or mid-career in software who are curious what life looks like at a different level of the org chart. When I was younger, I assumed people at higher levels had a lot more control, agency, and power. That’s true, but they are also further from the customer, removed from knowledge of how technical systems actually work, and have a lot less clarity about the day to day. To say nothing of many competing demands that folks at the director or higher level have on them.

Writing code, or telling an AI how to write code, is one thing. Thinking about what the company looks like in one year or five, how to bring different teams together, how to manage investors and understand the market, and how to keep every department rowing in the same direction: that’s a tremendously difficult job. This book is an accessible narrative of those tensions, to which I don’t think new or even mid-career developers usually get exposure.

So go check it out. Did I mention it’s free on Kindle through July 20th?

Balki, thanks for writing this excellent, interesting fable of a software developer’s career.

What I Don’t See When I’m Envious

I’m getting to the age where peers have accomplished a lot. I’m not talking about people who were exceptional out of the gate and did great things in their 20s and 30s. I’m talking about people that felt like genuine peers, but now have done things like:

  • made a boatload of money
  • built a business such that they have all kinds of freedom
  • are well known in their fields

These folks have things that I want. And I feel like I’m just as talented. I could be where they are and have what they have.

In my mind I often think “why does <X> have that and I don’t”. This envy is not constructive, but that doesn’t stop it from popping up from time to time. I think I’m getting old enough that status and legacy are starting to matter in a way they didn’t a decade ago.

Here are strategies I use to combat envy:

  • Remind myself that I don’t actually know everything they have. I can see certain aspects of their life, but even for close friends I don’t know everything, just what they choose to share. The friend who is a professor who works with interesting projects and gets the summers off might have to deal with horrible politics or a low salary. I just don’t know. That means I don’t know enough to know if I’d actually want to trade places. I am idealizing what they have and not understanding the downsides.
  • Even if I would want to trade places, I don’t know what they went through. When I see a friend with the thriving business who has flexibility and can work when he wants, I don’t see everything. I don’t see how he had to be tethered to it for years, or the risks he had to take, or the multiple years of 60+ hour workweeks and the stress that wrought on his body, family and friends. I try to imagine the late nights and the worries in the same way I imagine the benefits.
  • Remind myself that I have agency and can work toward what they have. Even though I’m mid-career, if I wanted to adjust things to move towards what someone I see has, I can do so. As mentioned above, I need to be willing to make sacrifices, but I am lucky enough to have the space to consider it. With sufficient focus and effort, I can do most anything, I just can’t do everything.
  • Even if I want to trade places with a friend, know what would make me happy, and would have been willing to make the sacrifices to be where they are, I am still discounting my current situation. It’s very easy to think “oh, <Y> would make me happy” but if I can’t look at where I am and be grateful, I might be kidding myself. And when I do take a hard look at where I am, I do feel more gratitude and satisfaction. One of my hacks when I’m feeling down is to just list 2-3 things that I like about my life.
  • Related to feeling grateful for what I have, I also try to remember that just as I am looking at people and saying “why can’t I have what they have”, other folks might be looking at me and saying the same. In fact, I might have said the same 20 years ago if I was looking at someone where I am now. It’s easy to discount what you have and focus on what you don’t, but thinking about these folks makes me more grateful for what I do have.

I’d be surprised if I’m alone in feeling this way. Do you feel envious? If so, how do you deal with it?

AI Can’t Care

I saw one post recently discussing how AI can’t substitute for judgment. There are many others if you search. And they all make an interesting argument.

But to me what feels more true is that AI can’t substitute for caring.

AI doesn’t care if the answer’s right or wrong. It doesn’t care if you were led down a rabbit hole only to find a dead end. It doesn’t care if a reader wasted their time or got a response that doesn’t actually address their question or need.

However, AI is good at giving feedback, checking details, and letting you create more quickly. AI should be used to help you draft but never publish. Use AI as a thought partner, a research assistant, someone who can help give you synonyms, reword a tough passage, review your work; but never take something AI creates and just publish it.

Why? AI can’t care.

But caring about your reader is the root of communication.

You can feel it when someone doesn’t care about their audience. We’ve all seen those LinkedIn posts full of emojis, or blog posts that have a smell that screams AI. That doesn’t mean the concepts explored are useless. It doesn’t indicate that the poster is incorrect. It doesn’t mean the post is not going to get engagement.

A post that AI creates may get seen or shared. But it also devalues the reader. When someone does this, it means they don’t give a damn. They don’t care enough to realize what they’re putting out there is not valuing their readers’ time.

Why would you pay attention to someone who doesn’t care about your time?

Everyone who reads something online, whether they scan it or read it deeply, is giving you the precious gift of their time.

Even oil we can make more of. But not time.

So use AI as a tool to help you move faster. But don’t forget to care about what you publish. That means carefully reviewing AI output to ensure correctness.

Otherwise you’re burning your reader’s trust.

Meetings are forcing functions

A recurring meeting serves as a powerful forcing function for long-running projects.

Many organizations face a common challenge: a complex project that requires effort and perspectives from multiple people, moves through definition and execution phases, and unfolds over weeks, months, or years. But one where the tasks to accomplish the project are not anyone’s full-time job.

Everyone has other obligations, fires to put out, and emails to answer. It’s easy for long-term strategic, high-impact work to sink to the bottom of everyone’s todo list.

One effective solution is to schedule a standing meeting. Whether in person or video, it doesn’t matter. The key to making progress is maintaining an agenda and, critically, opening each meeting by reviewing the to-dos from the previous one. This creates pressure on everyone to make progress. When people know they’ll be asked “what’s the status of X that we talked about last week?” at an upcoming meeting, it is easier, though not easy, to carve out time for that work amid the daily chaos.

This approach works across organizational boundaries too. If you’re a consulting firm, a regular cadence of meetings with your client is especially valuable. You’re  motivated to deliver., but people on the client’s team may be less so. A meeting where you consistently show progress while they haven’t made any creates gentle but real accountability.

If you’re managing a large, complex, multi-person effort, consider the standing meeting. As far as schedule, weekly, bi-weekly, or monthly all have worked for me in the past. Pick whatever fits the urgency.

Use a meeting as a forcing function to ensure people actually make time to move the project forward.

The Nepotism That Isn’t

This is something I’ve learned over the years, having watched it happen at company after company. I thought it was worth documenting for future me.

When I was a young programmer in the early 2000s, I was at a consulting company that took on investment money and brought in a new CEO and new executives. The original founder and other members of the old executive team were slowly pushed aside.

I remember watching the new executives bring in their own people, and I remember thinking: wow, that’s really crappy:

  • They don’t want to leverage what got us here.
  • They don’t value the current talent.
  • They don’t understand the company.

And frankly, I thought it was nepotism. New folks were hired into the company at a high level because of who they knew.

Boy, was I wrong.

The honest truth is that running a company is hard. Coming in to run a company is very hard. You’re typically brought in precisely because what worked before isn’t working anymore. (There’s the occasional case where someone is ready to leave for personal or professional reasons.)

I don’t think most VC firms or investors have any desire to have friends or former colleagues running their portfolio companies. They would much rather those companies be doing great and not requiring any additional time or thought.

But that doesn’t always happen, and sometimes a company needs some attention.

When you bring someone new in at the top, you often cast a reasonably wide net. An executive search for a new CMO, CRO, or especially a CEO starts with your network, but search teams also look in other places.

However, the executives who are brought in don’t always have the same scope when it comes to hiring the people right below them:

  • someone to lead demand generation
  • a new engineering manager
  • a VP of something

So what do they do?

Think about it: what would you do if you were under significant pressure, still getting up to speed, and needed to find someone you could trust to execute on a vision you were still figuring out yourself?

I know what I would do. I would tap my network. I would go find people I’d worked with before, people I trusted. There are people I can think of right now who, if I had the budget, I would hire without question. There aren’t many people I trust wholeheartedly, but they exist.

That is what I was watching play out back in the early 2000s, without understanding.

I was seeing executives come in under real pressure to deliver, still learning the environment, and doing what any human being would do: hiring people they knew, people they trusted.

Reflections from the February AI Builders Meetup

I just went to the latest AI Builders Meetup and it was really fascinating. It reminded me of the years of the Boulder-Denver New Tech Meetup, where there was so much energy in the room. There were people who flooded the meetup talking about all of the interesting things they were building.

This meetup was similar.

There was also the same kind of supporting infrastructure with companies willing to throw around money. For instance, at this meeting, there was plenty of beer and pizza. It was at Founder Central and there was plenty of space.

I have been part of other meetups where it’s very, very hard to find space or money for pizza. AI is such a hot topic right now that it is relatively easy to find space and sponsors, such as service providers or VC firms who want to pony up.

There were over 500 RSVPs. I don’t know how many people attended, but there were hundreds of people there.

As far as the presentations, they were demos and varied quite a bit.

Some were over my head. For instance, the folks that use the transformer architecture to predict and build audiences for drug trials. I understood the general concepts, but some of the technical details went beyond me. Still a really cool technical overview from Branchlab.

There was also a presentation about building personalized apps using Wabi.ai. I thought that was interesting but a little bit hard for me to understand why people would care about building their own apps. But I was never someone with a personalized ringtone or even stickers on my laptop, so I might not be the target market.

The next presentation was a demo from FreePlay, one of the sponsors. They were filling in for a talk that bailed; it wasn’t intentional. They covered how they built an agent to help people improve their prompts inside their eval system. They shared a Notion doc which had some learnings on building this agent, which were pretty useful. I think one of the key points that I took away was that cross-model optimization is really hard. Each of the models has their own wrinkles and idiosyncrasies, and it’s really hard to build cross-model applications or agents. You can work around some of the issues by aiming for lowest common denominator.

Another presentation was about Mai-Tai, an open source framework which lets you access coding agents from your phone. This was kind of a cool, interesting way to use a phone before Claude’s or OpenAI’s tools existed. It seemed really developer-focused; they’re looking for PRs.

The final project was really interesting to me. It was from one of the founders of Slider. It showed how you can automate constraints around agents and how that leads to better outcomes. In this case, they were doing that with design systems. They built a way to have an agent have ground rules and understanding around building applications with a certain design system, like a Workday application.

This was interesting to me from a number of perspectives. The first is that I’ve been thinking a lot about authorization as one of those guardrails and how that interacts. The second thing that struck me was when he talked about compilation checks versus runtime checks. Runtime checks are better-crafted prompts, and compilation checks are enforceable, deterministic guardrails like linters or authorization. He kind of didn’t want to give away all the secret sauce, so he didn’t dig into all of those deterministic checks. But to me, that seems like it’s where we’re headed. With this approach, you get the best of both worlds: the non-determinism to let an agent accomplish ill-defined tasks, and good guardrails to keep it from doing things it should not.

All in all, it was a great meetup.

Top Professional Accomplishments

Not to get maudlin, but it is fun to think about accomplishments over the years. The days are long, but the years are short, and I can’t believe I’ve been working in software development for more than two and a half decades.

My top professional accomplishments include:

  • Writing a book for a known publisher
  • Co-founding a startup that is still alive and kicking (5+ years after I left)
  • Running my own consulting business for about 8 years, and making a decent living from it
  • My time at FusionAuth; I’ve worn a bunch of different hats with real impact on the direction and culture of the company
  • Presenting at marquis conferences like Identiverse
  • Co-organizing the Boulder Ruby for about 5 years
  • Supporting the website of one of the biggest sporting events in the world
  • Keeping this tech blog running for over 20 years