Work
I like building difficult systems: the kind that sit close to the OS, span multiple layers, and remain loyal to real-world input while being strict and dependable in what they produce.
Over time, I found that the player-coach role fits me best. I don't want to be just a developer who completes assigned tasks on schedule and forgets about them at 6 PM, nor a gray-haired architect who stays high above the details, gives abstract instructions, and misses the real challenges developers face when turning those instructions into working code.
As a result, my role has gradually expanded beyond implementation alone. I still write code, debug hard problems, design subsystems, and do refactoring myself. But I also spend a lot of time shaping how engineering is done around me: through design work, code review, written principles, and development guidelines.
I am especially comfortable with problems that look impossible at first glance—systems that behave strangely, produce conflicting signals, or seem to resist straightforward explanation. My usual approach is simple: observe carefully, form a hypothesis, design an experiment, see what survives, and repeat until the problem stops being mysterious.
What I do
Most of my work lives at the intersection of low-level systems engineering, software architecture, and technical leadership.
I have spent years working on Linux-heavy software, including kernel-space and user-space components, security-sensitive design, reliability work, performance-conscious implementation, and large refactorings of code that had grown too complex to remain healthy.
I also write design documents, review other people's designs, and use code review as a serious engineering tool rather than a formality. A good review should not only catch defects. It should improve the design, make assumptions visible, and help the team converge on shared standards.
Another important part of my work is turning tacit engineering judgment into something more explicit. In recent years, I have written internal development guidelines and a series of short documents on engineering principles—such as "Happy Path Priority," "Single Source of Truth," "Separation of Abstractions," "Fighting Complexity," and others.
These documents create a common language for discussing engineering decisions and trade-offs. That matters not only because it saves time, but also because it helps build a shared understanding across the team of what good engineering looks like.
Operational Perspective
I am not only a software engineer. I also come from a long operational background.
For about fifteen years, I have been running my own remotely managed infrastructure for public and private services. The stack changed over time, of course, but the core reality stayed the same: real machines, real failures, real migrations, real users, real continuity requirements.
DNS, nginx, PostgreSQL, Redis, containers, failover, geographically distributed deployment—the usual infrastructure concerns that stop being abstract once real users depend on them.
Machines were replaced, services were moved, topology evolved, but I always treated continuity as a hard requirement. Changes had to happen without users noticing.
That experience matters because it changes how I look at software. I do not think only like someone who writes systems. I also think like someone who has to operate them, trust them, migrate them, and live with their failure modes. In security and infrastructure products especially, that difference matters a lot.
Experience
Here are the projects in my career I'm especially proud of:
CyberArk EPM Agent for Linux is part of CyberArk Endpoint Privilege Manager, a security product for centralized, policy-based privilege management across Windows, macOS, and Linux endpoints.
In November 2022, I joined CyberArk to work on the Linux agent. My main focus was architecture, implementation, reliability, and performance.
The project came with several challenges. One was the need to support a broad range of Linux distributions and versions, each with its own constraints and quirks. The harder challenge was designing a way to enforce privilege policies effectively without becoming intrusive to user-space applications and services, while still providing a high level of security.
After exploring several approaches, I designed a solution that combined kernel-level and user-space components. At its core was a dynamic kernel security module capable of hot-patching a live Linux kernel on the fly, without requiring a reboot or downtime. The design proved innovative enough to be patented, and CyberArk filed a patent application based on this work.
On November 4, 2025, this technology was granted US Patent 12,462,035. Here is my announcement about it: LinkedIn Post.
Over time, my role in the project expanded beyond architecture and implementation. I wrote internal development guidelines for the Linux agent team, covering both user-space and kernel-space work, and I also wrote a series of short documents on engineering principles that I use in design discussions and code review. These documents helped create a shared language for discussing trade-offs, abstraction boundaries, complexity, and code quality.
I also served as the final technical reviewer before pull requests were merged into the main branch. Alongside implementation work, this included reviewing designs, guiding refactorings, and helping keep the codebase conceptually clean and technically consistent.
The project aimed to create a cloud product that used consumers' mobile devices for computation, providing a familiar cloud experience while leveraging unused processing power on those devices. Mobile CPUs are increasingly powerful, and many phone owners don't use them 24/7, making it worth exploring how to utilize this idle capacity.
In May 2015, Dr. Lloyd Watts reached out after discovering my open-source project CrystaX NDK. He recognized my work in enabling the Boost C++ libraries on Android after reading my announcement and trying it himself. This demonstrated that Android could be used for more serious applications beyond typical user-oriented mobile apps and games.
For a long time, I was the sole developer, conducting extensive research to assess the project's technical feasibility.
The main question was: "Is it technically possible to run third-party code on consumers' mobile devices? Wouldn't this create a security hole on both sides — for customers, who could expose sensitive data by sending it to unknown devices, and for phone owners, who could risk their contacts, photos, and other personal information by allowing unknown code to run on their devices?"
Another question was: "How can GNU/Linux software run on Android devices in principle?" This was also fundamental, because compatibility is crucial in such a system. Its importance is impossible to overstate.
Over time, I addressed all these questions. It was an extremely ambitious project, and along the way I encountered numerous challenges and solved many technical problems.
Without going into all the details, here is what I accomplished:
I designed and developed a new containerization technology that enables full GNU/Linux systems to run on non-rooted Android devices. This posed a significant challenge, as modern Linux containerization techniques require elevated privileges — something not available on consumer Android devices, where application developers cannot control the device firmware. Without access to such privileges, I worked strictly within the sandbox to achieve a fully functional implementation.
This part of the project was implemented in C and C++.
I developed a mobile Android application, PhonePaycheck, to act as a work node for the cloud. I integrated the containerization technology into this application so that any Android phone owner could allow us to run arbitrary GNU/Linux code on their device simply by downloading PhonePaycheck from Google Play, plugging the phone into a charger, and connecting it to Wi-Fi. As compensation, we paid device owners for the rented CPU time. No rooting or complex configuration was required — the workflow was smooth and fully automated.
This part of the project was implemented in Java.
I developed a server-side management platform to coordinate work nodes, distribute tasks, deliver results to customers, and provide administration and maintenance capabilities.
This part of the project was implemented in Ruby on Rails with Redis and PostgreSQL on the backend and in JavaScript with React on the frontend.
This project not only tested my technical skills but also gave me invaluable experience and resulted in a strong professional relationship with Dr. Lloyd Watts.
The technology I developed for this project led to a US Patent application, which was granted as US Patent 11,210,194 in December 28, 2021.
This project harnesses home computers worldwide for protein-folding computations. The scale of computation required in protein folding is absolutely enormous, and there is no (and never will be) a single computer capable of performing all of it within a reasonable time frame. Because of that, the Folding@home project was established in 2000. From the beginning, it was a distributed computing initiative designed to run on the home computers of enthusiasts across the world. These volunteers provide their idle computational power to the project for free. You can read more about it on Wikipedia.
At the beginning of 2020, the project gained new momentum due to the rapidly spreading COVID-19 pandemic. Humankind needed a vaccine, but how could it be developed quickly? The only answer was: "By performing extensive computations that help guide real biological experiments in the right direction." Through computer-based simulations, scientists can obtain results much faster by ruling out many potential paths early and avoiding wasted time on fruitless research.
At Neocortix, we quickly realized we could contribute by offering our cloud network for such computations. At that point, we already had a working implementation of my containerization technology that allowed GNU/Linux software to run on Android. However, the main problem was that Folding@home had never targeted the Arm platform. It supported only Intel x86_64 systems on Windows, GNU/Linux, and macOS.
We began looking for contacts within the Folding@home project to discuss whether our contribution would be useful. We soon found the right people — both within Folding@home and at Arm. Our expectations were confirmed: Arm was not on the list of supported platforms. So we offered our help in porting Folding@home to the Arm (AArch64) architecture, and they gladly accepted.
After months of development and testing, I was able to migrate Folding@home to a recent GROMACS version and add full Arm support for its GNU/Linux builds. As a result, Folding@home officially announced the Linux-on-Arm release.
Although the Folding@home team was initially skeptical about the practical value of the Arm platform for their workloads, events quickly proved that the port was timely. Just a few weeks after the Linux-on-Arm release, Apple announced its new Arm-based M1 platform — the first truly powerful consumer-class Arm device on the market. I immediately took on the responsibility of supporting it and ported Folding@home to Apple M1. This time the work went much faster, since most of the effort had already been done earlier; only minor source changes were needed to support M1.
It was a great multi-company collaboration, where I got a lot of pleasure, working with people from different companies and worlds - Rex St. John and John Linford from Arm, Dr. Greg Bowman from Washington University in St.Louis, Joseph Coffland from Cauldron Development, and many others.
Here are a few links to read more about this collaboration:
CrystaX NDK was an open-source project that enabled C and C++ development for Android.
Launched as a fork of Google's Android NDK (Native Development Kit), CrystaX NDK quickly gained popularity. Initially, it simply enhanced Google's NDK with better C++ support—especially exception handling, since the official NDK lacked robust C++ capabilities at the time. But over time, I evolved the project to a mature state, continuously improving it and consistently staying a step ahead of Google's own NDK.
As a C++ developer, I knew exactly what other developers needed. So I kept adding features that I personally required, and it turned out that many others needed the same functionality. This is a typical trajectory for open-source projects: build what you need, and chances are you're not the only one who needs it.
As a result, CrystaX NDK grew from "an improved Android NDK with C++ and exceptions" into a full-fledged development toolkit that included a large amount of new functionality. My main goal was to make C and C++ development for Android highly compatible with industry standards, aiming to match the experience of developing in C and C++ on GNU/Linux.
To overcome many Android limitations, I came up with the idea of building my own libc replacement. This library was created and named "libcrystax." It became the core of the project because, without being restricted by the limited Android libc, I was free to add new features and make the entire toolkit conform to international C and C++ standards.
One especially important milestone in the project's life was the moment when I added support for the Boost C++ libraries. There is no need to explain to C++ developers what Boost is. For those unfamiliar, Boost is a comprehensive collection of modern C++ libraries. Many of them operate on the "bleeding edge," using non-obvious or not-yet-standardized language features, as well as clever or unexpected language capabilities that allow developers to do things not originally anticipated by the language designers.
This makes Boost a proving ground for the evolution of C++ as a language. Many new ideas are tested in Boost before being included in the C++ standard. Because of this, Boost was an ideal candidate to test the maturity of CrystaX NDK.
It was a long process, but eventually I reached the point where all Boost C++ libraries built successfully without modifying the upstream sources. This was possible because my approach from the beginning was to adjust CrystaX NDK to fully comply with industry standards, rather than altering third-party projects to make them work.
This approach also allowed us to build and support Python on Android, as well as many other open-source tools and languages from the GNU/Linux world—again, without any modifications to the upstream sources.
CrystaX NDK became popular as a drop-in replacement for Google's Android NDK and was widely adopted by open-source and commercial projects worldwide. While many users remain unknown due to the free-to-download nature of the project, Ogre3D, OpenCV, Kivy, and even NASA were among the most recognizable of them.
Over time, however, Google improved its NDK substantially, and the need for CrystaX NDK decreased. In 2016, I decided to stop working on the project full-time. I still maintain it, but only on a part-time basis. The project is now in a stable state, and I'm proud of what I achieved with it.
I don't know what the future holds for CrystaX NDK, but I'm happy to have contributed to the Android development community. And who knows... Maybe one day I'll return to it.
Here, I contributed to the development of the VIZIO VTAB1008, an Android-based tablet, as a subcontractor. This project was a pivotal experience for me, as it involved creating a customized version of AOSP (Android Open Source Project). Unlike typical Android work, we were directly engaged in the fundamental development of Android itself, rather than the usual development for Android.
Throughout the project, I gained in-depth knowledge of Android's internals—from the kernel level up to the user interface—which has greatly influenced my subsequent work.
I'm tremendously grateful to Marcus Williford, for involving me in this project.
I contributed to the development of Rhodes, an open-source product and part of the RhoMobile Suite.
Although I joined the project in its early stages, I quickly took responsibility for the Android, iOS, and BlackBerry backends, significantly advancing their development. I implemented a unified C++ engine for the Android and iOS backends, replacing separate Java and Objective-C implementations. This greatly reduced the maintenance effort for these platforms.
During this project, I realized the need for a robust C++ development toolkit for Android. Developing the same logic in different languages—Java for Android and Objective-C for iOS—was inefficient. This insight eventually led me to create my open-source project, CrystaX NDK (see above).
Additionally, I learned Ruby and the Ruby on Rails framework, which was an enriching experience. In my view, Ruby is one of the most feature-rich programming languages, though it is often overshadowed by Python. Ruby's versatility makes it excellent for a wide range of automation and production tasks, and I regret that it hasn't received the same level of attention as Python. Despite this, Ruby remains a powerful language, and I continue to use it in my projects.
I am grateful to Adam Blum, who showed through his example that open-source projects can also be commercial ones. His example reshaped my understanding of how open-source and commercial work can coexist and helped me reach the next level of professional development, where I started my own open-source project, CrystaX NDK.
This project was a comprehensive unified communications platform, integrating email, instant messaging, calendars, and VoIP into a single solution.
I began as a developer and eventually led my own department, focusing on building the server-side components. VoIP posed the biggest challenge due to its real-time requirements. A delay of more than 200 ms in a two-way conversation can disrupt the flow for listeners, so it was essential to ensure timely packet delivery or, when necessary, drop packets and smooth the audio.
I developed libraries to handle the SIP and RTP protocols and integrated them into the VoIP server for call routing and proxying. This was implemented in C++, achieving high-performance results.
This project marked a significant point in my career, teaching me both advanced technical skills and leadership in managing teams.
If you prefer listening over reading, I also made an AI-generated podcast based on this page. It turns the material into a conversation between two speakers, which makes the story feel a bit more relaxed and less linear than plain text.
The podcast is generated by NotebookLM.
