DEV Community: Francois Stephany

Triathlon training ≈ Startup life

Francois Stephany — Thu, 29 Aug 2019 13:35:59 +0000

I've completed my first triathlon last week and it struck me how similar the journey to the race was to what I'm experiencing in the creation of Bismuth.

Starting Point

When you're not an accomplished athlete, signing up for a triathlon is not something you do lightly. I was an avid runner in 2012-2015 but have stopped training since then. I regularly commute by bike (~9km each way) so my legs were still in shape but I've hardly done more than a 20km trip in my life.

When a friend asked me to join a small group of wannabe triathletes training for La Gileppe Trophy Orbea it was hard to resist. We would not train for nothing: we had a well-identified goal. This is very different than just aiming for an abstract objective (being a triathlete).

The same goes for a startup. Aiming for startup life should not be a goal in itself. You should have a more concrete plan.

Team & Network

The social aspect of the endeavour should not be underestimated. We were a group of five guys training for three sports. We were scattered throughout the region (Mons-Brussels-Liège, Belgium) and had only a few trainings together. It made little sense to meet for a one-hour run/swim when you live 2 hours away from each other. We had a couple of longer bike trainings on Sundays though.

But not training together did not mean that there was no network effect. Strava logs and a Facebook group conversation are powerful motivation tools. We could greet ourselves when completing an early morning swim session or a late bike ride. The odds that I took my bike for a spin after a long day were a lot greater than if I was alone. It's way too easy to postpone a task when you are the only one in town.

Humor and camaraderie work well when you are in doubt and think that you're falling behind. Sharing content and training tricks maintained the interest and made sure we learnt faster.

The same goes for a startup team. Being alone is good when you need to be focused on the work but interactions and discussions are important for ideation, motivation and mental health.

Planning

Even though we registered for a short distance (triathlon sprint), one of us showed up with an ambitious training plan. It looked a bit too much for me. I knew from the start that I would not be able to follow.

And it's alright. Sticking to a training plan you know you cannot follow is a stupid idea. Tune it down until you're confident you can make it.

On my side, I hadn't swam for ages and could barely cross the pool without losing my breath. Bike was ok-ish thanks to my commute but longer distances were an unknown territory. Running was my strongest point as I had trail running experience and knew the sensation in the legs and in my brain throughout the effort.

Knowing this, I created a plan custom tailored for me. I still don't know if it was optimal. It probably wasn't but it got me through the race without any hiccups so I consider it a win.

Execution and unplanned changes

Having the plan is only the beginning. This is something you cannot delegate, you're the one in charge. Here again, the peer pressure of the group is important. You are not accountable to them but you don't want to be the lazy ass that does not do anything.

Beware though. I've quickly noticed that social life can make it challenging to follow the plan. Up for a beer and pizza tonight? kind of text will challenge your focus and dedication. There's a balance between turning into a social hermit and going out every night. Keeping the pizza but swapping the beer for sparkling water is the kind of compromise I was willing to make.

A recent interview of Katie Arnold showed that with a bit of creativity, you can mix a social life with kids and strong long distance training.

At my level, the plan is just a guideline. The goal was not to finish in the top 10, so flexibility was more important than performance. In a startup though, you might aim for more. This is okay but be aware of the impacts on your life.

Polyglot

Triathlon or how to be mediocre at three sports

Swim, bike and run are different disciplines. Being at least decent in the three of them is the whole game. For me, it was a revelation: it is much more fun to train for three sports than focus on one.

In a startup, founders are usually doing a bit of everything. They need to juggle between sales, code, marketing, raising money and more. The result should be a balance between these tasks. Of course, the balance is different at every stage and the founder must quickly react to a new situation.

This diversity is extremely challenging but also super fun and rewarding.

Learning & staying humble

Starting a new endeavor is always full of lessons. In triathlon training, you learn to listen to your body. You experiment. You learn how you can improve efficiency by adjusting your swimming strokes. You listen to advice (try your wetsuit in open water before race day!). Some are valid in a context but not in another. Keep them in mind though, they could be useful one day.

You're the beginner with no experience. With practice, you will build confidence and find your rythm. Be patient but don't be passive.

Knowing when to slow down

In the second month of training, a pain in my knee started to develop. I slowed down training and quickly identified that the pain came from running. When cross-training it can be hard to identify a single source of trouble but in my case it was easy: my running shoes had more than 1000km. Fortunately, summer sales are always good to buy new shoes and the problem went away as fast as it appeared.

Not taking the time to slow down and identify the issue could have dramatic consequences. The same goes for a startup. You should always listen to your feelings (and to metrics) and adjust properly.

Equipment is not that important

Some would believe that you need top-notch equipment to complete a race. This is far from true and the only two technical pieces of equipment you need is a swimming wetsuit and a bike.

The bike is by far the most expensive thing you'll need. The best bike to start with is the one you already have. A woman finished the triathlon on a foldable Brompton and a lot of riders had mountain bikes. Find a cheap second hand bike on craigslist and start riding.

Nowadays, most startups can be launched without any specific equipment. A laptop and a phone are all you need to get started. You don't need a $3000+ Macbook Pro or an expensive SAP license to get started. Be smart about it and gear up only when you need to.

Be hungry for more

This is just the beginning of my triathlon journey. The sprint distance was a nice start but in the end of the race I still had some energy left. This means that training was good enough and that my body and mind were ready. The whole race was fun and a lot of endorphin was released that day. It's time to plan the next one. I'm tempted to go for a longer distance this time.

I've started to work full time on Bismuth at around the same time that I started to train for the triathlon. Focusing on both is a challenge and some will say that having two parallel activities both requiring a lot of grit is the best way to waste it. I don't believe it is. On the contrary, I think the two are complementary.

On bad days for Bismuth going for a run is a great way to let off some steam. On the other side, an early-swim session is a great way to start the day and is a good reason to jump out of the bed.

I can't wait to see how these two will eventually end up!

(pictures by Caroline Vermeulen and Lindsay Eeckhaudt)

Our Tech Stack: Rust, Typescript, React & Swift

Francois Stephany — Wed, 17 Jul 2019 14:58:13 +0000

tl;dr

Rust (actix-web, Diesel)
Swift (SwiftPM, swift-ast)
Typescript
React (Atlaskit, Redux)
AWS (Fargate, PostgreSQL RDS)
Terraform

Company Culture

I have a confession to make: I love discussing about tech stacks. They convey values and can tell a lot about company culture and the technical history of a technology team.

Of course they don't always tell the whole story: I know a place that emphasises on employee happiness and where COBOL is still king.

The holy stack that will solve all your problems does not exist. There is no silver bullet, remember? Instead, you pick the stack that makes the more sense to you, the one you're comfortable with, the one that fits your use case.

It might be tempting to go all-in in the latest technologies and niche languages. When I was at the beginning of my career someone wise told me that a new venture should not have more than one new shiny thing in its stack. I believe this is true and that developers are sometimes too attracted to technologies that won't survive the next winter.

Bismuth

Bismuth is a service that takes your code, passes it through the mill and shows you where its structure is not ideal. We are still in the early stage and have hundreds of ideas but the end goal is to improve the process of developing software. Not only for developers but also for other stakeholders.

We currently focus on mobile apps but the tools and philosophy can be applied to anything.

The Tech Stack

Bismuth has four main components:

Parsers for languages we support,
REST endpoints for API,
Workers that process the influx of code,
Visualisations engine for user interaction.

Parsers

Parsing source code can be challenging but it's an already solved exercise. Our motto there was not to reinvent the wheel for each programming language and don't roll our own parser. Each environment has its own set of tools that work for them. We probably won't be smarter than them anytime soon.

For Swift, we use swift-ast, which happen to be written in Swift. There were other options like using the C++ Swift compiler frontend but our team was mostly familiar with Swift and the library provided everything we needed.

For Java and Kotlin, we will probably go with Jetbrains UAST in Kotlin.

For Javascript and Typescript there are more options: Esprima (JS), RESSA (Rust), and the Typescript compiler itself.

API Endpoints & Workers

We chose Rust. That might sound surprising for a web API: dynamic languages have a good reputation for this type of work but Rust encompasses values that we believe in:

Correctness: Rust has a strong tendency to make you do things the right way. Is it very rare that a Rust library reaches the 1.0 version without being really production-ready.
Stability: The Rust team is very careful not to break things between releases. That does not mean that they are not moving fast (~6 weeks between releases)
Speed: this is less important for us but Rust is quite fast, even compared with C++ or C.
Libraries & build: There are tons of libraries ready to be used in the crates.io ecosystem. The build tool cargo feels familiar if you've used Ruby Gems, PHP Composer or Gradle dependencies.
All those values reflect in the community. It is helpful, inclusive and newbies are taken care of.

While still being relatively young, Rust ticks a lot of boxes. Software is hard and having a language that promotes good practice feels like a friend holding your hand.

It usually takes us a bit longer to write Rust code than to hack a Ruby or JS script but the feeling Rust gives when the code compiles is that it will be correct and that it will stands the test of time. Personally, this is a feeling I hadn't had since my OCaml days.

We believe that using Rust is also a strength when hiring new developers. Rust developers are usually sensitive to clean code: their brain has been washed by explicit error handling and a very strict compiler.

They might be much harder to find than Java developers but this can be seen as a strength as the odds to attract good developers is probably higher with Rust than Java (flame war fuel here).

UI and Visualisation

Typescript/React/Redux is now one of the standard stacks in frontend those days. Unless 4-5 years ago when the JS frontend war was fierce with a new competitor every week, we believe the winners have emerged and that we won't see too much disruption in the few coming years (i.e., React, Angular and Vue.js have won).

Our visualisations are built with D3, the de-facto standard for displaying visual data on the web and our GUI is built with Atlaskit.

We use this frontend stack both on the web and on our electron app. Electron can be really frustrating to work with at times but it is becoming ubiquitous on the desktop front (if God exists, she will destroy humanity when she sees how we waste our RAM).

Infrastructure

All this code sits into one monorepo. This is useful to keep track of everything in one place. On the negative side, it makes CI a bit harder as you have to detect which part of the app was affected. This might be alleviated by using Bazel to build every components of our systems but we are not there yet.

We deploy on AWS using Terraform. We had no experience either with AWS or Terraform but the documentation is good enough and it is quite easy to find support. Who doesn't have someone who knows AWS in their circle these days?

We use RabbitMQ for messaging between all our components. We're very far from reaching its limit and it serves us well so far.

Future

We don't know yet how the future will look like but we believe our stack is solid enough to withstand it. Time will tell ;)