![wide: Sunset in Austin. &copy; 2021 John Apostol](hero.jpg)

After a career of writing software for 7 years, I accepted the responsibility of leading my first engineering team.

As a newly minted engineering manager, it was my job to enact the process changes and efficiency tweaks I had already been advocating for. I could pave the way for useful cross-team guilds. I would get more face time with our engineers to understand their motivations.

Becoming an engineering manager felt like an additive to what I had been doing. There were a lot of new tools at my disposal; and I was happy to use them. I greedily filled my cup of knowledge as I embraced uncharted territory.

## I didn't expect to lose my ability to write code
I was sure I could still devote at least a third of my time to reading and writing code. It would be possible to stay up to date with our codebase, as long as I put the effort in. I was confident I could balance with one foot in both worlds.

To that end, I scheduled myself a monthly recurring "code day" clear of meetings. There were a few product tickets I self-assigned, small ones that wouldn't be missed either way. I told the team that I was doing this to keep up with them. As a way to maintain sympathy with the development process. Below the surface, I was mostly doing this to maintain my skills.

I compared myself with other managers; both at that time and from earlier in my career. Specifically, I was comparing our technical skills. Were others maintaining their technical edge alongside the teams they were cultivating?

![center: Climbing the steps of the Fushimi Inari Taisha shrine in Kyoto, Japan. &copy; 2021 John Apostol](inari.jpg)

Some senior managers still wrote code as a form of stress relief. Other managers, I remember, wrote code because there just weren't enough developers otherwise.

> Like some sort of secret weapon hidden behind Jira tickets in the backlog.

Others didn't write code. They were people leaders, project managers and partners across the organization. They greased the wheels and filled in the blanks so the dev teams could keep moving.

A few people had proudly said they could always get their hands dirty&mdash; if they needed to. Like some sort of secret weapon hidden behind Jira tickets in the backlog.

The first manager I had didn't let go of his technical side. He burned both ends of the candle; hustling to make sales for the company he built, while foregoing sleep and rest to make designs, and write code for clients' websites and emails.

He would take me aside and say, "John, we eat what we kill." We were lionesses hunting for the pride. We needed to hustle to make things happen. He would say this with bags under his eyes from pulling an all-nighter. I emulated him a few times, burning out with regularity every few months.

---

## The first year
My attitude when I first started managing a team was that I should be doing doing more than 100%. Managing the team day-to-day was an addition on top of what I did as a software engineer. I was striving to be the technical lead and the manager. My motivations were fear and safety.

I was good at writing code. I was a technical leader on the team, at least. I was afraid that if I wasn't writing code, things weren't going to get 'done right'. I was afraid of my team failing; and so I was reaching for the methods I knew best.

My first year as a manager was tumultuous. I couldn't find balance between what I needed to do and what I desired to do. I spent lots of time reading code reviews. I stole moments to write unit tests. I joined in the dev chatter about the latest trends in open source.

My cup was often running over and I was slipping in the puddles.

![wide: Suspended above sulfur vents on Mt. Ōwakudani in Hakone, Japan. &copy; 2021 John Apostol](sulfur.jpg)

---

## 2 teams, no time for code
There was a turning point when I picked up a second team to manage.

A colleague was having a baby and would be on parental leave. I was craving an opportunity like this to test and grow my capabilities as a manager. I felt I could manage two sets of priorities, two business stakeholders, and two teams of engineers.

I also knew I had to drop code altogether in order to make it work. I figured it was a temporary thing, until I went back to managing one team.

> There was no discernable dip in quality. It was going up, actually.

Honestly, it was surprisingly easy to avoid writing code cold turkey. My mind was filled with other logistical puzzles, and I never had time to entertain a line of code. The new team's codebase was fresh and unfamiliar. It would be difficult to ramp myself up to become an efficient code contributor. My original team had plenty of experience together, and needed project guidance, not technical help. Everything was more important than me writing code.

To no one's surprise, **features were still shipping**. Code was being reviewed. There was no discernable dip in quality. It was going up, actually.

It was stressful managing two teams. I wouldn't be able to keep that up for a year. That said, it was freeing to step away from my code editor.

In time, I separated from my first team and started managing the second team full-time. I had successfully removed myself from writing code at this point.

I repeated to my team what I knew was true, "You're the experts of our code, let me know how I can support you." Every now and then I would slip with a technical assumption. The devs would humble my thinking with their observations and plans for our work. They have my trust.

---

## I'm not the secret weapon
2 years into leading developers, I haven't lost my ability to write code. But it's different now.

![center: Alongside my wonderful colleagues at a STEM career fair at Texas State University. &copy; 2021 John Apostol](txs.jpg)

I've welcomed the overall shift, because it's allowed me to achieve balance and become a better manager and mentor overall.

My default way of approaching a software problem is as a system of possibilities, anchored to developers who will ultimately find the most pragmatic solution. All I have to do is bring the problem and surround it with context. I have a vibrant team of thoughtful software developers who are the experts.

Every now and then I may dabble in an internal tool to improve the developer experience. I'll forget some syntax here or there, and have to spend more time reading documentation to get back up to speed.

I still read a few code reviews to see how the team is collaborating, but not to stroke my ego as I did before. I try stay out of technical discussions, opting to tag a developer in my place. I've also changed my monthly recurring "code day" to a "docs day", where I read and write documentation, mostly about our team processes.

Each software project is an opportunity to hone our skills. Formerly, as a software engineer, I felt that opportunity knocking every sprint. As an engineering manager, I'm happy to do the knocking.

Letting Go of Code to Find Growth

![wide](hero.jpg)

Redux is a popular state management library for JavaScript apps that is routinely paired with frameworks like React or Angular. What follows is an explanation of how I’ve used Redux to make a production vanilla JS app more maintainable.

I’m hoping this is useful for anyone out there who is looking for a real-world Redux + vanilla JS example beyond a button incrementer or to-do app.

---

# Background

Let’s go back to late 2017/early 2018. The subject app is in production and has ~8 engineers actively developing. This ain’t your trendy universal React app. It’s purpose-built for managing content for our company.

The backend framework is Django and includes Wagtail as a CMS. The frontend is babel-transpiled vanilla JS with SCSS as a preprocessor. Templates are all handled by Django’s built-in templating system.

The frontend app has its roots in the Knockout JS framework, but this was reduced to vanilla JS in pursuit of faster page loads and script executions. Most of the frontend logic is meant to handle simple features like sharing to social networks, subscribing to a newsletter, and submitting forms.

Each page stands alone and references its own template CSS file for styles, and template JS file for logic. Since we don’t use a frontend framework at runtime, the pages are much faster than our competitors.

---

# Identifying the problems

As our app grew, we had to support more CMS templates that were used for even more pages. Common bugs would appear and reappear as we worked. Problems fell into two categories.

## 1. Code reuse was arbitrary and difficult

Our frontend code had duplication stemming from over-eager classical inheritance patterns. There were multiple levels of inheritance that had to be traversed to understand how a certain page’s logic would differ from another, very similar page.

This got worse with time.

Template functionality requirements were fluid. It was hard for newer hires to conform to the intricate inheritance layers when making changes. A ticket would be raised to fix a bug on one page with the assumption that it would apply to all templates. Unfortunately, that wasn’t the case.

## 2. Asynchronous data, without any management

Some code would make asynchronous data requests to a separate server. The response data existed only within the context of the requesting function. This was fine until we ran into situations where we wanted to share data between separate functions.

Some features required data from multiple asynchronous functions and an engineer would have to manually invoke those functions and do it in the right order. It wasn’t immediately clear what that order was and why it was important until bugs cropped up in staging environments.

It was especially awful with the duplication and confusing inheritance patterns already pervasive in the code. Plus, unit test coverage wasn’t very good.

---

# Composing a solution with Redux

I audited the entirety of the frontend application and reduced all logic into small building blocks called **features**. These features almost never interacted with each other. They simply wanted to run, process some template data, attach event handlers to the DOM, and had no need to exist after that.

Our app’s multilevel inheritance structure only existed to group features common to a template. I could accomplish the same thing and reduce cognitive load by simply composing our features together.

for this, I used the `compose()` utility that Redux provides. See what kind of effect it has on the code below.

## Before: multilevel inheritance

```javascript
class BasePage {
  constructor() { console.log('Setting up base page') }
};

class HeaderPage extends BasePage {
  constructor() {
    super();
    this.initHeader();
  }
  initHeader() { console.log('Initializing header') }
};

class FormPage extends HeaderPage {
  constructor() {
    super();
    this.initForm();
  }
  initForm() { console.log('Initializing form') }
};

class FormNoHeader extends FormPage {
  constructor() { super() }
  // Empty method so that this.initHeader() in FormPage constructor does nothing
  initHeader() {}
};

class DifferentFormNoHeader extends FormPage {
  constructor() { super() }
  initHeader() {}
  initForm() { console.log('Initializing different form') }
}

const formPage = new FormPage();
// Output:
// Setting up base page
// Initializing header
// Initializing form

const formNoHeader = new FormNoHeader();
// Output:
// Setting up base page
// Initializing form

const differentFormNoHeader = new DifferentFormNoHeader();
// Output:
// Setting up base page
// Initializing different form
```
*Most problems arose when we wanted to copy template functionality except for one or two pieces of logic.*

## AFTER: functional composition

```javascript
import { compose } from 'redux';

const setup = () => { console.log('Setting up base page') };
const initHeader = () => { console.log('Initializing header') };
const initForm = () => { console.log('Initializing form') };
const differentForm = () => { console.log('Initializing different form') };

const formPage = compose(initForm, initHeader, setup)();
// Output:
// Setting up base page
// Initializing header
// Initializing form

const formNoHeader = compose(initForm, setup)();
// Output:
// Setting up base page
// Initializing form

const differentFormNoHeader = compose(differntForm, setup)();
// Output:
// Setting up base page
// Initializing different form
```
*Beautiful*

Switching to functional composition proved to be highly beneficial. I was able to remove all logic related to individual templates since they are just comprised of features. This reduced the complexity of our frontend immensely!

Each feature comes with its own set of unit tests. These are easy to write, because of the isolated nature of the code. If unit tests are easy to write, they will get written more often, helping the team keep up with maintenance.

By using `compose()` we can also bundle features together and import that bundle all at once. This is helpful for when we create a new Django template X that needs to be like template Y, but with the addition of feature Z.

## Bundled features

```javascript

import { compose } from 'redux';

// Features
const setup = () => { console.log('Setting up base page') };
const initHeader = () => { console.log('Initializing header') };
const initForm = () => { console.log('Initializing form') };
const initSlider = () => { console.log('Initializing slider') };

// Similar to the BasePage and HeaderPage classes
const basePage = setup();
const headerPage = initHeader(basePage);

// We can take the headerPage bundle and compose off of that
const formSliderPage = compose(initSlider, initForm)(headerPage);
// Output:
// Setting up base page
// Initializing header
// Initializing form
// Initializing slider
```

# Sharing data with Redux

I didn't bring Redux in as a dependency just for `compose()`. I also needed a way to share data between features and manage async calls. I needed to use a data store.

To be a feature, a function..

* must be unary (accept only the Redux store as an argument)
* must return our app’s store for the next function in the chain
* must not be async

## A typical feature

```javascript
const makeLinksAlert = store => {
  const links = document.querySelector('a')
  Array.from(links).forEach(el => {
    el.addEventListener("click", () => { alert('alert!') });
  });
  return store;
};
```
*A lot of our features do small things like this.*

Each feature has access to the [Redux store](https://redux.js.org/basics/store#store), which is powerful.

At the same time, it’s important to restrict features from blocking on async requests during the initial script evaluation. It would be disastrous if a form wasn’t responsive as soon as it was visible. So I only `dispatch()` and `getState()` when it makes sense (typically on user interaction).

The Redux store maintains the state of important async calls. I dispatch relevant actions as async calls are made inside features. Features can subscribe to the store and fire once a value is truthy. This provides a way to chain asynchronous calls between features without having to rely on bloated Promise chains.

I created a simple subscribe function to accomplish this. Note that it also unsubscribes once the callback fires.

## Subscribe utility

```javascript
const passConditions = (conditions, state) =>
  conditions.every(condition => {
    const path = condition.split(".");
    // Check to see if condition values are truthy
    return !!path.reduce(
      (accum, curr) => (accum && accum[curr] ? accum[curr] : null),
      state
    );
  });

// Conditions are an array of string paths to access store keys.
// ["quoteId.value"] would only fire if nested key value was truthy.
// A store like { quoteId: { value: true } } would suffice.
export default (conditions, callback) => store => {
  let fired = false;
  // The redux store subscribe returns an unsubscribe function
  const unsubscribe = store.subscribe(() => {
    const state = store.getState();
    if (!passConditions(conditions, state)) return;
    // This line is to pass tests
    if (unsubscribe) unsubscribe();
    // The unsubscribe call is not enough to ensure the callback only fires once
    if (!fired) callback(state, store);
    fired = true;
  });
  return store;
};
```

There are circumstances where a feature is waiting on multiple async calls to fire. Simply subscribe to both async values and wait for them both to be valid.

## Using subscribe utility

```javascript
import subscribe from './subscribe'

// Store state
// {
//   form: {
//     loaded: true,
//     emailInput: {
//       value: 'email@domain.com'
//     }
//   }
// }

const validateInput = 
  subscribe(['form.loaded', 'form.emailInput.value'], state => {
    console.log('Validating input');
  });
```
*The validateInput feature will fire once when both conditions are truthy. It will unsubscribe afterwards.*

---

# Conclusion
I’m pleased to have found a use for Redux outside of React and to have applied some of the functional programming techniques I’ve been studying. The refactors have been thriving in production for a year now and our frontend code is healthier than ever.

Benefits recap:

* Removal of template JS logic
* Smaller, focused units of code
* Easier to test
* Less async bugs

That said, I’m still working to improve on this concept.

We’ve had engineers import a feature, without realizing that it already exists in the compose chain via a feature bundle. This means that feature would execute twice. I’m working on a solution for that.

Since template JS files have become tacit compose functions, I can evaluate the Django template at compile time and come up with the features that should be composed. Tie that to the CMS blocks, deploy dynamic JS to a CDN, and now we can build features without worrying about templates at all.

Maybe I’ll have a follow-up next year. 😄

Using Redux with Vanilla JS

Writing software for people is satisfying! Each feature is an opportunity to create a well-measured solution to a problem. In modern software development, we aren't just asked to solve these problems. We are also expected to delight our users.

![center: Photo by <a href="https://unsplash.com/@alistairmacrobert?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Alistair MacRobert</a> on <a href="https://unsplash.com/@alistairmacrobert?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>](hero.jpg)

I've found that when our job is to delight users, we can get lost in details. Mapping data from a database to UI elements on the screen is easier than ever. We're tempted to rush through simple problems to spend extra time on more flashy interaction effects or ultra-efficient code.

Sometimes that results in unreliable code with a pretty veneer.

---

> It works fast, it's reliable, it's fast, and it feels great!

That simple mental priority list helps me focus and refocus as I work. I believe it can be useful to others working on product features. Let’s step through it.

# It works

The most important part of writing software is writing **working** software. The entire priority list depends on this clause. All the industries we service depend on working software.

Let’s put ourselves in a user’s mindset. Would you buy/install/use/care about software that doesn’t work?
Our No. 1 priority is to write and deploy working software. For some, the work stops there. We’ve done our jobs. Mark it as complete and get that feature into production!

Our colleagues in other parts of the business may think this is where we spend most of our time. Truthfully, it’s easy to create that assumption for ourselves as well. Sizing stories when sprint planning and setting deadlines for functionality is simpler if we only have to consider delivering basic working software.

![center: Photo by <a href="https://unsplash.com/@chesteralvarez?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Chester Alvarez</a> on <a href="https://unsplash.com/@chesteralvarez?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>](gears.jpg)

Staying in this frame of mind may be fine for a proof of concept or a throwaway project. We should make that judgment call at the beginning of a project.

After our feature works, we can evaluate if it’s ready for the next step. I’ll argue that you haven’t done anything worthwhile without considering the second clause.

# It’s reliable.

Software isn’t reliable unless it works.

If it works once, we can make it work all the time. If we can’t make it work all the time, we should find out why not!

A common woeful moment we share is when we find our pristine, perfect feature falling apart shortly after the production deploy. One errant error breaks assumptions. The need for reliability is made painfully clear.

Feature reliability begins with developers. As good stewards of our product, we satisfy reliability concerns by writing tests and pursuing QA standards. Routinely, we may find that developing a feature’s reliability takes longer than the actual work on the feature. If we find that the spec calls for a reliable feature, then we can allow for that time in our planning.

Maybe we stop here. Our feature just needs to work and work reliably. For example, a progress bar for an internal file upload. Let’s consider the third clause.

# It’s fast.

Software isn’t fast unless it works reliably.

![center: Photo by <a href="https://unsplash.com/@alternateskate?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Alternate Skate</a> on <a href="https://unsplash.com/@alternateskate?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>](skate.jpg)

If a feature is rock-solid reliable, then we can determine what kind of speed improvements are appropriate.

This is vague by design. I would encourage focusing on high-impact changes or refactors that are measured with practicality. It would be awful for every feature to result in dozens of micro-optimizations to the architecture.

On the server side, now would be the time to consider caching strategies, reducing that important time-to-first-byte metric, and parallelizing asynchronous actions.

For those of us on the front end, we may want to optimize our assets. We can work with the UX team to tighten user feedback loops. These considerations help users stay engaged with our product.

With meaningful speed considerations applied to our feature, we can continue to the final clause.

# It feels great!

Software can’t feel great unless it works reliably and quickly.

For the features that have transcended the suitable performance threshold, we can begin the endless process of making it feel great. The idea is that we already have the necessary infrastructure in place to iterate successfully without continually having to get pulled back to the earlier clauses.

At this point, pursuing greatness is very specific to the project. It’s nebulous, and we should feel satisfied even to be at this point. Let’s optimize our multi-variant tests and discuss the finer points of Bezier curves for our transitions. We’ve earned it.

![center: Photo by <a href="https://unsplash.com/@willianjusten?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Alternate Skate</a> on <a href="https://unsplash.com/@willianjusten?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>](mountain.jpg)

---

> It works, it’s reliable, it’s fast, and it feels great!

# Applying this to your work.

Starting with your requirements, you can decide which clause you want to target for your feature and work to that end. Write a sticky note by your machine that reminds you of your goal. Then work through the priority list and build the feature. Be mindful and catch yourself whenever you find yourself drifting into micro-optimizations or feature polish.

If you want to apply this at a higher level, you can also think about your project’s target clause on the priority list. Is this project something that has to feel great or is this the kind of project that just needs to work reliably? From there, you can work down and align your feature’s priority.

Understandably, it doesn’t work that way if requirements become fluid. At least now you can identify when your feature creeps beyond its initial scope.

You can’t start by building great software. It has to work first.


John Apostol

Posts about Software

Letting Go of Code to Find Growth

Using Redux with Vanilla JS

A Sensible Approach to Developing Product Features