Is language just a tool?

Should we always use the right tool for the job?

Kamil Lelonek
Kamil Lelonek  - Software Engineer

--

DISCLAIMER

As some people suggested, I have to clarify that this article was written in a total peace, and not as a result of any upsetting event. I’m not annoyed, neither irritated nor frustrated. I just share my observations and maybe speak for other in some places.

The more I work in the software development area, the more I stop believing in the myths around it. There are lots of high-flown statements which programmers repeat and business people consider true. These sentences are great to brag about during interviews and conferences because they prove your maturity as a developer and your professional approach to the software.

The problem with them is, in many cases, they are just far from the truth. They hold something that doesn’t apply when it comes to day-to-day software engineering. Everything is about selling and we are selling (ourselves) all the time. That’s why programmers repeat them over and over but when they are put in their work environment, it turns out it’s very hard to take them out of their comfort zone.

They are engineers, right? They are supposed to learn, know and use any language, right? Of course, there’s a technology on the one side but there are developers and their happiness on the other. People have habits, routines and, simply, favorite tools they like using. Developers are used to some practices, style-guide, and configs. They like doing things in a particular way. They don’t mind being told what to do, but the how should be left completely up to them. No one should expect programmers to be satisfied once they are deprived of the freedom of choice.

The way to burn out

I’m shocked to see how different people close to me are becoming burnt out. They don’t feel the passion for coding anymore, they don’t have this programming spirit they had at the beginning of their careers. It turns out that the promises given by the software industry were just a delusion…

If we don’t do the same things for plenty of years, if we switch companies and projects, if we cooperate in different areas and if we work close to the business, budgets, and investors, we may start noticing something we haven’t signed up for.

Many times we are put into environments we don’t want to be in and only a few of us have the courage to oppose instead of just complaining and doing the work ineffectively.

Sometimes the business or the managers have their own goals and put developers aside. It’s not “developers oriented project management” anymore. It’s measuring KPIs, making money and achieving consecutive milestones without respecting programmers. No one will pay us to feel happy but to do our job, right?

The right tool for the job

At the very end, I’d like to mention the topic above as well. I’m far from saying that we shouldn’t use appropriate technologies for specific needs. Quite the opposite — we have to always pick the best tool for the task we want to accomplish. However, we have to consider these two things mentioned previously.

The particular tool is good as long as it doesn’t violate the developer’s comfort. The technology should not only be right for a problem or a client but for us as well. So if, for example, I don’t like C# and C# was the best tool for the job, I’d change this job rather than use the technology I’m not comfortable with, or rather than forcing anyone to use another tool which better suits me and not the project itself.

Summary

I’m not saying there are no flexible developers. It’s actually the opposite because I personally know a few experts like this. The thing is, they admit this is exceptional rather than something very common.

I was considering myself as a full-stack developer and a polyglot programmer for a long period of time. However, the longer I work the more I see I have a preferred set of tools which I’ll pick from when starting a new project. I’ll still choose between Elixir or Javascript, of course, depending on the problem to solve, but I won’t be happy with using, for example, Java in the long run.

Finally, no one is able to follow all frontend trends (even only JS ones) and be up to date with backend libraries, storage options and cloud solutions at the same time. So if you are a recruiter, don’t try to hire just a full-stack or even backend developer. Don’t let yourself be fooled by these effusive slogans. So if people are claiming that language is just a tool for them, you should see a red light, think twice, and verify how much is that true in their case.

Subscribe to get the latest content immediately
https://tinyletter.com/KamilLelonek

--

--