to be quite frank, i’m very proud of my technical progression as a software engineer. when i was admitted into ece at the university of waterloo, i knew how to code in the sense that i could make things work, but i had very little of the judgment or depth that i now associate with actually being an engineer. i wasn’t thinking seriously about architecture, performance, failure modes, maintainability, or what was happening beneath the abstractions i was using. i was mostly just excited that the code ran lmfao (why did i think commenting was the shit back then).
but putting aside the technical larp, one of the parts of my progression that i’m most proud of is how much better i’ve become at deciding how the work itself should be approached.
for almost any non-trivial task, there are $n$ directions you could take, and most of them are not obviously wrong. they may all produce something functional. they may all be defensible in isolation. but only a few will be proportionate to the problem, compatible with the system around them, and worth the time they cost.
i have always cared about moving quickly and choosing the right approach. what changed was not the goal. it was my ability to converge.
i’m much better now at identifying which constraints actually matter, separating the underlying problem from the way it was initially presented, and ruling out paths that are technically valid but poorly matched to the actual problem. i can better recognize when a task needs deeper design, when it needs a small experiment, when it should be measured before it is optimized, and when it simply needs to ship.
that judgment is difficult to quantify, but it may be the most valuable thing i’ve gained. knowing more gives you more possible solutions. judgment tells you which ones deserve to exist.
to me, that has meant learning to find the right direction faster, committing to it without needing perfect information, and continuing to move without turning every decision into a research project.
speed and direction do not naturally scale together (at least not without practice). shipping fast is not about how quickly you can write the code. it is about how little time you waste writing the wrong code.
~ a.k