The lights go out, the fridge goes quiet, and for about two seconds the whole apartment holds its breath. Then the power station clicks over, the router blinks back to life, and my terminal is still open where I left it.
That two-second pause used to mean a lost afternoon. Now it barely interrupts a thought.
Outages are a schedule, not a surprise
Living in Kyiv, I stopped treating blackouts as emergencies a long time ago. They are closer to weather. Some weeks there is a schedule you can plan around. Some weeks there is not, and the power simply leaves when it wants to.
The mistake I made early on was waiting. Waiting for the electricity to come back before starting anything serious. Waiting for a "proper" block of time with stable internet. Those blocks did not come often enough, and the work did not care.
So I changed the question. Not "when will the power be back?" but "what can I do with what I have right now?"
The boring kit that keeps me working
My setup is not exciting, and that is the point.
A portable power station sits under the desk and quietly feeds the laptop, the router and a lamp. A small satellite dish on the balcony gives me internet when the local provider's equipment goes down with the grid. A couple of cables and one small adapter make the router run straight from the battery instead of through its own power brick, which wastes energy converting power back and forth.
Each piece solved one specific failure I actually had. None of it was bought because it looked cool in a video. Most of it came from one annoying evening when something stopped working and I wrote down why.
That is also how good infrastructure gets built at work. Not from a big plan on day one, but from a list of real incidents and a fix for each.
Work that survives a cut
The hardware is the easy part. The harder part is shaping the work so it survives a sudden stop.
I commit and push more often than I need to. Small commits, clear messages, nothing important living only on my laptop. If the power goes and the battery runs low, the worst case is losing ten minutes, not a day.
I keep a short note at the top of whatever I am doing: what I was trying, what is half-finished, what to check next. When the lights come back an hour later, I do not have to rebuild my head from scratch. I just read the note.
And I split tasks into pieces that can finish in thirty or forty minutes. A long refactor with no safe stopping point is a bad idea when you do not know if you have forty minutes or four hours.
Offline is a mode, not a failure
Some work does not need the internet at all. Reading code. Writing tests. Sketching a design on paper. Writing a post like this one.
I keep a small list of offline tasks for exactly these moments. When the connection drops, I do not stare at a spinning icon. I switch lists.
It turns out a lot of deep work happens better without notifications anyway. Some of my cleanest code was written in a dark room with a phone on low power mode and nobody able to reach me.
The real lesson
It is tempting to think resilience is about having the best gear. It is not. It is about expecting interruptions and making them cheap.
A team that deploys small changes recovers fast from a bad one. A developer who saves often loses little when the laptop dies. A person who plans for the lights going out is not shocked when they do.
So when the apartment goes quiet tonight, I will probably keep typing. Not because I am brave or stubborn, but because a few years of outages taught me something simple: you do not need perfect conditions to ship. You need a battery, a plan, and the habit of pressing save.
