Emulating Unicorns

I'm sure most of you are familiar with the term Unicorn - a startup that reaches a valuation of $1 billion USD.

Those companies often offer great working conditions, and manage to recruit the top talent, meaning they have really smart engineers, and processes that work really well to develop, test, and deploy quality software. Oftentimes, they also publish their best practices on the internet for everyone to learn from.

If you are a novice, self-taught, part of a small team, etc. those practices are a great fountain of knowledge, and I encourage you to look at the way the unicorns do things, and emulating their processes in your own projects.

Of course, not everything they do should be emulated - Netflix' Chaos Engineering may be too risky for you, and microservices are probably overkill.

Today I will introduce you to two practices I have borrowed from leading internet companies.

AirBnB JavaScript Style Guide

Like any good programmer, I am lazy. This doesn't meant that I don't like writing code or work... I simply don't want to spend ten minutes thinking about how to structure said code. Thankfully, the folks at AirBnB have published a style guide that I have discovered when I started working with the Quasar framework. Using ESLint with the AirBnB rules improved my code a lot... It is now consistent, and I don't need to rack my brain about every decision - when to put a semi-colon, whether to use a trailing comma in an object, list, etc.

Of course, there are other style guides out there, and you may have your own preferences. If you don't already use a linter for your JavaScript code, do start. Gloss over the style guide, refer to it when your linter complains, and you'll see - writing in a consistent style will soon become second nature. Remember to be adaptable; if you join a company that has its own style, use that, and if you dislike some rules, feel free to change them (or use another set of linter rules).

Angular Commit Messages

I have used the word "consistent" twice in the previous section. To be honest, I really like consistency, and this tip is in the same vein. Sometimes I help people online with various questions, open their repository, and see all their commits look as follows:

• fixed bug
• refactored some code
• changed some stuffs
• added some stuff

Of course, we all continuously learn, and I have certainly been guilty of this myself in the past. Then I have read the Angular Commit Message Rules. Like the AirBnB JS style guide, this has helped me write more consistent commit messages, making my git log much clearer, more readable, and also allowing you to easily write parsers to generate CHANGELOGs.

Commit Message Rules

I encourage you to read the original document, but the TL;DR is that a commit message should have a header, consisting of a mandatory type, optional scope, and subject, followed by a body and a footer (which are not marked as explicitly mandatory, and I often skip them).

Header

The document defines some mandatory types (build, ci, docs, feat, fix, perf, refactor, style, test). Depending on your project, you can always use a different list. I mostly use feat, fix, docs, build, and test.

The optional scope includes animations, common, core, http, router, etc. As this is for the Angular library, this makes sense, but it does not for my personal projects. As I often use monorepos with Docker, Django, and a VueJS framework, my scopes are often docker, back-end, and front-end.

The subject should use present-tense (change, not changed), and not use capitalization or periods. Personally, I don't mind that style at all, and emulate it. If you prefer something else, feel free to start with a capital letter and end with a period - just make sure that you stay consistent. Consistency makes codebases easier to work with, and onboarding more pleasant.

Some examples:

• feat(front-end): add component Foo
• fix(docker): rename network mynte to mynet
• test: add unit tests for component Foo

Conclusion

This was a brief overview, so follow the links and read the original documents - they offer far more details than this post.

As always, be pragmatic. Take best practices and apply what makes sense to your projects. If you disagree with some rules, make your own. If you work with others, communicate with them, and write your own linter rules or commit message guidelines so the entire team is on the same page. If you join a new company that has its own established practices, follow those. If they don't have any, maybe borrow them from a unicorn, and become the office hero for a little while.

What about you, have you taken inspiration from any other projects and improved the way you work?