Hi, I’m Dmytro.
I’m a software engineer, and this publication is where I try to understand complicated engineered systems well enough that they stop feeling like black boxes.
Sometimes that means rebuilding a small version from scratch. Sometimes it means following a packet, a clock, or a protocol through all the layers below an API. And sometimes it means starting with something enormous, like the electrical grid, and working backwards until I can see where software, networks, devices, physical processes, and people meet.
If you are new here, you do not need to read everything in chronological order. Pick the system that interests you and start there.
🔬 What I am working on now: networking for software engineers, followed all the way from Ethernet and IP into Linux, substations, industrial protocols, and the power grid.
I want to understand networking
This is my newest project and probably the best place to start if you want to follow what I am building right now.
I wanted to understand networking below the familiar application APIs, but I did not want another tour through definitions of MAC addresses, ARP, routing tables, and interfaces. So I did something slightly less reasonable and rebuilt the network as a system of medieval signal towers.
The first part builds a local network and reconstructs Layer 2, Ethernet frames, MAC addresses, switches, broadcast, and ARP. The second part expands the kingdom into an empire and forces us to invent IP addresses, prefixes, gateways, and routing. The next step is to move inside Linux and rebuild the same machinery using interfaces, namespaces, veth, bridges, routes, and packet captures.
This is also the bridge into the next question: how does the power grid use this machinery when the packets are carrying measurements, protection events, commands, and remote engineering traffic?
Start here:
I want to understand the electrical grid
A few years ago I could write software used in the energy sector while still having a surprisingly weak mental model of the physical system around it. I knew individual terms, but I could not see the whole machine.
So I started from the beginning.
Why does frequency matter? How does electricity actually move? What do transmission and distribution operators do? How is the grid kept stable? Where do markets enter the picture? And where, across all those layers, does software actually live?
The result became a series that explains the European electrical grid from a software engineer’s point of view.
Start here:
I want to understand security and cryptography
TLS was one of the projects that shaped how I now learn technical systems.
I originally wanted to add HTTPS to a web server I had built myself. That small improvement turned into roughly a year and a half of learning about encryption, integrity, key exchange, certificates, authentication, trust, and protocol design.
Instead of starting with the finished TLS protocol, I built deliberately incomplete versions and fixed them one problem at a time. Encryption alone was not enough. Then integrity was not enough. Then key agreement was not enough. Each failure forced the next part of the protocol to exist.
Start with TLS:
TLS eventually pushed me deeper into the cryptographic machinery underneath it, so I also built a separate path through encryption, block ciphers, MACs, hashes, public key cryptography, and the ideas behind modern security.
Start with cryptography:
I want to understand systems fundamentals
Some systems do not look mysterious until you ask one question too many.
Time is a good example. Calling now() feels trivial until several computers need to agree on what “now” means. Then you end up with oscillators, clock sources, drift, synchronization, NTP, PTP, Linux clocks, hardware timestamps, and distributed systems behaving badly because a clock was slightly wrong.
Start here:
The web server project is older, but it is where this whole rebuilding habit really started. I built a small server piece by piece and followed HTTP, sockets, TCP, concurrency, and operating system interfaces below the simple request and response abstraction.
Start here: Building Your Own Web Server
How I approach these projects
I do not want to rewrite documentation in friendlier words and call that understanding.
The pattern I keep returning to is to begin with a smaller or intentionally incomplete model, make it work, find the assumption that breaks, and then introduce the next piece because the problem makes it necessary.
That is why the TLS series begins with bad security before arriving at a recognizable handshake. It is why the networking series begins with towers in one valley before introducing IP and routing. And it is why the power grid series starts with the physical system before asking where software belongs.
The finished technology often hides the reasons for its own shape. Broken versions are much less polite. They show you exactly what is missing.
Whenever a project can be made executable, I also try to put the code, experiments, diagrams, or packet captures next to the explanation. You can find the repositories and experiments on GitHub.
What connects all of this
TLS, Linux networking, cryptography, time synchronization, and the electrical grid do not look like one subject.
For me, they are connected by the same questions.
How does this system really work? Where are its boundaries? Which layers depend on which other layers? What assumptions are hidden behind the abstraction? What happens when one of them fails? And what becomes obvious only after I try to build part of the system myself?
That is the thread behind Rebuilt.
I am increasingly interested in systems where software cannot pretend the physical world does not exist. Networks carry real operational decisions. Protocols connect real devices. Timing, reliability, security, and failure behavior have consequences outside a browser window.
That is where I expect most of the next projects to go.
Follow the work
I publish these projects while I am still learning them, which means the map keeps changing as I understand more.
If this kind of systems work is interesting to you, subscribe to Rebuilt and follow the next reconstruction as it develops.