Destructive arguments used in technology discussions on social media that have to die
Tags: community, technology, socialmedia
Published: 2022-03-15 11:32:41

---
title: Destructive arguments used in technology discussions on social media that have to die
published: true
description: These are some antipatterns in communication about technology on social media we shouldn't use any longer.
tags: community, technology, socialmedia
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rve1sp69aqe615u2ufjt.png
canonical_url: https://christianheilmann.com/2022/03/14/noise-cancellation-for-development/
---
 
Social media is a wonderful thing as it does give everyone a voice. This can be a problem when that voice is used to bring other people down or make them feel small. As developers, we never shy away from giving out opinions. But maybe we should consider the effect these have on people.  When it comes to creating noise and stressing developers out, there are a few patterns people follow on social media that have to go away.

## *Gatekeeping*: You aren't a professional  if you don't use ${thing}

This is utter tosh. Over my career I've heard this dozens of times. In almost all cases the thing that would have made me a professional vanished in a few months. And got replaced by the next new shiny. I know highly professional developers working with woefully outdated tools and technology. Partly because their product demands it. But also because they are effective using it and don't see any need to learn a different one.

## *Assumed baseline*: You forgot to do the most basic things, you are horrible to ${people}!  

This is one I struggle with a lot. Valid HTML, the most basic accessibility features and a readable syntax are second nature to me. Using all these makes sure you don't block people out, and you make it easier for people to maintain and run with your work. But calling people out publicly for basic mistakes isn't helpful at all. This is a pattern you see a lot in social media. Almost every positive post will have someone find a flaw in it that could offend a certain group. Pointing this out may be important, but it is also a major bummer. 


## *Fear mongering*: These are the only skills employers are looking for!   

What engineering managers want from a new hire and what ends up in job ads differs a lot. This is a problem we need to deal with in our market. In almost any job I started in I had half the skills listed in the job description. It is never one killer technical skill that will make you stand out. It is how good you are in taking on new challenges and integrate into existing structures and needs. Companies don't need rockstars, they need people who can integrate into a well-working system. That we list a plethora of skills that are hot right now in job ads is annoying.

## *Wisdom of the ancients*: This never worked before and will fail now!

I talked about this in more detail in my "[Shut up old man](https://christianheilmann.com/2021/06/16/shut-up-old-man/)" post and is a real problem. The longer you work in development, the more tainted you get. This slows down innovation and frustrates fresh, excited people around you. One big step towards becoming a tech lead is to use your experience to help people grow. Not to let your horrible memories taint possible great new things to come. Enthusiasm is never a bad thing when it is being channelled into useful actions. Often things that were impossible for me to achieve are no issue for new developers in an evolved environment. 

## *My pet setup*: Why don't you use alpenhorn.js like real professionals?

I keep encountering this as comments from people asking to contribute to a project. It is reverse gatekeeping, telling me to earn their contribution by subscribing to their idea of a perfect setup. Even when the project in question is a decade old and has thousands of contributors. It is pure hubris to demand the product to change. A better way is to point out what benefits it would bring to reconsider a new architecture. That way you'll learn soon why it isn't that easy. For most projects, there is never any time for re-architecture, no matter how messed up they are. It is tricky and scary to replace an aircraft engine mid-flight.

## *Copying the big players*: This is used to build ${bigproduct}, so it will be even better for ours

This fallacy is rampant. It is annoying how many projects are huge because they started with a "big player" bootstrap. Frameworks and libraries are great to get a project off the ground fast. They are also vital for companies with huge projects and hundreds of developers. So, if you want to create something quick and you know you will re-write it soon anyways, fine. If you think that using the products the big players use makes your product scale and grow as fast, good luck. Fact is, you hardly will ever build anything from scratch when a company hires you. Companies have budgeted training on the job to get people proficient in the tools they use. The idea of publishing these platforms to the world is to cut down the amount of training for new hires. Not to enable lots of competitors to work as efficiently.  

# What do to instead of posting things like these

I'm forcing myself to be calmer, to care less about things being "obviously wrong" and to listen more intently. And to block out unnecessary noise. If you do the same, you'll find being a developer in today's world is pretty darn amazing and that what you know is already a lot - and maybe enough.

This is part of a bigger post about [noise and stress for developers and how to avoid it](https://christianheilmann.com/2022/03/14/noise-cancellation-for-development/).