Understanding how something works, finding where it fails, and improving it, whatever discipline that happens to be in.
Click a discipline to see how it connects.
I’m Selim Kandaz, based in the Houston area. I graduated with a degree in Software Engineering in 2024, and my background started mostly in software and IT, but somewhere along the way I got pulled toward the physical side of computing: the servers, firmware, and hardware that software actually runs on.
I currently work at CloudNinjas, in a hands-on role built around enterprise servers and computer hardware. What keeps me interested in that work isn’t just operating the equipment. It’s understanding how it actually works underneath, noticing where a process is slow or error-prone, and building something better around it. Day to day, that means working across vendors and platforms like Dell PowerEdge, HPE, ASUS, and Supermicro: BMCs, iDRAC, iLO, BIOS and firmware, RAID and storage, SSDs and HDDs, memory, diagnostics, stress testing, log collection, and validation.
Software engineering and hardware operations turned out to be a natural combination for me. If a process is repetitive, I start thinking about how to automate it. If a result can’t be independently checked, I start thinking about how to make it verifiable. That instinct is behind most of the tools I’ve built for myself: server testing, hardware inventory, diagnostics, automated reporting, memory and storage validation, firmware operations, and general Linux-based automation. Two of the larger ones, CNServerOps and SelimPyCoder, along with a handful of smaller utilities, are on the Engineering Work page. What matters more than any one of them is the pattern behind how I approach them: understand the existing workflow first, find where time or accuracy gets lost, then design the system around the environment as it actually is, not the other way around.
I write mostly Python and I’m comfortable in both Windows and Linux, but the real interest isn’t “writing code” on its own. It’s what’s underneath it: boot processes, networking, APIs, firmware interfaces, hardware telemetry, system logs, the layer where software meets physical hardware. That’s also where my interest in local AI comes from. I’m less interested in AI as a chatbot and more in what it can do wired directly into engineering workflows: diagnostics, data analysis, automation, decision support, in a way that still leaves a human able to check what the system is actually doing.
Outside of servers, I don’t really separate “software person” from “hands-on person.” To me they’re different ways of solving the same kind of problem. Cars are probably my biggest interest outside computers: mechanical repair, electrical troubleshooting and wiring, audio installation, body work, dent repair, polishing, paint correction, and painting. I’ve repaired forklifts, where electrical, hydraulic, mechanical, and control systems all have to be reasoned about at once. I’ve done concrete work, welding, wiring, and general fabrication, and I like 3D printing for the same reason I like most of this: it moves something from a screen into a physical object you can actually test. More recently I’ve been getting into aviation and avionics, which sits at almost exactly the intersection I find most interesting: electronics, computing, diagnostics, and mechanical systems, in a context where reliability actually matters.
A server, a car, a forklift, and an aircraft don’t have much in common on the surface. But they’re all systems built from interacting parts, and figuring out how those parts interact, and where they fail, is the part I actually enjoy, more than any single technology.
That shows up in how I solve problems. I want to know what’s actually happening, not what sounds like it should be happening. If a diagnostic tool says a drive is healthy, I want to know what SMART data that’s based on. If a report says a component passed, I want to know what was actually tested. I’m skeptical of numbers I can’t trace back to real evidence, which is probably why validation, traceability, and keeping raw evidence around, instead of just a summarized verdict, keep showing up in the systems I build.
At the same time, I try to stay practical about it. A technically elegant solution that technicians won’t actually use isn’t a good solution. I’d rather build something that removes real steps and real mistakes than something that’s clever for its own sake, and I usually build it in stages: get a first version working, test it against real hardware, find out where my assumptions were wrong, then fix the design instead of patching around it.
Most of what I know about servers, automotive work, electronics, mechanical systems, and fabrication didn’t come from a classroom. My degree gave me a foundation, but the rest came from working on things directly, getting them wrong sometimes, and sticking with a problem until I understood it. That’s probably the actual throughline across all of this: I like knowing how something works, and once I do, I usually start wondering whether I can fix it, improve it, automate it, or build my own version of it.
There’s more of this ahead: more automation, more hardware platforms, more of the aviation side, and more ways to get real use out of AI without losing the ability to check its work. None of it is finished. That’s fine; it isn’t supposed to be.