DEV Community: Guillaume Montard

What I learned building a Developer Tool

Guillaume Montard — Wed, 09 Oct 2019 15:24:18 +0000

A little over 18 months ago, I launched a developer tool called Bearer.sh.

Recognizing the lack of tooling for API integration to be a major pain among developers, I wanted to solve this problem through a developer tool. But, to be honest, I didn’t entirely realize what building such a tool meant.

A developer knows what to build

What is amazing when starting a developer tool, is that being a developer yourself, it’s very easy to reflect on your product; it’s thrilling. However, it’s both a blessing and a curse, as you need to constantly challenge your own perceptions and experiences, to make sure your points of view always reflect those of your audience.

We started with what I call “the positive arrogance of founders”—knowing what others need. This is illustrated well with the famous Steve Jobs quote:

"...customers don’t know what they want until we’ve shown them."

While this may be true, it does not preclude you from conducting in-depth discussions, asking questions, and eventually summarizing the different pains, personas, and opportunities of your clients. All these enable you to craft well-fitting solutions for your customers; these will become your products.

To this end, I strongly suggest doing a customer discovery*; we eventually did one, thanks to our great advisors!

What is a developer tool?

You have probably heard the terms low-code and no-code a lot lately, but don't mistake them for developer tools!

No-code solutions are for building software without coding. Some of the best examples are Zapier, Airtable, and Bubble. Most of the time, they are targeted, by design, at businesspeople that don’t have the technical skill or time for coding, setting them free from those barriers.

A low-code solution enables the building of software by coding using a simplified tool, for a fraction of the time and resources a traditional approach would take. These solutions are all about simplified code and they mostly appeal to IT professionals, releasing them from the need for engineering resources. Some examples are Appian, Salesforce App Cloud, etc.

Developer tools are about helping people build software by providing better application development ecosystems. They focus on core business problems instead of reinventing the wheel. Whether Algolia for search, Sqreen for security, or Bearer for API integration, each tool is all about helping engineering teams.

As “software is eating the world", given the increasing shortage of engineers, at every level of the pyramid, the industry is pushing for more abstraction.

And as you can imagine, both low-code and no-code solutions rely on developer tools :)

Simplicity vs Complexity

To build a great product, user experience is paramount; it especially has to be as frictionless as possible, even more so in the early days of use.

When we started, I thought it was about building something complex; we got as far as building a framework. Our intentions were great, but I forgot something very important, most people don't have time to learn something new, at least not right away.

Compared to SaaS or no-code solutions, developer tools, in particular, need to be versatile. Indeed, developers have different use contexts and cases, so the tools have to be appropriately adaptable, despite lack of prior knowledge of each individual set of requirements.

What we've seen is that most developer tools tend to add complexity over time, requiring increasing levels of user input. Developer tools are built around complexity layers. The first layer has to be attractive and easy enough to encourage a user to invest a little of their time and energy. Then, with further use, additional layers are added, handling more complex use cases.

This simplicity vs complexity is the biggest challenge when working on developer tools.

In the end, perfecting this mix, of simplicity and complexity, creates the secret sauce that makes a developer tool successful. It's also the most exciting challenge for me 💪

I'm happy to answer any question you might have below or on Twitter

Don't use API Clients 😅

Guillaume Montard — Thu, 26 Sep 2019 16:05:26 +0000

At bearer.sh, I've been interviewing dozens of developers and experts to understand how they build and manage their API integrations.

I've compiled those findings into a series of blog posts, here is the first part below, that is all about API clients.

First, why should I care?

Because as the number of integrations you build tends to grow, consuming all those third-party APIs at scale becomes a real technical challenge.

Integrating one or two APIs is not always that complicated, but when it comes to build dozens of integrations, each providing key business-critical components to your application, that’s when things get more complex (and interesting!). From there on in, you realize that every API is a single point of failure that needs to be managed accordingly; dealing with technical debt and security is going to be paramount.

Using API clients?

How difficult can it be to consume an API, after all? It’s not like it’s something new, right? Sadly, it is difficult, and it's at that precise moment we usually all make a critical decision:

Hey, I've found an API client for xyz API, let's use it it's going to go faster

But, what we've found out is that using a dedicated API client is the best way to build technical and security debt over time. When you think about it, most of the time, those API clients are just nice wrappers over REST calls. Ideally, they are provided and maintained by the API vendor, but it is more often not the case.

Imagine yourself consuming dozens of APIs, not an unusual feat, it means relying on dozens of dependencies,+ their own in turn. This will translate into numerous updates and security patches over time. Add to that the fact that, every API call will look different in your codebase; you quickly realize this may not be have been the ideal decision!

By the way, would you query your DB using a different client for every table? Different methods? It's not just because data comes from an API, that you should suddenly forget all your best practices.

From that single unspoken decision, the impact over time is going to be dramatic.

Great, what's the solution?

First, the keep it simple stupid (KISS) approach would simply tell us to query the API using a regular HTTP client (axios, httparty etc.). Yes, It is going to be more verbose, but is that a bad thing after all?

The ideal solution that we've seen is to build a dedicated service, responsible for querying all your third-party APIs. This way, every integration will rely on the same pattern, structure, and dependencies; you will be able to improve this service over time, and by design improving all your integration's codebase. You can think of it as a micro-service or a module for example, depending of your preferred architectural choice obviously.

And finally, you can also give a try to our universal API client if you don't want to reinvent the wheel 😅.

I'd love to know how you build and manage your integrations, tell me more in the comment section below!

Starting a remote-first and multicultural-first company!

Guillaume Montard — Fri, 06 Sep 2019 14:38:46 +0000

This post was originally published on our blog, where we usually write about startups, remote and APIs!

I've started a remote-first company 18 months ago, called Bearer. Not only as a remote-first but, in fact, a multi-regional, multi-cultural, multi-lingual too!

Since we’ve been running the company this way for more than a year now, I wanted to take the opportunity to reflect on the culture and process we've built, hopefully answering some questions anyone might have with what it's like to work in such companies.

Why a remote-first company?

To be honest, it all started mostly out of necessity before becoming an opportunity, and nowadays our company’s core value!

In the beginning, my co-founder was based in Scotland and myself in France; effectively, we were a remote-first company before we were even a company. We were remote-first founders.

Our ambition, with Bearer, was to build a company and we had a certain path in mind: To be able to cross the Atlantic, sooner rather than later, and become a multi-cultural company as a result. We've seen some of our friends’ amazing companies, like Algolia or Sqreen, follow this path. We realized we had an opportunity to learn and lay the foundations for a company that could scale continents, cultures, languages, and time zones, so we doubled down on it!

When we officially kicked-off the company we were a team of 5, across 4 cities in 2 countries. Everything was done in English, as it was the only way to communicate together, despite none of us being native English-speakers.

Today, we are a team of 10, across 3 countries and located in 4 cities. To give an even broader view, one of our team members traveled around Asia for six months while still working with us. Finally, in the coming weeks, we have one member moving to South Africa; obviously, she will continue to be Bearer 🐻!

Running the company

In a remote-first company, we quickly learned that communication is paramount.

We tend to often hear that engineering-focused companies are better candidates for remote working. I'm not sure; have you considered, for instance, if:

Communication is an engineer’s strongest suit?
Writing is an engineer’s best skill?

Communication, for us, meant setting up processes and tools, then finally, writing down and recording everything! Add to that the fact that 70% of our team has to do all of this in a foreign language and we have a serious challenge to tackle 💪.

We've set up some processes and rituals to help communication flow well between everyone and to make sure we can all give our best.

To give you a better understanding of how this works, some of our weekly rituals are:

Every Monday morning, at 9:30 am, the team receives a weekly note from me, some news etc. (thanks to Mathilde Collin for the trick)
Every Monday morning, at 10 am, team leaders meet with the founders, for 30 min, to talk about current projects
Every Wednesday, at 10 am, we have a 15 min remote-coffee break with whoever feels like it, to have casual chat about anything
Every Friday, at 11 am, we have a weekly demo (recorded) where everyone can demo their progress and share some knowledge

Then, once every Quarter, we all meet through an offsite for a week in a nice location; the next one is in Portugal 🏝. Outside those, team members can freely travel to meet each other when needed.

We also have some communication policies:

Every discussion is held using public channels (100% in English)
Every key technical decision is documented as an RFC and discussed
Every project is documented and can be commented on by anyone
Every day off is reported on a shared calendar sending Slack notification

We are careful not to create too many processes, giving the team freedom to explore. For instance, engineering team leaders’ only requirements are to have a public kanban-style board and a weekly discussion with founders; then they are free to manage their team and communicate however they want.

The office question

We have an office in Paris, a real one. This sounds a bit counter-intuitive for a remote-first company; however, this office can host about 10 people and is usually filled with 3, at best, including myself, and that's perfectly alright.

Our Scotland-based team members work entirely from home we happily provide them with a co-working space whenever they want one. They get together for pizzas on Fridays! In Poland, our teammate has his own office in the city of Gdansk. My cofounder works from his home, now in the north of France, in Dunkirk, and comes to the Paris office once or twice every month.

Working exclusively from home is not for everyone, and is certainly not for me, while it is for my-cofounder. Remote-first shouldn't be a synonym for working from home, it should mean having the liberty to decide and receiving the same support, whatever you choose.

Conclusion

Is remote-first working for us? I'd say yes!

We have an amazing team: highly-skilled, passionate, and truly committed. In return, we can offer them, probably the best perk, the option of working from anywhere.

To make it work, it all comes down to a simple value, trust. Without trust, I don't think it’s possible to make a remote-first company successful, even less so a multi-everything one.

Feel free to ask me anything in the comment section or share how you work in your remote-first company!