Following suit of the previous blog posts I should probably start with introducing myself as this is my first blog for Civo. I'm Niall and I am one of the Rails developers here at Civo - I can't make things look pretty but I do make them work; you may have also spoken to me already as we all answer support queries via Intercom.

In general at Civo, I like to think we have a great attitude towards development. We aim to introduce new features as often as possible, especially ones suggested by our users and we also try to fix bugs as quickly as possible - even if that means deploying on a Friday which we do here anyway.

Scratching your own itch

A prime example of launching new features (no matter how big or small they are) is a recent feature I worked on: new login notifications. Most of our users have probably received at least one of these emails by now, but don't worry if you haven't we purposely didn't send you an email for existing sessions as we didn't want to frighten you all at once.

This feature came about because I received an email one weekend from another service I use as there had been a new login to my account, which was just me signing in from my new home IP address. Straight away I thought, that would be a great feature for Civo and I was quietly confident we had all of the information required to achieve it. On Monday morning I mentioned it to the team and was informed there's actually a couple of suggestions for a similar feature (as well as some other functionality).

Later that day the work was completed, along with the additional suggestions from our users and was deployed to production (it also meant we could close those open suggestions). This is just one example of how open to new ideas we are and that there were no hoops to jump through just to get the "higher powers" to approve a feature.

Squashing bugs

Sometimes it is not as simple as fixing a bug and getting it deployed as there could be knock-on effects for other parts of the code or it could just be a something we cannot get to the bottom of right away. In these cases we would add the bug to our internal issue tracker so that is not forgotten about.

But a lot of the time bugs are just minor details that have slipped through the net, such as an HTML element missing a closing tag which is causing the page to render incorrectly or simply a broken link. I know that in some "bigger" companies no matter the size of the bug it must be documented, tracked and scheduled, but not at Civo. In the time it's taken me to do the aforementioned tasks I could have fixed the code and pushed it back ready to deploy - which is exactly what we do. Many times when Civo first launched I would tell Andy "I found a bug" and his response would be "well fix it and push it back".

I'm a huge fan of working in this way and also believe it breeds confidence within the team.