i’m ayush,
a software engineering student from india. most of what i do these days sits somewhere around software, open source, and figuring out how things actually work underneath.
i don’t have a very complicated definition of myself as an engineer. i’m still learning.
how i got here
i started programming like most students do — writing code because it was interesting, building small things, trying different technologies, and occasionally making something that worked without really understanding why.
over time, that stopped being enough.
i became more interested in what happens below the application layer. what does the operating system actually do? what happens when a process starts? how does a program talk to another machine? where do files, sockets, processes, queues, and workers actually fit together?
that gradually pulled me toward linux, operating systems, networking, backend systems, and infrastructure.
i’m still fairly early in that journey.
that’s important to me because i don’t want this site to pretend otherwise.
open source
a big part of my learning has happened through open source.
i contribute to Debusine in Debian, where i’ve had 20+ merge requests accepted. working in a real codebase has taught me things that tutorials don’t really cover — reading unfamiliar code, understanding existing abstractions, writing changes that fit the project, responding to review, dealing with tests and CI, and sometimes spending far longer debugging something than actually writing the fix.
i’ve also contributed to Jenkins, particularly around its documentation tooling and site infrastructure.
i like this kind of work.
there’s no clean slate. someone already made the decisions you’re looking at. some are good, some are old, some are necessary, and some only make sense after you’ve spent enough time with the system.
understanding that is part of engineering too.
zenYukti
i also started ZenYukti during my first year of college.
it started as a small technical community. over time it became something broader — a place for projects, open source, events, collaboration, and people trying to build things together.
running it taught me a very different side of software.
there’s a difference between building something for yourself and building something that other people depend on. even when the software itself is small, there are people, communication, maintenance, decisions, and things that quietly need to keep working.
i still enjoy building things through ZenYukti, but i don’t think of it as just a community anymore.
what i’m doing now
right now i’m deliberately slowing down and going deeper.
i’m spending the next few months working through systems engineering properly:
- linux and linux internals
- operating systems
- networking
- backend systems
- infrastructure
- debugging
- production engineering
i’m also learning Go properly rather than just picking it up when a project needs it.
that means spending time with the standard library, concurrency, networking, processes, files, tooling, and the parts of the language that become useful when you’re actually building systems.
i’m also building things alongside the learning.
one of the first things on my list is a small linux process explorer built around /proc. nothing revolutionary. i mostly want to understand processes properly by working with the interfaces the operating system actually exposes.
there are bigger ideas after that, but i’m trying not to skip the fundamentals just because a bigger project sounds more impressive.
what i like building
i generally prefer small, boring software.
tools that do one thing well.
programs that can be inspected.
systems where you can follow the data from one end to another.
code that doesn’t need a paragraph of marketing copy to explain why it is useful.
that’s probably also why i’m increasingly interested in infrastructure and backend systems. there is something satisfying about software that mostly stays out of the way when it is doing its job.
i don’t particularly care about using the newest technology just because it is new.
if a shell script is enough, use the shell script.
if a small service is enough, don’t build a platform.
if the standard library solves the problem, don’t add another dependency.
i’m still learning where that line actually is.
this site
this site is partly a portfolio, but i don’t want it to become a collection of claims about myself.
i’d rather keep it as a record of what i’m actually doing.
the work page has things i’ve contributed to and built.
the now page is about what i’m working on at the moment.
and the blog is where i’ll write down things i’ve learned, broken, understood, or found interesting.
some of it will probably be wrong at first.
that’s fine.
i’d rather have a record of the process than wait until everything looks polished enough to publish.
so, that’s me for now.
a software engineering student, an open source contributor, someone running a community, and someone slowly moving deeper into systems.
still learning. still building.