German Velasco

Daily writing retrospective

2026-06-02T00:00:00+00:00

Back in April, I decided to write daily for my newsletter. Up to that point, my newsletter was mostly a delivery mechanism for my blog. But I wanted to change that. I wanted to write more.

This is what I said in my first post:

It’s been a while since I’ve written in my newsletter (hope you’re still here!)

In this age of AI, I find that I want to write more (not less) in my own voice. To me, writing is thinking, and I have a lot of thoughts rolling in my brain that I want to clarify and solidify – so what better way to do that than to write?

But I have to dust some cobwebs.

Well, I love Martin Fowler’s “if it hurts, do it more often” aphorism. I frequently say it in programming or business circles. Why shouldn’t it apply to writing as well?

So, I’m going to try to write daily (for 30 days) and see if it sticks. At least for week days (weekends might be tough). If that’s not interesting to you, you can always unsubscribe. But before you do so, give me a chance!

I hope that what I write is useful to you.

More than anything, I’d love to also hear from you.

If I write something that interests you or sparks something in your mind, I’d love to hear it. Maybe this can become more of a conversation than me screaming into the void.

Well… that’s it. Hope you enjoy the ride with me.

Best,

German

In my typical retrospective format, I’ll ask:

What went well?
What went wrong?
What could we improve?

What went well?

First, the wins.

I wrote a lot more!

I wrote 29 posts in a span of ~40 days. I missed some days. But for the most part, writing daily – and publishing daily – was a tremendous forcing function.

Nothing like a good deadline to force yourself to just ship.

It wasn’t easy. I had to make time for writing (typically at 5am), since I didn’t have time otherwise. And it took about an hour to write each short post. But I loved being able to ship daily, even when I wasn’t fully satisfied with what I wrote. (Don’t let perfect be the enemy of good, right?)

I published blog posts

Out of that daily writing, I also created three blog posts:

It helped me think

In my first post I said “to me writing is thinking”. And boy did it get me thinking.

Because I had to write daily, I was constantly thinking of what I would write the next day, jotting down some ideas and notes, and it did help me work through some of the “thoughts” I had in my head (the ones I mentioned in my first post).

It helped me connect with readers

One of the coolest things was when a reader responded to a post. I love connecting with others over ideas. And a few people responded to some of my posts excitedly agreeing, asking questions, or offering their perspective.

It was honestly one of the best surprises about writing daily. Before I started, I didn’t know what to expect: either utter silence or perhaps outrage (those are the fears in our heads). Instead, people were interested and excited.

To those of you who wrote back, thank you!

Because I connected with readers, and because I have now made my newsletter into a vehicle that is more than just delivering blog posts, I feel comfortable writing there.

That may not seem big, but it’s a huge win for me.

Before this exercise, I felt like my newsletter had an implicit agreement that it was purely a delivery mechanism for blog posts. After 29 posts, I think the people who only wanted it for that reason have unsubscribed. :)

So, overall, I’m very glad I did it. But I want to make some changes. So, on to the what went wrong section.

What went wrong?

It’s costly

I loved the forcing function of writing daily. But the reality is that it is hard to always wake up at 5am and write.

Sleep is very important to me. Due to previous health issues, I try to prioritize sleep as much as possible, and my kids are also grateful when I’m not grumpy and tired. And though I wish I didn’t need as much sleep as I do, I think making sure I sleep well is the right trade-off.

I also have a bad habit of wanting to do too many things. So, as I was writing daily, I was also exploring new AI workflows, recording a couple of remote pairing sessions (which I’m still editing), and trying to get more information on how other teams are using AI. Oh, and I also had to do my regular consulting job. That’s a lot to fit into a single week.

So, even though I love writing daily, there are days when it is more important that I get an extra hour of sleep or that I edit a video.

I forgot to decouple deployments from releasing

Another huge problem was that by writing daily, I meant publishing daily.

In software, I always encourage teams to decouple deployments from releasing software to customers. We tend to use feature flags for that. That way, you can deploy whenever you want – ideally continuously. But you only release a feature when it’s ready.

Well, if I’d done that with writing, I could have written daily but only published when I felt ready. In that case, I might have felt differently about some of my posts.

Which brings me to the next point.

Some ideas need more space and time

Publishing daily meant I couldn’t fully work out some of the thornier ideas in my head.

Some writing just doesn’t fit into a single day – or into a single email, for that matter. Many thoughts are just complicated, and I feel like I have to untangle them before I can write about them.

I mean, that’s part of the beauty of writing: it forces you to work out those complicated topics until you can explain them simply. But because I had to publish something every day, I just couldn’t spend the time I needed on the thornier ideas.

So, publishing daily sometimes forced me to write about a simpler idea at the cost of refining a thornier one.

Posts are siloed

This is a good and a bad thing.

Because posts are not available in the general internet (unlike a blog post is), I felt more okay with publishing things that I wouldn’t have otherwise. I don’t mean that the posts were bad, but there’s an internal pressure when I publish a blog post that I have to make sure it’s really good because some unknown masses will read it.

In reality, for all I know, more people actually read the newsletter posts than my blog posts. But because the blog posts are “out there”, I feel that pressure. And that pressure can lead to not writing. So, the siloing can be a good thing.

But it’s definitely sad that they’re siloed.

I want to write to communicate with others. And I love blogs because to me they are part of the beautiful fabric of the internet. People sharing learnings, lessons, and ideas without gatekeeping. So, I’m a little sad that I have things written that live in emails and cannot be easily shared.

What could we improve?

Having said all that, I hope to make some tweaks.

I won’t continue to put the must-publish-daily pressure on myself. I wish I didn’t have to remove that (I like the forcing function), but I have to prioritize other things right now.

But that doesn’t mean I’ll stop writing!

On the contrary, I hope to continue to write more. I’ll still make 5am my writing time. It works most days. I just might not be able to hit it daily.

And I will continue writing in my newsletter. But I hope to publish a lot more to my blog as well. In a way, I would love it if I could write daily on my blog. That’s a bit wild, but I think it’s the ideal.

And I also hope to make my newsletter more of a 2-way channel.

I want to continue connecting directly with readers of the newsletter. That was one of my favorite parts of writing daily, so I’m really hoping I continue doing that.

Write to me or send me your blog!

Finally, some parting thoughts.

First, if you’re reading this, thanks for reading! Thank you for giving me some of your precious time.

Second, I encourage you to write more! (Make sure you write, not the robots!)

If you’d like a reader, send me an email and send me your blog. I love discovering new blogs to read.

Thinking about the extremes to break out of local maxima

2026-05-22T00:00:00+00:00

Thinking about the extremes is a powerful tool to help refine our intuition, unearth second-order effects, discover novel ways of doing things, and generally find alternate solutions to problems when we’re stuck.

Think of it like this: you’re a person trying to climb a hill.

One way to do that is to take a step in any direction. If you discover that the next step is higher than your previous one, great! You’re making progress.

You repeat that process over and over again, taking one step at a time. Each time, you check if you’re higher than before. If you are, you’re going uphill!

That’s marginal improvement, and it’s typically good. After only a finite number of steps, you’ll reach the top of the hill.

But once you’re at the top, any step you take will be a step downhill. You’ve reached a maximum.

How can you reach higher places? You can’t use the same “one small step” mentality. You actually need to change your approach.

And that’s where thinking about extremes can be helpful.

It’s only by thinking, “how can I climb Mount Everest?” that you realize you might need to get on a plane and fly to Nepal.

I think the same is true in business and software development. You can often get very far by making the next marginal improvement. One step at a time is good! You might even reach some heights. But at some point, you’ll likely get stuck in a local maximum. And it’s at that point that thinking about the extremes can help.

Consider this example. If you’re only trying to grow your revenue by 3% this year, you’ll probably focus on marginal improvements. But if you start thinking about how you can double or triple your revenue this year, you’ll come up with some wild, new ideas because you have to. There’s no other way to reach that goal.

Or think about query optimization in software development. You might try to optimize the query as much as possible. But at some point, you can’t make it any faster (you’ve hit a local minimum). If you think about the extreme you might ask, what if we could avoid making the database call altogether? You might discover a way to support the feature without that query or a different way to get the same information.

Steady progress is good and important. But every once in a while, you get stuck. That’s a good time to start thinking about the extremes.

Pair-programming is a cheat code

2026-05-01T00:00:00+00:00

I had that written on my office whiteboard for a while last year.

I had just finished working with a client for over a year where the whole team pair-programmed full-time (we also did a lot of mobbing).

I was then starting work with a new client, and I wanted to remind myself to push for pair-programming as much as possible because it is a cheat code for developers AND for businesses.

Here are some of “cheats” pair-programming gives you.

Pair-programming increases decision speed

I think this is one of the most underrated benefits of pair-programming.

When we’re building software, there are countless decisions we have to make. Those decisions take time. And frequently, they take coordination across teams. That’s really costly.

And those decisions tend to have ramifications that compound.

It’s typically cheaper for a business to change course early in the feature-development lifecycle. So, you want to arrive at the right decision as early as possible. With pair-programming, you have two people with full context able to bounce ideas off each other, challenge assumptions, and refine solutions quickly.

Compare that to finishing your feature, opening a pull-request, and waiting a few hours (or days) for someone to then question a piece of work. You go back and forth on alternatives (what you would’ve done with a pair at the moment you were coding that thing), and finally, you have to rewrite large pieces of the code because the decision made early informed the design of the whole feature.

Code-review is done in real-time with full context

It’s sad that most companies have a culture of doing code-review through pull-requests. GitHub has been a huge influence in that. And it’s a great model for low-trust environments (where PR author and reviewer don’t know each other). There’s high friction, and that’s a good thing.

But your company should be a high-trust environment. You know your team. You sync with them daily! So, to do code-review in the same slow, async way we do with open-source code seems suboptimal.

And when you’re reviewing a pull-request, you’re often missing context for the work that’s being done, decisions made along the way, and sometimes why the team is even building a given feature. So, as the reviewer, you have to either gain a lot of context to review the code well, or your review is worse than it would be if you had all that context.

Well, do you know who has all that context? The pair. And the pair can review the code as they write it.

That doesn’t mean others can’t look at the code. If you’re working on something gnarly that you want more eyes on, you can always tap another pair and ask them to do a review on a call. All of a sudden you have 4 people (2 pairs) reviewing the code while it’s being written. Very effective and efficient.

Knowledge transfer happens naturally

In programming, we’re always talking about the bus factor or domain knowledge silos. We don’t want a single developer to “own” a piece of code, and if they leave the company, get sick, or get hit by a bus, nobody else knows how to touch it.

(Also, note that they’re likely the only person who can review PRs related to that area of the codebase. Makes that PR problem even worse!)

So, teams tend to need to put a lot of effort into artifacts (documentation, videos, etc.) that can share that knowledge with other developers in case that bus really comes.

But documentation is costly and at best a proxy. Usually, it’s out of date and incomplete.

The code is the source of truth and the full specification of what our application currently does. So, it would be nice if we could rely on that. Of course, it takes time for people to gain knowledge of a particular domain in the codebase.

That’s where switching pairs frequently helps tremendously.

If you frequently switch who you pair with, that siloed context is immediately spread out across the team. The more you switch pairs, the more the context spreads. You don’t have to do anything special (other than rotate pairs).

Pair-programming is the best way to teach junior developers

And since sharing context is so easy with pair-programming, it’s also one of the best ways to teach junior developers. I’ve seen junior developers get good at an alarmingly fast pace. And they’ll ask the best questions, questions that frankly make you (the senior developer) better at your craft.

Pair-programming helps developers learn better ways to work and solve problems

The previous point leads to this one.

When you’re pair-programming, people have insight into how you work, not just the final code in a pull-request. That is phenomenal for two reasons:

a) Others learn from things you do. Things they didn’t even know were possible! It opens minds to whole new categories.
b) You learn from questions your pair asks! It’s amazing how a simple question can lead you to realize you haven’t re-evaluated the best way to solve a problem in many years.

(And note that we’re all switching between (a) and (b) all the time. I learn from you and you learn from me. And we both ask questions of each other.)

Is it still useful in an AI world?

Yes, yes it is!

Programming with AI is changing rapidly. How can your team learn to use these new tools as fast as possible?

I think there’s no better way to do that (and to develop best practices) than to pair a lot and rotate pairs frequently.

Think about it the other way. The more you silo information by not pairing, the slower the spread of knowledge and good practices. So, pair-programming is even more (not less) useful in this world full of LLMs.

Give it a try

There are more reasons why pair-programming is a cheat code, but hopefully those are good enough to give you a taste of the value it can bring to your team.

If your team doesn’t do pair-programming, I encourage you to give it a real try. Read a little about how to do it well (and there are ways to do it well and ways to do it poorly). And stick with it. It’s a skill that needs to be learned, so don’t expect to be immediately proficient at it.

What Managerial Economics can tell us about AI and Software Development

2026-04-23T00:00:00+00:00

Charlie Munger used to analyze investments by having a latticework of interdisciplinary mental models of how the world worked.

And I love the idea.

I don’t have as many as he did (I believe he had 80-90 mental models), and many of mine come from my Economics background. So, perhaps they’re not very “well rounded”. But they sure are useful!

The mental model I’ve been thinking about lately comes from Managerial Economics. It’s a framework for analyzing how a firm can trade off capital and labor to produce goods. And I think it’s helpful for Software Developers in this new age of AI.

It can help us think about questions like these:

What happens if the cost of LLMs drops dramatically?
What happens if AI is a great replacement for Software Developers?
What happens if AI is merely a tool for Software Developers?

Now, hold on to your hat. To fully understand the framework, we have to have the basics down. So, we have to take a detour into isoquant and isocost lines. I promise it won’t be too painful.

And in each section, we’ll see how we can apply it to our analysis of Software Developers and AI:

Isoquant curves and Isocost Lines
Perfect substitutes
Perfect complements
Are AI and Software Developers substitutes or complements?

Isoquant curves and Isocost Lines

Isoquant curves

Isoquants are the lines along which one input can be substituted for another while maintaining the same level of output.

And they’re typically drawn something like this:

That graph has two inputs (X and Y) and it shows 3 isoquants (Q1, Q2, Q3). The further up and to the right the isoquant, the higher the output (so, Q3 > Q2 > Q1). And the Marginal Rate of Technical Substitution (MRTS) is the slope at a given point on one of those curves.

At its core, MRTS compares 2 inputs to each other, and it tells you how much of one input you need to reduce to get one more unit of the other while keeping output constant.

That “while keeping output constant” is important.

In our analysis, we’ll consider the two inputs to be capital and labor – those are both very generic, but they also map somewhat neatly to LLMs/AI and Software Developers. And you can consider output to be anything the business owner is interested in – number of features, a stable, bug-free product, number of stories done, etc.

The isoquant curves tend to have a curvature like that (convex to the origin) because along the curve you have diminishing MRTS. That is, typically, you cannot simply go all capital and no labor (or vice versa) and still have the same output. You need both.

It’s helpful to think about it in the extremes to see how it works: if you have zero capital and all labor, adding one unit of capital might be very beneficial. And it would allow the business to reduce labor by a lot (while keeping output constant).

For just a second, let’s forget AIs and Software Devs. Think instead of 10 people digging a hole with spoons, and then you introduce a shovel. You might only need 2 people with 2 shovels to dig the same number of holes.

But at some point, the value of adding more capital doesn’t help your output. A single person with 3 shovels won’t dig any more holes. So the rate at which you trade-off labor for capital diminishes the further you go to the extremes.

It’s worth noting, all things being equal, a business owner would typically like to be in higher isoquant (to make more holes, produce more, and make more money). But given a fixed output, they can only move within a given isoquant. So, the business owner has to choose how much labor and capital to have.

But how do they choose?

For that, we want to look at cost.

Isocost Lines

We assume the business has a budget constraint. That is, we assume that they want to make more money, and if they produced more “output” (however we define that), they would make more of it.

But they have costs – and in our particular case, they have capital and labor costs.

So, we would have something like this:

C = C_labor * Q_labor + C_capital * Q_capital

Or in typical Economics notation:

C = rK + wL

That is cost is equal to the wage w, times the quantity of labor L, plus the cost of renting capital r times the quantity of capital K.

An isocost line shows all combinations of capital and labor that cost the same C.

We can neatly graph an isocost line (notice the constant negative slope):

How to choose optimum capital-labor combination

So, as with much of modern economics, the question becomes one of optimization.

What’s the optimal use of capital and labor (to minimize cost) for a given level of output?

The solution to that is the point at which MRTS is equal to the slope of the isoquant line. In other words, the point at which the isoquant curve touches the isocost line in the graph above (at that point, the slopes are the same).

At that point, the business owner is keeping their cost C, and they have the best combination of capital and labor to get that level of output.

Capital (AI) and Labor (Software Developers)

So, how do we apply this to AI and Software Devs?

Well, remember this is just a model. So we’re making many simplifications and assumptions.

If we treat Software Developers in the pre LLM world as labor, and AI as a new capital (think of a new shovel), we have to realize that businesses are going to start making a trade-off between the amount of capital and labor they use.

In particular, they’ll likely grow the amount they spend on AI while decreasing the amount they spend on Software Developers (all other things being equal).

That doesn’t mean that software developers will get paid less (it might, but that’s not the implication here). It means that for a given software product (keeping output constant), a business owner will likely spend more of their “software” budget on AI and less on Software Developers than they were doing previously. And they will do so until we reach a new equilibrium point where the MRTS between labor and capital is equal to the slope of the isocost line.

I’ve actually seen that already happening in companies. Their budgets planned for 2026 include fewer developers than originally anticipated and larger AI budgets. So, they’re actively moving money previously allocated for new hires into paying for LLMs.

Now, there are more implications and further analysis we can do here. For example, we can use the model to understand what happens if the cost of LLMs drops radically.

But first, I think it’s helpful to think of the extremes in order to develop more intuition around the framework.

To that end, we’ll look at two scenarios:

What happens if LLMs and Software Developers are perfect substitutes (the dreaded dark factory)
What happens if they are perfect complements (they just make us devs more productive).

Perfect substitutes

Let’s first see a scenario where AI is a perfect substitute for Software Developers.

That’s the dreaded dark factory where developers are completely replaced by AI. You can imagine several versions of this, but one would be a completely automated system where a PM just writes stories and AI pulls them, implements them, reviews them, and ships them.

When that’s the case, an isoquant looks like this:

That isn’t an isocost line that we just drew. It is an isoquant “curve” (and recall they used to be curved).

That isoquant has a perfect 1-1 relationship between the two inputs (or the MRTS is constant). So, you can replace one developer with a fixed unit of AI “stuff” and you’ll still get the same output. (what exactly is a unit of AI, I don’t know.)

So, if that is an isoquant, where does it intersect the isocost line?

As you can see, the isocost line intersects the isoquant at all capital (K), no labor.

Why is that?

Remember that a business will always like to be on the highest isoquant (furthest up and to the right) possible (assuming making more stuff makes more money). So, they minimize cost subject to being on the highest isoquant possible.

We can see how much more they would have to spend to reach the same level of output if they spent it all on labor.

As you can see, the company would have to spend far more money to keep the same level of output if they wanted to spend it all on labor.

So, yes, in the perfect substitutes case, it’s a sad day for Software Developers. The businesses need to adapt to the changing cost landscape (they’re competing with other businesses doing the same), so they would ultimately fully replace labor.

Now, is that what’s happening with AI? I don’t know.

But let’s take a look at what happens if AI and Software Developers are perfect complements instead. It paints a very different picture.

Perfect complements

Let’s go back to isoquants. The shape of isoquants for perfect complements looks like this:

That is, the perfect complements isoquant curve has an L shape. That’s because a business always needs both labor and capital in the same proportions.

When we combine that with an isocost line (assume the business has fixed budget), we get the following:

In other words, given a fixed cost, the highest isoquant (output) a business can reach is at the bottom-left corner of the isoquant L-curve.

Or put the other way around, given a fixed level of output, the lowest isocost line (i.e. minimizing cost) that reaches such output is that corner.

So, in a world of perfect complements, the prices of labor and capital are somewhat irrelevant when allocating resources. The business is simply constrained by their budget and the need to have capital and labor in an exact ratio. They cannot trade-off more capital for less labor (or vice versa) because both are needed in exact proportions.

Maybe one more graph will make it super clear. Let’s say the business wants to produce more output. It cannot simply add more capital or more labor. It needs to add both! And since they’re perfect complements, they have to be added in the same proportions.

That looks something like this:

As you can see, in order to reach a higher level of output (isoquant 2), the business has to spend more money (isocost 2). And it does so in the same ratio of capital to labor.

AI and Software Developers

Let’s now jump back to AI and Software Developers.

If AI and Software Developers are perfect complements, AI is a tool (+ machines, compute, etc.) for Software Developers.

But you cannot simply “deploy” AI without Software Developers. So, companies that want to produce more (e.g. ship more software) will need to increase their budgets to hire more developers and pay for more AI for those developers.

They can’t wholesale replace one with the other.

A decent example of complements are Software Developers and laptops. When you hire a new developer, you probably need to buy them a new laptop. 10 developers with 2 laptops doesn’t help you a lot. And 2 developers with 10 laptops seems like a waste of money. You want roughly one laptop per developer.

Are AI and Software Developers substitutes or complements?

Now that we’ve seen how isoquant curves and isocost lines behave at the extremes (when capital and labor are perfect substitutes and perfect complements), we can ask the question: are AI and Software Developers closer to substitutes or complements?

My guess (but it’s just a guess) is that it’ll be somewhere in between the two. At first, they’ll be more like substitutes. But in the long-run, they’ll be more like complements.

I have other reasons for that belief (this mental model doesn’t tell us about that). But that’s still my guess.

So, I would probably model it like a “normal” isoquant curve (convex to the origin):

In that case, what is happening is that LLMs are a new type of technology that will shift the relative balance between capital and labor.

But that doesn’t mean that less developers will be needed.

In the short-run, that might be the case. Like I mentioned, I’ve seen some companies reallocate some of their hiring budget towards buying tokens for their existing team.

But it’s typical for people to think of the world as a fixed “pie”. So, when new technologies are introduced, they’re worried their share of the pie will be taken.

When, in fact, technologies tend to increase the pie. So, it’s possible more (not less) developers will be needed (and that can be a bit surprising). Perhaps the job will change (it is seemingly already changing), but developers would still be needed, and in higher quantities.

We can actually see that with isoquant curves and isocost lines by considering what happens as LLMs get cheaper (assuming they get cheaper).

As you can see in that graph, LLMs getting cheaper means that the isocost line changes. That allows the business to reach a higher isoquant but only by also increasing the quantity of labor.

You see that the lower cost allows the business to move from Kq1 to Kq2 and Lq1 to Lq2. In other words, the business will employ more developers and use more AI with the same cost!

Of course, by now you might have noticed that how much those quantities change (i.e. the relative values of Kq2-Kq1 and Lq2-Lq1) depends on the shape of the isoquant curve. Based on how I drew the isoquant curves in the graph, the increase in the quantity of AI used (change in Kq) is greater than the increase in the quantity of developers (change in Lq). Both increase, but capital increases more (which is intuitive since that’s what got cheaper).

But that’s where the model stops and real world begins.

Those isoquant curves are nice and smooth and convex to the origin. Real-world companies don’t have a perfect mathematical equation that they minimize to figure out where MRTS is equal to the slope of the isoquant curve.

Instead, businesses try different combinations, producing different levels of output, and adjusting as revenues and costs change. But, as a rule, businesses will adjust because they have incentives to do so. They want to stay around and (hopefully) be profitable. So, I think changes are inevitable.

I think there’s more analysis that we could do. But I imagine you’ve had enough of isoquant curves, isocost lines, and MRTS for now. Still, I hope it’s a helpful mental model you can use now and in the future.

I’d love to hear what you think about the current state of AI and Software Developers. What’s the reality you are seeing now and the future you think is coming? Shoot me an email.

And thanks for sticking around!

Back to the top 👆

Your problem is (often) two problems

2026-01-26T00:00:00+00:00

Most of my engagements start with a product problem:

“We can’t satisfy demand for features. We need to ship faster.”
“Our application is new, but we’re already seeing bugs in the codebase!”
“We’re experiencing code quality issues, and we don’t have confidence to change the code.”

But fixing the surface-level product-problem isn’t enough. A company has to change the conditions that led to the issue in the first place. Otherwise, like a cancer, the problem grows back.

That’s why for most of my engagements I try to solve two problems: the terminal product-problem and the root team-problem.

A team needs to ship faster. When I join the team, I see pull-request review takes days to complete. Why? Turns out there’s a trust issue within the team. So, everyone acts like a gatekeeper.
People are seeing bugs in the codebase. And it’s only a year old! Joining the team, I discover there’s a lot of churn, everyone is new, and there’s a culture of pushing “hot fixes” and never looking back.
People don’t have confidence in changing code. When joining, I realize we have no test coverage, but people don’t know how to test. We have to talk as a team and change the culture.

So, don’t just focus on the surface-level problem. See what’s at the root. Not only do you fix the problem today, but you also create a culture that compounds the benefits into the future.

Remember, your team is the engine behind your product.

Why do we write tests?

2025-06-27T00:00:00+00:00

Tests, like all other code, should earn the right to exist

It’s a valid question. Tests, like all other code, are a liability – and therefore, they should earn their right to exist.

So, why should we write tests? What’s their raison d’etre?

We write automated tests to continuously verify the behavior of our application as early as possible.

Every word in that sentence matters.

Our tests verify that our application works as we and other stakeholders expect. As professional software developers, we’re responsible for the way the application works. Our goal should be to build high quality software that serves the end user. To do that, we need to ensure the application works as it should.

Of course, any application that survives even a few months of production use will inevitably change. As our application grows due to new and shifting requirements, we want our tests to continue to verify that everything is still working as expected. That’s why they should be automated.

But it’s crucial to understand that we want to verify the behavior of our application – not the internal implementation.

We want to ensure that our application as a whole, as well as each module and function, accomplishes the task that we created it to do. If, instead, we test how it accomplishes those tasks, we risk coupling our tests to the concrete implementation, which increases the cost of changing our application – just the opposite of what we want. That is why it’s often helpful to write the tests first, documenting the behavior in executable form before we’ve even written the implementation.

And we want those tests to run continuously. Each time we change a function, we should run that function’s tests. When we’re finished working on that function, we should run the module’s tests. When we finish a feature, we should run all of our tests. And, of course, before we merge a branch, we should run all of our tests again. That’s why it’s important that tests run fast.

That’s how we catch regressions before they happen – and it’s why we want to verify the behavior of the application as early as possible.

The reality is that everybody tests their applications, regardless of whether or not they write automated tests:

You can test your application with automated tests (you can even write the test first!),
You can test your application manually before you deploy it – e.g. clicking on the browser as you develop a feature and once again before deploying to production to make sure things “look” okay (something that is actually slower, less repeatable, and therefore more costly!), or
You can let your users test your application in production! (here come the bugs).

Each of those are different methods of testing your application. They do so at different points in the development process and at different cost to you.

Each method of testing happens at a different point in time and at different cost to you!

Automated tests happen early, when developers have most context on the code they’re testing and are therefore the cheapest way to test your application. Testing in QA or manually via the browser happens later (and it’s slower), which increases the turn-around time required to fix any regressions. Finally, having your users test your application in production happens very late and is very costly. It’s expensive to find the bug and fix it, but it is also costly to your company’s reputation.

So, if you want to decrease the cost of testing your application, do it as early as possible in the development process. Do it when you’re first writing the code.

🤖 ➡️ 😄 Humanize your standups

2025-05-22T00:00:00+00:00

In the age of remote work (which I love, but I know has trade-offs), standups can be boring 🥱.

People are sitting down (not a stand-up anymore, is it?), and it feels like roll call. When it’s your turn, you just shout what you did yesterday.

You, tomorrow during 'standup'

That is helpful to some in the team (like PMs), but it can also be done asynchronously. Which is why, I think, many teams switch to async standups.

But in a remote world, we’ve lost the coffee machine chats, the “how was your weekend?” moments, the ping-pong lunch game. We’ve lost some of that connection.

I think standups can give us some of that back.

Yes, let’s talk about the work. And while we’re there, let’s focus less on rote updates and more on blockers and helps – things that lead to collaboration.

But let’s also humanize ourselves a little. We’re not just 4x4 squares in a rectangular flatland.

I like to add levity when I lead standups. I try to be more light-hearted, self-deprecating, and shout-out non-work things I’ve learned about others (“Did you know James wrote a book?!”)

I also like to add quirky elements (like filters and lasers) that help people loosen up:

Using filters to keep things funny

Best way to end standup -- with lasers!

Typically, teams like it, and they adopt it.

One time, a teammate running standup acted like a news anchor. They called to site correspondents, asking for weather reports and updates from “the field”. The entire team went along with it. It was hilarious.

To be clear, I’m not advocating you turn your standup into a 40 minute slog fest. Keep standups short but add some sweetness too. Doing small things to add friendliness reminds us that we’re human, in this “thing” together, and creates camaraderie.

Elixir Streams hits a 100 videos! 🎉

2024-10-04T00:00:00+00:00

👋 Hello, hello!

As of last Tuesday, Elixir Streams has a 100 tips!

Since Elixir Streams has hit this milestone (and I’m amazed it did), I wanted to look back and share some history, some behind the scenes, and some of my experiences.

When, why, how

I published my first tip on Twitter on December 1st, 2022.

A few days before, I had seen someone retweet a video from Wes Bos. I liked the format of explaining a concept in a short video. So, when I was about to share the new --info flag for mix phx.routes, I thought, “why don’t I make a video about it instead?”

I recorded the video and threw it out there without further thought.

My first tweet with a video tip

Since I had created a video, I thought, “why not put it in YouTube too?” So, a few days later I did.

I had already done recordings for my Testing LiveView course, so I already had some familiarity with recording and editing videos. But as you can see, my first tips were a bit rough – I didn’t even know that Twitter’s videos were supposed to be square and didn’t know what YouTube shorts were at all.

Honestly, I didn’t think much about it. I didn’t have a grand plan to keep doing them. It was just a spur-of-the-moment thing… so, naturally, it stuck.

The website

After publishing a good number of tips in Twitter and YouTube, I figured I would continue publishing them.

But the videos were spread across Twitter, YouTube (and even LinkedIn). I wanted to have a single website where I could put all the videos, and maybe even a newsletter sign up so people could get notified when I published them.

Thus, in June 2023 the elixirstreams.com website was born.

Elixir Streams homepage now

One huge benefit of having the YouTube videos on the website is that YouTube doesn’t show ads when the videos are embedded! 🥳

I never liked that YouTube automatically included ads in my videos that I couldn’t turn off. I’m not in their ad program, so I can’t reject them. So, at first, I didn’t want to send people to YouTube since they’d get ads. But, I feel perfectly comfortable sending people to the Elixir Streams website. No ads.

The website tech

The website has never used fancy tech. It’s just another static site in my collection.

I chose to do a static site since:

(a) I don’t really need dynamic pages, and
(b) I can host the website for free with Render.

At the time, I really hoped there would be good Elixir static site generator, but I couldn’t find one. I still don’t think we have a mature, well-used, and well-maintained one. I might be wrong, but that was my impression at the time after doing a little bit of research.

I thought about building one… it would be awesome. But I was trying to publish videos, not build a static site generator. So, with a great deal of effort, I resisted the yack shave. Thankfully, I’d used Jekyll and Gatsby before, so I could pick one of them.

With Jekyll (that’s what this website you’re reading is built with), there’s some pain when setting up. But once I have the website running, it’s usually pretty smooth sailing.

Gatsby, on the other side (that’s what my TDD Phoenix site is built with) has always a huuuuge pain. It’s probably a phenomenal static site generator, but for the amount of time I wanted to spend configuring it, I’ve always found it a royal pain to go back and do anything with my TDD Phoenix website.

So, I decided against Gatsby and went with Jekyll.

The recording tech

I’ve upgraded my tech over time, but probably not as much as I should’ve. But hey, I’m doing this for free! 😅

I upgraded whatever Logitech camera I had to an Elgato Facecam Pro. I also bought a better source of light (an Elgato ring light) – which made me look like a corpse, until I discovered (very recently, to my shame) that you can adjust the temperature of the light.

I’ve always used Screenflow to edit videos. I’m happy with it. And I’ve always used an Audio Technica ATR2100 mic. A former colleague of mine who is a video editor (👋 hi Thom) recommended them to me back in 2019. I remember him saying something like this, “that’s a good, simple (read USB), cheaper mic for spaces that aren’t sound proofed very well” – just what I needed. And I’ve never needed anything more.

I’m hoping to improve my video more. I never really wanted my face to be prominent in the video tips, but it’s definitely part of it.

And recently, I got a rude awakening. I started a podcast that also goes on YouTube, and Peter, my first Elixir friend, had an awesome setup. Mine paled in comparison.

When the dead chat with the living

So, I’ve taken some steps already – like realizing that you can change the ring light’s temperature, adjusting the camera’s temperature, improving my light in the background, and actually recording my video in 4k. We’ll see how that goes.

Here’s a screenshot of my face in an upcoming tip (video tip 101!):

Better camera settings, warmer light, and proper face alignment

The intro and outro

The first few times I recorded, I didn’t know how to start talking. I said things like “Hey there” or “Good morning”. But nothing felt great.

It’s surprising how weird it feels to stare at a 3…2…1 countdown on your screen and then go directly into speaking like you’ve been talking all along. At least, it’s weird for me.

In any case, after a few videos, I started a video with “hello, hello”. And that seemed okay. Unfortunately, it became a crutch! I can’t start videos anymore without saying “hello, hello”. It’s the cue my brain uses to go into recording mode. 🤦

Fortunately, people seem to like it. It’s even become something of my signature!

People seem to like the 'Hello, hello!'

The one thing I wanted to have was a cool outro. I always remember Avdi Grimm’s “happy hacking!” ending to his videos. And if it weren’t so darn cool, I’d steal it for myself. But nah, I can’t pull that off.

Thankfully, my outro of “I hope you like it” came naturally at some point. And I kinda like it. It even gets people to reply to it sometimes. 😂

I like that people like it

The reception

The Elixir community’s reception to the videos has been great!

I have been amazed at how many people reply saying that they really appreciate the videos, how it helps them, and how they love the format – short and to the point so they can go on with their day.

Some of the YouTube comments I copied to the Elixir Streams website

By far, the coolest comment anybody’s said about my video tips was [Bryan’s tweet]:

Every word is gold. Bryan is a wordsmith

It’s such a nice comment that I made it the top quote on the Elixir Streams website.

The tips also get mentioned frequently in the Thinking Elixir podcast. It’s always such a nice surprise to be listening to the news and hear Mark and David talk about one of the tips!

But the biggest surprise to me came when I attended ElixirConf 2023 and 2024. People started approaching me and saying, “You’re the video guy”, or “I like your videos”, or they just went straight into “hello, hello!”

I guess I'm just the 'Hello! Hello!' guy now. (Hi Dhony!)

I also love when people say the videos have helped them. A few people have reached out in Slack or YouTube over the years to tell me how much they’ve helped them. That’s honestly one of the coolest things.

Isn’t the internet amazing? People from all over the world can create things, share them, and others find them and improve through them!

It’s been a wonderful experience being able to contribute to the community in such a visible way. I’d always been more of a writer (hello blog post!), but people really seem to like the short video format and benefit from it. So, I’m glad the community received them so well.

The metrics

I don’t have a canonical source of metrics. I have YouTube metrics (which are easy to get), the Elixir Streams website metrics (I use Fathom with as little tracking as possible), and Twitter metrics (which are kinda useless).

I’m not exactly sure what counts as a “view” in YouTube shorts. Many of the tips are under a minute, so they automatically get dropped into that bucket. And I imagine many people scroll away pretty quickly. So, who knows if that’s a view or not.

The Elixir Streams website’s metrics should in theory be included in YouTube’s metrics (since that’s where the videos are hosted). So, I imagine the YouTube metrics are the upper bound and the Elixir Streams metrics are the lower bound. But I’m not sure how accurate they are.

First, the website, which is the lower bound.

Fathom analytics for visits to Elixir Streams

Since the creation of the website, the website’s had 30.4k people and 48.6k views. I don’t have anything to compare that number to, but that doesn’t seem bad. If we round to 50k views and we have 100 videos, that’s roughly 500 views per video. That doesn’t count people going in through YouTube, or people seeing the native Twitter videos. Again, just a rough estimate.

YouTube stats are larger. I have one video that isn’t Elixir Streams related, so I filtered that out.

YouTube analytics since I posted first tip

In total, it says the videos had 90.3k views. That’s almost double, and therefore more like 1k views per video. Not bad! YouTube also shows 1.5k hours of watch time. That kinda blows my mind. People have spent over a thousand hours watching my 1-3 min videos.

By the way, if you look closely, you’ll see a spike near the beginning. That’s around December 30th when a blog post I wrote made it to the top of hackernews – the post had the video embedded in it.

Twitter doesn’t have aggregate metrics for all my video posts. I have aggregate metrics for all my tweets, but that’s a lot of noise.

So, instead of showing the aggregate, here’s a sample of a couple of recent posts.

First one on the lower end:

A recent post that wasn't really a hit

It got 1.5k impressions (whatever that means), 15 likes, 1 reply, and 3 reposts.

And here’s a more popular one:

A recent post that did pretty well

The video got 7k impressions, 62 likes, 2 replies, and 7 reposts.

This view of Twitter’s analytics doesn’t show how many bookmarked it, which is a shame. I think that’s a good metric of whether people like the post too.

What’s next?

I’ve considered what I want Elixir Streams to become. But I confess I’m not sure yet.

One one hand, I thought it could be my hub for Elixir tips and courses. I like the idea, but that would mean investing more in courses. I think it could be a good strategy, but I’m unsure if I want to create a ton of courses (they take a lot of time).

I’ve also considered making it a community place where I just curate YouTube videos from the Elixir community. It’s still something I’m considering, but there’s no going back if I announce that. So, I haven’t pulled the trigger with that yet.

Finally, I considered taking sponsorships to help offset the cost (of my time) of recording videos. Maybe I could even make it more of my regular job. But I’m not sure if I want to do that either. Sometimes when I tie things to “need to make money”, they lose the pure joy of creation. And if I do decide to try to make money somehow, I think I’d rather go the courses route.

In the end, it may just remain what is is. A hub for free video tips I create. And hopefully a great resource for the community.

Thank you for watching!

Finally, I’d like to say thank you to all the people who’ve watched the videos!

Without people watching and mentioning how much they like them, I would’ve stopped doing them long ago.

Hope you like ‘em 😉

– German

Introducing PhoenixTest

2024-01-31T00:00:00+00:00

PhoenixTest provides a unified way of writing feature tests – regardless of whether you’re testing LiveView pages or static pages.

It also handles navigation between LiveView and static pages seamlessly. You don’t have to worry about what type of page you’re visiting or navigating to. So, you can test a flow going from static to LiveView pages and back without having to worry about the underlying implementation.

Just write your tests from the user’s perspective. ✨

Why create PhoenixTest?

With the advent of LiveView, I find myself writing less and less JavaScript.

Sure, there are sprinkles of it here and there, and there’s always the occasional need for something more.

But for the most part, if I’m going to build a page that needs interactivity, I use LiveView. If I’m going to write a static page, I use regular controllers + views/HTML modules.

The problem is that LiveView pages and static pages have vastly different testing strategies.

If I use LiveView, I can write my tests like this:

{:ok, view, _html} = live(conn, ~p"/")

html =
  view
  |> element("#greet-guest")
  |> render_click()

assert html =~ "Hello, guest!"

But if I want to test a static page, we have to resort to controller testing:

conn = get(conn, ~p"/greet_page")

assert html_response(conn, 200) =~ "Hello, guest!"

That means I don’t have ways of interacting with static pages at all!

What if I want to submit a form or click a link? And what if a click takes me from a LiveView to a static view or vice versa?

A Unified way of writing feature tests

So, I wanted a unified way of writing feature tests – regardless of whether or not you’re testing LiveView pages or static pages.

And that’s what PhoenixTest does!

Imagine having a workflow that starts on a static page. We click a link and are taken to a LiveView page. Then, we fill a LiveView form (which could even have its phx-change triggered), and then we submit the form. Finally, we assert that what we expect to see is present.

All of that in a succinct, pipe-friendly way!

test "can create a user", %{conn: conn} do
  conn
  |> visit("/")  # <- could be LiveView or static page
  |> click_link("Users") # <- navigate between LiveViews and static pages
  |> fill_form("#user-form", name: "Aragorn", email: "aragorn@dunedain.com")
    # ^ will trigger `phx-change` if present
  |> click_button("Create") # <- submits LiveView forms and regular forms
  |> assert_has(".user", "Aragorn") # <- provides better error messages
end

Improving assertions

Then there’s the problem of assertions.

Because LiveView and controller tests use =~ for assertions, the error messages aren’t very helpful when assertions fail.

After all, we’re just comparing two blobs of text – and trust me, HTML pages can get very large and hard to read as a blob of text in your terminal.

LiveView tries to help with the has_element?/3 helper, which allows us to target elements by CSS selectors and text.

But, unfortunately, it still doesn’t provide the best errors.

has_element?/3 only tells us what was passed into the function. It doesn’t give us a clue as to what else might’ve been on the page – maybe we just made a small typo and we have no idea!

With PhoenixTest.assert_has/3 and PhoenixTest.refute_has/3, we can provide better errors when assertions fail.

How did you write feature tests before?

In the past, I would’ve used Wallaby to write feature tests.

But since I’m not writing as much JavaScript, I don’t feel the need for something so heavy – requiring chromedriver and slowing down our tests.

Instead, I’d like to have something more akin to what LiveView tests brought us – tests that act as though there’s a driver, but they mostly parse HTML and allows us to make assertions about it.

That’s where PhoenixTest shines.

Of course, without something like chromedriver, we cannot test JavaScript. So, PhoenixTest remains blissfully ignorant of it. If you need that, check Wallaby.

But if you’re looking for something to write fast feature tests for your LiveView pages and static pages – and something that is (hopefully) a pleasure to write – check out PhoenixTest!

Don’t silo your team

2023-11-06T00:00:00+00:00

I have worked in teams where a product manager (or someone equivalent) assigns tasks to developers. On paper, that works. And it’s likely done in the name of parallelizing work – “look at all the projects we’re working on at once!”

But in my experience, that top-down approach to assigning work has a huge downside: it discourages team collaboration.

When a product manager assigns tasks, every developer feels responsible for “their“ amount of work – especially in a company that rewards developers who finish more tasks. And that destroys collaboration.

I often see that lack of collaboration play out in code review.

When developers are measured by the number of tasks they complete, and when those tasks are assigned by a product manager, you’ll quickly find that developers aren’t doing as much code review as needed. Everyone wants their pull requests to be reviewed, but no one wants to do the reviewing. So, pull requests remain open for longer than necessary, and you’ll probably hear about it in retro.

Your team is divided because every developer is out for themselves. And of course, it’s not ill intended (or at least, it may not be). But your team’s incentives are working against collaboration.

By contrast, the best teams I’ve worked with see programming as a team sport. They share ownership of the codebase. And they see the team’s progress – not individual progress – the goal to be attained.

In those teams, tasks aren’t assigned. No developer is responsible for a task unless they take it upon themselves. And who better to know which task each one should take?

Many times, a task still lands on a single developer. Other times two developers choose to pair on a task. And yet other times, several developers collaborate to solve the difficult parts together but then separate to parallelize menial tasks.

A product manager can help list the tasks in terms of priority: the most important task is at the top, then the next, then the next. That is essential information for the team to have the most impact on the business.

But developers don’t need to be assigned each individual task – filing in line to receive their orders. Instead, trust the developers to work together to complete the tasks needed. That encourages the team to work on the solutions in whatever way they see fit.

When you do that, you will find that people are more comfortable doing code review because they’re treating progress as a team sport – the team is trying to finish the tasks, not each developer their own.

Of course, not assigning tasks to people won’t automatically make your team great at collaboration. There are other things needed – good communication, a willingness to work together, etc. But at the very least, you’re not hindering your team by creating a structure that actively works against collaboration.