Notes from AWS Summit

I attended the AWS Summit in Chicago this week. Like many other tech companies, we at Gesture use various AWS products so it was a nice opportunity to get exposed to what is becoming possible with their platform.

Additionally, looking into what AWS is up to is a great way to see where technology is headed in the near future (and the near future is looking increasingly like things you may have thought only possible in sci-fi movies)

Though many of their services are focused on backend and devops, as a front end developer, there were still many things that appealed to me.

Lightweight VPN for hosting simple sites. This is the AWS alternative to the various shared hosting providers out there. Want to spin up a quick WordPress server or marketing site? this is the AWS service for you.

Serverless, interactive query service that makes it easy to analyze big data in S3 using standard SQL. In other words, chuck a JSON file onto S3, define your data structure, then you can run queries on it. Would be cooler if they had a service that could look at a file on S3 and figure out the data structure on its own. Wouldn’t be surprised if they don’t have that coming out soon.

Rekognition, Polly and Lex
This is the next level stuff. APIs hooking into AI services. Rekognition does image analysis to make it easy to integrate things like facial recognition and object detection into your applications. Polly and Lex offer a killer combination of text into humanlike speech (Polly) and speech recognition and understanding (Lex) which allow you to add powerful conversational interfaces to applications (the same tech that powers Alexa).

Serverless (Lambda + API Gateway)
I’ve been following serverless architectures for awhile. It is a rapidly evolving area that is opening up so many different possibilities when it gets plugged into other services like those above.

Mobile Hub
Really cool configurator for building mobile apps, including mobile web which is more where my interests lie. Makes it really easy to get up and running with services like user authentication and management (Cognito), a NoSQL DB (DynamoDB), Storage (S3), etc. These baseline core services are low cost and scale. Lots of popular apps and companies have gotten their start with these and have continued to rely on them after scaling.

As I write this I am having fun doing the AWS Game Day challenge with my team at Gesture (currently we’re in first place!)

The Atomic/Functional CSS Movement

When I published Expressive CSS a few months ago, I knew it would be controversial, and it was (as evidenced in the comments on my Content & Display Patterns with Expressive CSS post). In the time since, there have been many articles and projects published by others that also advocate lightweight, scalable CSS using utility classes that are easy to write and understand.

From what I can tell, Thierry Koblentz was the first to really challenge CSS conventional wisdom with what in 2013 he dubbed the atomic approach. Whether you call it atomic, functional, expressive or something else, people are realizing that for too long we have been stuck in this dogmatic pursuit of semantics which has held us back from crafting CSS in a way that is actually maintainable and scalable.

There are still people who strongly reject this approach (for example, the so-called Maintainable CSS project). A few years ago, I would have been one of those people. Read CSS and Scalability and Rationalizing Functional CSS to understand why companies with large CSS architectures are switching to the Atomic/Functional/Expressive approach.

Here are some recent real world implementations:

Marvel Style Guide Screenshot
Marvel Style Guide

Solid by Buzzfeed Screenshot
Solid by Buzzfeed

When companies publish their frameworks, people often ask why not use an existing framework. Just take bootstrap and fork it. Better yet, use BassCSS or Tachyons.

Well, when you write CSS this way, creating a custom CSS architecture designed exactly for your project’s needs is not that hard and is actually fun. And if you do it right, changing things down the road is no big deal if you are using a CSS preprocessor and HTML templates. That is the benefit of the atomic approach!

I Wrote Our Developer Job Description

We’re hiring a new developer, and my boss asked me to “gussy up” the job description. I love working with great people, so I’m happy help that happen.

I tried to capture a little of the flavor of what it is I love about working at Gesture, and do it in a hopefully entertaining way. If you can write Java and the below sounds good, please send me your info!

Did you know that most tech companies have ping pong tables to hide the fact that they are lame, boring SaaS widget factories? Don’t fall for it. Work at Gesture. Join the team with the world’s best mobile fundraising platform that helps charities host awesome events and raise more money — $300M and counting.

Do you want to be a faceless, burnt out code monkey on a giant “IT” team with 5 levels of management where it takes months before your code even gets into production? Don’t be that. Work at Gesture. We have a small team that works efficiently, ships continuously and has fun while we do it.

Want to work for a bunch of guys in suits who constantly change their minds, blame engineering for their own mistakes, and take their employees for granted? Don’t work there. Work at Gesture. Our culture is about collaboration and camaraderie. Our female employees outnumber the men (yes, even though we are a tech company). Our CEO is more fun than your CEO. Guaranteed.

Want to write code that is rushed, poorly maintained and built on a foundation of technical debt? Don’t do that. Work at Gesture. Our Software Developers own the code and we do not let that fly. We have thousands of tests that let us ship with confidence. Our sprints are right-sized to make sure we have the time to do it right.

Are you a do-the-minimum, in-it-for-the-paycheck, that’s-good-enough McLazypants? A stodgy, my-way-or-the-highway, know-it-all Party Poopster? Don’t be that. You can’t work at Gesture. We are looking for Software Developers who take pride in their work, and aspire to improve as people and software engineers.

If you can write Java and want to work at Gesture, please send me your info!

Notes from UX Camp Chicago

UX Camp Chicago Saturday April 30, 2016 at Columbia College Film Row

It was a rainy day in Chicago yesterday, so it was a perfect time to spend inside at Columbia College for UX Camp Chicago. It was yet another great conference put on by the excellent Russ Unger and the excellent team at

Below are my notes from all the talks I attended. There were 3 rooms of talks happening simultaneously, so it does not come even close to capturing everything going on there.

While taking notes on my laptop, I occasionally stopped and just listened so there were all kinds of cool things the speakers had to say that I did not type down. The next event from Chicago Camps is Prototypes, Process and Play in August, so if any of the below sessions sound cool, you should definitely scoop up some tickets for that.

Ok, here are my notes!

Lessons Learned from the World of Wearables

by Carolyn Chandler


5900 steps = average number of steps of a person in one day
10,000 = the number of steps that sells fitness trackers
1 in 10 consumers own a tracker
40% of users drop fitness tracking in the first 6 months

During her work for Mira, Carolyn started an evaluation of fitness trackers by wearing 6 different brands of wearables as she started the Couch to 5K program. Most fitness trackers have 3-Axis Accelerometer, Gyroscope and Altimeter. Some have other features, but the most important thing is how they measure steps.

Standardization amongst fitness technology companies is a big challenge. Strides are measured by algorithms, which these companies do not share with each other. Fitbit was the most generous with step count – sometimes by as much as 4,000 steps. Typically, the variance between companies is around 2,000. Because there is no standardization, it makes it harder to compare your fitness level to other friends that do not have the same brand of tracker.

Everyone knows about watches and fitness trackers – what about other types of wearables such as hazardous chemical detectors (My Exposure), Google glucose sensing contacts, UV monitors (June).

Body area network is all of the things you can wear and how they get brought together.

Carolyn then talked about her learnings from the research she did working with Mira, which is an activity tracker specifically designed for women. A big problem she discovered was that most fitness trackers actually reduced the confidence of the women wearing it, for a variety of reasons including the style of the trackers, battery life and more. The tone communicated by these products can come off as judgmental.

Cheerful communications, especially in context, were very well received, especially when done in an interesting way that tells a story. For example: “Feeling lucky? You just walked the distance of the Vegas Strip today!”.

There are tradeoffs involved in design decisions. For example, a larger screen leads to a shorter battery life.

The next part of her talk was about CES. And interesting thing she saw was Underarmour’s health box which contained related wearable products, including one with a shoe with a tracker built in that has enough battery life to last one year. Another interesting product was smart fitness clothes that measure your waist size and other things.

She looked for advancements in improving battery life, such as using motion to charge, but unfortunately the current products don’t work very well. Others are trying to use solar energy to recharge, for example having solar panels on purses or bags.

How to Guarantee Product Failure

by Sean Johnson


Designers are marketers.

Business Objectives + User Needs. Designers especially in UX focus on user needs. This manifests in failures because business objectives are important.

Consider the customer funnel. Most companies consider acquisition and retention, but ignore what happens in the middle of the funnel, which is the engine of your product.

Focusing on the middle of the funnel, improving the experience of using the product, is better because product enhancements are more sustainable.

Retention is the most important level in the funnel. If you have a lack of retention, nothing else matters. Good retention means increased lifetime value of a customer.

3 levels to improve retention: Onboarding, Building Habits and Maximize Frequency.

Ghost town problem. How does your product look when a user first gets there and there is no content.

Assuming someone signed up for the product and is going to get to a spot where the content is filled in is a mistake.

Leveraging social sign on is a way to bring in content for the user. Less fields is better (combine first and last name, no confirm email or password). Avoid email verification requirements which block the user from progressing and force the user to leave and come back.

The goal is to have the user understand the importance of the product to them as quickly as possible. Anything that gets in the way of that is a problem. Using game mechanics to encourage behavior that will lead to this is a good strategy. Creating a custom product tour is another good idea.

Bake in proof that product will deliver to add to the user’s confidence in the product.

Explain reasons why you need users to opt in along the way of their use of the product will also build and maintain confidence in the product.

When possible, combine fields (for example, phone or email in one field) do not make users click submit before validating fields.

Do not use lorem ipsum text when designing. Always at least take a stab at writing copy.

For mobile apps, do not make first screen be a login. Let people experience the product before forcing them to create an account. Have onboarding experience assist in the creation of content. Hold off on account creation until user is ready to save their progress.

A newer approach is to use a conversational bot style chat interface to help with onboarding.

Think of email as a core part of the product.

Commit to a cadence of build, measure, learn. The speed to which you can burn through the loop will increase the likelihood of your product’s success.

Designers should love data. Use data to figure out why users continue to use product.

Focus on OMTM (One Metric That Matters).

There are not many silver bullets. Improving products in a long, grueling series of steps. A great deal of perseverance is required.

Get outside of the mindset of lore – things everyone does but are not tested.

Sketch-to-Code Prototyping

by Will Hacker


Wireframes don’t cut it anymore, especially for rapid prototyping. Over 500 height and width configurations for Android.

Highly recommended following Josh Clark.

Make lots of sketches. Low cost. Sketches plus post-it notes with color to represent different things (e.g. yellow for existing logic, purple for new). Will advocates then prototyping in pure code. The big problem for devs when you give them a representation of something “pixel perfect” is that you don’t consider that it will be delivered to 28,000 different devices.

Will’s team created a live code pattern library created by developers tied to the user experience team. With this library, they are able to deliver working responsive prototypes for review.

One challenge brought up by an audience member was that developers feel like their job is being taken away from them when they are delivered code.

Having a philosophy of “we build mobile products that people may or may not use on a larger screen”, changes the focus and mindset. The mobile view is the most important view.

Different team structure of interaction designer, visual designer and, something new, a UX Prototyper. This team delivers the prototype to development for inclusion in the product. The shift is that front end dev is done as part of the UX team, not the IT team.

This gets away from mockups and sending PDFs full of screens they don’t understand. Instead, deliver links that the viewer can see on their device.

Vocal Exercises: Finding Your Voice

by Natalie Kurz


Lauren started with a show not tell explanation of the concept of a brand voice. She started with a formal, professional “About Me” description. Next, she displayed the same information, but in an informal, personal voice.

Your voice makes you different from everyone else. For brands, different writers are writing different parts, but it should sound like it came from one person. A consistent voice will build trust with users.

Your website or product can have one voice, but different tones depending on the context and emotional state of the user.

Think about how you want people to think about your product. Different approaches during a workshop to developing a brand voice would be card sort, then evaluating paired terms, opposites and spectrum. Narrowed down the terms, looking to avoid misinterpretations, use a “we are ____ not ____” or “we are ____ like a ____” to further focus in.

She brought up company 404 pages as a good example of whether a company has a voice, she show 404 pages for the email marketing companies Mailchimp, Emma (whimsical) and Active Campaign (serious, professional) to compare and contrast some brand voices. Keep in mind that imagery also has a voice.

Having writing guidelines is a way to explain to writers how to write consistently in the brand voice, and for evaluating existing communications. Giving examples is to illustrate the brand voice is the most important part of good writing guidelines. Also, it is important to talk about tone as it changes for different parts of your site and for different personas and mediums.

Wearables for Everyone

by Scott Sullivan


Wearables suck.

The idea is good, but what’s out there sucks and design is the way to make it not suck.

We don’t think about the consequences of the new things we are making with this new smaller technology. We don’t know enough yet to have common patterns — it is the wild west.

We focus too much on industrial design, not enough on service design. Service design is an eagle’s eye view of an end-to-end experience.

Leonardo DaVinci invented a pedometer for Roman soldiers. In the 1960’s, the Japanese were getting fat so they became the first movers to mass market a pedometer to address this.

Experiential knowledge is different. You get it from the context of your life. You know what 10,000 steps means for you in terms of all the activities you do in a day to get to that goal. As you get experience, a fitness tracker gets less useful as you know and understand how to get to 10,000 steps and it has served its purpose at that time.

With the Fuel Band, Nike concentrated on Fuel Points which is different than steps. Playing basketball for an hour versus walking for an hour might have similar step counts, but playing basketball expends much more energy.

On the scale of services vs. commodities, some fitness trackers are closer to the commodity side (you had x amount of steps) while others are geared more towards service (based on your activity, you should do x).

A lot of people don’t use the sleep tracking because you can’t do anything with it. Jawbone UP3 follows a “Track, Understand and Act” philosophy and gives advice on what to do based on your sleep tracking, which is more useful. Yet Fitbit 1 outsells Jawbone UP3. This is likely because Fitbit has a screen and Jawbone does not, and people do not understand the idea of a disposable technology whose value is to pass data to your other devices and services.

In testing the calorie counting watch Gobe, he finds that sometimes it is eerily accurate and other days it is really off. Not there yet.

Fitness tracking is only a small amount of a health picture, and as important as diet.

Smart watches suck because they are too distracting. Notifications suck. They should be non-intrusive dashboards. This is what watches have traditionally been. If you need to have a smartwatch, Android Wear lets you do more service-based things with Geofencing and other contextual things.

He was especially excited about Withings Activité, a beautifully designed traditional analog watch that also does fitness tracking with a battery life of up to 8 months.

Google Glass was not a failure, but rather an experiment. It proved that certain technologies are not inevitable. The future of everyone wearing intelligent smart glasses is not a future that most people currently believe is going to happen.

The Narrative Clip is Scott’s favorite wearable device. Rather than active photography, it is passive and unobtrusive. It takes pictures of moments of you life that would otherwise go undocumented. It is a way to capture surprisingly meaningful moments that would otherwise go unnoticed.

UXers Are From Mars, BAs Are From Venus

by Cornelius Rachieru


Something you don’t learn in design school is that design is politics. Everything we do is subject to scrutiny and opinion. How teams work together is very important. Individuals might be stars, but how do people work together.

Companies are actually starting to hire teams (e.g. Stripe). Learning how to work with counterparts (e.g. on the business side) is a soft skill that should not be ignored.

The budget priority at startups is on UX work, at enterprises it is on business analysis.

Throughout history, design and business analysis developed separately, but have been impacted together by such things as the arrival of Microprocessors and the emergence of Agile development.

Business analysts design and describe solutions to stakeholders, which overlaps what design analysts do. This leads to conflict, for example in defining requirements.

In the latest BABOK (Business Analyst Book of Knowledge) defines Usability as: Ease with which a user can learn to use the solution. This is actually learnability. Only half a page of the book touches on visual design.

Designers do not do a good job of explaining to people what they do or explaining the design process.

Cornelius proposed this definition of UX: An evidence-based methodology that involves end-users throughout the creative process to identify, conceptualize and design services or products that are measurably easier to use, learn and remember.

How do we resolve the conflict between designers and business analysts? Work together to define methods to use where responsibilities overlap. We have been trained to treat users a certain way, but not our team members. Being nice to each other is the key to being successful as a team.

Atlassian developed an Experience Canvas based on the Business Model Canvas.

UX designers are encouraged to work in different industries, and are viewed as agents of change. Whereas business analysts will often stay in one industry, and are viewed as experts.

When it comes to making design decisions, politics come into play. Design decisions may be made by Business Analysts and executives independently of design. The Dunning-Kruger Effect can lead them to being confident in these decisions.

The Design Validation Stack has 3 layers: Design Theory, User Research, User Evidence. The third layer (evidence) is more reliable than the first (theory). Business Analysts similarly have a Business Validation Stack of theory, research and evidence.

At the theoretical level, we have deductive logic to determine what should be built based on accepted theories. At the research level, we use inductive logic to resolve arguments based on evaluating the validity of hypotheses.

Formal focus groups typically used by business analysts use people with their guards up, being skeptical and critical. A story-based conversation are much easier to synthesize because people are at ease.

At the user evidence level, we have an argument being tested in the real world. User experience practitioners implement usability testing of prototypes, whereas business analysts practice user acceptance testing on the product or service after it is built. Therefore, usability testing is a better form of evidence-based testing as you get feedback sooner, saving time and money.

It seems that the roles of Business Analysts and User Experience Designers are destined to merge.

Keep gh-pages and master in sync with one line of code

If you publish projects to Github, then you probably are using a gh-pages branch to create a nice home for your project with a demo and some documentation (e.g. like this). Read all about Github Pages at

A common pattern is to keep the gh-pages and master branches in sync with each other — whatever code is in master is the same as your project page (gh-pages). You can read about different ways to do this on Oli Studholme’s excellent article GitHub Pages Workflow and deleting git’s master branch.

I myself favor Lea Verou’s simple approach detailed here. Something along the lines of this:

git add -A .
git commit -m 'Your commit message'
git push origin gh-pages
git checkout master
git rebase gh-pages
git push origin master
git checkout gh-pages

How about we do that in one line? The secret to this will be setting up a Git Alias in our .gitconfig file. I have written about Git Aliases before (see here). If you aren’t already using them to speed up your workflow, then I encourage you to start now. Read about Git Aliases at Git How To

Open up your .gitconfig file (located in your $HOME directory). We will be adding two aliases. The first will be an alias to commit all changes to the current branch (aacm = add all . -git commit –m). Next will be an alias to push the commit to master and then to gh-pages (pomg = push origin master and gh-pages)).

aacm = !git add -A . && git commit -m
pomg = !git push origin gh-pages && git checkout master && git pull origin master && git rebase gh-pages && git push origin master && git checkout gh-pages

Now, when you are on the master branch and you want to sync it to master, simply run:

git pomg

Or, you can combine a commit with the push and sync by running:

git aacm 'Your commit message' && git pomg

Hope that helps your workflows! For more tips on Git Aliases, check out these resources:

Expressive CSS and Using NPM as a Build Tool

Expressive CSS Project PageSeems like every front end web dev eventually publishes a manifesto about their approach to CSS. So here is mine: Expressive CSS

(Shout out to Cole Peters for his Building and Shipping Functional CSS article which offers a similar take and inspired me to finish and publish my project)

One thing I tried that was different for my workflow on projects was to use NPM as my build tool. It always bugged me to have Bower and NPM in my projects when they do very similar things. NPM seems to be the more popular one and it can also somewhat replace Gulp/Grunt as a build tool.

My front end build tool needs for Expressive CSS were pretty basic. I needed to first process the .scss files into unminified CSS files for people who do not want to use SASS to be able to grab (and ignore the SASS files altogether). After that, I would need it to create the minified, source mapped CSS. Also, I added a watch command to enable automatic builds on file saves.

Thanks to node-sass CLI, I was able to configure npm to do exactly what I needed. Here are the relevant lines from package.json:

"scripts": {
    "build": "node-sass css/sass/base.scss css/stylesheets/base.css --style expanded && node-sass css/sass/utilities.scss css/stylesheets/utilities.css --style compact && node-sass css/sass/components.scss css/stylesheets/components.css --style expanded && node-sass css/sass/style.scss css/style.min.css --style compressed",
    "watch": "onchange 'css/sass/**/*' -- npm run build"

So, instead of grunt or gulp, we do npm run build and npm run watch.

Pretty simple, eh? For more info on using NPM as a build tool, check out these articles:

UPDATE: The talented folks at Webucator have created a video demonstration of this post:

Check out their YouTube Channel for lots of great training videos.

Simple Responsive Grid

Simple Grid Demo Page on GithubSimple Grid is the responsive grid system I am using on all of my websites these days. View it on Github.

3 years ago I published Extra Strength Responsive Grids, a grid similar to the one in Bootstrap (although we did release ESRG first). My use of the grid has evolved to the point where I wanted to open source this newer, better version.

Simple Grid is similar in function Bootstrap’s grid. The main difference is the inclusion of padding helper classes. Rather than filling up stylesheets with lots of padding declarations, I use these combined with grid classes to handle almost all the spatial arrangements of web pages.

The padding classes also eliminate the need to have .row as a class. With simple grid, you use a .grid-12 with an appropriate padding class applied to it instead of .row.

When I built the ESRG project, the demo page was themed in a humorous way to feel like a sales site for a pain reliever drug. For the Simple Grid demo page, I ditched the silliness and kept it simple and utilitarian. It is probably the smallest stylesheet for a project page that I’ve ever made, just the grid and some CSS to expose the underlying grid scaffolding. No webfonts, colors, images, or styling flourishes, just the business.

Additionally, I have a separate project for the Simple Grid Generator, a SASS mixin that I used to output the Simple Grid CSS. It comes with some different options to customize your own grids, and can also be useful to anyone who wants to see how to make their own SASS grid generator.

Building a Game With a 6-Year-Old

Free Summer HTML5 Car GameI just open sourced a game I’ve been working on with my 6-year-old son Jack over Thanksgiving weekend.

Click Here to Play

Want to work with your kids to make your own custom version? All the files you need are on Github.

A few years ago, I made a game called Match the Letter to help Jack learn his ABCs (still available for FREE on Google Play – no annoying ads either).

A couple years later, he asked me to teach him to make a game. I told him he’d need to know how to code and to do that, he needed to learn to read.

Fast forward to 1st grade, and he reads pretty well. The day before Thanksgiving, I was working at home (because my job is cool like that) and Jack brought it up again.

I started asking him questions and taking notes from what he said. He likes the Blocky Roads game (available on iOS and Android) which seems to be his inspiration.

Buttons for the gameWe’ve made some progress and I want to share it out with my fellow devs who might want to do the same thing with their kids. Play it here and check out the project on Github. Shoot, all you have to do is replace the png graphics with your kid’s own drawings and you will be all set. If you don’t want to make a car game, check out the Phaser Framework for building browser games and you can probably find an example or tutorial for the game your kid wants to make.

The look on my son’s face when he could play the game he thought of, using his own hand drawn graphics, was UNBELIEVABLE! It is so much fun!

Jack is providing all the drawings and direction on the game design. I just do what he tells me, while trying to teach him what it takes to implement his vision along the way. We even have his 2-year-old brother in on the action, play-testing on his own tablet.

Tutorial - Create a car with PhaserBig thanks to Photon Storm, the folks behind the Phaser HTML5 Mobile and Desktop game framework without whom this would not be possible. And super big thanks to Markus T who published a fantastic tutorial that gave me a huge jumpstart and is responsible for most of the code that is behind the game thus far.

I will keep working on it as long as he stays interested. No promises on how far we will get, but so far it is a blast!

Development Log

Game graphics by Jack11-26-14

My notes from Jack’s description of what he wanted his game to be (verbatim)


  • You can decorate it
  • Drive around farmyard
  • Press a button to make it go
  • Only go straight.
  • The car is named Syndro


  • Hills
  • Hot lava
  • Ramps
  • Parachutes if the car explodes
  • Other cars that are damaged


  • You can click on a building to park on it
  • Find stuff thats moving then unlock them in your farmyard


  • people walking by

When we finished the intro screen, Jack asked me “Are we finished??”

I told him we were done with the first step. He asked how many steps there were. I said about a thousand. He was unfazed by this and excited to start the next step. Here are the steps we have so far:

  • Step 1 – Intro Screen (Jack picked the font)
  • Step 2 – Draw the car
  • Step 3 – Animate the car
  • Step 4 – Pick a Physics Engine – Phaser
  • Step 5 – Create game page with hello world example
  • Step 6 – Find car game example to use (found this great tutorial!

Worked on animating the car and separating it into pieces in Photoshop.


  • Step 7 – Bring Jack’s car drawing into the game
  • Step 8 – Jack draw preview and control buttons
  • Step 9 – Add preview button to intro screen


  • Step 10 – Add button controls for touch devices
  • Step 11 – Publish open source for testing and sharing
  • Step 12 – Jack and Grant (little bro) test on mobile devices
  • Step 13 – Jack draw more game elements
  • Step 14 – Draw home screen icon


Share Your Git Aliases Day

Git aliases have been around for a long time, but in case you don’t know about them, they allow you to create shortcuts for just about any git command or sequence of commands that you can think of. Beyond just the convenience of less key presses, you can use to streamline your workflow by sequencing longer sets of commands that are hard to remember. Here is a nice intro article on Git aliases: Streamline your git workflow with aliases.

Wouldn’t it be fun if today was Share Your Git Aliases Day? Taking a look at other people’s .gitconfig files can give you an insight into how they work and give you ideas for improving your own workflow. For example, check out Must Have Git Aliases: Advanced Examples. Mathias has a really popular .gitconfig in his dotfiles collection that has almost 10K Github stars:

Here’s mine: