The internet has a lot advice on how to be a “10x engineer” meaning, how to be the most efficient (ten times more efficient!) and effective (ten times more effective!) developer (in the world!). In reality, it seems to me, that the bar for being an effective engineer is actually set quite low. I don’t need (or want) a “super” engineer on my team, instead I often wish that people would invest just a bit more than “the bare minimum”.
Yes, I’m aware of my own biases, meaning that I can be quite pedantic and tend to notice lots of tiny details more often than others. Additionally, my brain works in ways, so that I can generally remember a lot more dependencies (code, stakeholders, discussions, etc.), which others might not consider.
Some examples of what I mean with more than the bare minimum:
Feature Testing
The bare minimum for checking that the implementation of a feature works, would be to test just one happy-path and nothing else.
Doing just a bit more could mean, that you also think of some potential failure cases, or test inputs with random characters, or test additional components that interact with the feature-enhanced component, etc.
Bug Fixing
“A bug is fixed, if the described error doesn‘t occur anymore and maybe a new test has been added, right?”
Getting the described bug fixed is great, but it’s only of limited use, if the reported case, was just one of many similar cases, thus it might just fail on the next run, in a different location. Doing more, involves looking for similar input data (e.g. were those reported data duplicates or the only ones in existence?), checking the error log and error history thereof, so that additional issues can (potentially) be spotted and/or to ensure that the testing of the fix is done in full and not just for the one documented case.
Documentation
“The code itself is documentation, it‘s all we need!”
The code is indeed the ultimate documentation, yet I firmly believe in providing high-level and introductory documentation. You don’t want to jump into the code, to answer every single (business) question or to discuss high-level architecture topics. Having the basics in condensed form somewhere outside of your code, will also make it a lot easier to bring new people up to speed on the project. But documentation is only useful if it’s updated frequently, as such doing more than just the bare minimum means, you could update the existing documentation (or get this, add new information!) if you add or change something.
Writing Tickets
I‘ve already written about writing good bug reports. It just requires a bit more effort in adding additional details.
Summary
Those were just a few examples, and there could be many more areas.
In my experience having engineers that care about their work just a bit more than the bare minimum is more useful than a 10x engineer, at least in a day-to-day business.
Just don’t be a -10x engineer. 😉