Walking up a hill

The image at the top of this article is one I took this weekend at Flamborough Head in Yorkshire (UK). Ask me about it on twitter if you like!

About six months ago, I started working for a brand new shiny startup called Gradient. When I started there were three of us (including myself) and now there are 4 of us.

We're making something that I think are really cool so I thought I'd take a few minutes to list out things I've learned since starting here.

1. Doing software right to begin with saves time in the long run.

Okay, so I haven't really just learned this now but it's the first time I've been part of a team that is eager to build good software the first time around. Over the last few months Simon and I have crafted architectures which slowed us down to begin, but now we're faster than we've ever been.

Our tests cover the API, the frontend, and the database. We're striving for high test coverage and even at this stage I'm surprised by my own confidence during a deployment. We've yet to break anything in a deployment and we've been diligent about adding tests before implementing fixes which has worked wonders.

Our API is also staggeringly simple to extend. While we were getting going we crafted some great middleware oriented systems, now I only need to touch 3 directories to implement a new endpoint and then I can get on with writing tests.

2. Be intentional

Intentionality is important in many aspects of life. Recently I've learned more and more how important it is within a tech startup. We're constatly trying to be intentional and mindful of the culture, our people, the brand, our product design, our APIs, our open source code, and so many other things.

A regular flow with us these days is to sit back for a few minutes before approaching a task and just talk it through with someone. Generally this brings out even more ideas and excitement.

3. Be open about both problems and solutions

We're trying to talk about everything we do, from the problems we're having to open sourcing our solutions. We've already released a number of small node modules, and soon we're hoping to open source a huge chunk of our authentication services.

But it's not just code problems we're talking about. We are also managing to talk about business problems as well. Maryam, one of our folks on our marketing team, spent time talking about our CRM solutions. We figure that if we fail, we can at least document it for ourselves, and others, in the future.

4. Always lean towards shipping it

The 1.0 is always the hardest, and we're really feeling it right now. We're sprinting for a self imposed deadline, but simultaneously triaging new ideas and fending off feature creep. We have to lean towards shipping, even if it isn't perfect.

Side note: this doesn't mean shipping shit, it means shipping things with fewer features.

This is something I'm bad at with my blog. This article has been sitting here unfinished for the last two months. So I'm shipping it today, and I'm going to publish more of what I write. It's the only way I'll get better!