The Tech-Bias

I believe that learning in the world of software engineer is hindered by a fundamental bias: The Tech-bias.

Check yourself: Think back to the last conference you attended, the last podcast you listened to, the last blog-post, book or article you read, your last in-company tech-meetup: What was it about, generally? Technology, fundametals or soft-skills?

The absolute majority of content I see and that I see consumed exclusively deals with technology. The latest-greatest. How many kubernetes workshops/talks/tutorials did you have to sit through, and how often did you actually concretely deal with kuberenetes first-hand? How many frontend-technologies have you been taught, while being a backend-engineer, or vice-versa? Did you get tutorials on web-security that you never used? Been introduced to Rust while writing Java? Welcome to my world. Or, as I would put it, the current world of software-development.

We WANT to learn about these things because they are cool and sexy. Our bosses WANT US to learn about them because it is „industry standard“ and they don’t want to fall behind. But… they are not.

As a Java Backend-Engineer my „industry standard“ deals a lot with Spring Boot, JVM, Garbage Collector, Multithreading, Debugging and such (fundamentals). A lot of the problems I observe in our field are the quality of User Stories, overreaching bosses, lack of trust & communication (soft-skills). When I look through the top-entries on blogs, podcasts, developer-websites and conferences this barely ever comes up. Soft-skills do, sometimes. But fundamentals: Pretty much never. They are just assumed.

This might seem ok, since when you look at it from a hiring or business perspective, maintaining fundamentals is the responsibility of every participant himself. But just as sports teams do coach their athletes in the gym (even though stamina and power could be assumed to be the responsibility of the athlete himself), the business should take great care and spend ressources on these.

It is not hard and comes down to benign things, that just need to be repeated: Reading stacktraces, handling git, basic multi-threading, setting up your tools, being familiar with your IDE. One of my mantras is Never be to lazy to be lazy. Meaning: Take the time to set up that script, learn that hotkey, read about that basic thing. And then save 2 seconds on every commit for the next 20 years (Relevant xkcd).

I firmly believe that being interested is the best motivator when it comes to learning new things. It is virtually impossible to go against it. But don’t let yourself get fooled: „I might pick up something interesting“ might be as true for the next lecture on GraphQL as it might be for the „Lord of the Flies“ audiobook.

So please, when you next consider something to learn: Spend your time wisely. Expand your horizon, yes, but don’t let yourself get fooled into learning about things that are useless to you over and over again. Maybe actually challenge yourself to learn some fundamentals or soft-skills, just for some of your time, before picking up that tutorial on purely functional raytracers.