All that said, for the purposes of this article, I’m a front-end web developer who has spent their 7 year career building a product for testing accessibility of mobile apps. I’d like to give you — a front-end web developer, who may not have mobile experience — a quick run-through to the mobile apps built with web technologies landscape.

What is a hybrid mobile app?

As a front-end web developer, we’re used to our HTML content being rendered in the browser whether it’s being generated by a framework like React or Vue, or being served from an HTML file.

The mobile app world is a quite different story where the rendered content doesn’t follow agreed upon and maintained guidance, like web standards. For example, Apple and Google completely govern their own native tech stacks for building iOS and Android apps respectively. Those tech stacks create elements on the screen called Views. Then there’s the 3rd party cross-platform frameworks such as React Native, .NET MAUI (previously Xamarin), Flutter. These all allow you to build both an Android and iOS app, and sometimes a web and/or desktop app, from a single code base, but they each do that process a bit differently to each other.

React Native and .NET MAUI generate Views that mimic or are very similar to native mobile Views. They are designed to use technologies familiar to React and .NET developers: TypeScript/JavaScript with CSS and C# with XAML. Flutter is in it’s own league because it uses Dart to build Widgets that are rendered by it’s own graphics engine, bypassing the concept of native Views entirely.

While all these frameworks are often referred to in discussions of hybrid mobile apps, I prefer to distinguish them as cross-platform or code-once frameworks and reserve hybrid to specifically describe the subset of apps which present a blend of web and mobile content.

We’ll define a hybrid mobile app as follows: “A mobile app which primarily features HTML content rendered in WebViews alongside some native mobile content or functionality”

A WebView is a native mobile View which acts as an embedded web browser component to render HTML content inside of it instead of native controls like sliders or buttons. The mobile browser apps such as Safari and Chrome utilize a WebView as the main component with the addition of peripherals like the URL bar and back button. That’s a route to web developers to feel empowered rather than hindered.

The cross-platform framework names I haven’t mentioned yet are by this definition, hybrid app development frameworks: Ionic, Capacitor, Cordova/PhoneGap. It’s a bit complicated to untangle what each framework is and does, so we’ll dive into that in the next section.

Hybrid App Development Frameworks

Let’s start by talking about Apache Cordova/Adobe PhoneGap, since it’s the original hybrid framework, created back in 2009. Here’s the overview statement on the Cordova documentation site:

Apache Cordova is an open-source mobile development framework. It allows you to use standard web technologies - HTML5, CSS3, and JavaScript for cross-platform development. Applications execute within wrappers targeted to each platform, and rely on standards-compliant API bindings to access each device's capabilities such as sensors, data, network status, etc.

There’s some history with the project being acquired by Adobe, including in an offering called PhoneGap, but that was discontinued in 2020. Cordova is still alive and actively maintained, but you may see references to PhoneGap while looking for hybrid app development topics.

Cordova isn’t a UI framework, but rather a runtime environment for your web app on a mobile device. This means you could take an existing web app that you built with your favorite front-end tools and package it up to render inside a WebView in both an iOS and Android app. Now there’s quite a lot of reasons why you wouldn’t want to to that, but let’s cover the other runtime frameworks first.

Capacitor is a newer option for a hybrid framework to ship your web content wrapped in a mobile app, developed in 2018 as a modern alternative to Cordova/PhoneGap. The intro on the Capacitor docs site reads:

Capacitor is a cross-platform native runtime that makes it easy to build performant mobile applications that run natively on iOS, Android, and more using modern web tooling. Representing the next evolution of Hybrid apps, Capacitor creates Web Native apps, providing a modern native container approach for teams who want to build web-first without sacrificing full access to native SDKs when they need it.

What separates Capacitor from Cordova is that it’s built and maintained by the Ionic framework team. While the former are both native runtime frameworks, Ionic is actually a front-end UI framework for hybrid apps. Ionic can be used with both Cordova and Capacitor, but Capacitor is designed specifically to work in conjunction with Ionic. Here’s the introduction on the Ionic docs site:

Ionic is an open source UI toolkit for building performant, high-quality mobile apps using web technologies — HTML, CSS, and JavaScript — with integrations for popular frameworks like Angular, React, and Vue.

Now we’re finally in the front-end developer’s domain! Before we dig into it too much, let’s go over some important design concepts for hybrid apps.

Designing a Hybrid App

Like I said earlier, you can use either Capacitor or Cordova, to wrap your existing web front-end into a WebView inside a mobile app, but there are some considerations to make since content built for the web is structured quite differently than content built for mobile.

For example, a common pattern in web apps is a single page with lot of content that can be scrolled to or jumped to with links/landmarks. Whereas, in a mobile app, content is often better presented in small chunks with navigation through a flow of multiple screens. Mobile app user experience is built around the fact that the content is displayed in a small viewport, but the web was originally built for desktop and adapted to suite mobile devices as their browser became more and more capable.

I’ve spoke with folks in the industry that claim most users can’t tell whether an app is presenting native content or a WebView, but I find that hard to believe. Maybe I’m biased because I know too much about both, but it says a lot if a user downloads your app instead of visiting your website since there’s a much higher barrier to entry. They likely took the extra effort to open the App Store or Play Store and remember or find their account password to install your app because they want a native mobile experience. One thing I can confidently say is that a screen reader user will definitely know the difference since it will literally announce WebView when they hit one, and the landmarks are different, like the fact that Android only has 1 level of heading compared to the 6 levels in HTML <h1>-<h6>.

So all that said, how do you build a stellar hybrid app user experience? By using the concepts of responsive and mobile-first web design of course!

Figma has a wonderful article which covers the topic focusing on websites, but can be applied to hybrid apps as well:

“Mobile-first website design flips the traditional Web development approach. Instead of starting with a desktop layout and scaling down, you begin with a mobile website design. This approach prioritizes smaller screens, slower Internet connections, and the needs of on-the-go users.”

Another layer to mobile-first design is that Android and iOS each have a look and feel uniquely branded to Google and Apple. We’ve established that the web and mobile ecosystems are very different, but iOS and Android are almost just as different too. So you’re faced with some choices: design 2 experiences, pick iOS or Android and ship it to the other platform anyways, or roll your own that ideally caters to both. Trust me, I’ve seen it all, and my least favorite is an Android styled app shipped to iOS

While companies/brands love the idea of a consistent experience across platforms, users prefer your app to look behave like the rest on their device do. A lot of factors go into choosing a design pattern for an app such as target audience, development resource capacity, etc, so let’s set that aside and finally dig into building the bits

Building a Hybrid app Front-end

I want to bring us back to Ionic because its UI component library allowing front-end developers to build seamless experiences for both iOS and Android from a single codebase using technologies you know and love. It’s full of mobile-first components which render on iOS matching Apple’s aesthetics and on Android matching Material Design, Google’s open-source design system. These components are available in Angular, React, Vue, and plain ole JavaScript with beautiful interactive demos on the documentation site.

Let’s take a closer look at a Toggle component which is commonly used in the settings of a mobile app. In React, you import the IonToggle from Ionic’s library and use it just like you would any component for a web-first app.

import React from 'react';
import { IonToggle } from '@ionic/react';

function Example() {
  return (
    <>
      <IonToggle>Default Toggle</IonToggle>
      <IonToggle checked={true}>Checked Toggle</IonToggle>
      <IonToggle disabled={true}>Disabled Toggle</IonToggle>
      <IonToggle checked={true} disabled={true}>
        Disabled Checked Toggle
      </IonToggle>
    </>
  );
}
export default Example;

On iOS, you’ll get 4 toggles in Apple’s well known style.

For Android, the recognisable material design elements are used.

All of the Ionic components can be styled with CSS custom properties and standard CSS, so you can achieve that consistent experience across platforms by modifying the iOS and Android styles slightly or make them match exactly.

Accessibility

As digital accessibility advocate, I can’t write an article without touching on the topic. I think of accessibility in 2 realms: compliance and user experience.

The realm of compliance focuses on building digital content that adheres to the Web Content Accessibility Guidelines (WCAG). These are the guidelines which legislature around the world reference, and large enterprises strive to meet. There isn’t a similar de facto standard for mobile app accessibility despite the immense difference in how content is rendered, but instead, there’s only adaptations and interpretations of WCAG for mobile.

On the other hand, Apple and Google put emphasis on accessibility through the user experience of the iOS and Android ecosystems. There’s Apple’s Human Interface Guidelines with a foundations section dedicated to accessibility, and the Android Developer guide on accessibility.

There’s no straightforward way to make a perfectly accessible app today, but that’s ok! Just as with most things in life, it’s about finding the right balance. On the compliance side, that WebView inside a mobile app is rendering HTML, so WCAG criteria can be directly applied, so there’s certainly advantages for hybrid apps in that regard. However, accessibility compliance doesn’t always equate to a high quality user experience, which is where the advice from Apple and Google come into play.

Wrapping up

While the world of mobile apps can be intimidating to a front-end web developer, it’s certainly worth exploring, even to be aware of the landscape for if you find yourself in a project in the future.

With that in mind, I hope this article is a useful introduction and shows that you don’t have to step completely out of your comfort zone thanks to the concept of hybrid mobile apps, providing a very familiar experience. It makes them a useful jumping off point!

I've gone from individual contributor to manager to director, and the most consistent mistake I see is people treating management as the "next rung" instead of a fundamentally different job. We treat someone's ability to manage others as a reflection of their worth, yet we rarely teach what management actually requires. That gap does real damage — both to the people who take the role for the wrong reasons and to the people who end up reporting to them.

When someone asks me whether they should become a manager, I ask if they want responsibility for outcomes you don't directly control, or are they looking for validation, stability, or a raise? Those are not the same thing. At 18F, managers weren't paid more than individual contributors. That stripped away the usual incentives and made intent visible very quickly. The people who stepped into management because they cared about others' growth thrived or wanted to take the next path on their career progression. There are pros and cons to a relatively “flat” org structure like this, but I found it useful.

In one of my early jobs, I had a senior director who trusted me with leading an org-wide project. Not only was I put in charge, they invited me to leadership meetings and let me speak.  That experience shaped my career in ways I could not have anticipated at the time. Someone with positional authority chose to see me, pulled me into the conversation, and made my perspective matter. That's the job. Being seen often equates with being invited, and managers who understand this spend their energy opening doors, not guarding them can develop talent.

Deciding to give up everyday responsibility on design choices is not an easy one. I miss front-line delivery work and might choose it in my next role. There’s nothing like actually working on the problems in front of you, rather than just triaging or dealing with escalations. I’ve had front-end designers worry about losing their craft, and they're right to. You will write less code.

If your identity is tightly bound to being the person who solves the hardest technical problem, management will feel like erosion. The increasing number of “player-coach” roles that let designers keep designing while managing are the best of both worlds, but it takes a mindset to both focus on delivering artifacts while also coaching someone who may or may not be on your same project.

A few years ago, I took over coaching a new high school tennis team. Early into my tenure, I would notice the players looking at me for validation during crucial moments of the match. This didn’t happen with my old teams, but I realized what I needed to do. One of the things I emphasize through the pre-season and our practices is trust. Not just from me, but the entire coaching staff. I want the players to understand that they’ve been given the tools to make decisions out on the court. Sometimes, they’ll make the right ones. Other times, it won’t work, but by reminding them that they get to make the call because you’re the one seeing the ball is a lesson that transcends sports. As a director, I want my managers to instill this into their teams and same for individual contributors, because it’s crucial that people learn it for themselves. Few things are more rewarding than seeing someone grow into their craft and having a hand in that.

It's also worth saying plainly: you can grow without managing people. Leadership is not synonymous with line management. I've met outstanding principal designers who influence direction, mentor deeply, and carry real organizational weight without ever owning performance reviews. Some of my favorite designers are professionals I knew we could trust with almost any task in their toolbox; folks that delight clients and their colleagues alike. With senior designers and principals, my question is just ensuring they’re staying engaged and challenged by the work. Coaching and mentoring are non-managerial ways for them to contribute without having to “manage” someone.

On the flip side, I've watched senior designers become the glue — mentoring, stabilizing, unblocking — and then stall because none of that work was owned or legible. If you don't claim authority somewhere, the organization will take the value and flatten the role. This can be one of the ways that elevating into a leadership role can be a way to build yourself into a growth role in a company where you’ve spent a long time. It’s also where considering opportunities elsewhere are a chance to reframe how people see you; new jobs with a different title can give you a chance to reinvent yourself.

If you're considering management, be honest with yourself. If what energizes you is coaching, advocating, and shaping how work happens beyond your own hands, then management can be deeply rewarding. If what energizes you is making things and being close to the work, protect that instinct. The field needs senior practitioners just as much as it needs good managers.

Dear {'{Boss}'},

I have found a new design course called Mindful Design that I believe will completely transform our ability to produce design that actually works well for our users/customers. The course doesn't teach hacks and deceptive patterns, but instead teaches us how the human brain actually works, so our design skills will evolve to work with people, rather than against them. I think that will benefit us all in the long term.

I also think the course will be useful for our front-end developers because the instructor, Scott Riley, covers practical design skills from scratch. Our developers are not designers, but having a broader understanding of practical design and how the human brain works will improve their skillset and output a lot. It’ll also help them work more effectively and efficiently with our designers, who themselves, will always benefit from re-learning the fundamentals too.

The course has nearly 20 hours of video content and around 15-30 hours of practical exercises. I thought doing those exercises as a team will be an efficient way for us all to skill up at the same time. The course is written off the back of a really successful book, also called Mindful Design, which has helped countless teams already, including the BBC, Stanford, GitLab and Zeroheight.

If you would like to look over all the course curriculum you can find it here. Certificates are also available upon completion of the course should we want them, along with LinkedIn certifications.

I am asking that we allocate some of our training budget for this course if possible. Bulk discounts are available, should we want the team to go through this together.

Thanks!

{'{Your Name}'}

If you are a boss reading this, investing in your staff’s training is really valuable in both improving your company’s output, but also making your staff feel rightly valued, supported and invested in. It’s something I don’t even hesitate to do for the staff that work here. Staff training spend is also tax-deductible and often incentivised in various countries.

If you have any questions about bulk licences or anything related to Mindful Design, we’re ready to help at support@piccalil.li.

Check out Mindful Design

After 20+ years, the things that have the most effect on my day-to-day aren’t that I learned how to model my OOP systems using UML or know what a Monad is. Instead, it’s a bunch of (sometimes pithy) statements that fall under the umbrella of “programming principles”.

Now, there are many, many programming principles out there. Some are more like “laws” that describe how systems and people behave (like Hofstadter’s law: It always takes longer than you expect, even when you take into account Hofstadter’s law.) and while those are useful in broader contexts, I don’t find them that actionable when I want to write “good code”.

In this article, I go over the rules-of-thumb that help me write better code as I’m writing code. They don’t require me to write out my entire system before they’re useful, they just help me make better decisions as I go.

From pithy statements to actual useful habits

When you’re just starting out, at some point someone is going to point at your code and say “Premature optimisation is the root of all evil”. That sounds super serious, but also kind of odd.

Optimisation is something that’s good while “premature” usually isn’t. The big problem here is that you’ve now been told that what you’re doing is evil, but you don’t actually know what to do next. Avoiding premature optimisation is a good programming principle, but it doesn’t actually help you write better code.

A helpful senior developer might help you out there and explain You Aren’t Gonna Need It (YAGNI). This is another good programming principle that warns you against writing code that you anticipate needing in the future, but don’t need now. The reason you’re not going to need it is that between not needing it now and the planned future where you would need it, the plans are likely to change in such a way that you actually won’t need it after all. It’s better then to write things “just in time”, when you actually need them.

However, you’ll also be asked to follow the Don’t Repeat Yourself (DRY) principle. Don’t write code that does the same thing in multiple places, because that’s hard to maintain. If you listen to this, all you’d ever do is consolidate code that does the same thing into a single function or module, and call that from multiple places.

All of these acronyms are generally good advice. If you’re building out some functionality, it makes sense to anticipate the future at least somewhat, right? It makes sense that if you need that logic in multiple (future) situations, to optimise or refactor that already. That way you can make sure the current code takes that into account, and you don’t have to write it twice.

YAGNI and premature optimisation are usually brought up because rather than writing the code for the functionality you need now, you start writing code for the general system that offers the functionality you need now, but also the functionality you might need in the future. It means that you end up writing a lot more code, adding a lot more complexity and taking much longer than your senior co-workers.

These principles don’t actually help you as you write code. You could try leaving out random parts that you think you need later, but it would be much nicer to have a principle that helps you know what to leave out.

Enter the “rule of three” — the actually actionable, pragmatic principle that elegantly combines how you should be thinking about YAGNI, DRY and premature optimisation.

The rule of three states that you should only refactor (or optimise) code once you’ve written the same code three times. The first time you write the code, you just write it. It does the thing and only the thing. The second time you see that you need the same code again, you …literally copy-and-paste it and make the few changed you need. Then when you have to do that a third time, only then do you look at the now three implementations you have and generalise them into a single implementation that can handle all three cases.

The concept here is that, once you’ve written that code three times, you have an understanding of what general functionality you actually need, and what parts can be simplified and optimised. After three implementations you know what “level of abstraction” you need, and you can make sure that the generalised implementation actually works for all three cases. I “apply” this principle all the time because it’s so easy (I can count to three!) and it helps me avoid over-engineering right as I’m about to.

When you read up on programming principles, it’s easy to find Laws and Rules that sound very serious, but that require a lot of context to actually apply. I hope that from the example above you can see how getting from the general “premature optimisation is the root of all evil” to the specific “rule of three” has a much bigger impact on your day-to-day coding, and the quality of the code you write.

Writing the right thing

Lets now zoom in to that first implementation. It can be very tempting to optimise the code right from the start, making sure each line is fast and efficient. Often times though, the fast and efficient code is not the most readable code.

When it comes to writing code, we don’t actually spend that much time writing. Instead, we spend time reading the code we just wrote, or that already exists and reasoning about it to decide what to write next. So the easier it is to read and reason about the code, the faster we can write the right code. Code that’s fast and optimized is great, but if it’s hard to read and reason about, it will slow us down in the long run.

We want it all though: we want to write correct code fast and we want to write code that is fast. So how do we go about that? How do we choose?

Here, I like to apply another principle: “Make it work, make it right, make it fast”, which is attributed to Kent Beck, the inventor of Extreme Programming.

At any point during your coding you can look at your code and ask yourself: does it work? If the answer is no, then you focus on making the code work. You don’t care about anything else. Just make it work. If it works: great!

But things that work aren’t always doing the right thing, so next you ask: is is right? As long as your code isn’t right (it doesn’t behave the way you want to, it makes tests fail, it doesn’t accept the input you give it), you focus on making sure that it works right. Only then, when your code works and your code is right, do you ask: is it fast? If it’s not fast enough, you can now focus on making it fast.

This helps you prioritise your efforts. It’s a waste of time optimising code that doesn’t work yet, or that does the wrong thing. You’ll have to rewrite it anyway and then the optimisation is gone too. If your code doesn’t even work yet, there’s no need to worry about whether or not the broken code is right. It’s broken so you need to make it work before you can do anything useful.

What makes this principle so useful is that you can apply it at any time simply by looking at (the behaviour of) your code. You don’t need to plan anything out. You can just ask yourself these three questions, in order, and focus on the one that matters right now. You can forget everything else until it’s relevant.

If you squint, you realise that this is actually the same principle as the rule of three, just applied to a different aspect of programming. Both help you focus on the task you have right now, and avoid getting distracted by other concerns that aren’t relevant yet.

The crappy first version

There’s a bunch of principles that help you get into the mindset of writing that first implementation. Principles in this vein tell you to throw away your first implementation, or to build the best simple system for now and, actually, “make it work” in the rule of three is this exact same idea.

There’s a more high-brow version of this too called Gall’s Law, which states that “a complex system that works is invariably found to have evolved from a simple system that worked.”

The idea here is that if you try to account for all things from the start, the thing you end up with doesn’t actually work. An example of this is every “full rewrite” ever that ended up worse than the original and took significantly longer than planned. (this, of course, also has a name: Second-system effect.)

Reading all of that, you might be reminded of Keep It Simple, Stupid (KISS). The problem with KISS though is that if you’re building something to help people complete a task, some complexity might be unavoidable and then, KISS has no answers for you. Some things aren’t simple. Gall’s Law, on the other hand, at least tells you that the complex can exist if you’re honest about starting simple and iterating towards your goal.

Still, that’s not very actionable as you’re writing code, so lets see if we can find some principles that do help you write better code as you’re writing code.

Idempotency

As much as possible, the functions I write are idempotent. That’s a big word isn’t it? All it really means is that a function always does the same thing when given the same arguments. That doesn’t sound groundbreaking, but it actually has pretty big implications for how easy it is to reason about your code.

If you have a function that is idempotent, you can call it as many times with the same argument and it will always return the same result. For example, getting the length of a string is idempotent. No matter how many times you call "hello".length, it will always return 5. If you know the function is idempotent, you don’t have to worry it secretly returns a new string or read a variable from elsewhere in your code. Same arguments in, same result out.

A function that is idempotent can still have side effects as long as those are also idempotent: changing global state or a database entry can be idempotent as long as calling the function more than once always results in the same value being set.

When that’s not the case, calling a function twice (due to a user double-clicking, or a servers retry-logic on a flaky connection) might change the resulting value. That makes reasoning about your code much harder. If you find you need a side-effect, you can split that off into its own function and then make that idempotent. Rather than one larger function, you have two smaller functions that each do one thing.

You can treat idempotent functions like black boxes that let you “forget” the implementation details while you reason about your larger system. It’s like a brain shortcut that makes it easier to reason at a higher level. The function always does the same thing, so you can collapse it into a single step in your mind.

Single responsibility principle

Related to idempotency is the Single Responsibility Principle. This principle states that a function (or module, or class) should have “only one reason to change.”

In practice, this means that there should be one function that takes care of one aspect of your system. A nice example here is using an Object-Relational Mapping (ORM) to handle all your database access. The ORM module is responsible for talking to the database and the rest of your code should have no idea how that works. If you ever need to change how you talk to the database, you need to update your ORM and no other part of your code.

Again, this lets you collapse parts of the system as you reason about it. You don’t need to know how it constructs SQL queries. It’s not the responsibility of the code you’re working on right now. You can just treat an ORM like a black box that does database access for you.

You also see the Single Responsibility Principle described as “a function/module/class should only have one reason to exist.” If that single reason disappears, you should be able to remove that function/module/class entirely. If you switch to a different database and need a new ORM for example, the old one should be completely removable.

What often happens though, is that your ORM grows in functionality: it doesn’t just fetch data from the database, it also mangles that into a specific format that the rest of your code expects. Now, if you want to switch databases, you also need to update all the code that depends on that specific data format. Your ORM has multiple reasons to change, and that makes it harder to reason about.

Instead, you should have one module that only handles getting data from the DB, and another module that only handles data formatting. Now each module has a single responsibility, and you can change (or delete!) one without affecting the other: that’s the single responsibility principle in action.

A small trick to check for single responsibility is to describe what a function/module/class does in a single sentence. If you find yourself saying “and”, then it probably has multiple responsibilities and should be split up.

One level of abstraction

Related to the single responsibility principle is the idea that a function shouldn’t just do one thing, but also only operate at one level of abstraction. The phrase, “level of abstraction” is in itself quite an abstract concept, if you pardon me the overloading of the term. What it means is that when you read through the code in a function, all the operations should be at the same level of detail.

For example, consider this function:

async function processUsers() {
  const users = await database.fetchAllUsers();

  users.forEach((user) => {
    if (user.isActive) {
      sendEmail(user.email, "Hello active user!");
    }
  });
}

In this function, we have three levels of abstraction:

1. Fetching data from the database (database.fetchAllUsers()).
2. Loop over all the users and filter them to only the active ones (if (user.isActive)).
3. Performing an action based on that data (sendEmail(...)).

Not only do you have to use a lot of “and” to describe this function — it connects to the database to get users and filters them and sends emails only to the filtered users — but you also have to think about three different levels of detail when reasoning about this function: the database, active users and email sending. In real-world code, this might additionally have a bunch more await, validation and error handling.

As you read the function, the thing you’re focused on keeps shifting, making it harder to follow along. For example, first the function is about getting all users, then it’s about filtering them, then it’s about sending emails to those filtered users only.

Some things you can look out for that indicate multiple levels of abstraction:

• Multiple “and” when describing what the function does.
• Multiple loops or iterations over data.
• Mixing “low-level” operations (like database access) with business logic.

If you split this up, you can have three functions that each operating at a single level of abstraction:

async function getActiveUsers() {
  const users = await database.fetchAllUsers();
  return users.filter((user) => user.isActive);
}

function sendEmailsToUsers(users) {
  users.forEach((user) => {
    sendEmail(user.email, "Hello active user!");
  });
}

function processUsers() {
  const activeUsers = getActiveUsers();
  sendEmailsToUsers(activeUsers);
}

The getActiveUsers function only deals with fetching and filtering users to those that are active, the sendEmailsToUsers function only deals with sending emails, and theprocessUsers function gets all the active users and then emails all of them. Each function is easier to understand because it only deals with one level of abstraction, and you can reason about each part separately.

Notice how in the refactored version, sendEmailsToUsers doesn’t care where the users come from or what their state is. It just sends emails to the users it has been given. Each function has a single responsibility and operates at a single level of abstraction.

Are they all the same thing?

At this point, you might have noticed that a lot of these principles are related, and that’s because, to butcher a classic:

All good code is alike; each bad code is bad in its own way.

— Tolstoy (if he was a software engineer)

Good code is easy to reason about and things are easy to reason about when it’s clear what each part does. It’s also clear how the parts relate to each other, so all these principles highlight different aspects of writing code that’s easy to reason about.

On the flip side, it can be hard to figure out why some code is bad. Is it because it has multiple responsibilities? Is it optimised but incorrect? Does it take you on a tour of multiple levels of abstraction as you read it line-by-line? Does it do extra things that you aren’t sure what for? All of these things make bad code so hard to work with.

It’s much easier to end up with good code by (dogmatically) sticking to the principles above than it is to have bad code and make it good again.

Next time you’re writing a new function, I hope you catch yourself thinking about these principles, that you stop yourself from optimising code that doesn’t work yet, that you make sure each function only does one thing and that you keep yourself from designing complex systems before you have a simple system that works. Good luck!

Bibliography and further reading

Like I said, I learned all this stuff on the fly. Here are some of the resources that helped me along the way:

• Refactoring by Martin Fowler. This classic book has a JavaScript edition and though a lot of the code has a distinct Java flavour, the principles are universal.
• Making impossible states impossible by Richard Feldman. A great talk about modelling data structures to make reasoning about your code easier. Though the focus is on data structures and less about business logic like this article, I apply rules from this talk on a nearly daily basis.
• Make It Work Make It Right Make It Fast on the C2 wiki, attributing the quote to Kent Beck.
• Software Design Principles: Single Level of Abstraction
• hacker-laws.com is a collection of programming principles, laws and rules.

Dear {{Boss}},

I have found a JavaScript course that I believe will elevate our team’s knowledge of how the language really works, which in turn, will improve the quality of the JavaScript code we produce, day-to-day. I also think a deeper knowledge of the language will reduce our technical debt levels and also reduce bugs.

The course takes around 15-30 hours to complete, based on an average reading speed and it will also be a useful reference guide for us in the long term too.

JavaScript for Everyone was written by Mat Marquis who has written industry leading courses and books already. He was also part of the jQuery team, a member of the W3C Responsive Issues Community Group and an editor of the HTML specification. In short, he knows his stuff and his material is incredibly trustworthy with all of that experience.

If you would like to look over all the lessons you can find them here. Certificates are also available upon completion of the course should we want them, along with LinkedIn certifications.

I am asking that we allocate some of our training budget for this course and bulk discounts are available should we want the team to go through this together.

Thanks!

{{Your Name}}

If you are a boss reading this, investing in your staff’s training is really valuable in both improving your company’s output, but also making your staff feel rightly valued, supported and invested in. It’s something I don’t even hesitate to do for the staff that work here. Staff training spend is also tax-deductible and often incentivised in various countries.

If you have any questions about bulk licences or anything related to JavaScript for Everyone, we’re ready to help at support@piccalil.li.