Tips and tricks of a tech startup CTO

Arnaud Lachaume is one of the brains behind the creation of Keypup. He is responsible for the company’s core technologies and ensures that the platform evolves smoothly, that our technologies remain state of the art, and that we have a strong, innovative, and well-implemented development strategy. 

He has accepted to share his everyday life at Keypup as a startup CTO. He explores software strategies, maintenance and security guidelines, and some productivity tips. Read on!
‍

What’s your software stack?
‍

We use Ruby on Rails for backend development and React for frontend development, with a GraphQL API in the middle to expose our business data and logic.

The whole platform is split into small microservices communicating with each other via API and Pub/sub.

We use Google Cloud Platform - and more specifically Cloud Run - to host our backend infrastructure and Cloudflare workers to distribute our React app globally.

If you are interested in learning more about our deployment topology, we’ve done some detailed write-ups on our blog!

• GCP deployment, a complete guide
• Deploying a SPA using Cloudflare workers

How do you maintain your apps over time?
‍

There are mainly three topics to consider beyond feature development.

• Security: making sure our code and libraries remain secure over time
• Tech Debt: preventing code and libraries from getting old and difficult to maintain
• Performance: ensuring our components cope with the load as the number of customers and use cases evolve.
  

> Security: making sure our code and libraries remain secure over time

Our first move is always to set up static code and dependency analyzers as part of our builds, such as brakeman, rubocop, and bundler-audit. Even though rubocop is not a security tool, strictly speaking, I still consider it to be part of our security suite because clean and consistent code greatly helps developers spot potential weak points.

Activating Dependabot on GitHub also helps with keeping your dependencies up to date. Having a bot monitor your dependencies and automatically opening PRs is a real time-saver. 

Beyond this, I recommend using bug bounty services such as Detectify and Yogosha.
‍

‍

> Tech Debt: preventing code and libraries from getting old and difficult to maintain

There is no silver bullet for this one, it’s a philosophy of life:

• You need to dedicate time every week or month to review and update your components. 
• You need to take the time to refactor code when you see something wrong
  

The key is: “Take time”.

Sometimes it means pushing back a feature release because you discover that a whole section of your codebase needs to be rewritten in a more scalable way. 

As a CTO it is your responsibility to have these difficult conversations. The quality of your product and the mental sanity of your engineers is at stake. There is nothing more depressing for an engineer than working on a spaghetti lasagna codebase (yes, layers of spaghetti code).

Again: “Take time”.

> Performance: ensuring our components cope with the load as the number of customers and use cases evolve.

You first need to have the basics covered, which are:

• Use a monitoring tool, like New Relic, Data Dog, or GCP/AWS monitoring tools.
• Build meaningful dashboards to monitor your infrastructure. What are the key metrics for your customers?
• Setup meaningful alerts. Be careful not to spam your own dev team either. If your alerts throw too many false positives then they will stop looking at them altogether.
  

Once you have the basics in place, the monitoring work becomes an iterative process:

• Check your dashboard weekly (at least)
• Identify if you have enough data to explain the slowness of things

• If no, then add more tracing calls in your code

• Once you’ve identified a slow part, take the time to address it
• Wash, rinse, repeat

‍

What are some basic guidelines about development that every developer should follow?
‍

Take the time to think about your implementation. 

It’s normal to be eager to jump on your IDE when you get excited about a new feature - but generally, I don’t recommend doing it.

Think about the following questions first:

• What are the sub-problems of my problem? Decompose your feature into smaller problems.
• How is it going to impact the platform? The component? The performance?
• What is going to fail? Something is, and you need to find it.
• What will happen if the usage numbers I have in mind are multiplied by 1000? Is it scalable?
• How will someone abuse my feature? Someone will so put yourself in their shoes.
• Is there any library or service out there doing what I want to do? Can I leverage these?
  

I usually like to start thinking early about upcoming features, while I’m working on more imminent matters. Passive thinking is something you should leverage as a developer.

What free productivity tools do you use?
‍

GitHub and VS Code are the two main tools I use every day.

For architecture work, I use Lucidchart. For quick mockups, I usually go for Google Draw even though there are more efficient tools such as Balsamiq and Lucidchart as well (though I haven’t tried it yet).

How would you describe your team management style?
‍

Flex. I try to shield my engineers as much as I can and give them space so they can work in peace, have reasonable time to implement AND refactor and have time to think about improvements for the overall platform.

It means I place a lot of trust in my engineers and give them a lot of freedom. I rely on common sense and intelligence. Now if someone abuses that then I’m not flex anymore!
‍

Any side projects you are working on?
‍

Most of my side time is dedicated to Cloudtasker and Cloudenvoy, our open source libraries for GCP Cloud Tasks and Pub/sub respectively.

What is the thing you wish you knew before starting development?
‍

Don’t underestimate the unknown factor. Always double the estimates you initially planned to give.

You are working on code written by others. When I say “others” it includes you three months ago. You are going to discover things along the way that are not compatible with your envisaged implementation. From there you can force your way in and write terrible code or you can take the time to refactor.

Take the time to refactor, without creating surprises for your stakeholders. Double your initial estimates and everyone will be happy in the end.

How do you end your coding days?
‍

Here is my end of the day to-do list:

1. I close my laptop
2. I feed Mister Croquette - the rabbit of my cofounder, which I’m currently rabbit-sitting
3. I go for a run
4. I go for a beer

What’s your n°1 time-saving tip for software development?
‍

Add this to your bash_profile:

alias rubospec='bundle exec rubocop -a && bundle exec rspec'
alias frs="[ -f Gemfile ] && foreman start || yarn start"

Yes, I’m keyboard-lazy

Did you enjoy this interview? Share your thoughts on Twitter, happy to chat!

‍