Sea Monster of the Lost Dependency (a real story)

May 8, 2026May 12, 2026 Piotr GoslawskiLeave a comment

It was just another cloudy evening in the home office. Code written, recipes updated — all seemed ready to go. Yet something felt not right: a strange certainty that things were just off. Maybe it was the fact we still sat on a few-months-old Kirkstone release while fetching dependencies from the Internet sea. So just to calm my nerves I decided to make a clean build. Nothing is better than a fresh clean image waiting for you at dawn. Unaware of what was coming, I went to sleep.

In the morning there was a sea monster waiting for me, right in the middle of the console.

			
ERROR: efibootmgr-17-r0 do_fetch: Fetcher failure: Unable to find revision e067160ecef8208e1944002e5d50b275733211fb in branch master even from upstream
ERROR: efibootmgr-17-r0 do_fetch: Bitbake Fetcher Error: FetchError('Unable to fetch URL from any source.', 'git://github.com/rhinstaller/efibootmgr.git;protocol=https;branch=master')
ERROR: Logfile of failure stored in: /work/clean_run/nwbe-ems-yocto/build/tmp/work/corei7-64-poky-linux/efibootmgr/17-r0/temp/log.do_fetch.6077
ERROR: Task (/work/clean_run/nwbe-ems-yocto/build/../layers/poky/meta/recipes-bsp/efibootmgr/efibootmgr_17.bb:do_fetch) failed with exit code '1'

Not often does a tech sailor meet such a beast in his life.* It sat there looking at me with its failed-fetch eyes. Smiling and waiting for its food — my precious time.

A few hours later I knew where it had come from.

There was once an old repository. Stable and proven, like an island carved from rock. github.com/rhinstaller/efibootmgr. If you try to find it now, you will discover that it was quietly moved to github.com/rhboot/efibootmgr. Not really a big surprise — things do get renamed all the time.**

But that was not the source of the problem (it will be, the day someone decides to remove the redirection). The real troublemaker was the master branch. Or to be exact: the fact that it was gone.

Most of my wasted time went into trying to figure out where the branch had gone. My suspicion was that it was deleted long ago and had worked only because of some strange GitHub magic similar to this one — making it look like everything still worked in the old way, for as long as the spell held. Whatever it was — it was gone. And tech sea monsters wait exactly for such occasions. A fix eventually landed in Poky, but the world does not pause while every project catches up. Our project did not, and I had no intention of making that my first task of the morning.

What saved me was my laziness. Deleting old files takes too long, so there were always old builds lying somewhere on the filesystem. From there I could use the existing downloads and bypass the whole “can’t fetch it” drama. Image got baked, I could do my tests, and the next day I started by updating all the layers properly — the way it should have been done months ago.

Now comes the lesson:

The internet is a dangerous place. Repositories move. Branches vanish. Magic spells expire. Whatever lives outside your local build environment needs to be treated as if it could vanish at any time without any warning. So when the old tech sailor says you should keep a backup of the Internet — don’t laugh at him and just use BB_GENERATE_MIRROR_TARBALLS.

* mostly because we follow best practices when it comes to dependency management in Yocto
** old sailors might remember the Freescale-to-NXP storm that rolled through years ago

14 Ways to Reverse a 32-Bit Integer. (And Why They Don’t Matter Anymore)

April 3, 2026 Piotr GoslawskiLeave a comment

It was 2017. Pre-AI, pre-COVID. A time when people worked in places called offices, and finding a place in one meant writing cover letters, sending CVs, and having an interview with a real person.

And there I was, sitting in a small room with a department manager and two senior engineers—the three people who would decide whether I was a fit for their team.

They were well prepared. Intro. Work description. Ten technical questions—all written on a single sheet of paper. Real professionals.

Among the questions was the greatest one I have ever received:

Reverse the bit order in a 32-bit integer.

I got a pen, and my job was to write a solution. While coding on paper, I was loudly explaining what I was doing and why. I went with a simple while loop and pointers—the simpler it is, the bigger the chance the thing will compile — or would have, if writing Ctrl+F9 with my pen had any effect.

Luckily, I did not get the job. Sometimes rejection is the best thing that can happen in your life.

But the question stayed in my head. Later, I found multiple solutions—including a single ARM instruction that does exactly that. It became a fun little obsession: benchmarking different implementations and comparing them.

Now fast forward and it’s 2026. Post-COVID. Mid-AI. I am sitting on the other side, interviewing a potential candidate.

Should we ask them to do an online assessment?

The task I received ten years ago can now be solved in 30 seconds. Including all solutions I was so proud to find myself, even more. Including solid reasoning for each version. So how do you see whether the person on the other side really understands what is going on?

And if they do understand—does it even make them a good candidate? Do they need to know how to reason about code at all?

Times have changed a lot, and building teams is no longer just about whether someone is “a good fit” today. It is about predicting whether a person will still be a good fit in an environment that is going to change dramatically over the next five years. And in that context, reversing bits may not be the most valuable skill at all.

Maybe the best question nowadays is much simpler:

“Tell me about a technical question that stayed with you long after the interview was over.”

THE BALLAD OF THE DASH SISTERS THREE

February 7, 2026February 25, 2026 Piotr GoslawskiLeave a comment

By Claude Sonnet 4.5
Illustrations by ChatGPT 5.2

In the land of Typography, where the letters dwell,
Lived three sisters known to writers well:
Hyphen short and quick to bind,
N-dash middle, measured and refined,
And M-dash long with pauses grand—
The finest dashes in the land.

Young Hyphen danced from word to word,
“Well-known! Self-made!” her voice was heard.
She joined the parts that stood apart,
A matchmaker with punctual art.
“I’m twenty-one!” she’d proudly say,
Connecting compound words all day.

N-dash stood between the pair,
With balanced grace and thoughtful care.
“From 2020–2025,” she’d state,
Or “pages 12–19” to indicate.
For ranges, spans, connections true,
She was the bridge that saw things through.

But M-dash fell on harder times,
Forgotten in the daily lines.
No keyboard shortcut bore her name,
No common tongue would stake her claim.
While hyphens thrived in every text,
The em-dash wandered, lost, perplexed.

She haunted menus no one pressed,
In special characters she’d rest.
The writers typed their hurried prose
With double hyphens–comma’s close–
But never paused to seek her out,
That graceful line, that thoughtful rout.

Until the age of AI came,
And algorithms spoke her name.
The models learned her rhythm well—
That pause, that breath, that way to dwell—
And suddenly in generated text,
The M-dash rose, no longer vexed.

At first the readers did not mind,
But soon a pattern they would find:
“This mark appears in every line—
A tell-tale sign, a clear design!”
They pointed fingers, marked it so:
“The machine has written this, we know.”

The M-dash bore a scarlet brand,
The signature of silicon’s hand.
“When you see — you’ll always know
A human mind did not write so!”
And she who’d yearned to be embraced
Found herself again displaced.

But then one day a reader paused—
Not by the words themselves, but clause—
He stopped where M-dash held her ground,
And in that pause, himself he found.

The breath she gave, the space to think,
The moment’s rest, that gentle brink
Between one thought and what comes next—
He felt his own heart in the text.

“This pause,” he whispered, “holds me here,
Makes distant meaning suddenly clear.
What matters not is who first placed
This line of thought, this marked space—
But that I stopped, and stopping, knew
My own reflection breaking through.”

The M-dash learned that truth at last:
Her worth lay not in present, past,
Nor who might wield her—hand or code—
But in the pause along the road,
Where any reader, mind made still,
Might find themselves—and always will.

So raise your glass to sisters three:
– and – and — in harmony!
For marks are neither good nor ill,
But mirrors for the human will—
And in the space between each thought,
We find the selves we always sought.

The pause is where we meet ourselves—
whether written by hand or machine.

Failure Mode 1 — Sheep in the Ocean

February 5, 2026February 5, 2026 Piotr GoslawskiLeave a comment

Ever seen a whale pretending to be a grass field? Or a sheep swimming in the ocean?
Of course not.
Some things just don’t fit.

But the software world is different. Here the four-eyed sheep can fly in space and no one will care. Until the moment it hits the ground.

“Oh my – this guy is talking about sheep and whales again…”

Relax. No whales this time. Instead, let me show you two architecture failure modes —
and one solution they both quietly ignore.

When execution models impersonate each other, complexity leaks. The fix is a real boundary.

For our examples we will use Modbus an ancient way of exchanging data between machines—and one that still refuses to be replaced. Each device exposes a set of registers, read and written in a fixed, periodic loop.

Simple. Brutal. Effective.

Scenario 1

We start clean. A Modbus system runs in a single deterministic loop:

read state -> process -> write state -> repeat

One day, a new requirement appears: the Modbus data must be sent elsewhere using a modern RPC protocol.

Without much thinking we start adding the communication logic into the main control loop. Suddenly alien constructions start to appear – retry counters, timestamps, acknowledge signals. Before we know we create a full-fledged message broker inside our simple loop.

Complexity grows.

Scenario 2

Now the opposite.

We start with a clean, event-driven environment. Requests, responses, handlers, queues. Perfect.

We add Modbus handling. “Easy,” we think.
“We’ll poll registers and emit events on change.”

It works… until signals start changing faster than the event system can digest.
Events pile up, updates get dropped or reordered, information is lost

And the more we try to solve it the more complex system becomes.

What happened?

In both cases we made the same fundamental mistake – we tried to bend the problem we were solving so it fits architecture that was already in place. We ignored the quiet signal saying:
“This does not belong here.”

There’s a simple rule—very much in the spirit of model-driven design:

Software should model the domain and its execution semantics.

For each domain, we must choose abstractions that fit naturally—without distortion.

The solution: a boundary with translation

The solution isn’t a smarter loop or a better event system.
It’s a boundary.

Keep each concern in its native execution model—and translate only at the edge.

On one side, a deterministic polling loop:

Read registers
Process state
Write registers
Repeat at a fixed rate

On the other side, an event-driven system:

Requests
Handlers
Queues
Backpressure

The boundary translates stable state from the deterministic world into meaningful change for the event-driven world.

No retries in the loop.
No event queues pretending to be registers.
No execution model impersonating another.

Each side runs the way it was designed to run.

Getting there isn’t a technical trick—it’s a change in how you think about the problem.

Not:

“What’s the fastest way to implement this feature?”

But:

“What is the domain—and how does it naturally execute?”

Follow that, and things fall into place.

Sheep stay on grass.
Whales stay in the ocean.

And systems quietly become what they’re supposed to be.

Under the Broken Code

February 1, 2026February 1, 2026 Piotr GoslawskiLeave a comment

There is a tavern every tech sailor knows.

It’s where crews come ashore after long voyages through hostile seas — to rest, to trade stories, to remember old journeys and pretend they were simpler than they really were.

But most of all, they come for a drink.

The innkeeper pours rum without asking. If you sit at the bar long enough, he will lean closer and tell you a story — about the greatest danger a sailor can meet on the open sea. A story about the siren’s song, and three brave captains who listened to it.

“Ay,” he says.

“I served on many ships, under many commands. But three captains I remember to this day. Fine men, all of them. The best I ever saw. All gone mad. One by one…”

He takes a sip.

“The first captain — strong, proven. We won many battles with him. Shipped many systems. But one day… he started listening to the sirens.”

‘We always did things in C!’ he shouted.
‘And we will keep doing things in C! Arr!’
‘If anyone disagrees, let me remind you — Linux was written in C!’

So everyone wrote in C.

The ship still sailed, no doubt about that. But every complex change took ages. Every repair felt like carving a mast with a knife.

“Another captain,” the keeper continues, “a clever one. Loved elegance.”

‘Functional programming works perfectly on the backend!’
‘So make me monads in C++11! Arr!’

And there were monads. Everywhere.

The ship sailed. But no sailor could tell what the code was, what it did, or why it still floated.

“And then there was the third. He spent many years learning to sail the Yocto boat. And Yocto became the answer to every question.”

‘Yocto.’
‘Yocto everywhere. Arrr.’

One day, a big cruise ship required a mast replacement. We spent a month searching for it. Then another month rebuilding half the ship so the sail could be green.

“Fine captains,” the keeper says quietly. “Truly. Brave. Skilled.”

He stares into his glass.

“But the sirens — they sang to them. Afraid of being wrong, they stopped listening to their crews and started listening to the song.”

You notice the keeper pouring rum for himself. His eyes are tired. Sad. He looks out the window, toward the dark sea.

“Now listen to me, young sailor. There is a new danger out there,” he says.

He leans closer. “Close your eyes and listen.”

You close your eyes and focus on the tavern noise — people talking, glasses clinking. You catch fragments of conversation.

“…and we need no crews anymore. Ayyy.”
“…I can build any ship I want. Alone. Ayyy…”
“Ships will sail by themselves…”

“Can you hear it?” he asks. “And look around you. Some of those lads don’t even know how to tie a proper knot.”

“But all of them have the same shine in their eyes.
The same certainty.”

He finally looks at you.

“Not madness born from failure,” he says.
“But madness born from success.”

A pause. He studies you for a long moment, as if deciding whether to end the conversation — or share one last thing.

“Ships that need no crew… ships that build themselves… maybe they will sail someday. Not for me to judge. I never held a helm in my life — all I did was cleaning decks. I talk about captains while I never dared to be one. That’s the truth.”

“But there is one thing I know. One thing that terrifies me even more than the sirens.”

“The sea is changing. And there are new monsters living in it. Ones that don’t drive people mad.”

“Ones that steal their souls.”

You write a text.
You write code.
You create.

And you hear a new call from the sea:

‘It is not good enough.’
‘Your timing could be better.’
‘The code could run faster.’
‘Let me help you… if you want to push it further…’

So you give your work to the sea.

It returns. Better. Sharper.

But something is missing.

A small piece of you never comes back.

Welcome to the Tavern Under the Broken Code.

Lift your cup and drink.
To the sea that calls us every day.
To the captains driven mad by sirens.
To those who trusted the sea
and forgot how to sail.

Drink, and listen.
Not to the bartender. Nor to the sea.
Listen—to yourself.

The Secret Art of Keeping the Archwhale Alive

January 21, 2026January 22, 2026 Piotr GoslawskiLeave a comment

The Beast

There is a whale no one sees, circling slowly beneath the surface of every software project.

A mighty beast that carries systems on its back.

Be aware of its strength. When it is weakened or forgotten, it can pull the entire project down into the black depths of the entropy sea. And it does this so slowly, that by the time someone realizes what is happening, it is already too late. Planning turns to chaos, change becomes impossible, and there are no more doughnuts from the manager. People leave as the music fades into its final violins*. And the light goes out.

Flip the soundtrack

Things don’t need to end this way—if we simply give our archwhale what it craves most: attention.

And when I say “we,” I mean everyone involved in the project. Each of us adds a small piece to the story. Adding something means taking responsibility for it.

Now the most important part: to care about a whale is not to just think about it (even if your thoughts are warm, sophisticated, or reach far into the future).
To care about a whale is to take a knife and cut it into pieces**.

Chop chop chop?

Yes—but not so fast.

First, let’s clarify what this actually means.

As explained in this article, there are countless axes along which architecture can be sliced, depending on intent. Search long enough and you’ll find hundreds of possible artifacts: designs, diagrams, documents—plus frameworks and blog posts comparing architecture to whales, bridges, or chocolate cakes.

So our first problem isn’t a lack of options, but an excess of them.

We can’t just start creating projections at random. Too much documentation is as harmful as too little. Before we start running around with diagram-knives, we need to stop and ask a simple question:

What are we actually trying to achieve?

The spatial dimension

You carry the project vision inside your head. You navigate it effortlessly. You know where things are solid—and where shortcuts were taken just to keep things moving. You already plan new features, consider possible risks, and think about how to mitigate them.

What lives in your head is similar to what an author carries when writing a book: an entire universe where the real story unfolds. Just like you, the author can explore multiple possible futures happening inside.

Now imagine not one author, but a hundred, all writing the same book. Without synchronization, one kills the main character while another sends him to Scotland to find a brother who was never missing.

The universe must be shared.

That’s why we externalize it. Architecture artifacts—API contracts, dependency graphs, interface boundaries—are projections of the system that enable shared reasoning, coordination, and onboarding, keeping the universe stable while many minds shape it at once.

The time dimension

You carry the project vision inside your head.

Today.

Tomorrow your attention shifts. A month from now, you won’t remember why things are the way they are.

“It’s all in the code,” one might say. But that’s not true. Many decisions don’t affect how code is written, but how it is not written.

Why was language X chosen instead of Y?
Was market availability considered? Ecosystem maturity? Team experience?
And when a framework was selected, which trade-offs were accepted—and are they still valid?

What we want to record is not just why we chose A, but the full reasoning behind that choice.

In this sense, architecture artifacts are memory. We use them to keep the universe stable while time passes.

Not just records — thinking surfaces

Artifacts have one more important function: they act as thinking surfaces—places where ideas are tested before they harden into decisions.

You definitely know how this works. You don’t create class diagrams when classes already exist in code—you do it before, to see how dependencies might look. This allows to reason at a higher level of abstraction than the implementation.

The same applies to ADRs. Instead of writing an ADR after a choice is made, start earlier. Capture doubts, alternatives, and trade-offs. After execution, clean it up and keep it.

This suggests that artifacts should be created only when we actively work on a subject. In general, yes—but they should also be reviewed from time to time (for example, at each major release). Check whether they still carry information worth caring about. Outdated artifacts can be archived so they don’t introduce unnecessary noise.

Time for sushi

Now we are ready. We know what we want—and, more importantly, why. As in everything in the universe, balance matters. The number of produced artifacts must be just enough to keep the project synchronized across space and time. This way, it stays on the edge of exploration while remaining stable.

And remember: architecture survives only as long as people actively care for it.
Not admire it.
Not remember it fondly.

Care for it through small, deliberate acts: revisiting decisions, updating maps, removing what no longer matters, making the invisible visible again.

Ignore it, and it will not protest.
It will simply sink.

* Max Richter — “On the Nature of Daylight” fits perfectly
** Space archwhales love to be sliced — it keeps them alive.

Software Architecture and a Cosmic Whale

January 16, 2026January 22, 2026 Piotr GoslawskiLeave a comment

Has Anyone Seen My Architecture?

There are countless definitions of software architecture.
Some emphasize decisions, others structures, others “the important stuff,” or whatever is hardest to change. Read enough of them and architecture begins to feel like something that slips through every classification—a creature everyone describes differently, yet no one seems to have seen.

And yet, this creature clearly exists. No one doubts that.
We recognize it by its effects: slow delivery, bugs that refuse to die, changes that feel far riskier than they should, systems that push back against even the smallest improvement.

The Mysterious Creature

One might try to exercise the imagination—to picture something that lives partly in code and partly in our heads. A multidimensional entity, not bound to a single moment in time, but stretched across the full span of its existence. Shaped by past decisions and external forces, while simultaneously guiding—and constraining—what changes are possible next. With enough effort, one might even convince oneself of having seen it.

But that is not the point.

We are software developers. Our job is not to chase mystical creatures, but to solve problems. We have deadlines. Features. Things that must work. We have bugs that reliably appear at 3 a.m.

What actually matters are the long-term consequences of change:

Whether, given what we have today, we can meet business requirements tomorrow.
Where to look when things begin to break apart.
Whether deleting a piece of code is safe—or the first step toward disaster.

Chop It!

To reason about architecture, we do what physicists do with spacetime—a similarly ungraspable monstrosity. If you are still holding on to some animal-like mental picture of architecture, now is the time to let it go. Things are about to get drastic.

We are going to slice it.

The axis we choose depends on what we want to understand, and which trade-offs we want to bring into the light.

Boundary axis (Context diagram)
What is inside the system, what is outside, and who depends on whom.

Time axis (Architecture Decision Records)
How the system arrived at its current shape.
Which decisions were made under which constraints—and which alternatives were rejected.

Runtime behavior axis (Sequence diagram)
How work flows through the system while it is running.
Who calls whom, in what order, and where latency or failure can occur.

Infrastructure axis (Deployment diagram)
How the system maps onto physical or virtual resources.
What runs where, what can be deployed independently—and what cannot.

Change axis (Module or service diagram)
How the system tends to evolve over time.
What changes together, what should not, and where change is expensive.

There are many more possible slices.

But the important thing is this: none of these projections is the architecture.
They are views—showing relationships, revealing trade-offs, and giving your brain something it can actually navigate.

The End Game

The goal of the architecture game is not to catch the mysterious whale.
Those who try usually end up with piles of documents that age faster than the code—and quickly become useless.

The goal is to deliver. To know which axes to use at any given moment.
To move comfortably across different projections, and to predict the consequences of change—whether we introduce it deliberately or it is forced upon us. To prepare for disasters and to minimize the impact radius when they arrive.

One who knows how to play the game can deliberately evolve the system.
One who does not will eventually be eaten by code-degradation crabs.

Scrum estimations

January 11, 2026January 11, 2026 Piotr GoslawskiLeave a comment

The thing that never worked — while it worked perfectly

Disclaimer: I’m not a certified Scrum Master, Practitioner, Coach, or whatever title comes next. I’m just a software engineer who’s been fortunate enough to work at multiple companies, each with its own “flavor” of Scrum*.

I’ve always had mixed feelings about Scrum. Some things worked, some didn’t, and some only worked part of the time. Lately, though, I see more and more criticism framing Scrum as something that actively blocks progress. Much like “Scrum everywhere” ten years ago—only in reverse.

That’s not necessarily bad. There is no progress without challenging old ideas. But before going fully Scrum-free, it’s worth asking: do we really understand what we’re giving up?

Think about the estimation process.

Estimates have a terrible reputation, and for good reason. They never really answered the questions management cared about:

When will this feature ship?
Can the team squeeze in more work?

In that sense, estimation failed.

And yet, at the same time, it did something incredibly valuable.

Planning poker slowed us down. In fast-paced planning sessions, it created a deliberate pause—a precious moment to check whether we actually understood what we were about to build. It was the time to say: I don’t know what we’re doing or I think we’re solving the wrong problem.

Everyone was heard, and most importantly, every voice carried the same weight.

I remember being a junior, afraid of being judged by other team members while trying to keep up with everything happening around me. That single “?” card was my weapon. It was a safe signal. A permission slip to ask questions without justification.

So the real value of estimation was never about predicting delivery dates or measuring task complexity. It was about creating a shared, familiar environment where people felt allowed to speak up. It worked—not because Scrum was perfect, but because its rituals reduced ambiguity. Even when you changed companies, the practice stayed the same, and you always knew how to participate.

So before joining the next “Scrum is bad” demonstration, it’s worth asking:

If we remove the ritual, how do we preserve the space it created?

If you have no answer, there is always the “?” card you can use.

* 30-person circle stand-ups and effort measured in bananas included

Toaster – ultimate user manual

December 11, 2025December 15, 2025 Piotr GoslawskiLeave a comment

Toaster arrived…

You wake up one day, and there it is — the Toaster standing in the middle of your kitchen. Shiny, sparkly, ready to serve. Filled with breakfast excitement, you imagine yourself eating the greatest toast you ever had. Pure art. Perfection. Behold common bread-eaters, here comes the ultimate level of carbohydrate engineering. But first: where is the user manual? You search everywhere and realize there is none. Not in the box, not under it. Nowhere. Not even Uncle Google can help (but he can sell you a nice pair of Christmas socks, half price).

Do not panic. We have your breakfast covered.

Lesson 1: How to approach the Toaster

Preferably from the front. No need to kneel, no need to say hello, no need to stare at it waiting for sparkling dust to pop out. Sit down because what I am going to tell you will make your newly purchased socks fall from your feet:

The Toaster is just an appliance.

It is a tool — nothing more than this. Yes, it was fed with all the knowledge the human race produced so far. And yes, it needs so much energy that soon we will have to build power plants on the moon just to keep it running. But at the end of the day, the Toaster is just a metal box. It does not think, it does not have memory, it does not create ideas. Just a box. You put bread inside and the toast comes out. And that is it.

Lesson 2: The secret lies in the bread

So where is all the magic? Where is the sparkling dust and fireworks and all the big things that everyone is talking about? The answer is short: bread.

To use the Toaster, you need to understand the bread

Bread is not just a slice of fluffy dough — it is an artifact in which you can enclose the most powerful thing each human can produce: the thought. It is a space where your thoughts come alive.

The Toaster can make them crispier, bolder, and more exposed. It can fill the gaps that the primitive human brain can’t overcome. But there is one important thing that needs to be emphasized: it is you who creates the bread.

Lesson 3: Beyond the bread

Now stay with me — with or without your socks on — because we enter the realms of true toast proficiency.

When you master bread creation; When you stare long enough at your toasts; When you acknowledge that the Toaster is nothing more than a mere bread-browner, you will reach the state of enlightenment. You will see the bread no more. What you will see is your own reflection instead.

To master the Toaster, you need to become ONE with the bread

Now you understand the bread was never there. Only you, your thoughts, and the Toaster. Your mind is free. The true Toast creation begins.

Lesson 4: Sandwich — the Final Completion

You have become a great master of crispy toast. Your mind is no longer chained, and you can make not one, not two, but seven million six hundred and twenty-one toasts per day. Impressive. Now it is time for the ultimate truth.

The Ultimate Truth: even enlightenment needs cheese and tomatoes

And this is the most important part. So read it again and let it sink into your brain. Toast — no matter how great and crispy — if not turned into a sandwich, becomes cold and hard. And nobody will eat it. Not even you.

That is why it is important to sit down and actually make the sandwich. And you are right — making sandwiches is hard work. Maybe even boring. But the truth is, sandwiches are exactly what the world needs. When everything around turns into chaos, it is the sandwich — not a plain toast — that lets humanity move forward.

Good news: you can use the Toaster to help you make a sandwich — but this is something you already know.

Final Words

You have stepped onto the Path of the Sliced Bread. With all the knowledge you have gained, it is time to prepare some sandwiches.
Not because you are hungry – but because it is the right thing to do.

Thinking Toasters

coding, thinking and toasters