Five Years

Software engineering is a vast, multi-faceted discipline that spans multiple industries and pervades the lives of many people, in an incalculable fashion.

It’s been five years since I graduated, and I’ve been fortunate to work in a wide array of environments on various technologies that aim to solve different problems.

The constant variance in this field, the catalysts of which are things like new technologies and new problems to solve, has rendered me with an ever-changing mindset in the general case, but I’ve recognized a few consistencies that I’d like to share — things that I’ve discovered throughout the maturation process as a professional developer, things that weren’t obvious when I first stepped into this profession, eager and fresh-faced.

These observations are by no means exhaustive — I’m sure there is much yet to discover — and there’s always the chance that they’ll change or evolve over time, but right now they seem, to me at least, relevant to the industry (or my experience thereof), in their own befitting, ubiquitous way.

All the Hats

I graduated with a BSc. in Computer Games Software Engineering. It was much like other engineering degrees, only with a slant towards math and the de facto industry language, C++. From what I can gather, a lot of CompSci course will elect something like Python or Java as an introductory language.

Upon graduation, I could define myself; “I am a C++ programmer”. Only I wasn’t.

During my studies, I discovered that I actually didn’t want to work as a games programmer at all. The lifestyle didn’t seem appealing to me — the long hours, which didn’t offer any real recompense in terms of salary, the inevitable crunch to get projects over the line, the volatility in the market (around the time I was studying, a good number of reputable studios were closing).

Yet, I remained resolute; “I’m here to write C++ code”.

My resume was littered with it. C++ was the safe zone. It was the language that I first wrote, and thus it was the language upon which I’d compare any other language.

It didn’t take me long to realize that this wasn’t enough. I recognized that a good trait in a software engineer is versatility. Leaving university, I was tunnel-visioned with what I thought was my markup as an engineer, but it’s less about the language your write as it is the attitude or mindset that you roll with.

To use an analogy, think of it as a tradesperson. Perhaps one that is particularly proficient with a hammer, for simplicities sake. That’s awesome for those select jobs that need that tool, but what about when you need to drill a couple of holes into some drywall? Sure, you could do it with a hammer, but a few clumsy holes in the wall will eventually result in the concession that this wasn’t the best tool for the job at hand — you should have learned to use the drill.

This seems so obvious, at least to me at the time of writing. But my recently graduated self didn’t recognize this immediately. And even now, I see “I want to be a <insert_language_here> programmer” or “What’s the best language to learn to be a programmer” posts on Reddit or various forums. As I said, the ever-evolving field of software engineering aims to solve many problems, and thus has many tools.

Don’t be afraid to learn them. Don’t be afraid to step outside of that comfort zone. Sure, the syntax is somewhat alien, and the paradigms or idioms possibly don’t quite match what you’re used to seeing, but there’s a wealth of resource at your fingertips online, and it’s nothing you can’t fathom, especially since you’ve grown from that first semester engineer who was able to wrap their head around exception handling in Java.

A Tale of Two Engineers

I think this is more an observation on general mindset, but here we go anyway. I can broadly distill engineers into two types. This is a vast generalization, but something that seems to have served me quite well. Of course, we vary, as people and as professionals, in myriad ways, but this rings true for me:

There are engineers who can openly admit when they don’t understand something, and then there are those that cannot.

I’ve found this particularly when I’ve interviewed engineers.

Here’s the thing; this profession is largely based around smarts, intellect. There’s an expectation that you have a reasonable level of intelligence, that you’re able to solve problems. And that’s not wrong. But that doesn’t mean that not knowing or being able to comprehend something is a weakness. Actually, I’d argue it’s the opposite.

As mentioned, I’ve seen this in interviewing countless times. I’ll ask a question, sometimes intentionally ambiguous, and await a response. Often, I’m less interested in the solution itself than the thought process for resolving the ambiguity. Even the most trivial of problems can be riddled with ambiguity, like a knotted shoelace requiring attention. Tackle it now, and avoid tripping later.

This ambiguity manifests in various ways. As I said, it could be that its intentional, as part of an assessment. It could be that it’s terminology-based — man does this industry love fluffed up, smart sounding terms that can be boiled down to much more simple concepts. When I see this situation where someone doesn’t quite understand, I see there’s the type of engineer that asks outright “I don’t understand, what’s a virtual function?”. And then I see the engineer that doesn’t, that flails for a little while, and that quickly unravels at even the most cursory of questioning on the subject.

I can’t think of an instance where I’ve voted to hire the latter. To me, that’s the individual that, during your morning stand-ups, will tell you everything is alright, before revealing at the end of the sprint that they’re not as far as they thought they’d be. The former usually does highlight early when there’s a problem, seeks additional input or assistance, and ultimately has a more productive sprint.

And I get it. It comes down to that intellect factor again, the notion that we’re being judged intellectually in this line of work.

Don’t be afraid to ask stupid questions. There rarely are any. I’ve definitely been present at meetings where terms are being banded back and forth, and a good chunk of participants aren’t quite sure what’s going on until someone pipes up and asks the simplest of questions. It’s the imposter effect. None of us want to look like the stupidest person in the room. I’ve learned to be okay with this, it doesn’t bother me. We don’t know who possesses what knowledge, nor should we assume. Just as we shouldn’t assume our own is lacking in some way.

Who am I?

Over the past couple of years, I’ve developed a belief that you can call me a lot of things — a programmer, architect, engineer, designer. In fact, you could and may want to call me a lot worse. Actually, all I am is a communicator.

To me, the biggest facet of this job is communication. I mean, there are a lot of facets, but they all boil down to communication in some way:

• I’m communicating to a computer, through code, that I want it to do something for me
• I’m communicating how systems solve problems through designs
• I’m communicating requirements of non-technical colleagues into technical details for technical employees
• I’m communicating to my future self, and other engineers on the project, via the style of code I write

That last one is worth a bigger look.

There are a bunch of ways to write code. And that’s one of the great things about programming, that it’s actually a creative and expressive field. You can write a lot of smart code that does a lot of smart things, but one of the primary concerns you should have is that it’s well communicated. It should be readable.

You’re not going to be on this project forever. You’re not going to be the only person working on this project. You’d be doing your current self and your successors a great service by writing code that communicates your intentions well.

And it’s simple. It’s as simple as factoring things out into readable chunks, avoiding cute obfuscations, trying to adhere to language-specific idioms. None of these things are huge considerations. They’re minor, and should you adopt them into your general practice, will serve yourself (if people can read your code, they’ll ask you less questions) and future generations much better.

We’re aware of the boy scout rule. And it’s a pretty nice rule. But this small section of code your working is part of the larger camp. Please, leave behind some S’mores.

Closing Comments

That’s it for now. These are some of the things I’ve recognized as pretty consistent during my tenure as an engineer so far.

I offer this not as a dogmatic and declarative set of assertions about the world of software engineering, but as an insight into my own experience, and as food for thought that might provoke your own observations or discussions on the matter.