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.
Sometimes, software is just done. It’s important to recognise this, and draw a line in the sand.
We work on both projects and products, and each has a unique style.
How we think about seniority and career progression.
Everything that happens during development, from start to finish.
How we create.
Every line of code we ship needs at least two sets of eyes on it.
Time to ship? Find out how.
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.
Extra guidelines for writing modern (namespaced) PHP.
Extra guidelines for writing modern (ES6+) JS.
Guidelines specifically for writing React apps.
Guidelines specifically for the output in the DOM.
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!
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.