Christian Gill is a senior software engineer at Catawiki. He’s been a fan of using TypeScript, and even spearheaded its integration into his previous company’s tech stack. At Catawiki in particular, he enjoys TypeScript because of its ease-of-use across their vertical and horizontal team systems. Not only does it make it easy for his teams to work across codebases, but it also lets them easily scale their systems and free up a lot of their time as developers.
In this conversation, Christian shares why he likes using TypeScript, and highlights some of the benefits he enjoys. He also shares some advice on how to get started with it.
Watch the video, or follow along the conversation with the chapter summary and transcription below!
You can also reach out the Christian via his website!
Resources mentioned in this conversation:
- “Haskell Programming from First Principles”, Christoph Allen and Julie Moronuki
- “Never Split the Difference: Negotiating As If Your Life Depended On It”, Chris Voss
- TypeScript website
- TypeScript Documentation
- TypeScript in 5 minutes
Podcast chapters:
[07:35] Rapidfire questions, and intro to Christian
[11:00] What Catawiki does, and Christian’s role in that mission
[17:18] What TypeScript (TS) is all about
[19:45] How TS improves Christian’s life as a developer in general
[22:013] Christian’s experience of how TS enables his team at Catawiki
[34:26] How TS has changed Christian’s approach to software development
[37:47] Christian’s advice for getting started with TS
Transcript of the conversation:
[04:00] Jomiro: Just before we get deep into this: What has been something that you've learned about either yourself or your routine during the lockdown period? Has there been anything that you've realised or even something that you've learned new over the past few months?
Christian: That's an interesting question. Hmm. I think I learned to work at home basically, we all did, right? I used to be, on weekends, more wearing sweatpants, maybe pyjamas, and I realised that for work... If I'm going to be working, I need to get into more of a mindset, you know. So now I wake up every day, dress up as if I'm going to go to the office in jeans and a t-shirt, and that creates... Even if I'm all day at home, it feels better than if I was in pyjamas and just chilling on the couch. So that was something interesting about the lockdown period to discover that you have to keep living. If you're just in pyjamas and just chilling, it doesn't work.
Jomiro: Yeah, as you said, there's a mental difference, a mental shift in actually getting changed for work and getting out of those clothes. One of my colleagues actually at the beginning of lockdown — I don't know if she still does it, I'd be very surprised and proud if she does — but she left her flat and went for a walk around the block, and then came back. So, she still walked to work.
Again, it's that whole thing of getting into the mind frame of work, so you're not just rolling out of bed, or feel this weird blur of “life is just one long day.”
Christian: Yes. I think not rolling out of bed straight into work... That also helps a lot. Do something before as you would if you were going to the office. I think I'm going to try that one and go for a walk. That sounds good, especially when it's fresh in the morning.
[06:43] Jomiro: Exactly. And she and her husband would say “bye”, and then she left and came back. I think if you said that to someone before lockdown, they would think you're crazy. But I think it actually helps a lot now, and we can all understand why.
So, before we dive into our proper conversation, I've prepped a few quick-fire questions that you couldn't prepare for. They're really easy and nothing hectic, it's just to sort of get to know you a bit better. The idea is to not think too hard, just say what comes to mind. So, the first one: After a really tiring day, how do you spend your evening?
Christian: I usually watch a TV show with my wife. We are watching Pokémon now.
Jomiro: That’s the best.
Christian: Back to my childhood.
[07:59] Jomiro: And what's a really good book that you've read recently?
Christian: I'm reading that Haskell book. So, it's quite technical. But one non-technical book that I read that I really liked was Never Split the Difference. It's a negotiation book. I thought I was going to read it to get a better salary, but I ended up improving my relationship because it was more about listening to people and coming to an agreement than discussing salary. So it was an interesting book and very cool stories from the author, because he's a negotiator as well.
[08:45] Jomiro: Tea or Coffee?
Christian: Coffee usually, although I also drink Mate, which is an Argentinian drink in between tea and coffee.
[9:00] Jomiro: and how do you take it?
Christian: I'm not an expert brewer so basically I just drink from the machine, a Nespresso.
Jomiro: And what is one invention or app that you wished existed but doesn't?
Christian: If I knew I would probably be working on it.
Jomiro: And what is something you're glad you said no to recently and why?
Christian: I'm glad, even though it was forced, but we didn't go to our country because of lockdown, and we would probably have gotten stuck there. So I think I'm glad that we didn't move the tickets earlier just to go because yeah... We met people that got stuck in quarantine.
[10:00] Jomiro: And what is something that has cost you less than €50 but has been the best investment most recently?
Christian: AirPods. I'm not an Apple user, so I bought them, but they are not under €50.
Jomiro: I will gladly accept AirPods. I think as someone who also has them, they were one of those things at the beginning where I wasn’t sure if they’re worth the money. The minute I got them, I started listening to podcasts more often. I started to be more active because I could have my phone calls wherever I wanted without having to worry about holding a phone. Maybe not within the budget that I stipulated, but it's a very good investment.
Christian: It's not even the more expensive new ones. It's just the smaller ones.
Jomiro: Fair! But thanks, that's some really interesting insights. And on that note, welcome to the OfferZen podcast. It's really cool to have you.
Christian: Thanks. I am glad to be here.
[11:00] Jomiro: So just briefly, could you tell me a little bit about Catawiki. For anyone who hasn't really heard about the company just some insight into what the problem that you solve as a company is?
Christian: So Catawiki is an auction platform — so basically, people sell items on auctions. It's all about special items. From the top of my mind, things that I saw recently were a Barcelona T-shirt signed by Messi or — I don't know the team — but the one from Cristiano Ronaldo, one video, and a very nice Ferrari was sold recently. So it goes from all types of things.
And the idea is that some people put the high value objects, nice objects, that have some meaning to them. So this is what we are all about. Finding those special objects and letting people connect to them.
Jomiro: And what approach do you take to solve it from a software perspective? So how do you solve that with software?
Christian: Yeah, so we solve it in two ways. One is with people — so, we have a group of experts in different areas, and they are the ones creating the auctions. What items are going to go there? And we have custom solutions to just simplify the process for people as well. So that's on the people's side.
And on the technical side, we basically provide a platform for the clients to find these objects, to be able to sell them easily, and then to ship them, because not all the people selling are experts in selling. They just say “I have this special object, some relic from my grandmother, and I don't want it anymore, and someone might be interested. I need to sell it now. I need to ship it.” So we help the people with the platform for this process. And we also provide the tools for the Catawiki experts to work and facilitate the auctions. So basically providing this platform for them to work.
Jomiro: And how big is the company at the moment, roughly and also how big is the tech team that you're working in?
Christian: So the company, I think, is around 500-600 people… with 200 experts. So that's a big part of the company, the experts working on creating the auctions.
Jomiro: Experts in evaluating products? Or what makes them experts in different products?
Christian: So we have experts in musical instruments, in sportscars, in gems, in all the categories basically, there are one or two experts. These are basically very passionate people. You talk with them and they will start telling you about their area, right. I met one of the guys that work with the musical instruments, and he was all about music. He was just telling me who he met and the pictures he took with members, so they get very passionate about this, and basically that's what they do.
And the engineering team deals with protocols. So protocols, UX and everything. They are around 120 at least. That's what the development channel is in Slack.
Jomiro: Interesting. You are based in Amsterdam, but I assume part of your development team is also then distributed from other countries?
Christian: No, most of them are in Amsterdam, we all are working from home though. But the experts are scattered all across Europe mostly. So there are people in Spain, France, Italy, and the initial headquarters of Catawiki where it was founded is in the north of the Netherlands. So, there are a few developers that work in those offices as well, but now most of us are in Amsterdam.
Jomiro: And then where does your role fit in as a senior software engineer. What is your main focus? What is your main, day to day work?
Christian: I work on the front-end so basically all things front-end. Engineering is divided into two ways: So, one is vertical for the domain. I work in logistics for the fulfilment, which is everything after an item is sold — logistics, shipping, and payments. So, in the vertical stuff, we work with backenders, with mobile engineers, UX... to basically develop new features around this area.
Recently, I worked on the large submission: Basically, when people upload items to the platform or information in the shipping section, they're integrated with different shipping providers so they can use those prices easily. Now we're working on payment things, improvement in the security of payments. So those are business features or technical features that relate to our domain in the platform.
And then horizontally — which is very common that you have these vertical and horizontal divisions — horizontally, all front-end developers work together as a guild or as a team on our own concerns: keeping up to date with dependencies, doing interviews to hire more people, doing workshops to learn new things.
[17:18] Jomiro: Moving into our conversation today, in many talks and some of the articles you've written as well, you've sort of spoken about the power of TypeScript. And that's something we're going to chat about now.
Interestingly, using it beyond the basics. You've worked with it for a while, you've introduced it at your previous company, and you're obviously now working with it at Catawiki, as well. I'm really interested to understand what TypeScript is uniquely good at? What problems does it solve? And also, how does that look in terms of some of the stuff you do or some of the things you've done before...
Just to start us off: Could you explain to me like I'm five years old, what is TypeScript all about? What is it uniquely good at?
Christian: Yeah, so TypeScript is basically JavaScript with types; it is a superset of JavaScript. It brings the idea of checking types of compile-time, so there is a static process there. And the type is the way to tell if my program is correct in the way I'm using my data. So, I am not mixing numbers with text or more complex things like the user object with a different object.
TypeScript lets you validate all of that. As I said, it's a superset of JavaScript, so the goal is that it is really easy to integrate with any JavaScript application. So we have this compile-time, but basically, once it's compiled, it goes back to plain JavaScript. And you can run it anywhere in the JavaScript plan — so in the browser or within NodeJS on the server. It brings all of these types of checks that give you good guarantees that your code is working. With type checking also comes some tools that help you work with the code in a more scalable way or an easier way.
[19:45] Jomiro: So how does having that sort of integration — and what you're saying about compile-time — improve your life or improve your development?
Christian: By checking these types, compile-time will remove a lot of the weaknesses or errors of JavaScript, like “undefined is not a function”. That's a very common thing that happens.
JavaScript only checks things at runtime; it only checks when you execute the application. With TypeScript, it checks compile-time, which means we have a much faster feedback loop and a more correct one as well.
But if your application is weak, you might not execute all the code to check if everything works. That's what QA engineers will do — we'll go through every flow of your application to see that it's working. So TypeScript is not a replacement for that, but it's a much faster fit for you because it will tell you, “OK, you messed up here. You can fix it and continue the development.”
[21:04] Jomiro: If I understand correctly, you can actually tackle bigger projects with TypeScript because JavaScript couldn't necessarily handle that same scale.
Christian: Yes, if you have all these static time checking guarantees, it really shines when you need to refactor and come back and change the code, because you have the confidence that if I'm changing things they will work.
Of course, there is business logic that still needs to work. And the compiler cannot check that for you. I wish it could, but in that sense it’s not a replacement for QA or for unit tests. But it's a replacement for all of these ‘silly’ checks we need to run in the application just to see that I'm not combining text with a number when it shouldn't.
[22:13] Jomiro: I'd like to dive into what that looks like at Catawiki in particular, but maybe you can start with just to set the context of what requirements from a technical perspective you have at Catawiki? And why TypeScript solves those particular requirements. What are some of the things you need to be able to do at Catawiki?
Christian: Yeah. So the way I mentioned that we have this vertical, we have five verticals. Three of them are a user or client-facing, there are two or more internal things and then infrastructure. And each vertical has two or three teams. So we have all these different teams working on different areas of the platform, people working on the buyer side, where we work on the search of items, or the bidding page where you are bidding on an auction or the seller side where you want people to be able to input the product into the platform and get their money back when the item is sold.
This is separated in different services — we could say like, microservice architecture, right? And not only on the backend side, but also on the front-end side. And you have teams that work, for example, let's say on the seller and the buyer page all the time, refining features or designing new things.
And then you have teams like my team, where the shipping features are scattered across the different flows. So as a seller, I need to input shipping information, but then as a buyer, I want to see the tracking code when I buy the item. So our features are more scattered.
So in our case, it is not that we work on the same code base all day, but we work in different code bases all the time. So where Typescript comes in really useful is for the teams that work a lot in the same place, they will be kind of changing the same code or coming back to the same code very often and working together.
You want this to be a smooth process, right? For the other teams that we need to go to codebases that we might not be so familiar with Typescript makes it easy to discover this codebase, and to make sure that we are not adding a shipping button and breaking everything. I think depending on your team, there are different benefits, but they're all related to it.
Jomiro: So it helps you work across different codebases, right?
Christian: Yes, that's one way. And there are codebases that we change less frequently, and we go back maybe a few months later, and won't remember everything by heart. It helps you get up to speed with that.
And for the more active codebases, the bigger ones where more people are working, you need them to scale properly. And you also want it to be easy to work within this setup, where there are a lot of different teams working on the same thing.
[25:47] Jomiro: Maybe now's a good time to just get a little bit more technical than we have been before. What are some of the features of TypeScript that allow that kind of thing, the scalability, or allowing many teams to work on the same thing? What are some of the features within TypeScript that enable that I guess?
Christian: Yeah. So it goes back to basically the type checking that TypeScript does. There is a spectrum of how strictly you might work with TypeScript: You might disable strict mode, and resemble more like JavaScript in a way, but then you have fewer guarantees. Or, if you enable strict mode, it will do a few more checks for you — but you cannot use JavaScript in TypeScript, so that part will not be type-checked. So, you can basically opt-out of the type checking.
This is the spectrum: Do I go all in? Or do we just make it more loosely and it depends on your needs?
I personally like to make it stricter. The more I can represent with TypeScript, the compiler will tell me that things are failing. For example, I try to encode a state of an asynchronous operation. I get some data from the server, and I show it to the user, and therefore it states that it can be either idle, we haven't made any communication with the server, we need to show something to the user in the state. Then we file the request, it's loaded. And when it resolves, it either fails because of some error, or it can succeed.
Then we have the data to show to the user. And if you encode that in a way that you allow the types to make it valid, you prevent some inconsistent mistakes that later will have success on the same thing. So what is the valid thing to show to the user?
If you use some of the features of TypeScript's discriminated unions, you can then let the compiler discriminate for you what state your code needs to be in.
Another example of this will be having the compiler to check that you're not working with an empty list. For example, if you're showing a list of things, and it shouldn't be empty, let's say it's a list of currencies, and there has to be at least one currency that the user can pay with.
I can check that I'm not working with an empty list because if the list is empty, there would be nothing inside to show to the user. Those areas are where I like to go a bit of the extra mile and find ways not only with TypeScript at the compile-time but also in the runtime to check these things and cover those edge cases that might otherwise blow up in runtime when the user is checking the application.
[29:22] Jomiro: It seems that TypeScript gives you a spectrum from loose to strict, where you may not necessarily have the same customisation option with something like JavaScript.
And out of curiosity, because you mentioned that you introduced TypeScript at your previous company: Was it for a similar reason that you needed a TypeScript to solve something, or what was the thing that TypeScript was solving in that case?
Christian: In that case, we had — at least on the front-end side — we didn't have these different services. We had a single application for the whole website, and it was quite big. So it was how to go back to some things that after six months, we'll need to check the edit some page again, and then we are having trouble catching up with what was the state at that time.
And we thought that basically, TypeScript would help us with that. So it was kind of fun, an organic decision. We thought it was a good idea. We introduced it and actually proved the point. It was quite an organic process. But the recent two were the same to solve this problem of scaling an application that was becoming quite big for one person to remember.
Jomiro: So how does this look in terms of your own software processes at Catawiki? So could you give if you have a particular example that we haven't spoken about already, where you use TypeScript just beyond the basics? What is that? How does that look for you?
Christian: One thing that I introduced in my team, it’s not particular to typescript, per se, but it goes along: It's a library to do the checks that TypeScript cannot do statically, to do them in run time. For example, when you get some information from the server — because this will happen at runtime — we cannot check it. And this is one of those more flexible areas where you can either say this is whatever and just trust me that these will be what I'm telling you to the compiler and it will be okay.
But then we might make a mistake, a value that should always be some text might not be there because it's actually optional. So what we added in my team is a way to check that in the runtime, then we build this kind of gateway between the dynamic data that comes from the server, we check it, and we have the guarantees that if it's invalid, we are covering those cases.
I guess the success story was the first day we pushed it to production. We got one error reported in the system where we sent the runtime error, saying that there was some invalid data that should be text, but it wasn't. So we fixed that. It was kind of confirmation because it was the very same day.
Jomiro: And that would have slipped through the cracks if you hadn't picked that up.
Christian: Yes. Yeah, exactly.
If we are doing it the normal way of basically just telling TypeScript to trust the piece, this user object, for example, has all these properties and we can work as if it was type-checked. We would have gotten some runtime error, and the user will see some bad experience. But, yeah, we were able to validate on runtime that and show an alternate UI or some feedback to the user that something went wrong. And they could try again.
Jomiro: Awesome. I think that's really cool, and that again speaks to what you were saying earlier about it is allowing you to do more checks than you would have been able to do before without that.
Christian: And just maybe to be clear: this specific library is not a TypeScript thing. And there are several flavours, so there are things like modelling the functional programming style, which is what we are trying to use here, and the libraries called IOTs. They are all flavours for people that are more object-oriented style as well. If you search for one-time type valuation in TypeScript, you will find several of these libraries.
[34:26] Jomiro: And what is something you've learnt through using TypeScript as a way of making sure that you're using it as effectively as you can? Is there something that you've added to the way you approach certain problems with TypeScript or your workflow as a developer? Are there any hacks or tips that you have in that regard?
Christian: I think so. I started to work with it about three or two and a half years ago. It was part of the process of me trying to go from just JavaScript to learning other languages. In this process, I've been learning not only TypeScript, but I mentioned I was reading the Costco book on Golang, or some other languages, and I got really interested in this topic of study time and Type checking.
I found in this learning process that all the languages take this type even farther than what we do in TypeScript. I brought from there some ideas to go the extra mile, and to be more strict and more constrained to your types, but in a way that they can liberate you from committing the mistakes that you will be committing otherwise.
So one thing that changed in the way I write code, or a developer application, is that it's more compiler oriented. So, instead of having my application running and, and this is quite unexpected for a front-end developer, where you normally just make some changes, I want to see them.
The process for me looks like: I write some code, check for the types, and then I continue a loop of adding some more types and some more code and see if it's valid. And eventually, of course, it's the frontend, so you need to run it to see it working. But it can go much further than it normally would.
Jomiro: It frees up a lot of your time and your mindshare in that regard. There are fewer things for you to think about because Typescript takes off those things.
Christian: It actually is, yes, I can free my mind of a lot of things that the compiler can check for me.
You know some people when they think about using a statically typed language, they think about these ugly errors that occurred, you can use the metaphor, the compiler is screaming at you with errors.
But if you think about it from a programming metaphor, I'm just coding together with the compiler. It is trying to tell me that I either messed up here and I can change things. So it's really freeing your mind, and you're coming to rely less on your mind and more on the computer that will get it right for you.
[37:47] Jomiro: That's cool. I like the way you describe it now. You are changing your relationship to the compiler, it's now your friend, you’re pair programming with it.
So just as a closing thought for anyone who hasn't ever experimented with TypeScript, or has been thinking about introducing it into their team or at their company: What is some of the advice you have as a good first step, either in terms of how you pitch it to your team or your company, or even some of the first steps you can take to actually implementing it?
Christian: As I mentioned, TypeScript is a superset. It's really easy to get started with it. You can configure the web pack, to run together with TypeScript, and then you start moving one file at a time to TypeScript. All it takes is changing this extension for JS. And that's it basically.
The step of checking the types and the step of producing your compiled code, your JavaScript can run it independent of each other. So you can still compile invalid code. And you can just send it to production if you want. So, in the case if you’re moving into JavaScript, you move your JavaScript to TypeScript, it will give you some type errors, you can still use that code in production.
Slowly start fixing those type errors and slowly benefiting from it so for people coming from JavaScript, you need to invest a bit in learning, and especially learning how to use it with the libraries you're using. So how to use it with React or how to use it with NodeJS. So there is some investment in that.
If you want to introduce it in your company, you have to be the person that will drive this effort, right to teach it to others or be there to help programmers or your colleagues that are getting familiar with this.
Jomiro: Just on learning TypeScript, what's a good way to learn it and are there certain resources that have helped you in the past?
Christian: The Typescript website has some good resources. There is a handbook, and it's kind of like the specification. You can go around the different features that the language has. The only downside of that is, it's kind of hard to connect that to “why do I need this?” or “where I will use it?”
Eventually, you will figure it out like, “OK, that's for this, that feature can help me with this.” But initially, you might want to find some guidelines for using TypeScript with the library you're using. So if you work with React, or when you find a good view, a good guide to work with that. And yeah, it's easy to get started because it's optional. So you can add as much as you want progressively.
Jomiro: And then you were just saying if you don't have JavaScript at all, or you don't use JavaScript...
Christian: If you don't use JavaScript and you come from, another background and you want to get into NodeJS and front-end it might be easier because you might already know how to use a statically typed language come from C# or Java. You probably just want to know how my knowledge translates into TypeScript.
Jomiro: Awesome. Well, thanks. I think you've given some really cool insights into using TypeScript and also from your own experience. So I appreciate you sharing all of that. And I'm sure if someone does still have any questions about TypeScript in particular, or even is interested in some of the stuff you were talking about, is there somewhere online that they can find you in particular?
Christian: I guess Twitter is the easiest way. You can just send me a message. I think my DMs are open. You can ask me there or just tweet at me.
Jomiro: I will link that in the description of this episode in any case, so people can feel free to find you there. But otherwise, yeah, thanks so much for being here on the podcast today and sharing with us. It's really, really nice to hear from you.
Christian: It was great. And I encourage people to try TypeScript out and to see the benefits. And if you like it, perfect. If it doesn't work for you, of course, that's also perfect. Companies are looking for people working with TypeScript. I have friends that recently were looking for jobs, and they mentioned, specifically that. It's one of the requirements for frontend jobs, many companies are using it now. It has become quite popular in this StackOverflow survey. And its popularity is increasing a lot. So it's a good time to learn it.
Jomiro: Yeah. And just from what you've said, it sounds like there is a logic that you can apply from TypeScript and other languages, other problems, so even just learning it will probably help you with some of that as well. So that's exciting. Thanks, dude. Hopefully, we will chat soon again.
Christian: Indeed thank you.
