Don’t Trust the Tech Community
By: Joseph Gefroh
Tags: Technology, Programming, Software Development, JavaScript, Coding

Systematic issues

There is a perverse incentive system within the tech community that greatly amplifies the effects and reach of terrible advice.

Open source contribution is associated with notoriety and is a marker for success

Fierce competition amongst junior (and senior) developers causes self-promotion to be a viable ways to compete

Developers self-promote and produce content to help them stand out and get a job

Other developers consume and implement this content in their companies to ensure that they are doing “the right thing” and that they don’t fall behind

These inappropriately implemented tools and techniques end up crippling long-term viability of systems, damaging organizations and increasing costs

Open source = skilled developer?

Our industry generally regards open source contributions as a bragging right.

There’s an entire incentive system out there that rewards developing something that is widely used. Creating a successful, widely used library is (correctly) a noteworthy resume-maker. Having a repository with thousands of Github stars is used as a mark of success. These are credentials that says “hire me”. Who wouldn’t want to hire the creator of Redux, a maintainer of Ruby on Rails?

Fame and fortune awaits those with many stars (source: Github)

The fame is a huge allure for many developers of all skill levels. It incentivizes them to create libraries, promote them, and get them used by as many people as possible, regardless of whether it will actually benefit them or not in the long run. Developers hop on to this bandwagon by creating content for the new technologies, writing articles and promoting it.

The problem is that there’s a larger reward in creating new things over creating valuable things.

The lowest hanging fruit to build are libraries that do the same thing as other popular libraries, but only better. Look at how many ways there are to upload an image on Rails — Paperclip, Shrine, Refile, Carrierwave. How about the number of ways you can do state management— Redux, Mobx, Recoil, context, etc. The options are numerous, and ever-increasing.

When everyone will praise you for creating something new, people are incentivized to reinvent the wheel and talk about how awesome their new wheel is, which drives usage.

Within this ecosystem exist junior developers

Junior developers have to operate in this ecosystem we have to succeed, so that’s what they do.

It’s easy to forget, but the competition at the junior level is fierce. The junior developers most likely to be hired are the ones that stand out. They’re told by everyone from their community to mentors to teachers that the best way to stand out from the hordes of other junior developers is to show passion and knowledge.

They show knowledge by working on side projects, studying data structures and algorithms, and demonstrating they can use these new hot, in-demand technologies. They demonstrate their passion by writing blog articles, giving talks, and engaging with the community as a whole. It’s what helps give them an edge in their job hunt.

In their studying, they consume a plethora of content that talks about things on a surface level with an air of authority. Much of this content is essentially marketing spiel that heaps high praise on a specific technique or technology and recommends it without limit.

Just look at articles on Redux, GraphQL, or MongoDB. These tools are absolutely useful and appropriate in the right contexts, but it’s rare to see a nuanced recommendation or one that adequately explains the context behind the decisions.

When everyone will praise you for creating something new, people are incentivized to reinvent the wheel and talk about how awesome their new wheel is, which drives usage.

Lowering the bar

A lot of the new content is designed to lower the barrier to entry so that it is easy to adopt. Code samples show you the exact code you need to copy-paste to get up and running. FAQs show basic errors you run in to. They often invest significantly in the ease of setup.

Unfortunately, much of the guidance after that stops there. Rarely do I see examples that show you what not to do, or how doing something as shown will create an integration challenge in the future.

That’s to be expected — integration is not the library’s job.

However, this lowered bar and lack of context does cause people who don’t know better to follow these patterns blindly. Eventually, through experience they realize that they need to make changes, but by then it is often too late — the damage has been done.

It’s easy to understand how this happens: most articles rave about how you should use whatever they are talking about starting today because it is just so easy to use and set up, and light years above the current status quo. It deceptively leads people who don’t know better down the wrong path. They then repeat this misinformation in their own presentations, articles, and conversations until it becomes solidified as truth in the community.

People then chase shiny things despite marginally better value. Systems end up having to get rewritten, or start incorporating a dozen different ways to do the same thing, costing companies significant time and money.