Nic's Blog

Home of tips, tricks, experiences, and random writings of Nic Roth.

An obsession with my GitHub contributor stats

March can be a strange time of year to reflect, but lately I've found myself doing just that with respect to my GitHub stats. For about 12 months, I've been obsessed with tracking one simple graph, and I think it's time to analyze what this has done for me and decide if I need to make a change going forward.

More specifically, I updated my GitHub Profile to make my contribution activity public to the world, even for my work in private repositories. This still hides exactly what I've been doing, but it does show how many commits or pull requests I create on a given day. I've used this as a step toward accountability with myself: last year I set a goal to code more often, and this helps prove that I have been coding more often.

In my day job, I don't write much code at all. I lead a very strong team of engineers, and as a manager I empower them to make decisions and write code while I get out of the way. My focus on leadership, people management, and technical strategy for my day-to-day responsibilities has led me to side projects or weekend hacks to stay current with coding and modern web or app software trends. Thus, my goal to write code at least once per week was born. I've made a deliberate effort to take an hour or two in the morning or evening to write code at least once a week.

Evaluating my progress

In the last year I contributed 561 bits of work towards repositories on GitHub. That's just over 1.5 contributions per day. However, as you can see from the visual representation above, I haven't quite hit my goal. Even though it averages out to at least once per day, there are multi-week stretches of time with no activity whatsoever. On the flip side, there was a stretch of time where I wrote code for 49 days straight.

Reflecting on these numbers has made me think: has the obsession been worth it? I've dabbled with React Native, React web apps, Node.js backends, Ruby/Rails backends, native iOS or Android apps, and more in the past year. Exposure to all of these platforms in my free time has helped me in my day job, and it has also helped me build cool prototypes or MVPs of various ideas I may have. In many ways, it has been extremely valuable to continue coding regularly.

Keeping an eye on my contribution number has also driven me to write more code. It may seem obvious, but having a number to increase by one has made it pretty simple. There have been several days in the past year where I think to myself, "I need to keep the streak going" so that I can fill in the next box in the chart.  This has pushed me to write code when I might have just taken a morning or evening off to relax.

What's next

While I have been able to achieve my goal to write more code, it has me wondering: should this be my focus? I've gained a lot from coding more often, but I have also sacrificed growth in other areas. Lately I've become extremely interested in the Low-Code or No-Code movement. In many ways, we have hit an inflection point: non-coders are able to produce results and create value in ways that simply was not possible before. I've been following makers like AJ of Carrd, Ben of MakerPad, and Pat of Starter Story. The stories of their individual success and the success stories they share of others is often astounding.  

Looking ahead, I plan to continue coding. No questions. It's fun, rewarding, and second-to-none for me. However, I'm putting my obsession with GitHub stats to the side. Going forward, I will focus on delivering value and proving out ideas rather than writing code. If those ideas or value require code, I'll write it. However, there are a number of no/low-code ideas on my list that have been shelved due to my focus the past 12 months on purely writing code.

Here are a few specific ways I plan to hold myself accountable, in lieu of chasing my GitHub stats.

  1. Publish updates transparently discussing my progress on projects on my blog or another content platform
  2. Deliver something of value each month: a software prototype/MVP, new feature in an existing project, or test an entirely new business idea
  3. Reflect on this effort regularly, but evaluate thoroughly in six months

Writing this post is simply the first step toward achieving this goal. I'll keep you posted as I go.

How I spin up APIs from static data files in minutes

I've created many apps that could benefit from quickly spinning up an API from a static data file. This can include a frontend app or even a backend app. One example could be a bit of data you've got in a spreadsheet that would be great to simply throw in an API. Whether for testing something as a POC or running all the way to a production app, this can be a great way to get moving.

Note: The term API is somewhat glorified here. What I'm really making is simply a way to access JSON data over HTTP.

I'm familiar with Node.js and luckily I stumbled upon the package json-server a while back. This package is super simple: run a server that hosts data from a JSON file. That's it. You can install it globally using npm install -g json-server and serve up files locally for development. Alternatively, you can wrap it in your own app and deploy it to a service like Heroku for a fully-functioning public API stand-in.

I'll walk you through doing just that. This app is extremely simple on purpose. It's just three files. There's a link to all the source code at the bottom of this post.  


index.js

First, we have index.js which is our Node app. Here, we import our dependencies and create a server to host our JSON data.

const jsonServer = require('json-server');
const server = jsonServer.create();

// Create a json-server with our JSON file on disk
const router = jsonServer.router('db.json');
const middlewares = jsonServer.defaults();
server.use(middlewares);
server.use(router);

// Configure port for Heroku deploy
const port = process.env.PORT || 5151;

// Start the server
server.listen(port);

package.json

Next, in package.json we list our dependencies and configuration. Note: Heroku will automatically pick up on the start script in this file.  

{
  "name": "static-json-api-example",
  "version": "1.0.0",
  "description": "A demo app to host JSON files as an API.",
  "main": "index.js",
  "scripts": {
    "start": "node index.js"
  },
  "author": "Nic Roth",
  "license": "ISC",
  "dependencies": {
    "json-server": "^0.14.2"
  },
  "engines": {
    "node": "10.x"
  }
}

db.json

Lastly, we have db.json where we store the data. The json-server package is pretty automagical when it comes to configuration. As long as your data is a valid JSON file, it will render correctly as an API.  

{
  "stories": [
    {
      "title": "A demo.",
      "body": "This is the demo story"
    },
    {
      "title": "Second story",
      "body": "We are hosting some JSON!"
    }
  ],
  "authors": [
    {
      "id": 1,
      "name": "Jim"
    }
  ]
}

The Results

Using these three files, you can deploy a data API in minutes. Simply drop in your data file to db.json and deploy it to Heroku.  

In this example, if you query the /stories route you will receive the following data.

[
  {
    "title": "A demo.",
    "body": "This is the demo story"
  },
  {
    "title": "Second story",
    "body": "We are hosting some JSON!"
  }
]

Now, my frontend app can start to interact with an API stand-in over HTTP. I can wire up loading states, interactions, and more all without having to build a real backend.


You can view the full source for this example on GitHub here. On the repo, there is a button to deploy this app to Heroku so you can have your own live example in just a click.

An intro to Exploratory Testing

I wrote an introduction to Exploratory Testing on the Vivid Seats Tech Blog.

Exploratory Testing is a practice by which a diverse group of participants on and off the team run through scenarios of a feature prior to release in order to find bugs or defects that may have not otherwise been found.

Check it out here.

How I improved my workflow with Hyper Terminal, ZSH, and other tools

I've been using a combination of tools including Hyper, Pure, and ZSH to create my terminal of choice for the past several months. My workflow and day-to-day happiness with my environment has improved dramatically due to some subtle changes in the way I am able to work in the terminal. I outline my full terminal setup below, in hope it can help others improve their workflow.

There's just one caveat: don't copy these settings and configurations directly just because it works for me. Rather, use this post as inspiration to find pain points in your workflow and fix them. Ask yourself some questions: What bothers you about your terminal? Could it be better? How could you work faster?

Here's how I answered those questions for myself.

A new terminal app: Hyper

Hyper is a visually pleasing terminal that's powered by Electron (HTML, CSS, and Javascript). Some might say it's crazy to run a non-native terminal, and when it comes to performance, they may be correct. However, Hyper is very customizable and extensible. Best of all, it's built on a foundation that I am familiar with, so I am able to customize it to my liking with ease.

Hyper terminal in action

I use Hyper on a Mac primarily, but I have also installed and used it effectively on Windows or Linux environments. It's great to have a consistent workflow across machines, especially when I'm using a Windows environment to test my web projects. I store all my configuration in a the .hyper.js config file, and it's a breeze to transfer these settings to a new machine.

For a fantastic, clean, and minimal visual experience, I use the theme Verminal by Vernon de Goede. Verminal, like most plugins I have tried, is super easy to install and it is also customizable. I've found the default settings to be pretty useful, but it gives you a great starting point.

A new prompt: ZSH, Pure, and plugins

I pair Hyper with Z shell (ZSH) and Pure, a fast and clean ZSH prompt. Again, this is in an effort to create a visually-appealing and minimalistic experience. Not only is Pure visually appealing, but it has some extra features that improve my workflow. Most notably, Pure has some nifty git-related enhancements that improve my agility with git and version control. For example, it will display the current branch and status of that branch directly in your terminal. It will indicate a branch is dirty with a simple asterisk, and indicate a branch is out of sync with the remote repository with simple up or down arrows. Additionally, Pure removes a lot of the repetitive cruft that isn't necessary with every line in your terminal session, such as your username and host machine.

Hyper is very extensible, and there are many great plugins that can improve your day-to-day workflow in the terminal. Some of my favorite plugins help solve the little nags that can be easily solved. For example, hyper-tab-touchbar enables better interaction between the MacBook Pro's Touch Bar and Hyper. It will display open terminal tabs directly on the Touch Bar, which gives a great visual and interactive representation of your terminal. If you wish Hyper would quit when you close the last window, then install hyper-quit to do just that. It's a bit nontraditional for a Mac user, but it can be useful to some. For more great plugins, check out the Awesome Hyper project on GitHub.

Discussing Sprint Retros with Remote Team Members

Over on the Vivid Seats Tech Blog, I wrote a post about our teams have adapted to work with remote team members.

If you’re a member of an Agile development team with remote team members, you may be wondering how to effectively run a retro for your sprints.

View the full post on the Vivid Seats Tech Blog.

Push yourself to learn

The first time you do something, it’s almost always the hardest. After you’ve done something more than once, it becomes a matter of repetition.

Your first trip on an airplane was probably a bit daunting, especially if you were travelling alone. Similarly, your first trip to the gym can be terrifying. Your first time at a new dentist’s office. Your first date. Your first day at school. The first time you filed taxes. All of these experiences are a tremendous build up for something brand new, exciting, difficult or terrifying.

Once you’ve figured it out, however, you can repeat the process with precision.


My first UITableView was a several-hour marathon. I had to double and triple check that everything was connected between my code logic and views. I constantly had to reference Apple’s documentation. It eventually took an exception being thrown for me to realize that my prototype cells had to be named properly in the storyboard file.

But now? I can whip out a UITableView in a matter of minutes. Because of this, I’ve found myself using them quite heavily. Why wouldn’t I? It’s quick and easy. It gets the job done. Despite that, I’ve realized that getting the job done shouldn’t be my only goal.


It’s easy to fall into these repetitive habits when we design and build products — especially mobile apps.

Now, I push myself to try something new with every project. If I haven’t learned a new trick, tool, or process when a project is complete, I consider the project a waste.

I, like many, have tons of ideas for new products. When it comes to designing or building these new ideas, I push myself to start with the hardest part and challenge myself to complete the work that requires using new APIs, design styles, or features first. This way, even if I lose passion in the random idea I was building on a Saturday, I end up always learning something new.


I encourage you to set your goals before you start any new project. Set the bar high. Build something great. But most importantly, try something new in your next project — you can always push yourself to learn.