Image via pixabay.com

The Overwhelming List Argument

Posted in Engineering, Thoughts

I call it the overwhelming list argument().

It’s a rhetorical device that I see used to try to present something as more grandiose and complicated than it actually is. The technique is simply list out properties about the subject – the more the merrier – in rapid succession. Our brains can’t process the data fast enough, and given our natural tendencies to match patterns and overgeneralize, we are encouraged to extrapolate and imagine a vast ocean of unlisted characteristics that prove the point. If you listen to tech podcasts, John Siracusa makes his points often with this approach.

I was reminded of this tactic from this opinion on the supposed impossibility of full-stack developers. I’ve believed in the viability of full-stack development for some time, so I went into the article skeptical but hoping to gleam some additional insight into areas I had not considered. Finding a list – albeit impressively long – was a tad disappointing.

Funnily enough, I also see the same fears played out in just the realm of front-end development; engineers who see and live the life of continually shifting JavaScript frameworks and rendering methodologies worry about keeping up with the latest. They don’t realize that making strategic decisions on when to learn what is really how everybody, including the so-called experts, stays happy and productive.

The intellectual dishonesty comes from citing the full stack of technologies needed to build and run software, as if expert knowledge is required at every level of abstraction. Not only do all of us only have a finite number of hours to spend on learning new things, but understanding the entire stack in great detail does not actually make building the software any faster or more efficient. It’s the career equivalent of premature optimization: there may be a few problems where knowing the properties of a low-level technology manifests at a higher level, but 97% of the time you’d be perfectly fine sticking with the basics for every piece of technology that is not crucial to the product.

I’m particularly irked by how the author strained to try to list everything they know about the software needed to run an app or a website. It feels like a variation of the “real programmers know x” plea, likely to boost the ego of the author who at least can slap a label on each part, even as they continue to claim that the entire thing is too much to understand for a single individual.

Don’t be intimidated by quantity.