If I have learnt one thing in the software world it is that it isn’t just one world - far from it. I started off programming on my own, in my bedroom, I suspect not unlike many of the readers of this post. From small beginnings I landed my first job at a small webdev shop. Followed by working my way up the food chain at a tech consultancy where I dealt with the most enterprise technologies out there. This is not an endearment. Which brings me to today, where I work as an engineer at an early-stage startup dealing with real-time media.
I often find myself trembling at the thought “what if I was still at that that little webdev shop?”. I have nothing but praise to say about the team, the work and the business, so why does the thought fill me with angst? The reason is simple: every time I’ve changed role it has shattered the invisible glass panes that were surrounding me and shaping my perspective about software, engineering and the world more broadly.
Maybe that sounds a little dramatic, but consider this, how do you measure your own ability as an engineer? I would bet that you rate yourself relative to your peers. Sure, there are legends on the internet but they are distant, fuzzy and hard to benchmark. But Gary on the other hand, shows up to work with me, I read his code, he reviews mine, we discuss engineering problems and work through solutions on the daily, I have a pretty good idea of where I sit relative to Gary. This principle extends to those in my immediate vicinity, but drops off quickly beyond that. In your day to day, if you are surrounded by Garys you may think that the entire world is mostly just like them.
I have been fortunate enough to find myself in new domains and deal with problems and constraints that have shattered patterns of thought that I considered invariants previously. To be concrete, as a frontend engineer today you may be consumed with picking the right framework or the modularity of the code you write, but as a video engineer you are more concerned with ensuring the frame buffers make it to the end of your pipeline a quickly as the hardware allows - abstraction be damned. I may be exaggerating here, but the point I want to make is this: despite both roles often falling under the umbrella of “software engineering”, the problem set and solution space is wildly different, so your thinking must be wildly different too.
In a similar vein, at each step in my career, I have been lucky enough to work with someone who has redefined what it meant to be a “good” engineer. A person who casually solve problems you thought were reserved for the professors. An engineer who thinks so deeply and analytically that it hurts to even try. Or that person who knows everything there is to know about ... everything. If you are lucky enough to have met people like this, then well done and keep going, I salute you! If not, then perhaps you are the person I am writing this for.
If you have been writing TypeScript since college and building REST API’s around databases in various shapes and configurations, and all your peers are doing the same, the engineering landscape may look one way to you. But just beyond the horizon lies something completely new, foreign and exciting. A different world entirely. The worlds of frontend, of backend, of apps, of real-time media, of machine learning, of firmware, of hardware, and of countless others are there for you to explore; should you be so lucky. So what does it mean to be an “Engineering Astronaut”? If the opportunity to travel between worlds presents itself, buckle up and brace yourself! You may just look back one day and wonder with glee and angst “what if I was still at that little webdev shop?”.