Software Engineer · SDE-2Working on the boundary between network automation and network orchestration.
Building and maintaining production software where compatibility, reliability, integration, and delivery all have to work together.
I work at GYTWorkz on a network automation platform that connects automation workflows with a network orchestrator.
My work spans backend engineering, system integration, platform compatibility, production troubleshooting, observability, security, CI/CD, and release engineering.
Over time, the most interesting work has rarely been about adding another feature. It has been about finding what breaks when systems evolve, assumptions change, or distributed behavior does not line up.
Building and evolving the integration layer
Built and maintained production software connecting a network automation platform with a network orchestrator.
Keeping integrations working as the underlying platform changed
Worked through changes in the underlying network orchestrator across multiple platform versions while preserving existing behavior.
I had to understand both the old and new behavior and make the transition without unnecessarily breaking existing consumers.
Investigating problems that only appeared in production
Investigated production issues that could not be explained from a single component in isolation.
Making complex runtime behavior easier to understand and trust
Investigated inconsistent runtime behavior involving state, timing, and lifecycle across distributed execution contexts.
Worked on consistent request traceability across different communication paths so a single operation could be followed through the system.
Keeping production software healthy
Worked on dependency security, vulnerability remediation, CI/CD, packaging, build infrastructure, and release engineering.
A few examples of the engineering problems behind the work. The system is intentionally abstracted; the problems are real.
The same resource could behave differently depending on where a request was handled, creating intermittent availability failures in a distributed environment.
Reduced the chance of stale runtime state producing inconsistent behavior.
New versions of the underlying network orchestrator introduced behavioral differences at the integration boundary.
New platform support could be introduced without forcing unnecessary changes on existing consumers.
A single operation could move through different protocol paths, making it harder to correlate what happened from start to finish.
Made distributed operations easier to follow and investigate.
A dependency upgrade introduced unexpected behavior in an existing integration path.
Restored expected behavior while keeping the dependency current.
The release pipeline needed to produce artifacts for different CPU architectures while running in an environment based on another architecture.
Enabled the pipeline to generate the required architecture-specific artifacts consistently.
Security findings required dependency upgrades in production software that also had existing compatibility constraints.
Addressed security findings while maintaining expected application behavior.
My work also extended beyond application code into the systems that build, package, validate, and deliver it.
Conceptual representation · simplified
I don’t need to know the answer before I start.
I prefer to trace a problem back to its fundamentals.
Then turn what I learned into a practical solution.
The hardest problems are rarely isolated to one piece of code.
They usually appear where assumptions meet — between versions, between systems, or between what the software expects and what the environment actually does.
I enjoy that part of engineering: starting with something that doesn’t make sense and working backward until it does.
Still learning. Still building. Still looking for problems that are worth taking apart.