About Software Scientist’s Pursuits (humanized)

Software engineering is applied physics. Memory moves, threads coordinate, packets wait. Caches lie. Latency compounds, and systems fail without telling you.

Machines reason now too.

I spent 100 days digging into the JVM: memory models, garbage collectors, lock inflation, deoptimization, virtual threads, sandboxing, profiling, security boundaries. The takeaway wasn’t really “Java.” It was how many forces you’re actually juggling—coordination, latency, throughput, memory pressure, failure propagation, uncertainty. This publication is where I work through that.

What’s here

Systems thinking: designing from first principles, tradeoffs that don’t fit in diagrams, concurrency and scaling and coordination. Performance as a discipline: profile before you guess, memory before CPU, tail latency before averages. AI systems engineering: systems that use probabilistic models, plus guardrails, context flow, observability, and treating AI as distributed systems with uncertainty. Security and boundaries: sandboxing, deserialization, context propagation, supply-chain trust.

What it’s not

Not a tutorial dump, not a framework-of-the-week feed, not listicles. Closer to a lab notebook for people who like to think in systems.

Why “Software Scientist”?

The engineers I learn from don’t only build. They probe, measure, experiment, question assumptions. Science isn’t about certainty; it’s about curiosity with discipline. I want that same rigor for software.

Who it’s for

People who care how things work, not only that they work. Who want to design systems, not just wire APIs. Who are moving from deterministic systems to AI-in-the-loop. Who think simplicity scales better than cleverness.

The mission

I’m treating modern software engineering as something you can study: experiments, production stories, architecture breakdowns, uncomfortable truths. From bytecode to distributed AI systems. That’s what I’m chasing.