Abstraction, Perfection, and on Coding as a Craft

It seems almost every day that a new library is created, a new javascript framework, or bundle of utility methods that promises to make developing software faster, easier, more enjoyable, etc.

Heck, there’s even a joke website about how often new frameworks pop up!¹

What invariably happens is:

1. We get stuck in to a new framework or library
2. We quickly lose interest when we run into the first set of problems that require even a modicum of effort, and then
3. We then move on to the next greatest framework/library that promises the world.

How can we break this cycle?

We need to recognize that we are continually chasing the “Next Big Thing”, without a second thought. We need to also recognize that there is no “silver bullet” that can fix all of our problems. Oftentimes, we end up trading one set of problems for another.

Photo by Bench Accounting / Unsplash

It’s in time’s like these where the main tenets of Digital Minimalism apply², which I’ve modified slightly to fit a programming theme:

• Before embracing any new technology, identify what problems it purports to solve, and what benefits it brings
• Identify any costs associated with integrating, and take care to note any additional overhead it might introduce going forward
  • For example, will you have to periodically update the library?
  • Considering that the new library is a black box of code, will there be security implications you have not considered?
  • Is there a risk that breaking changes could cause problems with your existing code? (Angular v1 comes to mind…)
  • Is the size of library a factor? Are you inflating the size of your server or client payloads just so you don’t have to think as hard?
    • e.g. Do you really need to use isarray when Array.isArray() works just as well?
• Optimize your use of new technology to minimize drawbacks, while still taking advantage of any benefits.

Chasing Perfection

Cal Newport, in Digital Minimalism, mentions the point of dimishing returns as it applies to embracing new technology. We often dive head-first into new distractions (various social media, smartphones, the latest digital trends, etc.) without fully considering how to most effectively use those tools in our lives, and often become inundated and overwhelmed as a result. The same can be said for new frameworks and libraries:

• When we embrace new frameworks or libraries, we are effectively new to it and don’t have the skills to use it to its fullest extent.
• Even a minimal amount of effort delivers great dividends, but often we hit our first stumbling block early.
• We take this setback as a sign a give up trying to improve our skills, but often don’t let go of the library because of the time and energy already invested into it, due to the sunk cost fallacy

If we haven’t taken the time to consider the impact of our technologies fully, then it is easy to dive in and become emotionally invested³. Of the technologies that we do adopt, we must consciously use it to its fullest extent by working through setbacks in order to gain the benefits promised by a new dependency.

By “considering the impact”, I mean to read more than what’s on the tin, and to evaluate not only the amount of effort that needs to be spent to integrate the technology, but…

• What additional effort is needed over time to maintain the product?
• Does the product require overhead to use with your current workflow, or does it get out of the way?
• Of the benefits it provides, does it also introduce hurdles that nullify said benefit?
• Will its integration unnecessarily complicate things, or is it overengineered for its primary use-case?

Web Development as a Craft

It’s easy to conclude from what I’ve said above as a blanket condemnation or third-party libraries and frameworks, but that can’t be further from the truth. I only mean that we should be cautious over what choices we make, and what technologies we integrate.

For the same reason why I don’t ever recommend people build their own forum software, there are many libraries that deliver clear benefits at little to no cost.

bcrypt

We utilise bcrypt in NodeBB to hash our passwords, because rolling our own hashing or encryption algorithm is costly and prone to errors⁴. Integrating this into our password-checking code required minimal effort (great!), bcrypt is a vetted hashing algorithm used widely (awesome), and if it were ever compromised, mitigation steps would be (hopefully) trivial to deploy. Best of all, it required no overhead or maintenance to maintain.

Timezone tooling

If you happen to work with timezones at all, then it makes complete sense to offload this work to third-parties. Not convinced? Take a look at this video:

Luckily, with NodeBB, we can fall back to having the server deliver everything in UNIX timestamps, and have the end-user’s browser handle any time zone shenanigans.

Conclusion

I often tell people that I treat my work as a craft, as opposed to a science. While we often have strict success criteria to hit, how we get there can take many forms. To simply achieve your goal is the minimal amount of effort, but to do it well takes conscious effort and is the mark of a competent developer. It takes hours of practice to code well (some even say it takes 10,000 hours), but like any good craft, it requires honing.

Likewise, making choices on dependent libraries and frameworks is categorically hard, and we only get better at discerning between the fluff and the truly useful over many hours of crafting.

It’s easy, simple, and fun to experiment with new technologies⁵, but what we must always be cognizant of is the overhead of introducing any new functionality (whether it be via a new dependency or your own code) in the grander scheme of things. What seems fun now might become a chore later on, and it’s through careful and methodical thought that we can avoid these pitfalls.

¹ I have a sneaking suspicion this just always says zero, but I have a vague recollection that this used to also show a link to the GitHub repo for the latest framework.
² I’m making my way through this particular book now, and I’m finding it quite illuminating. There are no affiliate links in this blog post.
³ Personally, there are still situations where a little experimentation is necessary as part of the information-gathering process when vetting any new technology, as always, moderation is key.
⁴ Case in point: Move Fast and Roll Your Own Crypto: A Quick Look at the Confidentiality of Zoom Meetings
⁵ Again, the irony is not lost on me here, in that NodeBB self-selected a non-relational data store (Redis and/or Mongo) to store what is obviously very relational data.
^{Cover Photo} by Jonathan Hoxmark on Unsplash