|
12345 |
- title: Defining Productivity
- url: https://jeremy.codes/blog/defining-productivity/
- hash_url: 8de0797ae7cfe73b9c44c9751daf54ab
-
- <p>As developers, we use frameworks and third party tools to build websites faster and more easily. Ask any developer <em>why</em> they use these tools, and the answer is deterministic: productivity. Surely we want to be more productive in our work, but it's worth asking ourselves an important question: how are we <em>defining</em> productivity?</p><p>We have a tendency in our line of work to assume that what benefits us as developers translates to a benefit for those who use what we make. This is an unsafe assumption. When our natural tendency is to immediately reach for <a href="https://bundlephobia.com/result?p=react-dom@16.8.5" rel="noopener">heavy</a> <a href="https://bundlephobia.com/result?p=angular@1.7.8" rel="noopener">frameworks</a> without careful consideration for the problem we're trying to solve, we're courting failure of a kind. The kind where we're not only acting against the best interests of who we're trying to serve, but against our own as well. After all, no one is well-served by slow and inaccessible websites.</p><p>The more I've heard the term <em>developer experience</em>, the more blatantly self-serving it seems. Of course we should care about our experience as developers. We all want an environment that enables us to do the work, but are we considering the potential tradeoffs? When we develop with frameworks and third party tools, are they helping us to create things people would actually <em>want</em> to use? Or is our use of them simply about creating a delightful developer experience without much regard for how what we put in production <a href="https://whatdoesmysitecost.com/" rel="noopener">can affect people</a>?</p><p>Collectively, we've been doing an <em>awful</em> job. By the numbers, we're building <a href="https://webaim.org/projects/million/" rel="noopener">inaccessible</a> and <a href="https://httparchive.org/reports/state-of-javascript" rel="noopener">JavaScript-laden</a> websites. This is our reality in part because many development teams these days tend to be feature factories. They're appendages that businesses use to convert ideas into code which literally pay. That we even refer to those who use what we make as "users" is a part of the problem in that we're not regarding "users" as <em>human beings</em> who have <em>human limitations</em>. We're reducing them to abstract figures which we can rationalize away when convenient.</p><p>This mentality has consequences. At best, it causes us to overlook the challenges people face when they access the web. At worst, it causes us to knowingly trivialize them for our own gain. How are we supposed to build anything anyone would <em>want</em> to use when we're so preoccupied with our own comfort?</p><p>I was in middle school when I started to make websites, which meant my coming of age was defined by the idea that I could make websites and put them on the web for anyone to see. It was intoxicating in part because it was an open platform without gatekeepers deciding what methods of building websites were worthy. If you knew some HTML and could upload it to a web server, you were in.</p><p>Now that the web is increasingly the domain of privileged developers who can largely afford high-end devices and high-speed connections, it's vastly different. There's open disdain for CSS and HTML which make websites possible in the first place. This attitude has lead to a sole preference for JavaScript, which has created a brittle, slow, and inaccessible web that is failing to serve the public the way it should. We need to accept that the way we develop for the web is, at least in part, responsible for this failure.</p><p>The web is broken in part because of our privilege. We're not compelled to act upon the hard answers to questions like "who uses what I make, and what are their limitations?" We just have to be "productive"—whatever <em>that</em> means—and ship code in rapid succession on a schedule that aligns with increasingly demanding fiscal goals.</p><p>The web we own today is one that apparently can't be bothered to care about acccessibility or performance unless those things are profitable—which is exactly why it's so poisonous. When the bar for why our mounting tech debt should be addressed is whether doing so translates into profit—<a href="https://www.adatitleiii.com/2017/08/website-accessibility-lawsuit-filings-still-going-strong/" rel="noopener">or avoids costly lawsuits</a>—our moral compass has been demagnetized. It's a mental state in which we're willing to reject the needs of people unless it meets a financial test. Only privileged people could be so callous.</p><p>It's only when we genuinely realize that the tools we use have an irreducible cost that can we begin to use them with care. Just because we can rationalize this cost away doesn't mean it ceases to exist. Some folks are going to be impacted by the choices we make, and we need to make peace with that fact. It's easy to slap something up on a web server, but it's quite another to be a steward of it in a way that makes the web a better place. That starts with redefining our productivity with the goal of serving the interests of others instead of our own.</p>
|
