You Are More Than Your Tech Choices
May 22, 2021
As a software developer with a few years of experience, recruiters often message me trying to convince me to apply for a job opening. In one specific instance, I was actively job seeking and came across a very interesting recruiter message encouraging me to apply for a Python developer position.
In my experience both online and offline when you get a group of software developers together, people have opinions. Strong opinions that sometimes transform into a way that people self identify as a developer.
Here’s some examples of said opinions:
- Monolith vs Microservices
- Containers vs Serverless
- Language X vs Language Y
- SQL vs NoSQL
- Don’t use language X because it’s old and bad
…ok I over emphasized a bit on the last one, but you get my point.
My initial hesitation of applying for that Python job got me thinking “how much of my identity as a developer is tied to the technological choices and tools that I use?”
…turns out it was quite a lot.
There’s so many choices for tooling out there that it’s easy to forget the “who”, “what”, and “why” by jumping immediately to the “how” when starting on a coding project.
Non-software engineer customers don’t care if you used the latest and greatest framework or programming language to build that app, they care about the app working when they need it.
So this got me thinking more about what really matters to me as a developer.
What Really Matters (to me)
We’re more than the tools that we choose to use as software developers. Technology is always changing, so those latest and greatest tools you’re using today might not be the greatest in a few years. Instead of focusing on the tools, we should be focusing on why we’re here.
One thing that will always be around are 1) coworkers and 2) customers, so I’ve shifted my professional focus to center around these two things.
When selecting tools to build something, I’ve changed my thinking towards trying to use the right tool for the right job. To me “the right tool for the right job” boils down to alignment with:
- team values
- team goals
- the current team’s strengths/weaknesses
- being able to properly balance building out new features quickly and being able to maintain code that is already there