From messing up my company email password on the first day (I blame the AZERTY keyboard) to spending my first week at a new company doing customer support. That last one was the best onboarding experience I have ever had. It allowed me to work with a team that was not my team, but that I was going to work very closely with, and it also helped me navigate this new product and code base, I was going to work with every day more in-depth.

This onboarding was back in 2016 at Travis CI. Usually, the onboarding there consisted of some weeks of Engineering onboarding, and then on the third or second week, you would get the customer support onboarding. In my case, because of time constraints, I did it in the first week. It was the best way I could have had it; once I was doing my engineering onboarding, I already had many questions about the code and architecture and a better idea of the company and team structure.

At the time, customer support was important at Travis CI. There was even a customer support rotation for engineers to spend a week helping with highly technical tickets. This rotation was controversial amongst engineers because, for sure, it took time from your engineering tasks, and we were shipping slower. Still, it gave us a better vision of what customers needed. In the end, we were building a tool for other engineers.

I wonder if doing customer support onboarding directly when you join a company could be done (and be helpful) in all companies or just in companies building technical tools. It can give you a pretty good idea of how the company is doing and give you a broader view of the business. I enjoyed doing it, and it gave me a break from coding, but it wasn’t easy. Debugging errors on builds or understanding what the customer needs was challenging. Customer support folks need to be appreciated more for their work.

Building a product is hard. Building a new product from scratch is even harder, especially when the resources are limited. Building a product that will be used or that will be set up by developers comes with some extra tasks. One of them is public documentation.

On a team where the project is constantly changing, and the scope is only the quick view of what you want to achieve, development and documentation can be tricky.

You can’t start coding until you fully understand the ultimate goal of your feature, and you can’t write proper documentation if you don’t understand what you are building either.

Ok, in a perfect world with unlimited resources, a team would have someone dedicated to documentation, but that’s not the reality for many startups.

During this last year, while working on a feature that had very little information (scoping). I had this idea, that when things are not clear, an engineer should start with documentation. A documentation-driven development if you like.

Writing and explaining first what your feature does will give you clarity, you will get reviews from Product or your peers, and mainly you can get alignment if this is what you should be working on. If it isn’t, other conversations need to happen to clarify things.

I have used this method once. It did help me. I was lost on a feature I was working on. Starting to write about it brought me so many questions, and, at the same time, I was doing the public documentation that was still needed and part of the project.

This method seems to be used in other places. If it’s a fit for your, will depend on your team and company needs.

But, I do miss feeling comfortable. I miss using tools I know, the community, and especially, I miss feeling fast. This is likely related to the context I was in. I was learning Elixir while developing a brand new product and building a company, while… let’s leave this story for another day.

I’ve worked with Ruby since 2010, had some time where I was working mostly with AngularJS, then back to Ruby, then focused on Management, then Elixir, and now that I have some unexpected free time, I would love to get back to it and experiment again, but who knows where I might get along the way.

I’m very outdated in the Ruby world. I will take this opportunity to start blogging and share my journey. It’s been on my mind for a long time, but never really found the time or energy to do so.

Let’s see what happens!