Intro
This is a reaction to Sebastian Schöner’s blog post Get Shit Done. If you didn’t read his blog post, be sure to take a second to read it, it isn’t long, it’s awesome and I’m going to touch on what he wrote.
I specifically want to expand on the bullet point “catch the ball and run with it” with something that I’d like to call “embracing the unknown”
Embrace the unknown
I’m fortunate to have had the privilege of working for game development studios that utilize their own in-house technology. Working on custom technology while simultaneously shipping a game is hard. The closer you get towards release the more stress is being put on the custom tech and the more things tend to break/need to be touched. Naturally this meant that engine programmers in those studios had to wear a lot of different hats to fix the various problems at hand. Problems that reached from finding optimization opportunities to fixing bugs to adding tools to extending the build pipeline, etc.
What I want to drive home with this awfully self-glorifying passage is that the environment I’ve been able to grow my career in naturally produced engineers who gladly took any ball thrown at them. Growing up in that environment meant that it became second nature to dive into codebases that I wasn’t familiar with or to fix bugs/add features in a specific domain that I had very little experience in. Adopting this skill-set has become an invaluable asset and something that I’ve, unfortunately, not seen many other engineers do (especially outside gamedev).
Engineers who weren’t exposed to this usually don’t have the “catch the ball and run with it” mentality and usually block attempts of “passing the ball” with excuses like “I’m not familiar with this codebase”, “not my responsibility” or “not that important”. And while all of these statements have their right to exist, I think in general we can do better.
What I would like to see are engineers who aren’t afraid to embrace the unknown and look deeper into a problem even if it’s outside their domain knowledge and/or comfort zone. This could mean many things but to give you some pragmatic examples:
If you have an error in your
std::vector<>usage-code and don’t know how it works under the hood? Just take a look!1If you want to know how C++ lambda captures work in clang? Open godbolt and find out!
Have a binary that behaves strange and you want to find out why? Try to open the binary in Ghidra and see if you can make sense of it
Depending on the size of the ball played to you, this can be a huge return of investment because you always end up learning new things along the way that’ll help with similar tasks in the future - a new tool in your toolbox, so to speak. I understand that leaving your area of expertise is scary and not having all the answers for the problem before you feels unproductive, but once you’ve broken that mental barrier, many good things will follow.
Note: Of course, there’s a fine line between spending too much time investigating and consulting a domain expert and, if necessary, delegating the task. But at the very least you can help to narrow down the issue by forwarding what you’ve already looked into - and hey, you might still have learned something new for the next time!
Naturally, you can’t fix every bug on the planet and eventually, if you’re stuck or if you’ve spent too much time without getting a result, it’s time to consult a domain expert. But even then it’s still possible to embrace the unknown by preparing a list of questions that you can use to jump-start a 2nd attempt at fixing the problem without just handing it off and missing the opportunity to expand your knowledge in that particular domain.
These questions can range from
- “Where would you suspect this bug?” to
- “What would be the best place to put this feature in the codebase?” to
- “Does my assumption of how this system works align with reality?”
Don’t be shy, if you’re not super obnoxious, there’s really nothing you can do wrong here :)
Stepping out of one’s comfort zone is essential for growth. Embrace challenges, seek knowledge beyond familiar areas, and use every opportunity to learn and expand your expertise.
As a closing statement I’d say if you, so far, stayed in your comfort zone, be sure to leave it now and again - it’s worth it!
MSVC STL just as an example, other STL implementations are open source as well ↩