Why I Study Computer Engineering While Building Production Software

I did not choose Computer Engineering because I wanted to stop building software.

I had already been writing software for years, and production work made the missing layers more interesting. A slow API can be a query problem, but it can also be memory pressure, serialization, network boundaries, scheduling, or data arranged in the wrong shape. A reliable deployment can still hide a runtime that does unnecessary work.

Computer Engineering gave me a structured way to move toward those layers without discarding the backend and infrastructure experience I had already earned. The goal is not to replace practical shipping with theory. It is to understand enough of the machine, mathematics, and algorithms to make better decisions when abstractions stop being free.

Platform engineering repeatedly turned “implementation details” into product behavior.

A billing path needs exact state transitions. A report that takes minutes changes how an operator works. A webhook handler needs idempotency because a provider will retry. A deployment boundary decides whether one failure affects one operation or every route. These are application problems, but they are also questions about time, state, concurrency, and failure.

Profiling reinforced that lesson. Optimizing a path means measuring where time actually goes, separating CPU work from I/O, and checking whether a change moved the bottleneck rather than celebrating a faster local function. The same habit applies to systems work and quantitative work: define the workload, measure the result, preserve correctness, and make the experiment reproducible.

Computer architecture, data structures, algorithms, linear algebra, probability, and statistics changed how I describe work I was already doing.

Architecture connects code to caches, memory hierarchy, instructions, and data movement. Algorithms make complexity visible before a production trace does. Linear algebra turns graphics transforms and numerical workloads into structures I can reason about. Probability and statistics matter when a result depends on noisy data, uncertainty, or measurement rather than one deterministic request.

The useful part is not adding coursework names to a skills list. It is being able to ask sharper questions: what is the data layout, which cost dominates as input grows, where is precision lost, what state must survive a restart, and what evidence would prove that one design is actually better?

The best way I have found to connect the two sides is to build projects where the boundary is unavoidable.

iCloud Linux turns filesystem semantics, local durability, caching, authentication, and eventually consistent remote state into one mount point. VulkanRays makes device selection, memory, pipeline state, command recording, and synchronization explicit. Neither project is research-scale or a claim of mastery. Both force me to touch the layers I am trying to understand.

That work is more convincing than announcing an interest in low-level engineering. A small implemented system with clear limitations is stronger evidence than an elaborate roadmap. It also gives me a place to apply production habits: tests, CLI design, logs, safe state transitions, documentation, and honest failure behavior.

I am interested in performance-sensitive and quantitative systems, but interest is not shipped experience.

The credible foundation today is mathematics coursework, algorithms, profiling, C and C++, Python, data-heavy backend work, and projects that expose systems constraints. I am building from that foundation toward workloads where numerical choices, memory behavior, throughput, and latency matter together.

That framing keeps the direction ambitious without inventing a quant project or compiler that does not exist. When those projects are implemented, they should earn their place through code, benchmarks, tests, and documented tradeoffs. Until then, the portfolio should distinguish what I have shipped from what I am deliberately learning next.

I do not want to become less useful at shipping while moving closer to the machine.

Production experience taught me to care about users, operators, migrations, failure recovery, and the difference between a prototype and a system someone depends on. Computer Engineering is adding depth around performance, hardware, algorithms, and mathematical reasoning. Each side corrects a weakness in the other.

The work I am building toward sits where those concerns meet: systems that are fast for a reason, correct under pressure, measurable, and still operable by real people.