The Important Things and WTF is a Technical Vision

One of the more frustrating things for me when I tried to figure out whether I want to be a CTO was reading about the CTO being an owner of the company’s “technical vision”. I had no idea what it meant and I couldn’t find a simple explanation in concrete terms I could understand.

Recently I’ve been spending time thinking about “choosing the important things”. My experience in Hello Heart and my current attempt to found a company made me realise that the choices* you make early on in the life of the company and the product have a very big influence them. For example, a company founded by a biz person and a product/UX person is going to be a very different company than one that was founded by a tech person and an NLP person, even if the problem domain and audience are the same. Similarly, if on the early days on the product you decide that the main technical issues you want to address are development velocity, user experience and high availability, you will end up with a very different architecture than the one you would get if you decide that security, operational simplicity and extensibility are your main concerns.

Putting these things together made me realise that the first and most influential jobs of the CTO is deciding what’s important: what’s important today, what’s going to be important tomorrow and what will probably be important in three years.
This is one of the more fundamental ways in which a CTO shapes the technical vision of a company.

* Hint: I am not talking about your choice of programming language. Nobody cares about your choice of programming language.

Scala at Hello Heart – Adoption and a Bonus Training Plan

At 2016 I gave a lecture about Scala adoption in Hello Heart.

To make a long story short, while I personally really enjoy the language as a developer, we’ve experienced some problems in getting new developers up to speed. The language seems to be extremely frustrating to learn, even to – and I would dare to say especially to – the most experienced developers.

There are several factors that make Scala particularly hard:

The functional ideas in Scala are still new to many developers. While I don’t think Functional ProgrammingTM is necessarily “harder” than imperative programming, it is a new way to think about writing software. Learning ways to think is inherently hard, and the struggle can be a massive ego blow – especially if you are an experienced developer and expect to just “get” new languages easily.

You can end up with wildly different codebases, depending on the language features you use. The Scala language has many features, and it doesn’t constrain you too much in how you can use them. In a typical project, you wouldn’t use them all at once. Ideally, you would choose the subset of the features you prefer, and stick to them in order to achieve consistent style. This means you can see OOP Java-like style in one code base, functional, almost Haskell-y style in another, and any hybrid you can think of in between. Compare to Java code that is quite similar no matter where you look (a loop is a loop everywhere, as my mom would say).

Scala’s syntax is extremely flexible. Brackets? Which do you prefer? Because we do both. At the same time. Or either. Or none. Semicolons? Yeah you can use them. Or not. Hate dots? You can leave them out! Sure thing! Random punctuation marks for identifier name? Amazing! I’ve always wanted a codebase that looks like it was profanityped by a developer with massive anger management problems and an uncontrolled dirty mouth!

All these properties make Scala extremely fun to write DSLs in. And they do, my God, they do. So not only do you need to learn Scala when you learn Scala, you also need to learn the DSLs of all the different libraries used in your project.

All this brings me to my final point, which is that it is extremely hard to just open a source file and dive into the code. Unfortunately, that seems to be a preferred method of learning in our profession. Try that with Scala, and much hair pulling, curse words and cries for help are guaranteed.

So in order to shorten the learning curve, we created a training program that is meant to take a developer with some experience, and teach her everything she needs to know in order to be productive writing server code in about two weeks.

You can find our training plan here, and watch my lecture here:

The Business-IT Connection

One of the nicer things about being a CTO of a growing startup is being able to experience firsthand all the things the software engineering literature you read all the years talk about.

Hello Heart started as a B2C company. In our early days we built a product – blood pressure tracking apps, and sold these apps to our users. As we grew, we became a B2B2C company  – we started selling our apps to employers who were looking for health benefits for their employees.

With this change, we had to shift our thinking in so many ways. Suddenly, marketing and sales became completely different, as did business development. Along with these changes, the new features we had to implement changed. We were required to implement more and more features that weren’t about the individual experience, but about the employees’ relationship with their employer. Are these employees eligible for Hello Heart? To which employer do they belong? Integrations with other benefit programs. That kind of stuff.

The most interesting thing for me was the way our thinking about the product changed as we started growing. Our “product” is no longer an appliccation that we sell. It’s a service. Complete with enrollment program and dashboards and operations and all the magic that goes into Hello Heart (did I write that? Yes, I did). Our software had to change as well in order to accommodate that. We started writing code to manage clients and enrollments and shipping centers. 

Recognizing this change in the way we need to think took us a while and it has been fascinating to watch. For me, the key was noticing that we do a lot of things in a really hard way, and thinking – hey! Shouldn’t we have software to do that for us? It’s ok to do things in stupid and hard ways when you are a small startup and can’t afford to build all the software you need and just trying to figure out if your busines works. But when you find out it works and start operating as a business, this approach leaves you with a gap between what your business needs and what your technology provides, and your next challenge is to align the two. 

We are have been doing that for a while now and it is exciting and fun. I feel like I live in a fairy tale case study from a software engineering book.