Why aren’t you more like Github?

Photo by Chris Ried on Unsplash

Two years ago I decided to take up coding. I had been on the outskirts of it most of my career, running product, data and design teams.

As I followed the online courses and wrapped my head around javascript, react, redux, next.js, node, express and a gazillion other things, one thing kept blowing my mind: The tooling.

For people without coding experience, it is hard to imagine. It’s like there’s a secret world only developers can access. At the same time, these tools are treating rather matter-of-factly inside the community. Why wouldn’t you be able to do hot-loading and instant rollback?

I feel like regular productivity tools can learn a lot from the developer tools. Here is short list of features from developer tools that I wish my productivity tools would adopt;

1. Commit messaging

Whenever you save code to Github, you’ll add a commit message. This is a short description that summarises the changes you’ve made or what the version does. This gives you a changelog with each change described at the aggregate level.

For anyone who ever collaborated with anyone on a spreadsheet or a power point, this really is a no brainer. Sure, the message will take a second to type up, but the papertrail is incredibly and it saves you from resorting to file naming as a changelog (“Business case, JS update 1,2.xls”). Letting yourself and other people know at a glance what you did and why is deceptively simple yet incredibly powerful.

2. Automatic change tracking

If you’ve set your version control up properly, even single change to your code will properly tracked. It won’t upload or overwrite anything until you decide to do so, but locally you can easily see every change you’ve made. Once you are satisfied and upload, you can then see every individual change highlighted by version and know exactly what changed between the individual versions.

Regular productivity tools will often require you to actively (and intrusively) “track changes”, but predicting your need for it is insane. I don’t understand why a change history isn’t more readily available for my normal productivity tools.

3. Rollbacks

If you have made a mistake or deployed a faulty piece of code, Github and other tools let you revert back to any prior version. If you made the mistake earlier on, simply go back to an even earlier version. Branching and merging further assists this, but at its core the ability to freely timetravel across every state and version of your work is amazing.

Having to revise and then revert all of your changes in a power point because some C-level person changed their mind is a classic. Once that’s done, you just know they will decide that maybe it was better the other way and you spend the night changing the titles again.

4. Customisation

Developer tools often allow a tremendous amount of customisation through plug ins and modules. Often developer has his or her favority configuration and setup of Visual Studio Code or Atom, often radically changing the core functionality. Highlights, automatic formatters, short hand snippets and much more increase the productivity of a developer masssively and lets them tune the experience to fit their exact preferences and woring style.

Considering the incredibly number of people who use Word everyday, the experience is unbelievably uniform. The minuscule customisation feels tacked on and people learn how to use it instead of bending it to their will.

5. Community

Most of the core tools of a modern javascript developer (which is the technology I dipped into) are built on assumption of open collaboration and community. Sure you can make repos private on Github and publish private packages on NPM, but both by default expect everything to be shared publicly, allowing others to use it freely and get inspired by your work.

Every time a thorny problem arises, a quick search will find discussion threads on Stackoverflow, sample code on Github or Codesandbox or outright packages solutions that you can either fork or directly import into whatever you are building.

This ethos of openly sharing your work for the benefit of everyone permeates the developer tools, but is notably absent from regular productivity tools. Building a power point is an incredibly lonesome experience and any additional ressources are carefully selected and curated by the creators of the programs. I hope you like the icon sets or smart art that they selected, because that is all you will get.

Just like developers trail blazed the thinking about agile work practices and culture, they are also at the forefront of tooling. But the inspiration and cross pollination that I see in the ways of working seems absent in productivity tools. The big guys (even Google!) seem stuck in a concept of what our productivity tools are and how they should work. I would really wish the people building these would take a page from the tools they are using to build them.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store