
Ask HN: Why can't coders code? - exBarrelSpoiler
Jeff Atwood has been sounding the alarm about interview candidates who can&#x27;t Fizzbuzz since nearly a decade ago (https:&#x2F;&#x2F;blog.codinghorror.com&#x2F;why-cant-programmers-program&#x2F;)<p>In today&#x27;s discussion about the usefulness of HackerRank, and coding challenges in general, as a way to evaluate prospective hires, I suggest that the state of affairs with mediocre, or at least less-than-rockstellar, engineers is caused by the possibility that for &quot;most&quot; coding jobs, you don&#x27;t actually need to know CS fundamentals every single day. We&#x27;re at a point where for many types of development, those who use APIs, libraries, and code from Google are able to muddle through, ship products, and linger in companies for years - https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=12826364<p>Is there any merit to this theory? Because if not, then <i>why</i> are there non-ninja, 1X or less engineers out there with years of experience? Some of whom who are apparently quite ignorant about the very languages&#x2F;platforms&#x2F;etc. that they code on day to day? Surely not all of them inflate their experience on their resumes. Evidently companies did employ them at some point, and have them code. So how can they code without knowing how to code?<p>And if this theory is accurate, and many coding positions now no longer require 10x types, or even people who are all that knowledgeable at all, doesn&#x27;t that reveal an unpleasant truth about the state of the industry? That the quality or ability of an engineer does not have to have a strong correlation to the quality of the product? If large corporations are full of these folks, yet remain profitable, what does that say about the tech industry? And if smart nimble startups hire 10x engineers and throw them through intense gauntlets, yet still fail, does that then shift the responsibility of failure from engineers- regardless of their quality or ability- to management themselves?
======
rabbitz
Development usually involves tasks that range from the easy and mundane to the
difficult and arcane. And those tasks are usually not simply assigned to a
single engineer to either succeed or fail - usually the hard stuff is given to
the more advanced coders and the easy stuff is reassigned to whoever can
handle it. I can imagine a single coder on a 10 person team who can spend 10
years on a code base doing all the 'easy' parts. There are always tons of
maintenance tasks (or 'bookkeeping' bits of work as I like to call it) that
are simple, boring, and ever-present up for grabs.

Coding is just like anything else - some people only do the minimum in order
to get a "passing grade" and so they never really get past the basics. It
isn't so much that they code without knowing how to code, but that whoever is
in charge of managing them isn't necessarily an expert on coding and often
times people find it easier to improve their ability to trick their manager
rather than the difficult task of learning new or more advanced things.

------
ankurdhama
It's all about Engineer vs Mechanic. There are many many tasks of low stakes
that require a mechanic and there are very few high stakes tasks that require
an Engineer. A mechanic is very good with the tools where as Engineer is very
good at the underlying concepts. Unfortunately in IT we call them both
Software Engineer :(

