Posts

Planting Seeds Looks Easy

·
8 min read

Much of an engineer's most valuable work looks trivial from the outside. On choosing the right seed, why it grows in silence, and how Streamlit changed our internal tooling at Perk.

Engineering Culture
Streamlit
Python
Thoughts
A small sprout above the ground with a vast network of roots spreading underneath it

I’m on a sabbatical month. For the first time in a long while I have time to read, to think, and to ask myself what I actually do for a living. And one thing keeps coming back.

A lot of my work doesn’t show, because it looks simple. It isn’t.

Planting seeds

Much of what I do is planting seeds. Said like that, it sounds easy. You’re a gardener, you put a seed in the ground, you move on.

But imagine someone hands you bamboo. What a beautiful plant. You put it in the planter next to everything else, and a year later there is no everything else. The bamboo ate it.

The hard part was never planting. It was knowing which seed goes where. To know that, you need to see the whole garden: what’s already growing, what needs room, what would choke the rest.

Software systems are the same. Someone new arrives and wants to change everything, top to bottom. I understand the temptation. But the current system is in balance, even when it’s imperfect, and changing everything at once breaks that balance. The real work is finding the one missing piece that fits, and that takes a lot of thinking. When you get it right, it looks obvious. That’s exactly the problem.

The piece we were missing

For years we needed a back office: a way for us, from the inside, to make changes to the system.

We used Django Admin for a long time. Django Admin is great at what it is: a view over your models and tables. It’s not built for workflows. You can bolt buttons onto it that trigger actions, and you can build something with Django templates, but it’s not simple. It works when two or three engineers really understand it. It doesn’t work when you want any engineer, even one who doesn’t know that corner of the system, to ship an internal tool quickly.

The obvious answer was the bamboo. A proper back office in React. It looks like the professional choice. But our domain lives in Python. Our models took years to get right, they are the language of our business. A React client means translating all of that into TypeScript, keeping two languages in sync forever, and a frontend to maintain for a handful of internal users. It would have eaten the garden.

The seed came from the community. Right after PyConES 2025 in Seville, where people shared what they had tried and what worked, we took a proper look at Streamlit. And we said: this is it. This is the piece we were missing.

It sounds almost silly. Streamlit lets you build web interfaces in Python, and you can use the models you already have, even your Pydantic models, directly. One language. One source of truth.

It’s not built for massive scale. Under the hood there’s a Tornado server holding a session for every user, and that has a ceiling. It didn’t matter. The people using these tools were around thirty, not thirty thousand. I’d still love to see it move to something like FastAPI one day. The right answer at Perk isn’t necessarily the right answer somewhere else.

Seeds grow in silence

And yet it was hard to justify. Who is going to build it? How long is it going to take? There’s no time.

So it grew in silence. Not out of secrecy, but because nobody buys a promise. An idea on a slide is hard to judge. Something that already works is easy. You have to arrive with the thing already working.

It’s not a new idea. Eric Schmidt spent six years against Google building its own browser. Larry Page and Sergey Brin hired a few Firefox developers anyway and built a demo. Schmidt’s verdict: “It was so good that it essentially forced me to change my mind.” That demo became Chrome. Granted, they owned the company. Most of us don’t, which is exactly why the demo matters even more.

It started with a conviction, and we turned it into a demo. It didn’t take long, a couple of weeks. When you have focus, these windows open and something comes out. The hard part is creating those windows in the first place, and that’s what most companies struggle with.

Then we put the demo in front of the people who would use it every day. One question: would you like to have this? The answer was a clear yes. They loved it. Growing in silence doesn’t mean working alone, and it doesn’t mean going around anyone. It means arriving with something real.

That’s when we went all in. A tool nobody knows about is a seed nobody waters. Showing it, explaining it, getting it in front of every team that could use it, until we agreed this was the way to go: that’s what turns a demo into something people adopt. Socializing it matters as much as building it.

Then it spread. Today our ground transportation and flights teams use it to manage inventory and content, configuration that used to need an engineer. It was a web page anyone could understand, the pieces were well connected, and for us, building a new tool on top became trivial.

The magic is that our whole system is written in Python. Suddenly you have a viewer sitting right on top of it, where every widget, element and button is just more Python, calling the same code the rest of the platform already runs. Clean layers, models, repositories, views, all connected in a way that makes sense. It opened doors: pages we didn’t think were possible, suddenly built in days.

Nobody asked for it. But the moment people saw it, they wanted it. And now it looks like it was easy.

There is always time

“Alejandro, there’s no time.” There is. There’s always time to try the future.

Stop asking whether you can try something, and try it. Not every seed takes. When one doesn’t, write down that it doesn’t fit, and move on. That’s not wasted time either. Knowing that something doesn’t fit is knowledge you didn’t have before.

The walrus operator shows both sides of this. When := was proposed for Python, much of the pushback came before anyone had used it in real code. Today while chunk := f.read(1024): is just Python. But the fight over it was so bitter that Guido van Rossum, who backed it, stepped down as BDFL once it was accepted. Being right wasn’t enough. He won the argument and lost the will to keep having it.

Try first, then convince. They go hand in hand. Experimenting doesn’t need permission. Production does need consensus. Before something new goes live, you have to show it’s the right decision, and you don’t get there alone. The goal is to convince, not to conquer. And convincing is much easier when there’s something real on the table.

Everyone is a gardener now

AI has made all of us gardeners. Anyone can plant now. Anything, in any quantity, in an afternoon. That’s great.

But planting was never the hard part. The garden fills up fast, and nobody stops to ask what’s growing next to what. You can plant any seed you want. The real question is which seed you should plant.

To answer that, you have to understand the piece. What it does, what it needs, what it will do to everything around it. If you just want to plant, go ahead. If you want to be an engineer, you have to understand what you’re planting.

That includes how it grows. Elegant code is easy to use. Elegant code is a pleasure to read. AI makes it easy to forget that, which is why I care about it more now than ever.

Why this matters

When a decision like this goes well, nothing happens. There’s no incident, the next team builds on top without friction, and nobody remembers there was a worse option on the table. Good seed-planting is invisible by design.

Technical work gets measured in milliseconds. Seeds get measured in years, and sometimes never. I’m not going to wait for the harvest to talk about them. What’s worth sharing isn’t the harvest. It’s how you choose what to plant.

This sabbatical gave me time to look back at the garden. Most of what I see growing there, nobody remembers planting. That’s fine. That’s what seeds do.

So, which seed have you planted that nobody noticed, precisely because it worked?

References

  • Streamlit
    The open-source Python framework we used to build our back office on top of our existing models.

  • PEP 572 – Assignment Expressions
    The proposal that introduced the walrus operator (:=), accepted in July 2018 and shipped in Python 3.8.

  • Guido van Rossum – Transfer of power
    The email where Guido stepped down as BDFL: “Now that PEP 572 is done, I don’t ever want to have to fight so hard for a PEP and find that so many people despise my decisions.”

  • Google Chrome – History
    How Larry Page and Sergey Brin built the Chrome demo that changed Eric Schmidt’s mind after six years of opposing a Google browser.