This site is a round-up of how Human Made works internally, covering everything from our client projects to the services and products that we offer to users and developers. We cover how our development process starts from the day we get an inquiry, through to maintaining existing projects for years to come. The stuff we talk about explains who we are, how we create great work every day, and what we’re looking forward to in the future.

Philosophy

  • Completion

    Sometimes, software is just done. It’s important to recognise this, and draw a line in the sand.

  • Projects vs Products

    We work on both projects and products, and each has a unique style.

  • Roles and Growth

    How we think about seniority and career progression.

Process

Everything that happens during development, from start to finish.

  • Development

    How we create.

  • Reviews

    Every line of code we ship needs at least two sets of eyes on it.

  • Deploys

    Time to ship? Find out how.

Style

We have our own set of style guides for projects we work on. While we follow the WordPress style guidelines for the most part, there’s a lot of things those don’t cover.

Note that these are simply guidelines, and you’re free to deviate from them if you want to. We’re always improving these, so if you come up with something better, propose a change!

We also check our code against these coding standards programmatically, with packages available via Composer (humanmade/coding-standards) and npm (eslint-config-humanmade).

An Important Note

One of the key aspects of Human Made is individuality. While we’re publishing this site with both descriptive (“this is how we work”) and prescriptive (“this is how we want to work”) information, it’s important to note that these are guidelines, not rules. We often debate various things internally, and projects can have inconsistencies from each other. Sometimes, this is a good thing. The flip side of consistency can be monoculture, where experimentation is discouraged.

Engineers can often get caught up in issues like “what’s the best way to do this?”. While we obviously want to work from the best possible starting position, there’s nothing to say you have to stay there. Take the best that’s available and run with it.

Experiment. Deconstruct. Rebuild. Blow it all away and start from scratch.

Some of the best projects come from a dissatisfaction with the status quo. If there are things in this guide you disagree with, fix them. Nothing will ever be perfect. Maybe something that’s annoying you today turns into a better tool for everyone tomorrow.

This guide is a living set of documents, and will be updated as we continue to refine, refactor, and rebuild our processes and tooling.