The Invisible Systems Engineer: Notes from a Legacy Office in Japan |
There is a particular tiredness that comes from living on two clocks at once. I care about Linux, networks, and how systems actually fail. My weekday environment is a traditional office: locked-down Windows, paper in the air, and shelves of 1990s floppy disks that nobody can read because the drives are gone — but nobody wants to throw them out either.
I am Prakash Niraula, a system engineer at a construction company in Sakai, Osaka. I daily-drive Arch Linux at home, I have provisioned machines on Oracle Cloud, and I try to think in processes, isolation, and boring reliability. At work I am often the only person in the room who wants to talk that way. This is not a story about being exceptional. It is a story about trying not to lose the plot.
I am not “forged in fire.” I get exhausted. I get the timesheet app running for a few dozen people and still feel behind. The point of writing this is to name the gap — systems work vs spreadsheet culture — so I (and anyone in the same seat) can keep studying without waiting for the office to become a tech company.
The gap between systems and spreadsheets
Plenty of construction, manufacturing, and logistics firms still run the real business on macros, shared Excel files, and one person who “knows the sheet.” Modern cloud and backend work moves fast. Those offices often do not. If you like kernels, routing, and data structures, routine application support in that setting can feel like you are always slightly in the wrong room.
Misaligned scale
When core operations live in a fragile spreadsheet — one broken formula, one corrupted file — software is treated like a digital clipboard, not like something that can take the company down. I still have to respect that clipboard. People depend on it. I also have to see it as a risk, not as “just how we work.”
Hardware that was never meant for the job
Pushing a small fanless office router (the kind meant for basic VoIP) through a huge CAD copy job — tens of terabytes of traffic it was not sized for — is not a personality test. It is a capacity mismatch. Naming that without humiliating the people who bought the box is part of the job I am still practicing.
The isolation tax
Being the only technical lifeline means you carry design choices alone. There is often nobody to argue a network limit with, nobody to check a schema, and no shared vocabulary for “this request fights TCP” or “this will not survive a restore.” I do not always explain it well. I am still trying.
Language, tenure, and moving slowly on purpose
For engineers working abroad — including in traditional Japanese companies — the technical friction sits on top of language and hiring norms. I am not a native Japanese speaker. That makes every design conversation slower. Add the common local expectation that you stay in a first role for several years (often talked about as three to five), and you do not “just switch jobs” because the stack is dated.
You cannot always walk management through why an architecture will not work, or why a workflow will break, and have it land. Hierarchy and translation eat the details. That is frustrating. It is also the room I am in. I try to write things down, show a small demo, and pick which hills are worth the week.
Why this work burns energy so fast
Old hardware, rigid process, and language load do not magically make you tougher. They spend the same budget you need for learning. If most of my attention goes to office friction, a small internal app, and compliance, there is not much left for the systems work I actually want to get better at.
Weekends are not a secret lab. Saturday can disappear into leftover maintenance or just being empty. Sunday is laundry, food, cleaning — then Monday is already in the hallway. When a quiet hour finally shows up, I often lie down. That is not laziness. That is an empty tank. I am trying to protect a few of those hours instead of pretending I will “grind” through them.
Keeping a personal standard (quietly)
What I refuse to do is let the office’s tools become the ceiling of what I study. That is not a rebellion speech. It is a study habit I fail at regularly and return to.
On my own time I try — not always successfully — to keep a higher bar than the weekday stack: type-safe data layers, modular web apps, Linux boxes that I can rebuild, bits of functional programming (including Effect when I have the focus). The office can still be Excel and a locked PC. I can still read man pages after dinner if I have anything left.
What this actually trains. You get faster at spotting bottlenecks, fragile single points, and “this will hurt on Monday.” You start seeing software as something that has to survive backup, a bad NIC, and a tired operator — not only a UI. That is useful. It is not a superpower.
What I am trying next (without a movie ending)
I do not have an escape plan with a date on it. I have a few rules I am attempting to follow:
- Do the day job honestly. Keep systems up. Document risk. Do not martyr myself trying to convert an entire company to a stack they did not ask for. The salary is real. So is the duty of care. “Let it fail” is not a strategy I am comfortable preaching; “do not silently absorb infinite scope” is.
- Spend scarce attention on the hard parts. I use AI for boilerplate and first drafts of UI scaffolding, then I read the result. The scarce resource is judgment on architecture, networking, and ops — not typing speed.
- When I look for the next seat, look where the work is valued. Remote-first and international teams often weigh Linux and systems skills differently than a local tenure checkbox. Domestic pipelines still matter in Japan; I am not pretending I can ignore them. I am trying to keep both doors in view.
Moving from a legacy floor to infrastructure work that fits better is slow. The clarity I get from seeing fragile systems up close is worth keeping. The environment is temporary if I keep building skill. The mindset is what I am trying to take with me.
People also ask
Can you do systems engineering in a non-tech company?
Yes, in a limited way: backups, networks, identity, the one internal app everyone depends on. You will not get a platform team. You can still practice fundamentals if you protect study time.
Is Excel a real production system?
If the business cannot invoice or staff a site without it, it is production — even if it should not be. Treat it with the same suspicion you would give an unbacked database.
Should international engineers in Japan wait three years to change jobs?
Local resumes often read tenure strictly. That is a real constraint, not a myth. I am not giving career advice for every visa or industry. I am saying: know the cost before you burn a bridge, and keep skills portable anyway.
If this sounds like your week
I publish some of the systems and product work I can stand behind: projects, GOLO CRM, Web Converter Tools. If you want help with infrastructure, internal tools, or a workforce dashboard that should not live in a spreadsheet, send a short brief. I will tell you what I can do — and what I cannot.