![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: Welcome to The Zebra! &copy; 2021 John Apostol](hero.jpg)

There's a non-trivial amount of preparation you made when hiring for your team. You had to anticipate the need, make the requisition, screen candidates, interview the best ones, and finally make the offers.

There's a moment of triumph you feel after a candidate signs. Recline, spin in your chair, you're done.

**But you're not.** You're forgetting something. You have the biggest opportunity you will ever have to set them up for success.

Employee experience begins with the application, continues through the interview, and then kicks up after accepting the position. Your new hire is excited and likely anxious about what comes next.

You have a captive audience. Welcome them properly. The goal here is to ensure they land on their feet and know what's expected of them.

I like to do this by answering some common questions that run through a new hire's mind.

---

# How do I set up at your company?

I'm glad to work with a great company onboarding team that takes care of all the prerequisites. My new hires are set up with their essentials. It's a straightforward, turn-key process for me.

That said, it's still important to remember that onboarding at the company is top of mind for your hire.

Remember, they've made a big life decision to work with you. **All** of the basic questions around compensation, PTO, acceptable work hours, equipment, and relevant access must be answered first. Make it as easy as possible to work for your company, before considering how they will work for you.

I tell it straight.

> "Make sure you have your direct deposit information, HR forms, and all the other pieces solid before worrying about your first project."

I give them space to figure all those things out. People want to 'hit the ground running' and give you a good impression, but that's unnecessary pressure on top of all the changes being reckoned with.

If you effectively **are the people team**, then do take care of this stuff first. Make this your only priority. Your new hire can't effectively deliver on the team's goals if they're unsure when they'll get their first paycheck or how to log into their new email account.

Get them what they need.

---

# How will I work with my manager?

You new hire is a stranger. They have an impression of you, but they don't know what it's like to work with you. Give them a headstart and save trouble for the both of you.

I like to do this by sending a personal welcome email after they sign. In that email, I express my satisfaction in them coming aboard, make it clear to prioritize getting set up. Crucially, I take it a step further by sharing [a one-page guide on working with me](/about/manager).

*I'm honestly proud of what I wrote there and seeing my latest hire's reaction prompted me to write this post in the first place. Feel free to reference it for your own.*

I encourage every manager to think about what makes them tick. Think about what success means to you and how your reports can be successful working with you. If you're a lock, this is the key. Write it down and give it to your people. They will love the cheatsheet. It serves to clear anxieties and level set on your expectations.

You don't need to have it on a website, but I do recommend you have it digitally so you can share it as needed and refer back to it when you need to ground yourself. **Spend real effort on this.** It will pay off down the line.

---

# What's expected of me?

If you've given your new employee your one-pager, you're already partway to answering this one.

While every new hire should be able to receive your one page guide, most new hires require a personalized 30/60/90 plan.

For clarity, a 30/60/90 plan lays out expectations for your employee to meet within 30 days, 60 days, and 90 days. These are the milestone steps that they will center on to ensure success.

Here is where you can lay out the projects ahead of them and what deliverables would be required. I find it's best to keep the 30/60/90 light and digestible. There should be room for interpretation, both yours and theirs, such that success is defined but the details aren't precious.

Here's a plan very similar to one I've given in the past.

```
## 30 days
- Read & learn
- Ask questions. Get answers.
- Get some useful code into production

## 60 days
- Find your groove
- Overcome some challenges
- Start contributing to our roadmap initiatives

## 90 days
- Focus on roadmap initiatives
- Improve our team
- **Own** your code
```

My example here is purposely vague for when I was hiring a generalist engineer. I've given much more specific ones as well. You should tailor the 30/60/90 plan to guide their expectations on what you're looking for.

Make it accurate and hold them to it.

---

# How do I work with my teammates?

If you want your new hire to transition well, they need to understand all the relevant personalities they will work with. Thankfully, you don't need to spend much effort here. This should be delegated to your team.

I like to do this by scheduling 1:1 meetings between my new hire and each person on the team. I space them out at least 1 day apart and account for 45 minutes on the calendar. Why 45? Not conforming to a 30 minute or 1 hour meeting gives some fluidity and ambiguity, which is perfect for meeting someone new.

In the event description I write something like the following:

> Please meet <teammate>! She is our team's Quality Engineer, working to make sure that we ship appropriately functional products. <teammate> joined us back in <year of hire> and has a great knowledge of our team's services and how they interact with other services.

I also provide a *proposed* agenda, which they could honestly do without. I think it gives some touchstones and guideposts for them if they need it.

Make sure both of them can manage the meeting in case they need to reschedule or add a video conference link.

Lastly, remove yourself from the equation by declining and removing yourself from the guest list. It's not about you.

---

This isn't all-encompassing but I hope it was helpful for anyone wanting to give their new hire the best experience and all the tools they need to be successful. Remember, their success is your success.

*If you found this useful and are looking for a great opportunity managing amazing humans at a company with an unmatched culture, please consider browsing [The Zebra's careers page](https://www.thezebra.com/about/careers/).*

How to Welcome Your New Hire

![wide: Austin Central Library. &copy; 2019 John Apostol](hero.jpg)

A while back, I had a personal website built to show the portfolio of projects I had completed up to that point. It was built on Rails, my technology of choice at the beginning of my software career. Many years later, I decided to rebuild my site as a blog to jumpstart my motivation and creativity.

Here's how I built this site using modern technologies and sensibilities.

---

# The Use Case
I love building things and writing. That said, I didn't have an up-to-date place to put up anything. I figured that I should try to share my work and thoughts in a blog format where each post could stand alone. Eventually I would organize pieces to be more cohesive.

This blog would be an archive of myself and my work over the years. Mostly I would write about software but I figured that I could branch out into my other interests over time.

My goals were to bring myself joy in both developing `johnapostol.com` and when writing content.

## Joy in coding
* Fun to write code for the blog
* Scalable technology
* Proud to be fully custom made

## Joy in writing
* Fun to write content for the blog
* Easy to manage and publish
* Displays code samples as beautifully as prose

I had started a [Medium account](https://medium.com/@johnapost) not too long before I began this project. I liked the ease of putting up content on Medium, but more than anything, I really liked the way Medium *looked*. After some sleuthing I found that I could syndicate my content to Medium and get canonical references back to my own domain.

I could also seed my blog with content I had already written on Medium. Sweet!

---

# My Tech Choices
One of my favorite parts of any project is picking my tech at the beginning. In projects like these, I usually reach for a mix of my favorite tools and also treat this as an opportunity to learn some new ones.

## TypeScript
I'm a big fan of static typing in a JavaScript environment. At one point, [flow](https://flow.org/) was my go-to, because types were easily stripped away without a compiler. I could continue to rely on [babel](https://babeljs.io/) for JavaScript compilation. These days, [TypeScript boasts the same capability](https://www.typescriptlang.org/docs/handbook/babel-with-typescript.html) as well as overwhelming community support. If I can easily use TypeScript in any project, I will.

## Next.js
I see no better way to get a fully custom website up and running other than writing it with the [Next.js framework](https://nextjs.org/). It allows for ultimate control on top of very sensible defaults. See, I like using babel, webpack and TypeScript, but I don't like working hard to configure those tools. Most of the React-flavored frontend toolchain is taken care of with a simple Next.js application. Oh and I wanted to use React under the hood because of familiarity and overall ease of development.

Lastly, I felt empowered to build my app as a static site. I felt that Next.js had the best guidance for building that while giving me freedom to pepper in dynamic functionality with serverless functions and APIs if I ever decided to go down that road.

## Vercel
Heck, if I'm using Next.js, *which was created by Vercel*, I may as well *host my app on [Vercel](https://vercel.com/)*. Their *Hobby* tier is free forever and with careful management of my dynamic content (I have none in production), I could skate by with their usage limits indefinitely. Next.js and Github integration are top-notch. Not to mention the edge CDN. I had managed to avoid paying for server costs with my last host, why start now?

![center: Hosting, caching, preview deployments; all for the price of free.](vercel.jpg)

## Markdown
I'm comfortable with Markdown syntax. It's simple to read and write, and looks great in diffs as well. I didn't want to deal with custom formatting HTML elements and working with WYSIWYGs. Markdown content is also very portable. I had seen other people bend Markdown formatting to their presentation needs and knew I could too.

## Why not Gatsby?
Gatsby was still coming into its own as a Cloud provider at the time. While the static React framework was great, I didn't see much benefit moving away from the Next.js + Vercel ecosystem.

---

# Main Concepts
Now with something to build and some tools to build it, I had to find a way to tie everything together neatly in a repo. I got to work.

Next.js + TypeScript + Vercel came together beautifully. The most I had trouble with for these pieces was learning about the new features and breaking changes in the latest Next.js release and figuring out if I should be using `interface` or `type` keywords when typing my React component props.

The first real problem came when I tried to realize my vision of writing in Markdown and having React components format my words. It was (and is) very doable with plenty of examples online. Before thinking of solutions, though, I really had to consider the problem.

I wanted to **write content in Markdown** and host all of that **in a single repository** with **no database or server-side logic**. All logic had to be performed at **compile time**.

This was in order to scale my blog for free within Vercel's generous usage limits.

## Thinking as a user
One nice thing about a personal project like this is I'm the user. I could consider how much involvement and manual effort I would stomach to get this thing built. And if I wanted to favor DevX over UX at any point, I could just do it.

As John, the writer, I wanted to write content in only Markdown. My primary directive was **that no HTML should clutter up my words as I wrote**.

---

# Code
After identifying my needs as a user, I could zero in on the code needed to reach my goals. First, I needed a library that could parse Markdown and allow me to process formatting like *italics*, **bold**, or `code` into React components that I could custom style.

Thankfully, there's an excellent library for this called [react-markdown](https://github.com/rexxars/react-markdown/). It elegantly handles Markdown rendering by allowing you to specify what component should be responsible for rendering each bit of formatting. See how it's used in `[slug].tsx`.

```javascript
// [slug].tsx
import React from "react";
import ReactMarkdown from "react-markdown";
import CodeBlock from "../../components/CodeBlock";
import Heading from "../../components/Heading";
import Image from "../../components/Image";
import Link from "../../components/Link";
import Paragraph from "../../components/Paragraph";

const Post = () => {
    const renderers = {
    code: CodeBlock,
    heading: Heading,
    image: Image,
    link: Link,
    paragraph: Paragraph,
  };

  return (
    <ReactMarkdown source={postBody} renderers={renderers} />
  )
}
...
```

Now I could render Markdown into bespoke components for my blog! My content looked as follows. Notice the frontmatter at the top of the file, which is used for metadata.

```markdown
---	
title: "Using Redux with Vanilla JS"	
preview: "What follows is an explanation of how I've used Redux to make a production vanilla JS app more maintainable."	
slug: "using-redux-with-vanilla-js"	
tags: ["software", "javascript"]	
---	

![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.
```

The next trick was figuring out how to import my Markdown files at build time. I could have gone the loader route, which would allow me to import raw `.md` into my pages, but decided that it would serve me better to convert my Markdown files into JSON for making simple queries. This allowed me to build out dynamic slugs with the Markdown frontmatter and have an index of posts to display on my site.

For that, I needed the help of [processmd](https://github.com/tscanlin/processmd) to.. process my `.md`.

I wired up a `build` command in my `package.json` to run processmd with file-watching so that it would run as I updated my Markdown files.

```json
// package.json
...
"scripts": {
  ...
  "watch:posts": "processmd posts/*.md --outputDir content --summaryOutput content/summary.json --watch"
},
...
```

As I wrote out my content, processmd would create `.json` files, one for each post. Let's take a look at `getInitialProps()` within `[slug].tsx`.

```javascript
Post.getInitialProps = async ({
  query: { date, preview, slug },
}) => {
  const { bodyContent, title } = await import(`../content/${date}.json`);

  return {
    date,
    postBody: bodyContent,
    preview,
    slug,
    title,
  };
};
```

Another neat thing about processmd is that it can create a `summary.json` manifest file for you. I used this to list out all the posts I had available on my blog.

```json
// summary.json

{	
  "fileMap": {	
    "content/2019-01-30.json": {	
    "title": "Using Redux with Vanilla JS",	
    "preview": "What follows is an explanation of how I've used Redux to make a production vanilla JS app more maintainable.",	
    "slug": "using-redux-with-vanilla-js",	
    "tags": ["software", "javascript"],	
    "dir": "content",	
    "base": "2019-01-30.json",	
    "ext": ".json",	
    "sourceBase": "2019-01-30.md",	
    "sourceExt": ".md"	
  },
  ...
}
```

Now, if I import `summary.json`, I could display a list of my posts on the index page. I'll zoom in on the important part.

```javascript
...
export const getStaticProps = async () => {
  const summary = await import("../content/summary.json");
  const { sourceFileArray, fileMap } = summary;

  const recent = sourceFileArray.slice(-5).reverse();
  const posts = recent.map((sourceFile) => {
    const destFile = sourceFile
      .replace("posts/", "content/")
      .replace(".md", ".json");

    return {
      ...fileMap[destFile],
      date: fileToDate(destFile),
    };
  });

  return { props: { posts } };
};
```

Now that the guts of my development and writing process were in place, I could go about styling the individual components that make up each post.

---

# Inspired by Medium

I'll be perfectly honest, Medium has an amazing reading experience. I could write absolute drivel and it would look good on Medium. There's plenty of air and space that makes it a pleasure to read. I didn't think I could do any better without a big investment like hiring a designer.

I figured the best way to make my content pop was to lift styles from the best source. I dug into Medium's styles and lifted what made sense, tweaking and adjusting to retain the same breezy qualities, while fitting my own sensibilities.

You can see the difference between the styles for my **[Building a Serverless React App on Firebase Functions](/post/building-a-serverless-react-app-on-firebase-functions)** post hosted on my blog and syndicated on Medium.

![center: On the left is Medium. On the right is my blog.](compare.png)

## Polishing

I had some room to get fancy with all the raw pieces coming together. I wanted a clean way to show my author byline and my post title. I played with a couple options and ultimately decided to have a byline that transitions into a sticky navigation element as readers scroll. It took a lot of finessing and I'm very proud of the final effect.

---

# Not yet done

My blog is being continually improved, both through code and content. Maybe my pace of delivery isn't great (this post has been in draft for 4 months), but I greatly enjoy using what I built.

There were some final problems I still had to overcome! At a certain point, it became clear I had made a mistake in having my site be fully static code driven. I had to eventually move away from my `processmd` setup. In a follow-up post, I will get into how I migrated from a static generated blog into a CMS-driven static generated blog powered by [GraphCMS](https://graphcms.com/). Please look forward to it.

How I Custom-built My Markdown Blog

![wide: View from Hope Outdoor Gallery in Austin, TX. &copy; 2020 John Apostol](hero.jpg)

*This is for myself, to remember my feelings and learnings from this unique time.*

# A Realization

I had planned for 2020 to be the most important year in my career. This was the year to solidify my career goals concretely beyond "work with great people and make great things."

I have a career in tech across corporations and startups of varying sizes. I know what kind of teams I want to work with and what kind of teams I want to avoid. For a while, these were the biggest career problems I faced. After a few proving years, having a well-paying job as a software engineer in tech felt like a given. Privileged, I know.

Now I sit on Zoom calls for part of the week, interviewing similarly-skilled and competent people. Many of them were laid off from their jobs, with one key difference between their economic uncertainty and my own situation.

I work for a company less impacted by the global pandemic than the company they had worked for.

---

# Be Organized

The pandemic has ravaged everyone's plans. In the worst cases, it's taken lives and economic security. In these times of uncertainty, leaders remain important examples for their teams. Beyond giving a damn and providing assurances, we serve as guides for teams navigating confusion and anxiety.

Now, more than at any other time, it's important to be organized in thought and action. This is not the time for chaos. People leaders need to provide a foundation for their team to succeed.

In my case, this meant ditching my outdated note-taking system. I recommend everyone take some time from typical priorities and invest in organizing their thoughts. **I wholeheartedly recommend using [Notion](https://www.notion.so/) for this.**

Every modern worker should have a note-taking platform with a smart searching feature. With Notion, I only need a key phrase or topic in order to find hidden footnotes from otherwise uneventful status meetings.

> I note feedback, the date it was given, and other context around it.

Along with taking better notes, I also started taking *more notes*. Where I had been more freewheeling with my announcements, I was now preparing statements and reviewing them to make sure I communicated with purpose.

Unlike before where I was more apt to act upon feedback with immediacy, I have been more meticulous. I note feedback, the date it was given, and other context around it. This is to avoid making decisions in the heat of the moment. Where possible, leaving space for consideration leads to better decisions; something our teams benefit from.

A lot of us are working remotely for the first time. Whether we express it or not, we are anxious; sizing up own economic welfare and wondering how to work effectively. Our teams are feeling this too. We should first put good effort into organizing ourselves. People benefit from any structure their leaders give them.

Having a disorganized leader is stressful. We must free our team of that stress.

# Be Available

In my Notion dashboard for my team, I have enshrined a little note to myself, **Quarantine; be human**. I credit this with keeping me grounded in reality.

I would start most work days with a hello to my international reports. There's a 6 hour timezone difference between us. We've had a remote working relationship since way before the global pandemic, but that doesn't make the situation any less strange for them. A simple, human greeting in the morning bridges us and provides a human tether we can both depend on.

As I noticed online indicators go green, I would say hello to each teammate in turn. It's easy to take hellos for granted when working in the same physical space. Don't turn this into a work update, and don't neglect doing this.

I instituted optional working calls every day, once in the morning and once again after lunch. When my company instituted remote working by choice, and then by mandate, I was worried about whether the team would be able to remain as tight knit and productive. I was worried work would become formulaic and stuffy.

> ..we bought candle kits to make in our kitchens.

The optional Zoom calls were a haven for the socially restless like myself and a few of the engineers. Team members were encouraged to join in if they wanted to chat. A message would go out in Slack and a few of us would jump on to joke and chat.

I've been quite glad that our team has been able to have scheduled outings still. In our last outing, we bought candle kits to make in our individual kitchens. In making those kits, we learned about each others favorite smells (someone said cigarettes and gasoline) while the most experienced of us answered inane questions about wicks and heating wax in microwaves.

We onboarded a software engineer intern this past month and successfully kept our tradition of team lunches for new arrivals, even though we had to order in and talk over Zoom. Our intern just had their mid-internship review today. They only had great things to say about the experience so far. These were high accolades considering they've never met us in person.

In all these interactions I've worked to reinforce that we are still a community, we are still working together. Leaders should be available to their team, in 1:1s and in group settings, formal and informal.

# Overcommunicate

I believe in setting good examples. A lot of what made me into the person I am today is because I emulated others who I respected. Let's keep in mind that our actions (and inactions) carry weight with our teams.

If we want our teams to be more communicative while working remotely, we should expect to be more communicative.

To that end, I set reminders and review announcements I've already made in prior weeks so that I can follow up and answer and questions that people have had the time to develop. Here are a few other rules of communication that I follow in my day to day.

* **Check and double-check on decisions and ideas.** Just be careful to not nag for status updates.
* **Ask for feedback, often and in various ways.** Some people feel more comfortable in a 1:1 setting, others in a group.
* **Outline priorities and provide a vision for the team.** This gives our people a window into the future, and that we're still thinking about futures.

---

**A good leader is a shock absorber that cushions the blows of change.**

I've gotten over the initial year hump of people management. The training wheels have come off! I'm finally past the point where I wonder if I'm suited for the job. It's mine now and I have people depending on me to be good at it.

Notes on Managing a Remote Team During COVID-19

![wide: My baby Chrome extension](hero.jpg)

Honestly, I thought that Chrome extensions were more effort than they were worth to develop. I thought my extension would have to be useful for other people on the Chrome Web Store. Here’s how I was wrong.

*Skip to “Making the Extension” if you just want the goods.*

# The Use Case

I work at [The Zebra](https://www.thezebra.com/). It’s a neat place with smart software engineers collaborating on interesting problems.

Any place that has software engineers has people griping and sniping about their tools. We’re craftspeople and take pride in our efficiency.

At The Zebra, we have an expectation that developers will squash their commits before merging into `master`. This was not an issue back when we used GitHub for hosting our Git repos. GitHub had useful configuration that allowed admins to enforce squashed commits. All was right with the world. A few folks *really* wanted us to delete our source branches. 🤷

We found no such option when we moved over to GitLab. In fact, our developers found an [old GitLab issue](https://gitlab.com/gitlab-org/gitlab/issues/17613) asking for this functionality (2 years old at the time of writing).

We’ve lived with it for a little over half a year before I decided to look into whether a Chrome extension could solve the problem for us. At least, it could solve it for me.

# The Setup

At the core of our issue was that the GitLab Merge Request UI had a little checkbox that controlled squashing commits on merge. We simply needed that box to be checked as the Merge Request screen loaded, effectively protecting our squash commit culture by default. Bonus if developers could uncheck the box in case they *really* wanted to include their discrete commits in `master`.

I didn’t want to read a single bit of Chrome Extension documentation. I actively refused to. It was nearing midnight and I gave myself a 30 minute time limit to make things interesting.

So I set off to Google how to do this. I found a great article by thoughtbot.. but it was over a few screens worth of scrolling so I decided to just skim the code to see if I could get the gist. I had Netflix to watch, ice cream to eat.

*What’s to stop you from doing the same thing? Nothing really, go ahead.*

# Making the Extension

I needed exactly two files for my purposes:

```markdown
gitlab-squash-default
|- manifest.json (small config for extension)
`- content.js (the actual browser code)
```

The `manifest.json` file is just that; a manifest. This is how Chrome will understand your extension and when to apply it.

---

## manifest.json

```json
{
  "manifest_version": 2,
  "name": "GitLab Squash Default",
  "version": "0.1",
  "content_scripts": [
    {
      "matches": ["https://gitlab.com/*/merge_requests/*"],
      "js": ["content.js"]
    }
  ]
}
```

Here’s a rundown of the most important values.

* `name`: How you’ll recognize your extension when applying it
* `manifest_version`: This should be set to `2` as the earlier version isn’t supported. Don’t ask me why; I skimmed, remember?
* `content_scripts`: You probably want your extension to run against a single URL or a URL pattern. Set that here. It’s nice to know that you can use wildcards. My extension is only applied to URLs that begin with `https://gitlab.com/` and must then include `/merge_requests/` in the middle of the path somewhere. I also specify what file runs against those matching URLs.

---

## content.js

```javascript
window.addEventListener('load', () => {
  checkSquash = setInterval(() => {
    const checkbox = document.querySelector("input[name='squash']")
    if (checkbox) {
      checkbox.checked = true;
      clearInterval(checkSquash);
    }
  }, 250);
});
```

And that’s all the JS that I needed to make the functionality. This little code snippet would fire whenever the URL matched GitLab’s Merge Request screen and the desired checkbox would be checked upon its availability in the DOM. 🎉 🎉 🎉

---

# Enabling the Extension

With those two files written, follow these steps to enable it for your use:

* Go to `chrome://extensions/` in the Chrome.
* Enable `Developer mode`. This is a toggle on the top right of the page as of Chrome 80.
* Click `Load unpacked` and select the directory your files are in.
* Enable the extension, the name will match what’s in `manifest.json`.
* Test it by going to your specified URLs!

If you don’t see that the extension is working correctly, check for errors on the extensions page. You can also reload the extension after making changes.

---

That’s it, hope that helps you. Feel free to check out my extension if you like. Yep, I’m hosting my extension for GitLab on GitHub.

I’d appreciate any comments if you found this useful or entertaining. I’m looking to start writing more and could use the encouragement. Also, we’re always [hiring at The Zebra](https://www.thezebra.com/careers/).

## Resources

* [My extension, gitlab-squash-default](https://github.com/johnapost/gitlab-squash-default)
* [The thoughtbot article I skimmed](https://thoughtbot.com/blog/how-to-make-a-chrome-extension)
* [The Chrome Extension documentation I never read](https://developer.chrome.com/extensions/devguide)

John Apostol

Letting Go of Code to Find Growth

How to Welcome Your New Hire

How I Custom-built My Markdown Blog

Notes on Managing a Remote Team During COVID-19

Creating a Chrome Extension Without Much Effort