Developers, Our Toolbelts Form Us!
Published: 2021-09-27 10:56:38

---
title: Developers, Our Toolbelts Form Us!
published: true
description: And why phrase "for software engineer the toolset doesn’t matter" is just a manipulation.
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0rd07ttgozylbgw1uc2u.jpg
canonical_url: https://medium.com/infobipdev/developers-our-toolbelts-form-us-94423f0171d8
---
Some time ago a headhunter from one of the biggest social networks in Russia contacted me and suggested an interview. I knew about their technical stack, however, and I declined the call since it’s not what I desired to deal with. 

To my surprise the headhunter said “yeah, but I believe that for a professional software engineer the toolset itself doesn’t matter”.

Wow, that pissed me off, to put it lightly.

Well, maybe I took it too personally and it harmed my fragile nerdy ego, but it wasn’t just that. 

From the beginning of my career in 2015 I always hear cool stories about T-Shaping, 10x-engineers and especially the requirement to be language-agnostic. At first glance there is nothing bad in any of it, especially being language-agnostic. 

You think that all you need is to learn high-level approaches and specific tools don’t matter. All lollipops and rainbows.

### Choosing The Tool That Makes You More Productive

The big gap here is that when you’re talking about being language-agnostic, no one mentions the productivity of a developer.  If I was a chef in a restaurant, it’s obvious that I would be more productive in serving good meals if I worked only with my own knives, my own tools.

Why are software engineers in that case not the fortunate ones? 

Programming is also a craft, so let the craftsman choose the instruments they need to accomplish tasks.

As a specialist, I’m really interested in solving specific and hard problems. I like challenges. Also I may prefer to work in specific business areas, like eCommerce, video-streaming, social networks, etc. 

You guessed it: For each specific problem there is a set of good tools.

Developers work in teams. We’re not marathon runners - we are football players. And we get paid for things we deliver in specific infrastructure so there are a lot of reasons why we should use things we don’t like or we didn’t choose. Our employer or client chose them.

However, You are not a bad engineer if you don’t want to appreciate a corporation's choice and while searching for a job you filter companies by their technological stack also.

In fact, I think you might even be a better engineer and quite a visionary person, because you invest in your own future and carefully overcoming traps like maintaining someone else's legacy, which doesn’t develop you as a specialist. 

### Technology Agnostic Doesn’t Mean Forced Into Technology
So let’s change the definition. For me, being technology-agnostic means being able to switch to a new more effective thing, but not accepting everything that is dictated to you.

You are a specialist, you’ve got this mental model of what are pros and cons for each applied tool. As a specialist, share these insights with your current or potential employers without silent hating or hesitation.

Businesses are interested in cheaper and faster hiring of new employees, thus preferring the most popular and the most mature technology. That’s fair, but you as a software engineer should also introduce an “effectiveness” variable into their equation.

It is not only tools that I’m used to, maybe because I’m young and still “foolish and hungry”. 

It's easy to get stuck with a painful tool, because you've gotten used to this pain. 

I prefer tools that have an acceptable tradeoff between speed (including mine) and safety. In the last few years I’ve become a fan of limiting the ways to solve specific problems. For example:
* Go provides simplistic features for concurrency and error-propagation.
* Rust has a borrow-checker that protects you from race-conditions and so on. 
* And for me if a company has a monolithic technical stack, for example Java or .Net, there will always be cases where they don’t perform well and it’s a good point for experimenting.

More and more, I hear stories when a company hires high-graded developers and gives them the freedom to solve problems with tools that they think are more appropriate. 

This is quite a sweet approach when companies have that kind of confidence in developer’s professionalism, that they don't care how the problem will be solved. I won’t lie, as a software engineer, I dream to be so good at my job that I can do just that.

It’s quite valuable when a new software engineer brings improvements into a company's technical stack. This new blood can properly justify their decisions, when they consciously choose the technology - the tools that form them - during their career.