Forem: Folafunmi

Modern Frontend: Growing Responsibilities

Folafunmi — Fri, 29 Apr 2022 18:12:49 +0000

TLDR: The increasing complexity in the frontend ecosystem should trigger a reassessment of valuation, job descriptions, and general overview of frontend developers.

Intro

Lewis Caroll description of Wonderland, as a place where “It takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!”, which epitomizes the current landscape of frontend engineering where standards evolve and change is the only constant.

Several months ago, I stumbled upon an intelligently written piece by Brad Frost on what had then begun to be called The Great Divide. This made the rounds. In this article, he outlined two functionally distinct aspects of web development: Front-of-the-front-end web development and Back-of-the-front-end web development.

NB: In this post, I do not give heed to the nuances of syntax. As such "Front-End", "Frontend", "Front end" would refer to the same aspects of web development neither do I concern myself with the semantic differences, if there are any, between "Developer" and "Engineer". All terms would be used interchangeably in this write-up.

It’s become more prominent in recent times that the term "Front-End Developer/Engineer" needs an overhaul, with reasons stemming from the ever-expanding surface area of responsibilities that have to be catered for and categorized as "Front-End".

In line with this, various points were raised stating that the minefield that is CSS is a big enough challenge. As bluntly put by Mandy Michael in her article, Is there any value in people who cannot write JavaScript?”

When every new website on the internet has perfect, semantic, accessible HTML and exceptionally executed, accessible CSS that works on every device and browser, then you can tell me that these languages are not valuable on their own. Until then we need to stop devaluing CSS and HTML.

Here she puts forth the brilliant idea, that although a divide exists, it doesn't exist for the casting down of one side or the other.

Addressing the differences between developers Ronald Long, in the context of peace, wrote in his article on the subject:

Yes, there is a divide, but no, neither side is any more valuable than the other.

It is worthy of note that the divide being spoken of here refers to how the broader ecosystem splits the responsibilities of the frontend developer into two sections. Those who major in HTML and CSS (front-of-the-frontend developers) sometimes referred to as UI developers and those that are far more dependent on Javascript (back-of-the-frontend developers).

However, most times this distinction only serves to educate the developers themselves as employers and recruiters do not give heed to the growing landscape of responsibilities of the frontend developer. As such most frontend developers are expected to be both front-of-the-frontend and back-of-the-frontend savvy.

This results in a , as requirements for frontend developers now differ significantly from those of a few years ago. The developer community, in an attempt to capture the current state of frontend engineering, has adopted the term Modern Frontend.

Sadly, this doesn't appear to have gained traction with many people. The common sentiment (in my experience) by other engineers and those in management, towards what is regarded as frontend, hasn't shifted to reflect the expansion. Particularly in the context of regard and valuation.

Possible Reasons

Based on personal experience as well as those of the numerous articles I've read on the topic, I can classify the justification for the resilience to change in perception into two classes:
Sentiment
Responsibility
These are highlighted in the reasons that follow.

Recently, I came across a brilliant article on Frontend Vs. Backend System Design Interviews, where the author gave his two cents (more than that though) on the context, similarities, and differences in interview processes between jobs listed for Frontend and Backend Developers/Engineers.

The author, Zhenghao, also expressed a concern for a Career Ceiling which seems to be exclusive to frontend engineers only. This is in line with intermittent opinions that pop up every now and then saying or implying that "frontend engineering isn't real engineering".

The author along with anyone that has paid attention to the frontend ecosystem knows that frontend is just as much as challenging as backend.

However, it's quite important to recognize the underpinnings of such statements. Paraphrasing some of the opinions from Zhenghao in this post, possible reasons include:

Inertia

The reluctance to a change in the mentality that frontend is not real engineering can be seen quite clearly in differences in compensation.

At the time of writing, estimations from Glassdoor inform of a pay gap of 10 - 70% between Frontend and Backend developers for roles with similar experience depending on the industry and location.

Also, this can be seen in the roles of those that move up the career ladder. Depicted in how most (from those I’ve seen) of VP of Engineering or CTOs were previously Backend Engineers or Infrastructure(DevOps) Engineers. I give more details on my reasoning around this in the section on experience.

Economics

This reasoning values an engineer by the amount of money(resources) you control. This can also be referred to as responsibility.

As noted by Zhenghao in his article,

I had this realization that when I was going through the backend system design interviews vs. the frontend system design interviews - the technical topics those interviews tend to cover let me think about some economic reasoning leading to the perception of a "Frontend Ceiling” as well.

Backend systems require more expensive resources to run, be it Digital Ocean droplets, EC2 instances etc. These compute seem to require much more to both maintain and scale.

Frontend systems on the other hand run on the user's devices, which costs a company essentially...NOTHING! No maintenance is needed. No bills.

Essentially, bad backend code or DevOps integrations can lead to a hefty bill from AWS that'd make anyone cry, but bad frontend code can be seen to mostly affect a user to a certain degree and doesn't drain the funds of the company.

Length of processes

Frontend applications live on the user's device, spun up, and terminated with the open and close of a browser tab. While backend application servers however run for months and or years.

Flawed frontend code only lives long enough to affect the currently open tab. Flawed backend code however can and often will accumulate, leading to slowdowns or crashes. One can be ignored the other most certainly cannot.

Experience

This point is from my personal experiences in the tech space. It's easy to associate the term frontend with inexperience. In reality, it is relatively newer due to the technologies that surround it.

From my research, when web browsers were first released there wasn’t much of a “front-end.” There were static HTML pages and CGI scripts that generated HTML.

Asynchronous JavaScript and XML (Ajax), from its inception in 2004 (or 1999 depending on who you ask) then until its proliferation in 2008/2009 periods wasn't widely adopted.

JavaScript, which serves as the base for modern frontend, wasn't as used till frameworks that emerged around the 2010s. Developers around these periods worked largely on the backend (server-based tasks, databases, etc). Backend developers that then worked on user interfaces are styled, Fullstack Developers.

This largely leaves mostly newer developers who focus on the front-facing interface to embrace the “frontend” description. Thereby easy to associate them with fewer years of experience.

Coupled with the fact that frontend (referring to HTML, CSS, and JS) has the least barrier to entry–a web browser. As such beginner web developers are advised to start with HTML, CSS, and JS which are the fundamentals of frontend.

These are brilliant points!👏🏾

However, I hold other opinions which do not invalidate the points listed above, but rather take into account how broad the Front End ecosystem has become.

This is due, largely, to user expectations which have led frontend down a road of solutions that succumb to incidental complexity.

Frontend isn't working hard to become as complex if not more than backend.

The need to adapt to the end-user, to maintain a stable pace with advancements in browser technology, devices, web standards, etc has led to newer(sometimes weirder) solutions in the frontend ecosystem.

The definition of the frontend role has expanded to include human-computer interaction, responsiveness, UI optimization and reusability, browsers, devices, and accessibility amongst others.

Over the last couple of years, there has been an explosion of options for nearly everything in the ecosystem some of which I highlight in the next section.

Rising Frontend Complexity

With almost every passing week emerges new abbreviations and concepts, further expanding the body of knowledge.

Sophisticated abstractions intended to ease the workload on engineers tend to demand new understanding and inspire new ways of building apps. Complexity in itself doesn't attenuate, it only evolves.

Change is rapid and unpredictable.

The increase in internet usage shows that web developers now have to consider a larger audience, tougher demands, and offer better user experience by whatever means necessary.

All in a space that's come under more scrutiny in recent times with Google's announcement to rank pages based on Core Web Vitals. Frontend developers as such have to resort to more nuanced technologies to meet egregious and ever-rising demands while balancing what tradeoffs may come their way.

Modern frontend has spurred the demand for pixel-perfect, real-time, reactive, concurrently rendered, responsive sites with minimal bundle size, accessible HTML & CSS, stylish UI with snappy responses, optimistic updates, cached data, and performant animations across all devices to which newer features can be easily added without a hit to performance or developer productivity.😰

Really, is that all? Want my left hand too?🙄

There also exist different ways to achieve similar results, all with their nuances and learning curves. This has led to the further rise in complexity of frontend architecture. Some categories of these choices include:

1. Tooling

Frameworks: React, Vue, Angular, Solid, Svelte, Qwik
Frameworks: NextJS, Remix, NuxtJS, Sveltekit
Bundlers: Vite, Snowpack, Webpack, Parcel, Rome
State managers: Redux, Zustand, Recoil, Pinia, Vuex
Package managers: npm, Yarn (1,2,3), pnpm
Serverless: Netlify functions, Vercel edge functions, Cloudflare workers, AWS Lambda
Project structure: 😂

Frontend tools are no longer presented as optional features. Developers can only handle so much complexity on their own before relying on useful abstractions to solve routine tasks.

Libraries and tools were born out of necessity, the need to adapt to tougher requirements as well as the desire for the better developer experience. The model of modern frontend therefore favours configuration and flexibility.

The plethora of choices when it comes to tooling is both a blessing and a curse. For example, if some better architectural model surfaces tomorrow there’s a good chance it’d be available sooner rather than later. Here, it’s a blessing.

However, this means frontend developers have to weigh x+1 factors in making the choice of tools to use. Vadim Demedes laments about this in his article where he explains why he switch to rails from javascript single page applications.

2. Various rendering and hydrations modes

It really does seem like everyone is trying to come up with three letter acronyms for new rendering modes.

CSR - Client Side Rendering
ISR - Incremental Static Regeneration
DPR - Distributed Persisted Rendering
DSG - Deferred Static Generation
SSR - Server Side Rendering
SSG - Static Site Generation
There’s more coming!

These would be explained in a different blog post. Watch out!

Also, for the types of applications there’s the choice between:
SPA - Single Page Applications
MPA - Multiple Page Applications
Hybrid
The best resource I have come across on the topic can be found here

Not to mention the different modes of hydration i.e Progressive hydration, selective hydration, or sidestepping hydration altogether and going for a framework that favours resumability (thank you Misiko!).

This might seem to be a challenge mostly faced by authors and maintainers of libraries, who work immensely to create sane abstractions for the developer community.

For example, to switch from SSR to ISR in NextJS can be the addition of a single line of code.

However, note that frontend developers being burdened about user experience and performance have to weigh the tradeoffs between the different modes and the community that surrounds them.

At the point of writing, it is quite possible to ship relatively complex web apps built without an explicit backend. Thanks to hybrid frameworks frontend has gone fullstack!

3. Evolution of the web and user expectations

The web is poised to become its own operating system, allowing developers to bypass building the same app for different platforms.

With the rising CPU performance of devices, phones and computers can do more and users have come to expect more. This can be seen in Line Engineering’s report on web development.

Versions of popular apps such as VScode, Photoshop etc are now available on the web.

The usefulness of a site ultimately comes down to user interactions. This can yield beautiful rewards for the business as a whole when done right as well as reap alarming consequences when gotten wrong.

In 2015, Invision published an article with compilation of statistics on the effect of UX on businesses. Simply put, the ROI of UX cannot be overlooked.

Conclusion

I wrote this piece, not as a swipe at other forms of engineering, because they do have various choices to make and also have to handle rising complexity. The point of this article was to show that frontend ought to be appreciated alongside the immense work being done by engineers all around.

Truly, this is a hard and exciting time to be a frontend developer. As Kevin Ball put it, in his article

The technology is moving so fast it’s hard to keep up, the ecosystem is fragmented, and there is tremendous pressure for even individuals to meet and exceed the user experience standards set by massive billion-dollar companies.

Work requirements are evolving in all spheres, likewise, it's important to update our assessments of all roles.

This is an incredible time for innovation, there have never been more opportunities, and there has never been more powerful tooling.

This is an amazing time to be a Front End developer ✌🏾

Resources

Tailwind vs Sass/SCSS: Structure and Consistency over Style and Comfort

Folafunmi — Thu, 10 Mar 2022 13:13:18 +0000

Introduction

For this article, I choose the totally non-controversial and completely innocent topic of CSS frameworks, particularly placing the growing Tailwind library and the dominant Sass/SCSS.

Why? I just love violence 😈. But actually, having read several opinions on both sides of the aisle, I choose to air my views as a contribution to the ongoing debate regarding CSS frameworks. Who knows, someone might just find it useful 🤷🏾‍♂️

It’s difficult to miss the appeal of Sass (Syntactically Awesome Style Sheets), which is an extension of CSS that provides features that seem to have been left out of CSS itself. It preserves the natural feel of writing CSS, but at what cost? 🤔

Alternatively, Tailwind proposes a utility-first approach to CSS where styles pre-exist with classes that can be added to any HTML element. While this has developer experience (DX) benefits, it’s an unnatural way of writing CSS because you don’t actually write CSS, it’s already been written! Aren’t we just writing HTML then? Doesn’t this violate separations of concerns? 🤔

It’s apparent that both Sass and Tailwind recognize that plain CSS needs help. Judging by the widespread adoption of both frameworks, the developer community seems to agree with this premise. As at the time of writing this, Sass had 7.1M+ weekly downloads while TailwindCSS had garnered 2.4M+ weekly downloads on NPM. In reality, these numbers represent the lower bound of their uses.

Both aim to increase the quality of life around writing CSS but their approach however differs.

What is Sass?

Released in 2006, Sass (Syntactically Awesome Style Sheets) is a mature stylesheet language that’s compiled to CSS (Cascading Style Sheets). Essentially, Sass makes you write CSS more efficiently. It provides features with a fully CSS-compatible syntax.

Sass is preprocessed into CSS. The Sass preprocessor (written in Dart or Ruby) takes input data in Sass or SCSS format and converts it to an output that's pure CSS. This is necessary because browsers can only read CSS code.

This means when you run Sass/SCSS code, you're actually converting your code to CSS. That CSS code output is then used directly by a browser.

What is SCSS?

To clear up the confusion between Sass and SCSS, SCSS stands for “Sassy CSS” and is a more natural feel to CSS compared to the original Sass syntax.

The initial Sass syntax uses indentation for nesting and provides a visual hierarchy in the code, its appearance is similar to Python or Ruby but unlike CSS. It uses the .sass extension.

SCSS on the other hand uses curly braces that better resemble regular CSS. It uses the .scss extension.

An example of indented Sass syntax from the official docs.

@mixin button-base()
  @include typography(button)
  @include ripple-surface
  @include ripple-radius-bounded

  display: inline-flex
  position: relative
  height: $button-height
  border: none
  vertical-align: middle

  &:hover
    cursor: pointer

  &:disabled
    color: $mdc-button-disabled-ink-color
    cursor: default
    pointer-events: none

An example of SCSS syntax from the official docs.

@mixin button-base() {
  @include typography(button);
  @include ripple-surface;
  @include ripple-radius-bounded;

  display: inline-flex;
  position: relative;
  height: $button-height;
  border: none;
  vertical-align: middle;

  &:hover { cursor: pointer; }

  &:disabled {
    color: $mdc-button-disabled-ink-color;
    cursor: default;
    pointer-events: none;
  }
}

Both perform the same function and have the same capabilities. However, SCSS syntax is more appealing, easier to learn, and personally, it’s the only one I’ve ever used.

Benefits of Sass

Sass provides features that enable developers to move faster when working on a project. Some benefits include:

Variables: Facilitates the DRY (Don’t Repeat Yourself) approach. Although regular CSS has this feature at the time of writing albeit with a different syntax.
Mixins: Even DRY-er approach. This encapsulates certain rules into one.
Functions: Useful for some folks, but not me 😅 🤷🏾‍♂️.

What is Tailwind?

Contrary to Sass/SCSS, Tailwind adopts the atomic CSS style, using the term utility-classes to define a subset of the much broader term.

Utility classes here mean classes that do one thing well.

What is Atomic CSS?

Atomic CSS is more of an architectural philosophy rather than one particular library or framework. Notably, Tailwind wasn’t the first on the atomic CSS scene. There are other libraries that adopt the atomic CSS pattern like Tachyons.

According to John Polacek in his article,

Atomic CSS is the approach to CSS architecture that favors small, single-purpose classes with names based on visual function.

Please note that Tailwind classes aren’t the same inline styles. The differences have best been captured elaborately in this article by Sarah Dayan. Rather than go through the reasons outlining differences, I’ll just give a scenario instead.

Say you want a card profile component that appears in landscape on a widescreen with left-aligned text but portrait on a smaller screen with center-aligned text, and it also changes the background color, shadows, and opacity when hovered or focused.

Can inline styles help you out there? Yeah, I didn’t think so.

My comparison

As the title implies, the essence of this article is to give my take on the two frameworks and explain my thought process behind them.

There are undeniable advantages for both Tailwind and Sass. Based on your preferences you’d place more weight on one over the other in certain instances.

In all honesty, I initially started out with Sass. I loved it, it saved me from repetitive and cumbersome native CSS. But per my experience with both as well as recent updates, Tailwind has evolved to become my go-to CSS framework on most new projects. Here are my reasons:

1. Composability & Modularity

With Sass, there has to be extra effort on the part of the developer to achieve a modular system in order to make CSS more manageable and robust. This can be done using different modular CSS methodologies like Object Oriented CSS (OOCSS) or Block, Element, and Modifier (BEM), etc. More on those here.

This however is a given with Tailwind. Tailwind classes by their atomic nature are able to effectively build composable isolated components.

2. Naming

I’m sure there are developers out there who pride themselves on being able to come up with clever and suitable names for CSS classes. I, am not one of those people.

Let’s say you want to name a classes for a card that holds the card ads for a site. You might come up with,

.car–card {...}
.car–card .img {...}
.car--card .img img{...}
.other {...}

Further down the development line, you discover the same design is used for other ads on your app. This can become,

.ad–card {...}
.ad--card .img {...}
.ad–card .img img{...}
.other {...}

Then later you discover that the same design is used for the card that show your app services. This it becomes,

.media–-card {...}
.media--card .img {...}
.media–card .img img{...}
.other {...}

🤦🏾‍♂️ Not the best of examples, but do you see my point?

Tailwind takes the burden of naming off my shoulders by providing suitably named and well documented classes which can always be looked up whenever needed. They utility classes mean the same things wherever, whenever.

3. Responsiveness

Tailwind pushes you to use best practices when developing. Notable it enforces the mobile-first approach, thereby forcing the developer to think of responsiveness right from the get-go.

It encourages a robust approach that takes into consideration different screen sizes and orientations. This can also be easily extended in the tailwind config file.

4. Onboarding new developers

It takes developers some time to get accustomed to any new codebase, even ones that have a familiar language. Specific decisions have to be understood enough to be followed. Essentially, newer developers have to interpret what someone else meant and whether their decisions were deliberate and contextual, or arbitrary and habitual.

According to Daniel Terhorst-North in writing about CUPID,

The greatest programming trait is empathy; empathy for your users; empathy for support folks; empathy for future developers; any of whom may be future you. Writing “code that humans can understand” means writing code for someone else. This is what idiomatic code means.

New developers can get accustomed to Tailwind classes in a short time. Although this would still be more than the time to learn Sass since, it is in appearance, still CSS.

Sass provides more freedom in development however, this can lead to a problem of clarity.

5. Clarity

The flexibility and freedom provided by Sass can serve as a blessing and a curse. Nesting selectors and media queries can hasten development for the author of a codebase but not so much for a maintainer that'd come in later.

It's quite easy to create confusion due to nesting in Sass where elements can be selected from (almost) wherever. Granted, this is also possible with native CSS and isn't peculiar to Sass however it's an issue solved by atomic CSS. So, this is more of an architectural issue rather than an intrinsic one.

I once wrote mixins using Sass like:

@mixin font-face($weight: 500, $style: normal) {
  font-weight: $weight;
  font-style: $style;
  font-family: Poppins, BR Firma;
}

@mixin font-look($font-size, $line-height) {
  font-size: $font-size;
  line-height: $line-height;
}

@mixin font-look-mediaQuery($font-size, $line-height, $screen-width: 600px) {
  @media only screen and (max-width: $screen-width) {
    font-size: $font-size;
    line-height: $line-height;
  }
}

.p-bigbold {
  /* Paragraph Big Bold */
  @include font-face(500);
  @include font-look(1.125rem, 1.4375rem);
  @include font-look-mediaQuery(0.875rem, 1.125rem);
}

When I wrote this only God and I understood it, now only God does 😂

6. Resilience

Here I ask the question, How easy is it to mess up?

Making changes feels safer. Sass/SCSS can be global (there’s such a thing as scoped CSS) and you never know what you might break when you make a change. Classes in your HTML are local, so you can change them without worrying about something else breaking.

7. Predictability && Consistency

Tailwind is fully deterministic. It does the same thing everywhere. Compared to Sass a component can be copied and pasted in a different and there’s a better chance it looks the same. With Sass, it really depends on the architecture.

No need to fight specificity battles, I prefer the consistency of Tailwind.

8. Constraints

Being able to follow a design system is a hallmark of a good frontend developer but in cases where there isn't a clear design, system Tailwind provides sane defaults that are invaluable.

Tailwind's utility classes help you work within the constraints of a system instead of littering your stylesheets with arbitrary values.

In practice, one way(my preferred way) of sticking to a design system is to define constants that hold the values of all different sizes, colours, fonts, and all that a design system entails. Then apply those constants wherever needed in the codebase.

This is possible in both Sass, with the use of variables, and also tailwind with the use of custom classes. But without a doubt, Tailwind's tooling takes the cake.

9. Tooling

On VScode (my IDE of choice) the IntelliSense provided when styling with Tailwind is second to none.

I found Tailwind's syntax intuitive yet the tooling makes writing Tailwind even easier. In fact, I only got to know some CSS rules when I began writing Tailwind.

Yes, I'm looking at you whitespace-nowrap.

Concerns

As with all things, there are demerits and trade-offs. Some of the ones I list here are per my use as at the time of writing.

Notably, there are other concerns with Tailwind that have been handled by subsequent upgrades. I won't dwell much on those in the section below.

1. Breaking Constraints

Tailwind is utility-first, not utility-only. Asides from the practice of just adding regular CSS or Sass styles alongside Tailwind classes, the maintainers of Tailwind provided a way to add in custom sizes, colours, etc directly in the Tailwind classes.

This is possible thanks to the Tailwind JIT (Just In Time) compiler. Just like Sass's nesting feature, this is also a blessing and a curse.

It helps in cases where the developer wants one-off dimensions that are not available in the default Tailwind classes and isn't worth creating custom classes for. But then it provides an avenue to keep using custom values all over the app.

Although this is unlikely, you'd be surprised what you'd find in some codebases 😬

2. Size

Although Tailwind utilizes PostCSS to remove all unused styles, it's still larger in production than if Sass had been used.

This actually isn't much of an issue since if your CSS is in the range of kilobytes there are far better ways to improve performance on your site. So, this isn't so serious but it was worth mentioning for the sake of being thorough.

Also, keep in mind that Tailwind used to be massive in development but in recent upgrades, the JIT compiler has deployed in response to this. However, this has created a different problem which I elaborate on below.

3. Debugging

Recent upgrades of the JIT compiler to Tailwind development have made debugging using the browser dev tools more difficult in some cases.

This is due to the JIT compiler creating classes on the fly, therefore, removing the need to purge unused CSS classes since they were never created in the first place.

However, because the classes are created on the fly any class not specified somewhere in the code doesn't exist and cannot be added ad hoc in the dev tools. This is needed sometimes to quickly see how a certain class affects the styles.

This can become especially burdensome if there are several custom tailwind classes added to the config.

There are tools to help with this though like Devtools for Tailwind.

4. Theming

This might be more of a personal preference but I’m not for the bg-white dark:bg-black syntax which is the default way of theming in Tailwind. Why have classes that do nothing half the time? What if I want more than two themes?

I’d rather have variables that I can switch out at will. Another approach is to use custom classes that are toggled like the approach that Next-themes takes. However, this is specific to NextJS.

Conclusion

As a note, it’s not the tool but the craftsman that does good work. Tailwind provides benefits out of the box, but these can be opted out of following bad usage of the library.

Everything rises and falls on architecture.

In summary, I’ll advise choosing Tailwind in a new project as it presents sane defaults which help provide structure to an application.

There are other alternatives to just Tailwind or Sass. The option of Styled-components is also a good one, which enables the use of Sass/SCSS syntax within its tagged templates. You can also use Tailwind in conjunction with Styled-components using a library like Twin.macro or Twind.

For a holistic view of the opposition to Tailwind, you can read a different point of view here.

I hope this article helps.

Please share your thoughts and opinions in the comments section below.

Resources

A Guide to Order: Setting up Prettier and Eslint with Husky, Lint-staged and Commitizen

Folafunmi — Thu, 17 Feb 2022 15:30:23 +0000

TLDR: To save yourself a headache, use coding standards and become more efficient by automating your development workflow.

Intro

Have you ever had to code review a PR that has 2000+ changes, when the actual code change was less than 15 lines? I have and it’s quite annoying.

When we write code it is to the end that it’s understood by other developers and also your future self. As such we find value in guiding principles and conventions by which we’re able to develop in a consistent manner. This is the very reason for coding standards.

Order over chaos.

Coding standards are best-practices guides that developers follow in order to write code in a predictable and consistent manner. Basically, this makes it easier for the team to maintain and extend an existing codebase.

Engineers at their core tend to prefer automation over manual processes. Being willing to spend hours automating a task that’d take just a few minutes of manual labour. In like manner, there’s the obvious benefit of automating the enforcement of coding standards in a project.

Yes, it’ll fix your errors without additional effort!!! 🎉

This write-up contains explanations as well as a tutorial on how this can be done using Husky, Lint-staged, Eslint, Prettier, and Commitizen.

Learning outcome

Understand what coding standards are
Understand the advantages of coding standards
Understand git hooks
Setup git hooks with husky and lint-staged
Configure Eslint, Prettier, and Commitizen

Prerequisites

Node >= v14

NB: As usual, I lean towards a thorough approach to learning and understanding, therefore I go through the explanations first outlining the benefits and answering why we need to set standards for every project in an organization.

Alternatively, if you’d rather just know how to set up the tools don’t worry I’ve got you covered. You can go directly to the tutorial section here

The what, why, and how of coding standards?

Coding standards are a set of guidelines that recommend programming styles, practices, and methods for a given program.

Why do we need them? Because everyone writes code differently which is usually fine until you have to work with someone else's code.

In development, I generally go by the maxim:

Prefer structure and consistency over style and comfort.

This presents benefits for every developer that’s working on and will work on the project.

Benefits of coding standards

It gives a uniform appearance to the codes written by different engineers.
It improves the readability and maintainability of the codebase and it reduces complexity also.
It allows catching of errors in their infancy
It helps in code reuse and helps to detect errors easily.
It promotes sound programming practices and increases the efficiency of programmers.

This is general aids developer productivity and speeds up work. It reduces the guessing game and revisions that newer developers have to go through when making contributions.

Style guide

A style guide contains general rules about “how to write” code. This usually contains fine-grained instructions on how code should appear. These would provide guidelines for how the code should look, clearly stating anti-patterns.

To quote an article on the topic,

“All code in any code-base should look like a single person typed it, no matter how many people contributed.”

Typical factors considered when choosing a style guide include:
Indentation: tabs or spaces, indent width

Bracket placement
Quotes to use
Spacing
Ordering
Comment style and the use of documentary comments
Variable, class, and file naming conventions
Statement style and best practices of their usage
File organization
Declaration of classes and interfaces
Exception handling
Import and export types

For example, Airbnb’s style guide for React gives a perfect picture of the expectations of a style guide.

More examples of coding standards can be found here

In practice, it’s important that all these have to be chosen by the team to ensure the standards fit the needs of the project and the developers involved. Coding standards for each team are different as such they have to be decided appropriately. In the end, it’s these developers as well as those that would come who will maintain the codebase. Therefore, they have to be considered when deciding on coding standards.

Suggestion: Call a meeting with the dev team where coding standards are explicitly discussed and agreed upon.

Then, the golden question that this article aims to answer is, how can I enforce this in my codebase? 🤔

Linting

Linting is the process of using a tool to analyzes source code to flag programming errors, bugs, stylistic errors, and suspicious constructs. This is done using a Linter or Lint tool.

The most popular amongst the lint tools is Eslint. According to the docs,

ESLint is a tool for identifying and reporting on patterns found in ECMAScript/JavaScript code, with the goal of making code more consistent and avoiding bugs.

Can be installed using:

npm install eslint --save-dev

# or

yarn add eslint --dev

To set up a config file:

npm init @eslint/config

# or

yarn create @eslint/config

This will create an .eslintrc.{js,yml,json} file in your directory. In it you’d find something like:

{
    "rules": {
        "semi": ["error", "always"],
        "quotes": ["error", "double"]
    }
}

These rules guide Eslint when it scans your codebase to know what conventions you’ve specified to follow.

Your .eslintrc.{js,yml,json} configuration file will also include the line:

{
    "extends": "eslint:recommended"
}

This provides some (default standards](https://eslint.org/docs/rules) (all of the rules marked "✓") from Eslint. These can also be extended using Eslint’s rich plugin system.

You can create and publish your own config, and can also install plugins from other creators from NPM. Some notable ones include:

An alternative linter is JShint.

Formatting

Prettier is an opinionated code formatter with support for various languages. It ensures that all outputted code conforms to a consistent style. Prettier takes your code and reprints it from scratch by taking your configuration into account. You can learn more here.

The docs present extensively the benefits of using Prettier as a code formatter. Some of which include:

Building and enforcing a style guide
Helping Newcomers
Easy to adopt

Can be installed using:

npm install prettier --save-dev

# or

yarn add prettier --dev

Differences between linters and formatters

Linters analyze your codebase to catch errors and suggest best practices ( involving the use of the abstract syntax tree) while formatters fix code style. Linters should deal with tasks like function complexity, syntax improvements, etc while formatter should deal with tasks like spacing, line wraps, comments, etc.

Linters can be used as formatters, but they are not the best fit for those classes of tasks.

The Prettier documentation makes reference to (formatters vs linters](https://prettier.io/docs/en/comparison.html#how-does-it-compare-to-eslinttslintstylelint-etc), stating to:

Use Prettier for formatting and linters for catching bugs!

Both do their job well as such should be used together.

However, there’s a known problem when using both Eslint and Prettier. A good approach is to run prettier first and then Eslint. There, however, exists a simpler solution. Enter prettier-standard.

Prettier-standard helps to format with prettier (actually prettierx) and lints with eslint preconfigured with standard rules. No eslint config has to be set.

Tip: On VScode, an extension that can make this experience better is Error lens. This highlights sections of the codebase that require linting or formatting thereby creating a better experience for the developer.

Git hooks

Git hooks are scripts that Git executes before or after events such as commit, push, and pull. They can be used to alter internal behavior and receive notifications when certain events occur in a repository. Git hooks are built into Git so there’s no need to download anything. These Git hooks run locally.

Some example hook scripts include:

pre-commit: Can be used to check that the commit message conforms to convention.
post-commit: Can be used to email team members of a new commit.
post-merge: Can be used to install new dependencies

A comprehensive list of Git hooks can be found here

Hooks are regular scripts that reside in the .git/hooks directory of your project. This makes them easy to install and customize. They plug into the entire development life cycle. We now know how to perform customizable actions at every stage in the commit creation process, therefore can greatly increase developer productivity.

A more elaborate explanation of the hooks overview, concept, and scope can be found here

Set up Husky and Lint-staged

Install husky

First, we have to initialize husky. We do this using npx,

npx husky-init && npm i

#Or

npx husky-init && yarn

This would edit the package.json file by adding the husky dev dependency and the script,

"scripts":{
…
"prepare": "husky install"
}

This helps to install husky on other devices.

It also creates a .husky folder in the root directory.

|-- .husky/
   |-- _/
       |-- husky.sh
   |-- .gitignore
   |-- pre-commit

The pre-commit file contains a default script:

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npm test

This script contains commands that’d run just before a commit is made. Let’s edit this to run type checks and test scripts before a commit is made.

Omit the typescript portions of the script if you’re using Javascript

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npm run tsc
npm test

And we add the script to the package.json

"scripts":{
…
"tsc": "tsc",
"prepare": "husky install"
}

But there’s a problem. This would run the test files and type checks every time we change anything at all. To solve this we use lint-staged.
### Install Lint-staged along with Prettier and Eslint

Install lint-staged, prettier and eslint using,

npm i --save-dev lint-staged prettier eslint

Lint-staged allows us to run scripts only when certain files are about to be committed. Let’s edit our package.json to reflect this,

"scripts":{
…
“lint”: “eslint . --fix”,
"tsc": "tsc",
"prepare": "husky install"
}
…
"husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
"lint-staged": {
    "**/*.{js,jsx,ts,tsx}": [
 "npm run lint",
“npm run test --watchAll=false --findRelatedTests --bail”,
],
    "**/*.{json,css,md}": "prettier --write"
  },

Please play around with the flags to obtain the suited result.

We can then go back to edit the pre-commit file,

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npm run tsc
npx lint-staged

You can then add .eslint.rc, .eslintignore, .prettier.rc and .prettierignore as you see fit.

Now, when a commit is to be made lint-sage would run the type checker, eslint and prettier.

Set up a commit message hook and Commitizen

The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history.

We can create a hook that’d check if the commit message is according to the conventional commit standard.

To add a hook to check the commit message, run the command:

npx husky add .husky/commit-msg

Then paste in the script below,

#!/bin/sh
if ! head -1 "$1" | grep -qE "^(feat|fix|chore|docs|test|style|refactor|perf|build|ci|revert)(\(.+?\))?: .{1,}$"; then
    echo "Aborting commit. Your commit message is invalid." >&2
    exit 1
fi
if ! head -1 "$1" | grep -qE "^.{1,88}$"; then
    echo "Aborting commit. Your commit message is too long." >&2
    exit 1
fi

In order to simplify the process of making a commit according to conventional commit standards, you can install Commitizen.

Install commitizen as a dev dependency,

npm i –save-dev commitizen

Then initialize commitizen,

commitizen init cz-conventional-changelog --save --force

This would provide a setup such that when you make a commit(after git add … of course) using the command,

git cz

You get this,

Now you’ve set up an automated workflow with husky, lint-staged, eslint, prettier and commitizen.

This implementation can be extended using dependency cruiser to lock down certain dependencies from being used across the codebase. This is however quite optional and should be adopted as the need demands.

Caveats

There are some caveats to this approach though.

Might be overkill for small apps
Doesn’t eliminate the need for proper communication
Not a replacement for CI

Conclusion

Compliance with coding standards leads to more maintainable software and a team that works well better and ships faster. This is as a result of less back and forth on pull requests.

A research article that studied two small projects even shows a dropping error rate when coding standards are adopted.

Its authors' quote,

The dropping of error trends indicates that as developers align with the coding standard, there will be less fault corrections, hence fewer probability to new faults. Nevetheless although less, developers will be making errors in any circumstances, which justifies the coding standard check step in the software development process. Another thing that is evident through this research is that the use of checking tools in the implementation step mitigates the errors in the code checking step.

The adoption of coding standards can lead to better performance from the team generally as well as boost individual performance and growth. It provides a focus on reliability, security, and structure.

Consequently, it dampens individual coding style yet I argue that priority should be placed on structure over style and consistency over comfort. In my view, its benefits far outweigh its cost.

Hope this article helps.

Resources

Everybody cooks beans! Get good at debugging!

Folafunmi — Thu, 10 Feb 2022 10:50:19 +0000

TLDR: Inevitably, you will create bugs. But can you debug it effectively? That’s what will matter.

Introduction

Different organizations have their jargon. One I’ve picked up, stemming from my Engineering Manager is "Everybody cooks beans", which aims to communicate that everybody makes mistakes.

This statement hopes to present a mentality that as much as we all want to do good work, mistakes are inevitable. Although his focus is on software engineering, it isn’t exclusive to the field. An adventure into any field presents opportunities to make mistakes. And it's in those mistakes that learning happens.

Software engineering christened the term "bugs" to refer to unintended behaviors from a particular program. "Unintended" is the keyword here, as software essentially acts as designed not as intended.

Code doesn’t lie.

As software engineers, our role is to convert intention into code using syntax from a myriad of languages. This skill of delivering precise instructions to a computer to perform tasks comes with a responsibility to translate intention into instructions. It doesn't take long to realize that most of your work as a software engineer is to make the program behave as it's supposed to rather than as it is😅

Precise instructions create features, the alternative produces bugs.

This isn't always the case as some faults in a program might impact performance but not obstruct function.

NB: I don’t attempt to distinguish between bugs and errors. In my view, the disparity between the two, if any, wouldn’t significantly impact the focus of this article. As such I use the terms bugs and errors interchangeably.

Some common types of bugs/errors can be found here.

As software engineering grows and as software becomes an interconnected network of services, the surface area for bugs to exist has only widened.

Debugging which is analogous to troubleshooting is the process that involves identifying a problem, isolating the source of the problem, and then either correcting the problem or determining a way to work around it.

The discipline to traverse multiple factors to narrow down issues to get at a root cause stands as one of the most important skills a developer can have.

The skill to debug software, therefore, isn't an add-on, it's a must-have.

Debugging your own software has been described as being a detective in your own crime.

Even the most experienced and skilled developers are susceptible to committing crimes of their own. The only difference exists in that, through time, they have sharpened their detective skills to more quickly figure out the culprit.

Some of the most advanced organizations still fall prey to bugs leading to an inability to dispense their services. A common term used in situations such as these is "outage".

These can be caused by internal or external factors. The interconnectivity of services testifies to the inevitability of bugs/errors per time. Even the likes of Mozilla, Cloudflare and AWS suffer outages. Usually, these are followed up by a post-mortem which, essentially, is an analysis of the error with the benefit of hindsight.

A comprehensive list of post-mortems can be found here.

Challenges of debugging

Compared to other aspects of software engineering there aren't as many well-documented resources on debugging. Worse is that developers often have an informal introduction to debugging, which is in the instance of a fault.

Quite often, debugging happens under pressure and with little information to go on. Failures are often sporadic. Engineers are short on time and have to come up with a solution yesterday. Managers check-in within intervals. In worse cases there's panic, and everyone eagerly waits to hear "we fixed it".

In such cases, it's important for the developer to follow a systematic approach. This entails repeatable steps that follow a predefined pattern. Following a systematic approach will help other developers too, should they encounter a similar bug.

Methodology

In no manner do I consider myself an expert at debugging but I have developed repeatable patterns that have helped me in tracking down and fixing bugs. It’s my opinion on debugging which bears semblance to the scientific method.

Note: The majority of my experience is as a front-end developer in the webspace as such my examples would be given in that regard. However, I do believe that this approach would benefit other aspects of software engineering. More so, I'm aware that there are caveats in peculiar cases for which one or more steps in my method would not apply but my focus is on the rule and not the exceptions.

Step 1: Reproduce the error

This is a critical step and must not be overlooked. You have to be sure that a particular sequence of steps or a certain scenario causes the bug and document it. You’d need it later.

Go ahead to detail the bug using the following guide:

Describe the bug clearly
Give a detailed account of the environment
Outline precise steps to reproduce the bug
Include attachments for clarity
This is called bug reporting and an elaborate guide to writing good bug reports can be found here.

If you lack sufficient information about the bug, try to get some before you forge ahead, otherwise, you’d be flying blind.

A bug that cannot be reproduced cannot be said to have been fixed.

There might be instances where reproducing the error is impossible or painfully difficult. There are measures to put in place to aid debugging in such cases and would be discussed under the developments in debugging section. For now, move on to the next step.

For web developers, a platform like Code Sandbox is invaluable in debugging as it provides an isolated environment where the error can be reproduced reliably. No longer would we be haunted by statements like "it fails on my computer".

Step 2: Follow the evidence

Analyze the call stack and error message. Different programming languages provide a means to access the call stack in the error object. This provides a stack trace that contains information related to the failure.

Usually, the stack trace contains the following information:

file name where the error occurred
line number in the file where the error occurred
the column number in the file where the error occurred
function/class method name in which error occurred

Going through the logs is vital as stack traces can provide insight into the origin and type of the error.

It’d also be beneficial to know how to use Google. Query structure and google docs help a lot in narrowing down searches. You can learn that here.

If need be, go through documentation and test files. This should become second nature to software engineers with the inevitability of third-party software. Once, I had to figure out the functionality of a library by going through their tests because the documentation sucked.

In the case of third-party software, there'd have been other developers who've encountered this error. If so, you can short-circuit the process and skip to step 4.

However, if you're the unlucky fellow 😅 that encounters the issue first proceed to step 3.

Step 3: Develop a hypothesis

At this juncture, based on the knowledge of the systems at play as well as their interconnections, you should make an educated guess.

Mark Erikson, a Redux maintainer, outlines this as having a plan,

Understand how the code should behave first. Look at the actual behavior. You can probably make educated guesses for where things are diverging. Focus on those areas. Don't randomly tweak. Change one thing at a time and compare results.

Experience definitely helps here, but even if you’re new to the situation there’s no need to fear. Come up with an explanation according to what you currently understand. You can always revise it later.

This hypothesis can come from colleagues as well as from Q&A forums like stack overflow as well as search results from Google or tutorials from Youtube.

Step 4: Test the hypothesis

It is possible, based on prior knowledge, to jump right through by guessing the cause of failure. However, I have seen that this isn't always possible. As such any proposed solution should be applied and then validated against the steps in the bug report.

Do not be a sucker for punishment! First, try the suggestions from your search results and Stack Overflow. Especially for third-party software.

Step 5: Take action

Treat the disease and not the symptoms.

Here you can choose to refined the method of resolving the bug. This can be to refine your hypothesis based on info gotten from testing the hypothesis.

Check if the bug is a stand-alone issue or if it’s a result of underlying problems in the codebase or configuration. If you’re satisfied with the outcome of testing the hypothesis then you can commit to the fix (for example to make a pull request).

Step 6: Test and Observe

“Never allow the same bug to bite you twice.” - Steve Maguire

There's the need to be watchful as a supposed fix might introduce new bugs. Therefore, regressive testing should be carried out to determine if the bug really had been squashed.

Regression testing is a software testing practice that ensures an application still functions as expected after any code changes, updates, or improvements.

Herein lies the importance of Step 1: Reproducing the bug. You’d have no way of knowing if truly the bug has been fixed if you didn’t have procedures that cause the bug to surface.

Test with those procedures and others to confirm, and if you discover another bug,
Great! It means you caught a bug before it went into production.

Testing isn't debugging. Testing here starts with a known condition (testing whether the image shows up) while debugging starts with an unknown condition (why is the image not showing up). Another difference, although somewhat comical, is that managers would accept a test that yields no fault but not a debugging effort that yielded no solution 😅

A case study

Let’s consider a scenario where this methodology was followed.

NB: My example might seem trivial but the aim was to details a scenario where the methodology could be seen in action. Also to point out that bugs/errors might surface from little things.

I recently encountered a bug/error, where the Twitter preview image wasn’t showing up for a specific page of a website.

Step 1: Reproduce the error

The bug report can be outlined as:

Description: Twitter preview image not showing up for landing page route alone.
Environment: Twitter web and mobile
Steps to reproduce: Tweet *** link, the preview doesn’t show up.
Attachments: (excluded for this example)

Step 2: Follow the evidence

Firstly, I tried to validate the card preview and got an error.

ERROR: Fetching the page failed because the response is too large.

Step 3: Develop a hypothesis

On seeing the words “response was too large”, I checked to confirm the resolution of the image was indeed hosted on the site, it was about 1200x1200. Hmmm…seems large🤔

Hypothesis: The image is too large and twitter’s bot isn’t able to fetch it.

Step 4: Test the hypothesis

I requested for an image with smaller dimension and waited.

While waiting I happened to run across the description and noted that only one page had this issue and the same image had been used for the others. I checked the docs for Twitter’s limit on the dimension of a preview image, it was 4096x4096.

What? So the image fits within the limit?! 🤦🏾‍♂️

I didn’t bother checking if it’d be fixed in Step 5, it wouldn’t.

Back to Step 3: Develop a hypothesis

I read the error message again.

ERROR: Fetching the page failed because the response is too large.

Oh, the page itself is too large?

I checked the documentation and found that the limit for page size is 2MB. I thought that was ridiculous. No way was the page document over 2MB. However, I check the network tab for the response.

What?! 2.5MB?! How’s that possible, it’s a document?!

The site was built using React so I couldn’t check the file size directly. I had to see what the Twitter bot saw, so I went to the command line.

Wow, so the document really was 2.5MB. How so?

I went snooping around the page source (pretty printed of course) but I wasn’t sure what I was looking for. So I went to VScode and opened up the component for that page. Going through the imports I found something interesting.

The SVGs were large (not good), but that wasn’t what got to me. They were imported as ReactComponent. This meant the image would actually be rendered as svg elements. And being that size the elements would be massive.

Aha!! I found the culprit!!

Step 4: Test the hypothesis

I then switched out the imports and changed the way the images were rendered from using the svg tag to the img tag.

That's from the old import,

And the old usage,

Which is then rendered as,

To the new import,

And the new usage,

Which is then rendered as,

A simple change but this ensured the svg tag stayed out of the picture.

I could also have requested for smaller SVGs too.

Step 5: Take action

I made the PR and after some explanation it got merged into beta. I went back to the command line,

Hurray!!! 479kB!!! 🎉

Step 6: Test and observe

Went back to the Twitter card validator and confirmed that the preview image showed up. It did!!

Tests

Different types of tests include:

Unit: Verify that individual, isolated parts work as expected.
Integration: Verify that several units work together in harmony.
End-to-End(e2e): A helper robot that behaves like a user to click around the app and verify that it functions correctly. Sometimes called "functional testing" or e2e.

We're to write tests that give confidence in our software, and this presents a challenge with testing.

In reference to this, Kent C Dodds expatiates on a tweet on writing tests by Guillermo Rauch.

// Detect dark theme var iframe = document.getElementById('tweet-807626710350839808-968'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=807626710350839808&theme=dark" }

You can read about that here.

Developments in Debugging

No one likes frustration. As a result there have been advancements in debugging tools to improve the developer experience as touching tracking and fixing bugs/errors.

No one wants to be this guy.

As such tooling has been evolved to reduce the surface area for bugs to reside. Some of these developments include:

Better IDE support for debugging
Static analysis
Logging
Open telemetry
Command-line tools
Profilers
CI

Communities

In all honesty, I have found communities to be the most helpful resource when debugging. It's pacifying to know that someone else ~~shares your pain~~ has encountered a similar problem. It's even better to know that one or more solutions have been implemented.

The feeling of copy-pasting an error message and seeing several matching results from Stack Overflow is just soothing.

Software engineering as a whole has benefited greatly from the sharing of knowledge. Thereby, removing the need to reinvent the wheel.

Conclusion

Most developers would confess that it's a fool's errand to hope to write bug-free code. Rather, it's more practical to write resilient software that can be debugged more easily.

Similarly, good system designs bake in fault tolerance from the get-go. In reality, it's not if they will occur rather when will they occur. The most experienced engineers also have their demons.

It takes time and practice. You have to get better at reading error messages and Googling. But over time it gets easier and is a necessary skill to grow. Don’t allow early frustrations to keep you from trying. You’d struggle more at the beginning, don’t worry everyone does.

Everyone eventually cooks beans, but can you debug it effectively? That’s what will matter.

Hope this article helps.

Resources

Why I decided to write

Folafunmi — Sat, 05 Feb 2022 13:17:04 +0000

I made this decision in the wake of serious thought, having considered various opinions I found on the web here and here, as well as my personal and professional growth.

I've always admired writers. Their ability to construct a narrative, to limn a world entirely from static words, to communicate ideas, and to transfer knowledge amazed me. I've read genres from across the board, seems what's keenly considered as legendary and also sadly as mediocre.

I've made up my mind, what isle I would like to belong to; what quality of content I want to publish. Consequently, I can boldly make the statement that,

For every word I write, I have read ten thousand more.

To stand on the shoulders of giants, my thoughts and opinions have been shaped from years of reading opinionated as well as technical articles, cuddling jargon, and hunting down every keyword that caught my eye.

I never considered myself to be a writer but circumstance and undeniable advantages admit me into the class. Albeit with raw opinions, unrefined skills, and imposter syndrome which lay not far behind.

Writing is an art

Writing, right from the dawn of time, has been used as a medium of communication. A means to share thoughts, feelings, and ideas. To express emotions and opinions through inert words, yet springing forth living ideas.

Historically, entire civilizations, epics, and tales have been preserved by the estate of writing. The medium upon which these writings were done changed over time but the art persisted through the times emerging in various fields and cementing its place in history as an important medium of communication.

The software engineering field seems to have taken a clue from this too. RFCs are write-ups that explain a concept concisely and have led to very important parts of the modern world lending credence to technologies like TCP, HTTP, etc.

Blogging platforms like Medium, Dev.to, Hashnode emerged to aid engineers and those alike to have a means to rhyme to reason and put pen to paper. If you have an idea, it can easily be written down, publicized, vetted, and appraised by others.

In helpful communities, a critical feature is feedback. As stated by great writers alike, feedback exists as a key factor in writing, upon which that which is brilliant is regarded as so, and that which is mediocre is done the mercy of being corrected.

Of course, the keyword here is "helpful". The alternative atmosphere would lead to a hunting ground for smart alecks, an avenue for writers to be insulted, and worse of all for ideas, new or recycled, to be aborted right at its conception.

Yet, choosing to step out of the shadows, brave the storm and become vulnerable, I choose to put my thoughts on a page. As a sign of growth and a snipe to the fear of the unknown.

Plus, let's face it, haters will hate. Therefore, I adopt the Latin saying:

Illegitimi non carborundum!

Which when translated to English is,

Don't let the bastards get you down!

Reasons to write 🧐

Ordinarily, there exist several reasons to write. From a means of communication to the documentation of an action, topic, or contract. All stand as valid but my decision to write stands a mere subset of the extent of reasons given.

In making the decision to write, I considered several factors which swayed my decision to the eventual affirmative. Some of which I highlight in detail below:

1. To gain mastery 💪🏾

"Excellence is an art won by training and habituation. We do not act rightly because we have virtue or excellence, but we rather have those because we have acted rightly. We are what we repeatedly do. Excellence, then, is not an act but a habit." - Aristotle

I genuinely want to be a master communicator, to hone the skill of the explainer and be able to construct words that best describe my thought process on any subject.

Initially, I'd been worried about giving the perfect analogy for a given scenario and had not been concerned with how such an analogy would be conceived. I was focused on the end goal and not on the journey. To give an analogy, I was only keen on reaching the peak of the mountain, not considering the climb.

In the book, Mastery: The Keys to Success and Long-Term Fulfillment, George Leonard writes,

“Perhaps we'll never know how far the path can go, how much a human being can truly achieve until we realize that the ultimate reward is not a gold medal but the path itself.”

I'd been self-critical, comparing myself to the best of the best, masters in their craft, forgetting that all I needed to be was just that bit better than I was yesterday and wait for the compounding effect to run its course.

Where for a million zeros it remains zero, but a million tiny steps (in the right direction) can take you quite far.

Right now, I've decided to stay on the path of mastery and become a master by the process. To learn the rules and not just the exceptions. To put out an idea however raw it may be.

2. To better communicate ideas 📣

Great ideas deserve to be shared.

In my stint in software engineering, with the majority of my experience tilted to the front end of the web, I've come across many libraries and frameworks with newer ones surfacing every other week.

I've heard and read ideas that I agreed with and others I didn't. Writing would help me better communicate my understanding of such ideas to my teammates.

Software Engineering is teamwork and an effective team is one that can share ideas openly and collaborate.

In the past, there were scenarios I'd tried to explain a concept to a teammate with hopes it'd get adopted, only to be met with awkward silence.

Similarly, I'd tried to explain an architectural change that I considered beneficial only to be met with the doubtful intro, "So you're saying..."

In line with this, I recently encountered an article by Shawn "Swyx" Wang on when to consider blogging about an idea, which he called the three-strikes rule. The third time the charm.

The 3rd time we reference an idea in a conversation, we have to blog about it.

Swyx further explains,

By the third time you refer to an idea, it’s no longer a coincidence. It’s a pattern. You’re increasingly likely to refer to it again in the future. It’s marinated in your head for a bit, and you’ve likely gained some experience explaining it to others. It’s also not so old that it may have lost relevance.

Writings also show that you know your stuff. Signal to employers that you're a good written communicator and upfront presents your views about certain technologies.

In my experience and research, even having opposing opinions on a particular technology will not deter would-be employers as a good argument would prove diligence to detail.

3. Exposure to opportunities 🎉

It's undeniable; good writing deserves some accolades.

Asides from the obvious clout that comes with putting out quality pieces, writing puts your knowledge out in front of recruiters and possible employers.

Essentially, by writing, I want to create my own luck. Be it in jobs, speaking engagements, or community clout.

For example, consider the following:

Upon creating a newsletter and being exposed, this tweet led Sebastien Lorber to get hired to work on Docusaurus at Meta(Facebook)
Thorsten Lünborg joined the Vue core team because of his work on responding on their community forum, without writing contributing to the codebase.

Just to name a few.

I've found that recruiters and employers want to reach out. Everyone wants the best and brightest working for them. This study tells of tech talent shortage.

This shows that opportunities abound, but if I never put myself out there I won't see any of them.

4. Knowledge reinforcement 🧠

A good teacher is firstly a good student.

To properly communicate a concept takes understanding the concept to relatively fine details. For example, writing a beginner's tutorial means you have to explain key concepts without reliance on jargon that might abstract away sections in which your understanding is lacking.

In an interview I did, I was asked what a bundler was. I knew of Webpack, Rollup, Parcel, Snowpack, and Vite. Yet I couldn't give a simple definition for what a bundler was without repeating the word "bundle"😅.

Writing forces you to fill in gaps in your understanding, nudging you towards better understanding of the concept. The more you understand, the easier it is for you to communicate simply without having to respond to all questions with "it depends"😜.

Feedback from the community also presents another learning route. Good explanations will be praised and bad explanations will be ~~shredded~~ corrected. All in all, it serves as a learning experience.

As Swyx shares while on a podcast with Kent C. Dodds,

You can learn so much on the internet for the low, low price of your ego.

5. Monetary benefits 🤑

Writing aids the knowledge of the writer, but it also provides knowledge for its reader. Therefore, it qualifies as a service that can be rendered and as such can be monetized.

Several platforms exist that pay developers for composing articles and or tutorials. A list of such writer programs can be found at here.

It's exciting to be paid for sharing in knowledge, and this incentive makes developers(myself included) inclined to learn more and in turn write better software.

This provides nice benefits as the community at large is uplifted. It spurs better articles to be written just as awards such as the Emmys and Oscars spurred better movies being made.

6. Preserve a snapshot of my growth 📈

Recently, I had to explain a concept to a new developer, it didn't go well. I noticed that I used much more technical jargon than if I'd been asked a few years ago.

I'd forgotten how I learned the concept as such my delivery was less effective. I had become more advanced and as such had left behind heuristics and simple illustrations that'd helped me understand. This is sometimes referred to as the curse of knowledge.

I want to change this. My writing would be a preserved state of my knowledge per time and would serve to help myself as well as other developers at that stage in their growth and career.

7. Monitor my growth 👀

Writing will provide insight into how my understanding evolves. How references and examples changed with time. My personal source of observability.

This would inform of key metrics like:

Showing topics for which my understanding is subpar or lacking,
Providing an avenue to see how best to structure explanations
Knowing what ideas seem to gain traction?

All provided alongside input from the community.

Conclusion 🏁

In hindsight, I wish I'd taken this decision sooner. The benefits far outweigh the risks of not being good enough.

However, late definitely beats never. And to those who are or ever hope to be writers, my advice is, Just write!