Our engineering principles at Chalkboard

Every technology company usually has a handful of guiding principles whether they realise it or not. At Chalkboard we know we have a core set of engineering principles that we believe are important to the way we work as a team and help us to make the best product possible.

Confidence

Startups are known for rapid growth and developing quickly. Quite often this comes at the expense of not having a good test suite or not having a test suite at all. Eventually, lots of teams learn the benefits of testing and as a team matures it's common to see the testing process grow.

At Chalkboard we already have a mature test suite and we endeavour to maintain it as part of our development process. It provides us with lots of benefits: we can have confidence in our new code or changes to the code base, we can have confidence in our deployment process that broken code won’t make it to production and we’ve found that although it takes time and effort to write and maintain the test suite it saves us time in not having to revisit features over and over to troubleshoot or bugfix.

Our test suite covers everything from unit tests to integration tests, from API smoke tests to end-to-end tests using browser automation.

Product

The best features of a product are often a result of tight collaboration between product and engineering. Important for the product team to be able to understand and communicate user behaviour to engineers, as well as for engineers to understand and communicate what the technology can achieve.

This relationship takes effort and ensures that as much information is shared and communicated during the product development process. It also needs engineers that care about the product and actively want to share their knowledge and ideas for tackling the user problems we’re trying to solve.

At Chalkboard we regularly surface and communicate the what and why of product features so we can effectively collaborate on the how.

Technology

We use the best tools for the job, but they need to be proven and they need to have a valid use case. We like the next shiny piece of technology as much as the next team, but we know we need to keep a level head and evaluate it.

We are wary of taking on new dependencies and will try to see if we can avoid adding a new dependency if possible by seeing if it's worth taking on work ourselves (within reason of course!)

Where we do feel we need to use a new dependency, we will spend time evaluating new packages, looking at the wide community as well as GitHub issues, repository activity etc. to see what the general pros and cons are. We’ll also take time to do a proof of concept where relevant so we can really see how a piece of technology works for us.

Lastly, we’ll always tap into the wider team and their experience to see what input they can give.

The above approach has led us to use many tried and trusted technologies (Postgres, Node, Express) as well as new tools like GraphQL and Typescript, all of which provide large benefits to our development process and ultimately the product we build.

Words by: Rhodri George - Engineering Manager

Does all of this sound good to you? Want to know more or join the team? Check out our careers page – we’d love to hear from you.