Skip to main content Accessibility Feedback

Are developers lazy?

A few weeks ago, I had a conversation with someone who felt that the reason developers tend to just reach for npm install solutions and implement bad websites so often is because they’re lazy.

I disagree.

I have a degree in anthropology, and one of the things I’ve come to believe from studying and teaching people for years is that much of human behavior is driven by systems, not individuals.

  • Hiring managers to tend to throw lots of buzzword tools into job descriptions to attract “the best talent,” which leads to an industry believing that you need to learn and use those libraries too if you want to stay relevant.
  • Companies pressure developers to get things done under absurd timelines. This leads to “grab the first tool you find that solves the problem,” even when that tool may be more full-featured than you need, or have accessibility issues.
  • As libraries get more inertia, every solution that turns up in Google starts to reference these tools. So many tutorials I find for generic questions present library-specific solutions. This perpetuates buzzword soup in job descriptions and copy-paste behaviors in developers.

None of these have to do with laziness. They have to do with a system that prioritizes profit and output over users and professional growth. Developer behavior in a system like that is rational and smart.

I’m typically the one lone dissenter advocating for browser-native solutions against a team of people saying “let’s just use this tool.” None of the folks on “team third-party tool” have ever been lazy. They’re incredibly hard working.

They’re just choosing the tools that will allow them to meet absurd internal pressures quickly so that they can chip away at an impossibly long todo list.

If we want to improve the quality of the web, we need to fix the system, not the developers working in it.

Tools like React and Vue were built to solve real, actual problems that big companies like Facebook struggled with internally and couldn’t solve with existing solutions.

When developers at big companies invest in creating tools, they tend to get invited to speak about them at conferences and other events.