Everything Wants a Second Life

Nothing has only one use until you decide it does.

If I Can't See It, I Don't Understand It

Nothing has only one use until you decide it does.

If I Have to Do It Twice, I Build a System

Nothing has only one use until you decide it does.

Think Inside the Box

Nothing has only one use until you decide it does.

Embrace the Mistake

Nothing has only one use until you decide it does.

Monday, August 17, 2026

Automating My Fire Tablet Macrodeck

Homelab · Automation · Quality of Life

Automating the Fire Tablet Dashboard (So I Stop Thinking About It)



The quality of life of the tools I use every day isn't something I'm willing to negotiate on. Throughout this whole process of building a healthy, well-managed network, I've implemented tools I rely on daily — with the catch that I have to keep track of whether I left it on, whether I left it plugged in, or whether, when I sit down to work, I need to charge it first.

More than a technical issue, this is about usability. Getting something to just work automatically usually isn't about skill — it's about taking the time to configure the right solution when the opportunity is already sitting there.

Every new service I add to a well-run network trips the same wire: something has to be started by hand.

The Problem

Two bad options, and neither one respects the hardware.

With this tablet, that meant two bad options. Either I let the screen time out on its own, then plug it back in and wait for it to charge past 2% before I could wake it and reopen MacroDeck. Or I leave it plugged in and awake permanently — and since most of what I repurpose is aging Android hardware nobody wants anymore, permanently-on is its own quiet problem.

The goal was to automate a tool I already use and already trust — not add a workaround for it. Left as-is, the tablet would either be dead when I actually needed it, or slowly wear down hardware that's already past its prime just to stay reachable.

This isn't about being lazy. It's about automating a workflow with tools that are already free and already installed, and keeping the resulting knowledge around for the next device that needs it.

First Attempt

Chasing Windows' own sleep events didn't work.

Of course, none of this was as simple as "enable ADB, add a Windows scheduled task, done." The first version tried to hook directly into Windows' own power events — Kernel-Power Event 42 to catch the system entering sleep, Power-Troubleshooter Event 1 to catch it waking up — firing an ADB script over USB at each transition. Waking worked reliably. Sleeping never did.

The reason took some digging: right as Windows logs that it's entering sleep, the USB controller is already cutting power. The ADB command doesn't have time to complete before the connection dies. It's a race condition against the OS itself, not a misconfiguration — and no amount of tweaking the trigger fixed it.

The Fix

Stop fighting the race. Switch to Wi-Fi, and let a heartbeat do the work.

The fix was to stop trying to win that race. I switched the tablet's ADB connection from USB to Wi-Fi, and let go of the idea that IMPERFECT needed to catch the exact moment it went to sleep. Instead, IMPERFECT sends a simple "still here" signal to the tablet every 58 minutes while it's on. The tablet's own screen timeout is set to 60 minutes. If that signal stops arriving — because IMPERFECT suspended, hibernated, or shut down — the tablet just falls asleep on its own, on Android's terms, with nobody needing to catch the exact moment it happened.

How it works

📶 Wi-Fi ADB — tcpip 5555, no cable needed
💓 Heartbeat — every 58 min while IMPERFECT is on
😴 Timeout — tablet sleeps on its own after 60 min of silence
🔌 Full wake — swipe + MacroDeck, on real resume from sleep

Quick Setup Guide

Get it running on your own tablet.

Requirements: ADB debugging enabled on the tablet, once, over USB

1. Enable Wi-Fi ADB (one-time, over USB)

adb tcpip 5555

2. Disable "stay awake while charging" and set the native timeout

adb shell settings put global stay_on_while_plugged_in 0
adb shell settings put system screen_off_timeout 3600000

3. wake-tablet.bat — full wake, fires on real resume from sleep

adb connect 192.168.2.170:5555
timeout /t 1 /nobreak >nul
adb -s 192.168.2.170:5555 shell input keyevent 224
timeout /t 1 /nobreak >nul
adb -s 192.168.2.170:5555 shell input swipe 300 820 300 205 300
timeout /t 1 /nobreak >nul
adb -s 192.168.2.170:5555 shell monkey -p com.suchbyte.macrodeck -c android.intent.category.LAUNCHER 1

4. heartbeat-tablet.bat — lightweight ping, every 58 minutes

adb connect 192.168.2.170:5555
timeout /t 1 /nobreak >nul
adb -s 192.168.2.170:5555 shell input keyevent 224

5. Two Task Scheduler jobs

One triggered on system resume (Power-Troubleshooter, Event ID 1) running wake-tablet.bat, and one recurring every 58 minutes running heartbeat-tablet.bat — with "start when available" enabled, so a missed cycle catches up the moment the machine wakes instead of getting skipped.

This is tuned for a Fire Tablet running MacroDeck, but the heartbeat pattern works for any always-plugged-in Android device you want to keep reachable without fighting Windows' own sleep timing.

The Point

The simple fix beat the elegant one.

Here's a solution that works — and it feels less like scripting and more like orchestrating: two devices talking to each other cleanly across a network that's already well set up and documented, like a well-run line of dominoes. None of it works without that groundwork already in place.

It's not having to think about turning things on and off, or wondering whether something's charged. This is the first step in automating my workspace — not the last.

What's the oldest device you've kept alive with a script instead of replacing it? Drop it below.

This post contains Amazon affiliate links. If you purchase through them, I may earn a small commission at no extra cost to you. Every product listed here is something I personally own and use daily.

Thursday, July 30, 2026

Beyond the Internet — Watching the Network

Networking · Infrastructure · Monitoring

Beyond the Internet — Watching the Network.

When I first started building my homelab, I wasn't trying to create a lab at all.

I was simply solving a problem for myself. Normally, I build things because a client asks for them. This time, I was the client. Well — the direct client, not the final one.

One service became two. Two became five. Then ten. Before I realized it, the homelab had grown into something that other people relied on every day.

And that changed everything about how I needed to think about it.

Sometimes the internet isn't the problem. Sometimes the network still has work to do — and nobody knows it until someone notices that the photos aren't syncing.

The Problem

The network might still appear online while something important is broken.

A while ago, I created a simple troubleshooting guide so anyone in the house could recover the internet if it went down. That solved one problem.

But the network is much more than internet access now. Today the homelab runs photo storage, a music server, a DNS filter, a firewall, a Cloudflare Tunnel, a service launcher, and an external management system for a client. Each of these services can fail independently — and when one does, the network might still appear "online" while an important part of it is actually broken.

That's when I realized I didn't need another troubleshooting guide. I needed visibility.

The Solution

One screen. Five services. Green or red.

I wanted anyone to be able to glance at a screen and immediately know whether everything was healthy, what service was down, and whether something needed attention. No commands. No SSH. No digging through logs.

Uptime Kuma — a self-hosted monitoring tool — runs in Docker on the NUC. It checks each service every 60 seconds and shows a simple status: up or down. That's all anyone needs to see.

Uptime Kuma showing all services green

Uptime Kuma — 5 services monitored, all green.

Monitored services

🔥 Firewall — OPNsense · 192.168.2.1
🛡️ DNS — Pi-hole · dns.home:8080
📷 Fotos — Immich · fotos.home:2283
🎵 Music — Navidrome · music.home:4533
🔧 Taller — taller.creativelydifferentbuilds.com

The Physical Dashboard

A repurposed Samsung A51 — always on, always visible.

The monitor lives on a Samsung A51 running Fully Kiosk Browser in kiosk mode — screen always on, always showing the status of every service. It connects to Uptime Kuma over the local network at monitor.home:3001.

The goal is simple: anyone in the house — whether they understand the technical details or not — can glance at the screen and know if something needs attention. Green means everything is working. Red means something needs a look.

Samsung A51 showing Uptime Kuma with all services green

Samsung A51 repurposed as a physical dashboard — always on, always visible.

The Launcher

Access for the family — no technical knowledge required.

Alongside the monitor, the service launcher now includes a card for Uptime Kuma. Anyone in the house opens servicios.home:8888 from any device — phone, tablet, or PC — and has direct access to every available service. No IP addresses. No ports to remember. Just names.



The Monitor card is now in the launcher — accessible from any device on the network.

What's Next

The list keeps growing — and that's the point.

As more services come online — home automation, security cameras, a local AI assistant, a family photo album, a music library — each one gets a card in the launcher and a monitor in Uptime Kuma. The infrastructure grows, but the experience stays simple.

Eventually, I'd like to build a guest access system — a QR code menu with curated services for visitors. A pre-selected family photo album. A shared music library. Maybe a local AI assistant. Content that's safe to share, easy to access, and requires nothing more than scanning a code.

That's still an idea. But the infrastructure to support it is already here.

Quick Setup Guide

Get Uptime Kuma running in under 5 minutes.

Requirements: Docker installed on any always-on machine

1. Run the container

docker run -d \
  --name uptime-kuma \
  --restart unless-stopped \
  -p 3001:3001 \
  -v uptime-kuma:/app/data \
  louislam/uptime-kuma:1

2. Open the dashboard

Go to http://[your-server-ip]:3001 and create your admin account.

3. Add a monitor

Click + Add New Monitor → Type: HTTP(s) → enter the URL of your service → set interval to 60 seconds → Save. If the service uses a self-signed certificate, enable Ignore TLS/SSL error.

4. Add a local DNS record (optional)

In Pi-hole → Local DNS Records → add monitor.home pointing to your server IP. Now anyone on the network can open it by name.

There are many detailed guides out there for setting up Uptime Kuma — this is just the version that worked for me. If you run into something specific or need help getting it running in your setup, drop a comment below.

Real World Update

The internet was working. The photo service wasn't.

This is exactly why I built this. The internet was up. The network was running. But Immich — the photo service — went down, and the monitor caught it immediately with a timestamp.

The reason: photos don't have a permanent server yet. Immich runs on my main workstation, and when I shut it down for the night, the service goes with it. That's a known limitation — one that will be resolved when the services move to a dedicated always-on machine. For now, the monitor makes that limitation visible instead of invisible.

As soon as the workstation came back online, Immich recovered automatically. The monitor logged the downtime, the duration, and the recovery — without me having to check anything manually.

Samsung A51 showing Immich down after workstation was turned off

Immich down at 22:43 — timeout of 48000ms. Back up at 22:44 when the workstation came online. The monitor is in Spanish because my wife and kids are native Spanish speakers — the system should work for everyone in the house.

That's the point of visibility. Not to prevent every failure — but to know exactly when it happened, how long it lasted, and when it recovered. Without asking me.

The Honest State

It works perfectly. It looks like a work in progress.

Right now, the A51 is literally thrown on my desk — and it looks exactly like that. Next to the Fire Tablet running MacroDeck, the setup works perfectly but doesn't look intentional. Because it isn't yet.

"If a cluttered desk is a sign of a cluttered mind, of what, then, is an empty desk a sign of?"

— Albert Einstein

I've read that quote many times. And I agree with it — I don't want an empty desk. I want one that looks organized and functional. One that doesn't make a visitor wonder what happened here.

The plan is to mount both the A51 and the Fire Tablet on the wall with permanent connections to the PC. Everything within reach, nothing in the way. The desk stays as the workspace — the wall becomes the command surface.

That's the next project. Unless my mind takes a different route first — which, if you've read this blog, you already know is a real possibility.

The Point

A well-monitored network is one that anyone can trust.

The internet might be fine. But the network has more work to do. And now, anyone in the house can see exactly how it's doing — without asking me.

Green means everything is working. That's all anyone needs to know.

What are you monitoring in your homelab? Drop it below.

This post contains Amazon affiliate links. If you purchase through them, I may earn a small commission at no extra cost to you. Every product listed here is something I personally own and use daily.

Wednesday, July 29, 2026

If It Only Works for Me, It Doesn't Work.

Networking · Infrastructure · Design

If It Only Works for Me, It Doesn't Work.

When I started this blog, it was simply an excuse to write.

A place to document ideas, experiments, and the occasional lesson learned after breaking something.

My homelab started the same way. It began as a technical challenge. I wanted more control over my own infrastructure. More privacy. More ownership over the services I used every day.

At first, everything was built for one person. Me. I knew every IP address. Every port. Every password. Every service had its own bookmark, its own shortcut, its own way of being accessed.

That worked — but only for me.

If every new application requires me to explain "go to this IP address, on this port" — I haven't built a useful system. I've built a puzzle.

The Realization

This infrastructure isn't just mine.

My wife uses it. My children use it. Guests will eventually use parts of it. And hopefully, years from now, they'll use services I haven't even deployed yet.

If every new application requires me to explain "go to this IP address, on this port, using this browser" — then I haven't built a useful system. I've built a puzzle.

Don't Make Me Think

The best systems don't ask users to remember.

One idea has been influencing my thinking for years: Don't Make Me Think. Steve Krug wrote about it in the context of web design, but I believe the principle applies almost everywhere. The best systems don't ask users to remember. They don't require explanations. They simply make the right thing obvious.

I realized my homelab deserved the same treatment.

The Solution

Names instead of numbers.

Instead of asking people to remember addresses like 192.168.2.114:8080 or 192.168.2.20:2283, I configured local DNS records in Pi-hole so every service now has a name:

Local DNS records

firewall.home
dns.home
nas.home
fotos.home
music.home
servicios.home

Pi-hole local DNS records

Pi-hole Local DNS — 6 registros activos, nombres en vez de IPs.

Nobody has to remember where a service lives. Only what it does.

The Launcher

A starting point for everyone in the house.

I built a launcher that lives on any device in the house — a simple page that shows only what's relevant to each person. Not because they need access to everything. Quite the opposite.

The goal isn't to expose every service. The goal is to make the available ones effortless to find. No documentation. No explanations. No technical knowledge required.

It runs on the NUC — the machine that's always on — served by a simple Nginx container. Any device on the network opens servicios.home:8888 and sees it immediately.

Tarjetas de servicios del homelab

Servicios activos y planificados — cada uno con nombre, no con IP.

Launcher de servicios abierto en el Pixel

El launcher abierto en el Pixel — accesible desde cualquier dispositivo en la red.

The Philosophy

This may seem like a small change. Philosophically, it changes everything.

The infrastructure stops feeling like a collection of servers and starts feeling like a product. One designed for people instead of administrators.

Eventually I want to add much more — a local AI assistant, a family wiki, a digital library, internal tools, automation. The list keeps growing. But I've learned something important: every new service should become easier to discover, not harder. Adding functionality should never increase complexity.

External access is a completely different problem. That requires authentication, permissions, reverse proxies, VPNs, and much stricter security. I'll write about that separately.

Inside my network, my philosophy is simple: if someone has permission to use a service, they shouldn't have to think about how to reach it. They should simply open it.

The Point

A well-designed system disappears.

The funny thing is that this has very little to do with servers. It's really about design. A well-designed system disappears. People stop thinking about how to use it and simply use it.

That's the kind of infrastructure I want to build. Not one that impresses me. One that quietly works for everyone else.

If someone has permission to use a service, they shouldn't have to think about how to reach it. They should simply open it.

How do you handle service discovery in your homelab? Drop it below.

This post contains Amazon affiliate links. If you purchase through them, I may earn a small commission at no extra cost to you. Every product listed here is something I personally own and use daily.

Tuesday, July 28, 2026

Designing Around Constraints.

Philosophy · Design · A Life's Work

This is the final post in the six-part series Build Different — How I Think. If you haven't read the others, they're all worth starting from the beginning.

Designing Around Constraints.



I never start from a blank canvas. A blank canvas paralyzes me. I need something to push against — a restriction, a problem, a condition I can't ignore — before anything starts to move.

That's not a limitation I learned to work around. It's how I've always worked. And it took me most of my life to understand that it wasn't a flaw.

You never start from a blank canvas. You start from what's already there.

Before the Tools

A blank surface with no rules was uninteresting. A surface with limitations gave me something to design inside.

Before computers, before software, before design school — I drew.

Not on paper, necessarily. There were pieces of plaster chalk near the house growing up. We used them to draw on the street. In another neighborhood, I used markers on walls. Almost always monochromatic. Patterns. Mosaics. Geometric shapes on sidewalks. Not flowers or vases — my mother enrolled me in drawing classes and I was bored immediately. Still life didn't interest me. A mosaic on a sidewalk did.

I didn't know why at the time. I know now: my brain needed structure and repetition. A blank surface with no rules was uninteresting. A surface with limitations — the shape of a sidewalk tile, the width of a chalk line — gave me something to design inside.

My Father's Method

He never praised good grades. He rewarded good understanding.

My father was an engineer with more than 35 years of experience. And he had an ability that I've never seen replicated: he could explain anything to anyone using whatever was at hand.

If the person listening was an upholsterer, he explained mechanical engineering through upholstery. If they worked in pastry, he explained it through baking. If they were a designer, he spoke in design. He adapted the explanation to the way the other person processed information — not to show off, but because getting the concept across was what mattered. The medium was irrelevant. The understanding was everything.

He never praised good grades. He rewarded good understanding. His rule was simple: understand the concept first — everything else follows. Decompose the knowledge, then recompose it in a way you can work with.

I didn't know at the time that I was learning a method. I was just a sponge — absorbing everything from everyone, especially him. But that instruction became the foundation of everything I've done since: find the formula hidden inside the problem, understand it completely, and then you'll know exactly what needs to be done.

I spent 25 years absorbing that — from birth until I left home. I became an expert at seeing the world the way he saw it.

What I didn't know until much later was that this was also how he worked. He collaborated with presidents, with multinationals, with international organizations. He solved problems of extraordinary complexity. And he never announced it. He walked down the street like anyone else. The people who needed to know what he had done — knew. And they sent others. Always by referral. Always because the work spoke before he did.

I watched that for 25 years. And I absorbed it without realizing I was learning anything.

1998. The First Computer.

The blank canvas never inspired me. A specific goal always did.

I was twelve. A PC arrived at the house. I discovered the internet — version 1.0. I spent time searching for images. When I learned I could change the desktop background, that became the daily goal. Change the wallpaper. Find something better. Change it again.

That obsession led to the first practical design decisions I ever made: a folder with dividers, printed and organized. Covers printed for notebooks. Not design projects — just solutions to small needs with the tools I had.

Then came the tutorials. Photoshop at 13. 3DS Max at 15. Freehand, Illustrator, After Effects. I learned the tools without knowing the theory behind them. I designed without structure. The blank canvas never inspired me — but a specific goal always did. Make this wallpaper. Build this effect. Solve this visual problem.

University — The Why Behind the How

The university didn't teach me to design. It taught me to think in design.

I arrived at university thinking I already knew how to design. I had the tools. I had the hours. What I didn't have was the vocabulary for why anything worked.

Balance. Hierarchy. Alignment. Typography. Proportion. Repetition. Color theory. Psychology of form. High contrast techniques. Pointillism. Building a color chart from scratch. At first it felt unexpected. Then it clicked.

Every assignment arrived as a restriction — a format, a brief, a set of rules. And automatically, before I started, I already knew the direction. The constraint didn't block me. It activated me.

A friend told me after graduation that university had been easy for me because I already knew how to design. It bothered me — it made my effort seem small. I told him: the university didn't teach me to design. It taught me to think in design. I didn't fully understand what I meant until years later.

2009 — The First Hard Technical Constraint

The tightest technical constraints produced the most creative solutions.

One of my first projects after university was building a virtual world inside a web browser. This was 2009. HTML5 didn't exist yet. Web-based 3D engines were in their infancy.

I joined the team and proposed a change: use a game engine to render everything in real time inside the browser. The restriction was severe — limited polygons, baked renders, textures compressed to 1024 pixels, all running inside a browser that wasn't designed for any of it.

It didn't last long. The funding ran out. But the lesson stayed: the tightest technical constraints produced the most creative solutions. Not despite the limitations — because of them.

The Paint Factory

The box changed. The approach didn't.

After that came the paint factory — the leading brand in the Dominican Republic. Pre-made label templates. Specific color systems. Budget limits at every level. Design that had to work within the brand, within the printing process, within the cost structure. The box changed. The approach didn't.

SIUBEN — 2013. The Hardest Brief.

How do I make someone want to look at this?

I became a father before I started at SIUBEN. I arrived focused on design. The real challenge came with the first book — a national statistical study. Hundreds of pages of data. Complex tables. Dense numbers.

I physically rejected looking at a complex statistical table — and I had to make one readable. If you've read the previous post in this series, you already know why that rejection wasn't just aesthetic.

I asked myself: how do I make someone want to look at this?

The answer was the same process I had been using my whole life, applied to data for the first time: Understand the data. Decompose it into parts. Restructure it into something worth seeing.

I used the same design principles I had learned in university — contrast, form, hierarchy, typography, negative space — but applied them to statistics instead of graphics. I didn't discover how to make infographics. I discovered I already knew how. I just hadn't applied it to data yet.

The publication was a significant success. Then I repeated the model. Understand. Decompose. Restructure. Every time.

The Formula Behind Everything

Every field has a formula. The skill is understanding it — and then designing inside it.

After 20 years of working across graphic design, communications, government, construction, and technology, I've noticed that every discipline follows the same structure:

The structures

Methodology of Research
Problem → (Data + Analysis) → Interpretation → Knowledge

Creative Brief
Challenge / Need → (Audience + Insight) → Key Message → Creative Solution

Advertising Campaign
Objective → (Insight + Creative Concept) → Media Plan → Impact / Conversion

Homelab
Need / Use Case → (Hardware + Software) → Configuration → Functional Service / Automation

3D Design / Render
Concept / Plans → (Modeling + Texturing) → Lighting / Render → Final Image / Animation

Software Development
Requirement → (Code + Logic) → Testing → Deployed Application

Fabrication / Workshop
Design / Diagram → (Cutting + Assembly) → Finishing → Completed Piece / Furniture

The domain changes. The structure doesn't. Every field has a formula. The skill is understanding it — and then designing inside it.

Working Behind the Scenes

Not visibility. Function.

My father never walked around showing his portfolio like a business card waiting to be praised. He worked hard. He did it right. He didn't announce it. And the right people always found him.

I learned that by watching him for 25 years — not because he taught it as a lesson, but because it was simply how he lived.

In almost 20 years of professional work, I've worked with every type of client — commercial, institutional, governmental, international. I've never entered a competition. I've rarely shown my work publicly. What exists is on Behance and Dribbble — and most of it is years old. The rest belongs to the people it was built for, under agreements that prevent me from showing it.

That aligns with something I've understood about myself for a long time: I work best as the number two. The person who makes things function without needing to be the protagonist. The one who finds the solution inside the constraint and hands it off without a signature.

There is a specific pleasure in watching something work — a system, a publication, a network, a kitchen — and knowing that you built it, without needing anyone else to know. My father taught me that pleasure. He lived it for 35 years. He worked with presidents and walked down the street like anyone else.

That's the version of success I understand best. Not visibility. Function.

The Closing

And what's already there is always enough to build something worth building.

My father simplified complexity. My mother invested in therapy I didn't understand at the time. The university gave me vocabulary for instincts I already had. Twenty years of clients gave me constraints I couldn't ignore. And every restriction — economic, technical, physical, temporal — produced work that unlimited freedom never would have.

You never start from a blank canvas. You start from what's already there.

And what's already there is always enough to build something worth building.

If any part of this series connected with the way you work — drop it below. I'd genuinely like to know.

Build Different — How I Think · Complete Series

Post 1 — Embrace the Mistake
Post 2 — Think Inside the Box
Post 3 — If I Have to Do It Twice, I Build a System
Post 4 — If I Can't See It, I Don't Understand It
Post 5 — Everything Wants a Second Life
Post 6 — Designing Around Constraints

This post contains Amazon affiliate links. If you purchase through them, I may earn a small commission at no extra cost to you. Every product listed here is something I personally own and use daily.

Monday, July 27, 2026

Everything Wants a Second Life.

Philosophy · Design · Reuse

Everything Wants a Second Life.


I didn't pick up this habit as an adult. I always had it.

My father held the position of electromechanical engineer and his various projects always left behind certain remnants — H-beams, structural pipes with a diameter of either four or five inches, forklift batteries, and other items which the clients regarded as trash but which he saw as having potential. These items would end up in a corner of the yard. To me as a child they appeared to be junk but to him they were stock. When clients from new projects came they would look for precisely what a previous client had thrown away. If you need 60 centimetres of beam, you shouldn't buy six metres just to get use of a portion of it; instead you should use what is already on hand.

When I was working in his office as an adult I became more aware of this fact: almost everything was put to a second use. That's when I first realised that things had potential before they had a specific purpose.

The question isn't "what is this for?" The question is "what else could this be?"

The First Job

Nothing I made came from the trash. It came from the leftovers of something bigger.

The first job I had professionally was in a sign shop, where I used a large-format cutting machine — five by ten feet. After each job there would be leftovers. Whenever you cut a five-metre sign consisting of 20 or 30 letters, various pieces fall off. Circles, squares, strips. For the shop the pieces were waste. For me they were material.

I turned those items into something during the spare time I had between jobs — coasters, keychains, key holders, small planters, decorative objects for the house. My boss liked it because it meant that he need not purchase new sheets when dealing with small requests. I was solving two problems at the same time: the residue and the need.

The Glass Tray

That table has already undergone at least four lives. It isn't finished yet.

I purchased a desk at a department store which included a retractable keyboard tray, but it was constantly hitting my knees so I took it off. However, the tray was made of tempered glass with ornamental bolts — too good to throw away.

The following day I visited the workshop and spoke to the man working there: I wanted the tray converted into a table, with an angle iron base, four legs, and a further shelf below. He carried out the work. The table then served as the base for the Logitech Z5500 subwoofer I had saved money for over two months. After I stopped using the speakers, my mother painted the table. Now it sits in her house as a plant stand.

That table has already undergone at least four lives. It isn't finished yet.

The Property With Maria

She brings the idea. I find the path.

My wife has a creative vision when it comes to decorating. As soon as she spots something she would like in the house, my first thought is never "we can't." It's always: "We can do that — let's figure out what we already have."

A lamp from a socket, a bulb, an extension cord, and a switch. A fragment of countertop as a nightstand. A paint bucket, cleaned and painted, as a planter. Bottles with labels removed, painted, as centerpieces. She brings the idea. I find the path.

We don't do it purely to cut costs. There is a value that extends beyond the object itself — the act of building something together gives the space a significance that no store can manufacture.

The Granite Ovals

Twenty sink cutouts. Four or five stools. Still there, years later.

My father and brother constructed bathrooms for an industrial site large enough to accommodate 500 or 600 employees. Ten sinks per bathroom, two bathrooms — twenty sinks total. Whenever the countertop was cut to fit each sink, an oval cutout remained: roughly 45 by 25 centimetres of solid granite.

My father didn't throw them away. He took them to the property outside the city. I suggested we convert them into stools and small tables — concrete base, pipe filled with concrete, granite top. He liked the idea.

They built four or five pieces, distributed around the property. Granite handles weather without issue — no rust, no mould. They're still there, years later, exactly where they were placed.

The Homelab

The same question. A different scale.

I moved to a different country. I needed infrastructure. I had hardware that other people would have regarded as obsolete.

The instinct surfaced again. Rather than outsourcing everything to cloud services or purchasing new equipment, I looked at what I already had and asked the same question I've been asking my whole life: what else could this be?

The result: a network serving a property of 1,200 m² with more than 30 devices — firewall, DNS filtering, Cloudflare Tunnel, self-hosted services, parental controls. Built from hardware that had no particular destination, with time and documentation as the main investment.

The Honest Disclaimer

This isn't a philosophy of going to the landfill and restoring what you find. It's not ideological recycling. It's not hoarding.

Each time something is left over — from a purchase, a project, or a job — I consider a possible second use before I think of it as waste. Not every item has one. Not everything is worth the effort. And converting one thing into another is rarely completely free — there is always some reinvestment of time, skill, or money.

But the mindset matters. Especially with materials that don't come in small quantities but can become something much larger than their original purpose.

The Point

Nothing has only one use until you decide it does.

My father asked the question about structural beams. I asked it about glass trays, granite ovals, and old computers. My wife asks it about paint buckets and glass bottles. My children are starting to ask it too.

Which means the answer to that question is the one thing in this post that has definitely found a second life.

The question isn't "what is this for?" The question is "what else could this be?"

What's the most unexpected second life you've ever given something? Drop it below.

This post contains Amazon affiliate links. If you purchase through them, I may earn a small commission at no extra cost to you. Every product listed here is something I personally own and use daily.

If I Can't See It, I Don't Understand It.

Philosophy · Mind · Visual Thinking

"I swear to you, gentlemen, that to be too conscious is an illness — a real thorough-going illness."

— Fyodor Dostoevsky, Notes from Underground (1864)

If I Can't See It, I Don't Understand It.


I found out I was dyslexic as an adult. Not from a doctor. Not from a formal evaluation. From a style consultant who noticed a pattern during a 400-page document review session — and typed "dyslexia indicators" into Google while I watched.

Every item on the list was a click. Every description was my life. And instead of feeling like something was wrong with me, I felt something I hadn't expected: relief. I had just put a name on a way of thinking I'd had since childhood.

This is that story — from the beginning.

The Beginning

My mother never called it therapy. She called it extra class.

When I transitioned from kindergarten to primary school, something happened. I don't remember the details — I was a child. What I do remember is that my mother received information, and that summer before first grade I spent my vacation in what she called a "homework room." A special leveling course. For me, it was just class.

From second grade onward, I always had somewhere to go after school. A homework room. Educational therapy. Some kind of specialist. The locations changed. The content was always the same: mathematics, which was always relatively easy for me, and calligraphy. Endless calligraphy.

My mother never explained why. I never asked. I was a child — I assumed it was just something children did.

What I do remember is a specialist telling her — not me — that my brain recognized patterns faster than normal. That I thought quickly. My father later mentioned that someone once told them I had the mental ability to disassemble something in my mind without ever having seen it taken apart.

Nobody told me any of this at the time. For me, it was just extra class.

The Calligraphy

Twelve years of the same cursive system. From second grade to the last day of high school.

My school had its own cursive calligraphy system and required every student to maintain it. Combined with the therapy sessions, I spent years doing calligraphy. It was repetitive. It exhausted me. And somewhere in that exhaustion, I started looking for ways to do it faster without losing legibility.

My handwriting was never beautiful. But it was readable. That was enough.

Looking back, I think those years of forced repetition planted something. The instinct to find a faster path through a repetitive task — without abandoning the result — started earlier than I realized.

The Method

I didn't memorize what the book said. I understood what the topic meant.

Grammar was always the exception. It still is. Words that sound identical to me but apparently have different accents, different meanings, different rules. I passed grammar with the minimum required grade. I think some teachers passed me out of sympathy — or out of recognition that I understood everything else.

Because in the subjects that made sense to me — mathematics, physics, chemistry, biology — I excelled. I became addicted to Discovery Channel and National Geographic documentaries. Not as entertainment. As input. My brain absorbed scientific information through video in a way it never could through text.

When I had to give presentations, I stopped trying to memorize the material. Instead, I took the topic, mixed it with information from a documentary I already had in my head, and explained it in my own words. I didn't say what the book said — I said more than the book said. And the teachers loved it.

I could explain how the heart works by comparing it to a car engine. I could explain mathematics using chairs and cushions instead of numbers. I could explain physics concepts using things I'd seen in documentaries that had nothing to do with the textbook.

Understanding the concept was worth more than memorizing the answer. I just didn't know yet that this wasn't how everyone's brain worked.

The Notebooks

My notebooks weren't notes. They were infographics.

During every class, if there was a formula, a scientific explanation, or a concept I needed to hold onto, I would draw around it. A box around a key word. An arrow connecting two ideas. An icon next to a concept. A rough sketch of something the teacher described verbally.

My notebooks weren't beautiful. They were full of irregular shapes, marks, and drawings. For anyone else looking at them: chaos. For me: a system that worked perfectly. I understood my own visual language better than any clean set of written notes.

When the consultant named my condition years later, one of the first things that made sense was this. The tendency to take notes with graphics and very few words wasn't a study habit I'd developed. It was how my brain processed information. I just hadn't known to call it anything.

The Psychologist

She didn't name it. But she got close.

Before I finished high school, I spent about a week visiting an educational psychologist. I remember clearly what she told my mother: the problem wasn't lack of confidence. The problem was too much of it. I thought so fast, and I accepted my first answer so completely, that I stopped questioning whether it was right. I needed to learn to be wrong — consciously, intentionally.

She was partially correct. What she was describing was a symptom of something she didn't name. My brain moved fast. It skipped details. It accepted patterns as complete when they weren't. She saw the output — she just didn't know what was producing it.

The Name

The moment everything fell into place.

I was working on a 400-page national report — graphs, statistical data, full layout. The final review was done in group sessions where the economists read the document aloud and I made corrections in real time. They would identify a word, repeat it, and I would correct it in the file.

Except I couldn't see what they were pointing at. They would say a word and I would read the same line and see nothing wrong. They would repeat it. I would read it again. Still nothing. "I read it the same way — what's the problem?"

The consultant — a style editor — noticed the pattern. Not once. Not twice. Consistently. He asked me if I was dyslexic. I didn't know what that meant. We searched Google together. He read each indicator. Each one landed.

It wasn't a diagnosis that changed anything. It was a confirmation that named everything. The calligraphy sessions. The notebooks full of graphics. The documentaries. The presentations that went beyond the book. The grammar I could never see. The details I consistently missed. The visual memory that operated above average. All of it had a name. And the name didn't make me less capable — it explained why I had spent my whole life building systems to compensate for something I didn't know I was compensating for.

The team adapted. The economists learned to be specific: line number, paragraph number, exact word, exact change. Not because I needed less — but because that level of precision let me process the correction visually instead of grammatically. The solution wasn't to change me. It was to change how the information was delivered to me.

I kept working. I thanked my mother for the effort she put into something she never fully explained. And I moved on.

The Visual Memory

Reading exhausts me. Images don't.

Reading a book puts me to sleep. Not because the content isn't interesting — because the act of reading requires extra effort that most people don't notice because they've never had to. Every sentence costs more than it should. Eventually the brain gives up.

But I can scan 2,000 or 3,000 photos — sorting by color, by composition, by form — quickly and accurately. I can hold visual information in memory in a way that doesn't translate well to words but works perfectly in images. An online test I took confirmed it: visual memory above average.

The brain that struggles with grammar and misses typographical details is the same brain that can disassemble a concept mentally, translate it into a visual system, and build something from it that nobody asked for — because it could already see what it would look like before it existed.

The Point

It wasn't a limitation. It was a different operating system.

The doodling wasn't distraction. The documentaries weren't procrastination. The infographic notebooks weren't poor study habits. The systems I built at every job weren't just efficiency — they were compensation mechanisms that worked so well I never needed to know why I was building them.

I didn't find out I was dyslexic and suddenly understand everything. I found out I was dyslexic and realized I had already figured most of it out — I just hadn't known what I was solving.

My mother put in the effort. My father named the ability. A consultant named the condition. And somewhere between the calligraphy sessions and the 400-page report, I built an entire way of working around something I didn't know I had.

If you can't see it, you don't understand it. That's not a weakness. That's just how some brains work — and once you know it, you can build everything around it.

Do you process information differently than the people around you? Drop it below.

This post contains Amazon affiliate links. If you purchase through them, I may earn a small commission at no extra cost to you. Every product listed here is something I personally own and use daily.

If I Have to Do It Twice, I Build a System.

Philosophy · Design · Process

If I Have to Do It Twice, I Build a System.


I have to be honest about something first: repetition exhausts me.

Not in a dramatic way. But when I realize I have to do the same thing a hundred times, something in my brain activates that refuses to accept it as the only option. The repetitive task stops being a task and becomes a problem waiting to be solved.

In my years working as a graphic designer, I encountered two very different types of work.

The first was complex. Corporate identity. Advertising campaigns. Report layouts. Press kits. These projects required thinking, coordination, adapting to the constraints of the brief. They were demanding, but they were interesting.

The second type was repetitive. A set of 40 name badges for a sales department. 300 business cards with different information on each. A catalog of 1,000 products where name, category, code, and price repeat in the same position on every page. Five or six presentations of the same product for different regions. A session of 350 photos that needed consistent backgrounds and uniform crops before they could be used for anything.

The complex work required my full attention. The repetitive work required my patience — and I don't have much of that when the solution is sitting right there.

The tools were always available. The question was always the same: are you willing to invest the time to learn them?

The Discovery

I found genuine pleasure in spending 15 hours to automate something I could do manually in 3.

Batch processing in Photoshop. Data Merge in InDesign. Scripts in Illustrator. Mail Merge in Word. Automatic numbering in PDF. These tools existed long before I started using them. Most people in my field knew they existed. Very few invested the time to actually learn them.

I did. And I found something unexpected: genuine pleasure.

I would spend 10, 15, sometimes more hours figuring out how to automate something I could have done manually in 3 or 4. Not because I was being inefficient — but because I understood that once the system was built, I would never have to do it manually again. The investment paid for itself the next time the same problem appeared. And the time after that. And the time after that.

That moment when the automation runs for the first time and produces exactly what you needed — without you touching it — is a specific kind of satisfaction that's hard to describe. A confirmation that the hours were worth it.

The Cases

Seven problems. Seven systems. All built with tools that were already there.

350 staff photos. The institution hired an inexperienced photographer to take ID photos of all staff members for their institutional badges. Instead of a clean backdrop, she used standard A4 paper sheets as the background — inconsistent, wrinkled, and far from professional. Manual editing for 350 photos would have taken days. I set up a Photoshop Batch: automatic subject selection, standardized crop, background removal, export. All 350 processed in a fraction of the time. The imperfect input became a clean, uniform output.

Data Merge — one tool, every repetitive problem. InDesign's Data Merge became my answer to almost every repetitive design task. I used it for statistical infographics — 36 regional documents generated almost automatically from a structured data table. I used it for 10,000 field staff identifiers. I used it for full department business card sets.

But there's a benefit nobody talks about: Data Merge forces the information to arrive in a table. That means every department had to organize their data in a structured format before sending it to me. Errors were caught before they reached the design. The automation didn't just save time on output — it standardized the input.

The numbered receipts. The accounting department ran out of pre-printed numbered receipts and was waiting on a purchase order to restock. I built the template, set up automatic numbering, and exported the PDF. Printed on the laser printer already in the office. It was so efficient that the department cancelled the purchase order entirely. The cost of printing locally was lower than the procurement process. Automatic numbering is a native feature in InDesign, Illustrator, and PDF export. It just required someone to use it.

The institutional identity crisis. A government institution went through a brand identity change. The new isotype arrived 30 to 35 days late — no official stationery could be printed for 10 regional offices during that time. My solution: a Word template with the header and footer locked, containing the new identity. Every department already had a digital color printer. The purchase order for offset-printed stationery was cancelled. The files were already there.

The measurement ruler. One of the most frequent conversions I did was between inches and centimeters. I printed a custom conversion ruler and left it permanently on my desk. The next time someone arrived with a measurement question, I didn't calculate. I put the object on the ruler.

The paper form distribution. Distributing forms to field units across the country meant counting stacks constantly — always in multiples of 50. I converted the stack height into a measurable reference using the industrial copier's output. Units stopped asking me to count. They came, read the ruler on the stack, and took what they needed. Over four months, I processed approximately 750,000 copies. Counting each delivery by hand would have been impossible.

The homelab. The same instinct that built systems in professional environments eventually applied to the homelab. When a cable broke mid-run through a wall in a tenant's property, re-cabling the entire line wasn't an option. I relocated a router, converted it into an access point, and used its position as a signal relay. The wall stayed closed. OPNsense restarts automatically after a power cut. Pi-hole runs in Docker with a restart policy. Cloudflare Tunnel reconnects through systemd. I didn't build the homelab to manage it every day. I built it to manage itself.

The Honest Limit

I don't automate everything. I automate what I can control.

Some repetitive tasks require equipment or resources I don't have access to. An automatic die-cutting machine is incredibly expensive — so when I have to do die cuts, I do them by hand. No complaints.

But if I can automate it within the digital tools I already control, I will. Every time. Because once you've built the system, the work stops being repetitive. It becomes a process. And a process can be improved. A repetitive task just gets done again.

The Point

I don't work harder. I work once.

Every system I built started with the same frustration: having to do something again that I had already done before. Every automation was a decision not to solve the same problem twice. And every time I found a tool already sitting in the software I was using — already available, already documented, just waiting for someone to invest the hours — I felt the same thing.

Not efficiency. Satisfaction.

The tools were always there. The question was always the same: are you willing to invest the time to learn them, so you never have to do it manually again?

What's the most repetitive task you've ever systematized? Drop it below.

This post contains Amazon affiliate links. If you purchase through them, I may earn a small commission at no extra cost to you. Every product listed here is something I personally own and use daily.