In this episode, we talk Typescript with Dan Vanderkam, principal software engineer at Sidewalk Labs, and author of Effective TypeScript. Dan talks about the difference between working on a personal project versus a project at scale, what typescript is, and how it can help you once you move to those larger projects.
- Sidewalk Labs
- Effective TypeScript
- The Secret Guide To Computers
- Mount Sinai
- Alphabet Inc
- Type Systems
- Turbo Pascal
- Effective C++: 55 Specific Ways to Improve Your Programs and Designs, Third Edition
- TypeScript Handbook
- Basarat's TypeScript Deep Dive
- Basarat's T
- Programming TypeScript
- TypeScript Quickly
[00:00:05] SY: Welcome to the CodeNewbie Podcast where we talk to people on their coding journey in hopes of helping you on yours. I’m your host, Saron, and today we’re talking about TypeScript with Dan Vanderkam, Principal Software Engineer at Sidewalk Labs and Author of Effective TypeScript.
[00:00:20] DV: I think more and more companies nowadays are starting to adopt TypeScript. And so I think inevitably, you will run across it. And so getting comfortable with it, I think it’s going to be a pretty good investment.
[00:00:31] SY: Dan talks about the difference between working on a personal project versus a project at scale, what TypeScript is, and how it can help you once you move on to those larger projects after this.
[00:00:50] TwilioQuest is a desktop roleplaying game for Mac, Windows, and Linux to teach you real world developer skills. Take up the tools of software development, become an operator, save the cloud. Download and play TwilioQuest for free at twilio.com/quest.
[00:01:07] Simplify your infrastructure and cut your cloud bills in half with Linode’s Linux virtual machines. Develop, deploy, and scale your modern applications faster and easier. Whether you’re developing a personal project or managing larger workloads, you deserve simple, affordable, and accessible cloud computing solutions. Get started on Linode today with $100 in free credit for listeners of CodeNewbie. You can find all the details at linode.com/codenewbie.
[00:01:37] Awesome applications need data wherever, whenever, and however users want to consume it. In addition to a fast to deploy application stack, join React with Cassandra Dev Day, a half day interactive virtual event this December 9 where you can learn how to use React with Netlify and Apache Cassandra, the same database that powers Netflix, Spotify, and Apple. Are you in? Register at events.datastax.com/reactwithcassandra.
[00:02:11] The more you know about web development, the more fun it is. With Pluralsight, you can take your skills and your career to the next level. Start a free account today to access 50 expert-led courses, plus five extra free courses rotating in each week, charged into 2021 with the confidence of someone who has development experts in their corner. Go to pluralsight.com/free to create your free Pluralsight Skills account today.
[00:02:40] SY: Thank you so much for being here.
[00:02:41] DV: Thank you.
[00:02:42] SY: So tell us a little bit about how you started your coding journey.
[00:02:46] DV: I really moved pretty much straight from playing with Legos to writing computer code. And in some ways, I don’t think those two are actually all that different. What happened was, it was probably in fifth or sixth grade, and for reasons I don’t entirely remember anymore, I expressed an interest in learning how to work with computers and there was a computer teacher at my grade school at the time. She gave me a book, which just talked all about everything to do with computers and how to program them. It’s called “The Secret Guide to Computers”, which I’ve learned since then is a little bit of a cult classic.
[00:03:20] SY: Oh, cool!
[00:03:21] DV: Yeah. So I learned how to program basic from that, and I was kind of off to the races.
[00:03:26] SY: What kinds of things did you make?
[00:03:27] DV: I made a ton of little computer games when I was a kid. I think that’s how a lot of kids get started with programming. I think there’s something really fun about just the quick interaction of writing some code and then seeing that turn into something moving on the screen or seeing it respond to the changes you make.
[00:03:44] SY: Yeah.
[00:03:44] DV: And I found that really appealing.
[00:03:46] SY: Do you remember the kinds of computer games you made?
[00:03:49] DV: Yeah. This was back in the 1990s. So there’s a lot of games that were sort of platform style where you have a character and you move left and right and you jump. I really enjoyed those. I like making choose your own adventure games too because those were relatively easy to program.
[00:04:05] SY: That’s great. So okay. So you read that book, you built these computer games, then what happened? How did you get into it as a career?
[00:04:13] DV: I continued to write computer programs, but I think as I got into high school, I became a little bit less interested in writing computer games. But when I went to college, I was trying to decide what my major would be, and I was interested in math and I was interested in computers. As I went through college, I sort of increasingly realized that the opportunity is if I decided to focus on computers were quite a bit better than almost any other field I would go into and I still enjoyed writing computer code. So that’s sort of how it came about. I got an internship at Microsoft after my junior year of college, which it was my first experience working at a software company. And then after college, I went and worked at Google, which was, I think, a pretty interesting first job.
[00:05:02] SY: So how long were you at Google for?
[00:05:04] DV: I was at Google for about seven or eight years, which is quite a long time. My sister studies people’s careers and she was telling me that for a millennial to work at one company for eight years straight out of school is almost unheard of.
[00:05:18] SY: That’s a long time. Yeah. What made you stay for that long?
[00:05:23] DV: Well, I stayed because I think in a larger organization like that, you have a lot of potential to move around and keep things fresh without actually leaving the company. And so over the course of my time at Google, I probably worked on four or five different teams and I worked in three different offices. I started in the Mountain View Office and then I moved up to their San Francisco Office. And then about halfway through my time at Google, I moved to New York. And so all of this changes as well as the teams that I changed between, I think, kept it feeling fresh to me.
[00:05:57] SY: So you mentioned that working at Google as your first job was an interesting experience. What do you mean by that?
[00:06:05] DV: Sure. In terms of software engineering workplace, I thought it was fascinating in quite a few different ways. So one of them is that it was my first experience of working on software at scale, which we’ll get into this, but that’s part of the appeal of TypeScript is operating at scale. And so something that I think is hard to really come to understand if you start writing software on your own, just creating computer games or even at a university where you are writing code over the course of a semester is software where you’re working on projects over the course of years, with dozens or hundreds of other software engineers is actually, in some ways, kind of a categorically different thing than working on small projects. The sorts of things that you care about wind up being a little bit different. You have to always be thinking about the future and how things can go wrong and how new people who aren’t familiar with the code base will be able to start working on it and understand it. So in terms of working on software at scale, Google is one of the largest code bases of any company, I think. So that was really jumping into the deep end and of learning how software worked at scale.
[00:07:17] SY: That’s intense.
[00:07:18] DV: Yeah. It takes a while for new employees at Google, especially then I think certainly now to really become productive because I think there is a lot to get used to. I might’ve been grumpy about it if you asked me at the time, but I think in retrospect, that was a really great learning experience. I think it’s been a really good, positive reference for me to have in the rest of my career around how a large code base and a large organization can be managed in a more or less effective manner.
[00:07:47] SY: So what did you do after Google?
[00:07:49] DV: So after my seven or eight years at Google, I started to increasingly realize that I really knew how software was built at Google, but I had less of a strong grasp of how software was built in the rest of the world. So if I ever wanted to start a company or work on side projects, I was at a little bit of a disadvantage in doing that. So I started to more actively think about leaving. I wound up working at, it was an open-source research group at Mount Sinai, which is one of the hospitals in New York City. I joined an open-source lab there that was working on building software for working with genomes.
[00:08:27] SY: Wow!
[00:08:28] DV: I’ve always been somewhat interested in cell biology. I think it’s sort of an interesting alternative way of organizing information and complexity versus how we organize computer code. But I was particularly interested in coming up to speed with how open source software was built. And so I think my first six months working at that group for quite the crash course and just how the software world had changed over the previous 10 years that I’d been working at Google. For me, that was a really fun experience, just learning how everything was done in the rest of the world.
[00:09:01] SY: Wow! That is such a big project, such an impactful project. I think so often developers are trying to figure out how to use our skills for good and how to kind of do things beyond just getting more clicks and how do we create meaning from the work that we do. And it sounds like you were doing exactly that.
[00:09:19] DV: Yeah. It’s funny that you phrased it that way because the guy who started this group, he has a famous quote that the greatest minds of his generation are just trying to get people to click on an ad.
[00:09:28] SY: Right. Yeah.
[00:09:30] DV: But yeah. I think one of my takeaways from working in that group is that software is useful in so many different parts of the world. Right? There’s that famous saying about how software is eating the world. And I think over the course of my career, I can see software becoming a bigger and bigger part of so many different industries where it wasn’t necessarily 15 or 20 years ago. Right? I think the car industry now is maybe a good example as cars are starting to have more autonomous features and move towards being self-driving. But if you are good at software and are interested in building software, it’s an interesting change in perspective from just deciding that you want to go work at a tech company and you’ll work on whatever they want you to work on to picking a domain that you’re interested in, like maybe biology and just knowing that your software skills will be extremely valuable in that field, whatever field it is.
[00:10:26] SY: Absolutely. So then you went from that to working at Sidewalk Labs where you are now. How did that happen?
[00:10:33] DV: That’s right. So after working at the lab at Mount Sinai for a couple of years, I was starting to feel ready to try something different. And one of my old managers from Google reached out to me and he told me that he was becoming the CTO of Sidewalk Labs, which is one of the alphabet companies that works on smart cities. And my old manager, Craig Nevill-Manning, he had been one of the first hundred or so employees at Google. He’d been there forever. And so for me to hear that he was actually leaving Google after 15 years was quite meaningful. And it made me think that maybe this is a company to check out. I had also been thinking about what we were just talking about that you should not necessarily just work in tech for the sake of working in tech, but maybe pick a domain that you find interesting and know that your technical skills will be valuable there. And so with Sidewalk Labs, the domain is cities and urban technology, and I’ve lived in cities as long as I’ve been an adult. And living in cities as a technical person, I think you can’t really help but think about some of the systems in cities and ways in which they can be better. Right? Like in New York City, we always talk about the subway and the bus system and ways in which that could be better. But there are so many different systems that operate in the city. And so I thought that working at Sidewalk Labs could be interesting because I would get a lot more insight into how those worked.
[00:12:00] SY: So I know that one of the things you all do at Sidewalk Labs is called “generative design”. What is that?
[00:12:07] DV: That’s right. So the idea of generative design is to bring computers more into the master planning process for neighborhoods. And so what master planning is, is you have some parcel of land in a city, usually several blocks, and you want to come up with an overall plan for that area. So Hudson Yards is where the Sidewalk Labs office is in New York City on the far on the West Side. And so that’s an example of the sort of size of site that you would use master planning for. And usually the way that master planning works is you’ll work with a couple of different architecture firms and sort of say at a high level what you’d like from the site and you’ll be presented with a few different designs and you’ll give them feedback and they’ll come back with a few new designs and maybe you’ll do that a few times, but you’re always looking at maybe like two or three different options. And so the thought with generative design is that if we can bring computers more into the system, then instead of having three options, you could have a thousand options or a million options. And of course, you can’t look at a million different master plans. And so what you have to do is start coming up with ways of objectively measuring how well different designs do. And this is always where it gets a little bit tricky because there’s many things that make a design good or bad that are quite difficult to quantify. You can’t quite put a number to like how a neighborhood feels.
[00:13:36] SY: Right. Right.
[00:13:37] DV: But there are a lot of things that you can quantify. So for instance, the number of apartments in an area, the amount of square footage of retail space. But then also in New York City recently, there’s been a lot of controversies around putting tall buildings next to parks because they cast shadows on the parks. And that’s absolutely something that you can quantify, right? You can run simulations and measure how much time the parks are going to be in shadow. So the hope with generative design is that there’s things that people believe our intention right now, for instance, the amount of square footage, the height of buildings and the amount of shadows that you cast on the street or on the parks. Those are things where you might assume that they’re competing against each other, the taller you make the buildings, the more shadows they’re going to cast. But the hope with generative design is that if you’re a little bit more creative about your design space, that maybe there are actually some designs that achieve both and that it’s not as much of a trade-off as you thought. Our sort of inspiration here is the AlphaGo Program that Google’s DeepMind created a couple of years ago. And it was famous for beating world champion go players, but what was really most fascinating about it was that it wasn’t taught conventional wisdom about how to play Go. It just learned to play Go by playing itself over and over and over again. And so when people looked at the way that it played Go, they learned that a lot of the things that had been conventional wisdom for hundreds and hundreds of years actually turned out to not be totally right. There were productive strategies, if you didn’t follow the norms and you played a little bit differently. And so our hope is that there are design patterns like that for urban districts where things that we think are trade-offs now are not actually that you can, in some cases, achieve both goals.
[00:15:50] Explore the Mysteries of the Pythonic Temple, the OSS ElePHPant, and The Flame of Open Source all while learning the tools of software development with TwilioQuest. Become an operator, save the cloud. Download and play TwilioQuest for free at twilio.com/quest.
[00:16:57] SY: So I want to get into your book, Effective TypeScript. But before we start really digging into that, can you tell us what exactly TypeScript is?
[00:20:06] SY: So TypeScript is all about types. Can you explain the concept of types and typing to our audience?
[00:22:47] DV: Yeah, it’s a great question. It’s a tricky one. I personally, almost always start a project with TypeScript. But if you’re less familiar with TypeScript, I think it’s a harder decision to make. If you feel like there’s a very high probability that you’re just going to throw this code away relatively soon, like if it’s an experiment, maybe it’s not worth it. But projects that are small tend to have a pattern of becoming large as time goes on or putting it another way, every large project started as a small project.
[00:23:17] SY: That’s true.
[00:23:17] DV: And as your project gets larger, it gets harder and harder to switch it over to TypeScript. And so I would recommend that people start their projects using TypeScript. Maybe the only exception is if it’s really explicitly just an experiment.
[00:23:32] SY: So talk to us a bit more about what it looks like to use TypeScript. What does it look like? What does it feel like? What can I expect?
[00:27:08] SY: What would you say is the biggest criticism of TypeScript?
[00:27:34] SY: Oh, wow!
[00:29:17] SY: So in terms of people who are new to code, is TypeScript a good thing for early developers to get into? Or is it more of an advanced topic?
[00:30:13] SY: Coming up next, Dan talks about good books and resources to learn TypeScript, as well as his own book, Effective TypeScript, and some of the ways in which people don’t TypeScript effectively after this.
[00:30:38] Who doesn’t want their React app to make it to the top five? Build for virality with Apache Cassandra and Netlify, battle tested for scaling data and deploying with speed. Learn how to use this dynamic trio together on December 9th at a half-day virtual event called React with Cassandra Dev Day. You don’t want to miss Honeycomb’s CTO Charity Majors and Retro Game Builder Ania Kubów showcase what it takes. Join us at events.datastax.com/reactwithcassandra.
[00:31:11] Linode has data centers around the world with the same simple and consistent pricing, regardless of location. Choose the data center nearest to you. You also receive 24/7, 365 human support with no tears or handoffs, regardless of your plan size. You can choose shared and dedicated compute instances or you can use your $100 in credit on S3-compatible Object Storage, manage Kubernetes, and more. If it runs on Linux, it runs on Linode. Visit linode.com/codenewbie and click on the “Create Free Account” button to get started.
[00:31:52] SY: So let’s talk about your book, Effective TypeScript. What was the impetus for writing it?
[00:34:41] SY: So when I hear Effective TypeScript, I assume there’s a lot of ineffective TypeScript in the world and we’re trying to help people be better at it. What are some of the things that people tend to get wrong?
[00:34:53] DV: So one of the problems that you run into with working with type systems is that if you don’t model your data accurately, if your types are not accurate, then you wind up fighting against the type system quite a bit. So for instance, if you say that a field can’t be null, but in practice, it actually is, you’re not going to get as much value out of TypeScript, like it won’t catch errors for you. Or the other way around, if you say that a field can be null, when it can’t, you’re going to have to be scattering all these null checks around your code or doing type assertions to get rid of that case where it would be null. And so I think a lot of the frustrations that people have with TypeScript ultimately can be traced back to not modeling your data accurately and the type system. And ultimately, TypeScript and type systems in general are a tool and you can use them well and you can use them poorly. And I think the better information you give to TypeScript, the more it’s going to be able to help you. That’s probably one of the patterns that I see the most is if you look at TypeScript and you see a lot of type assertions, so this would be saying that this symbol as type that’s telling TypeScript, that you want to override its opinion on what the type of something is or using an any type, for instance, which is a way of disabling the type checker. If you see a lot of those, that’s usually a sign that somewhere in the system, the data is not being modeled accurately. And I think if you want to get the most value out of TypeScript, you need to sort of trace that back to the root and figure out why isn’t the data being modeled accurately and how could it be modeled more accurately?
[00:36:39] SY: So when would you read this book? Is this kind of the first book you read on the job? Is it something you read to get you from intermediate to senior? Where does this fall into your TypeScripting journey?
[00:36:50] DV: I think it’s exactly what you just said that it’s sort of intermediate to senior. The tagline of the effective series is that it’s supposed to be the second book you read about the language, which maybe isn’t the greatest marketing slogan.
[00:37:04] SY: It makes sense though. Yeah.
[00:37:07] DV: Yeah. I think once you’ve dabbled in TypeScript a bit or at least familiar with the syntax of it and sort of the experience of using TypeScript and you want to understand it more deeply, that’s the right time to read Effective TypeScript.
[00:37:20] SY: Any final thoughts about TypeScript for our audience?
[00:38:28] SY: So if Effective TypeScript is the second book you read, do you have any recommendations for the first one or some of the newbie-friendly resources you might recommend?
[00:38:39] DV: Yeah. So there’s a lot of great documentation online for TypeScript. The TypeScript team has put together a new edition of the TypeScript handbook, which walks you through the language. I think the Basarat’s TypeScript guide online is quite popular. If you want a book, there’s another O’Reilly book called “Programming TypeScript” by Boris Cherny. That’s quite good. There’s also, I think it just came out, by Yakov Fain called TypeScript Quickly, which was also supposed to be good. Those are a few options.
[00:39:15] SY: Now at the end of every episode, we ask our guests to fill in the blanks of some very important questions. Dan, are you ready to fill in the blanks?
[00:39:23] DV: Let’s do it.
[00:39:23] SY: Number one, worst advice I’ve ever received is?
[00:40:43] SY: Wow!
[00:40:43] DV: So I shouldn’t have been so skeptical. So I think oftentimes, new things don’t work out, but sometimes they do. And looking back on it, the things I use today, almost none of them existed 15 years ago. And so those new ideas often don’t look that enticing at first, but wind up being quite impactful. So I guess I’d say maybe assume that new things don’t work, but don’t rule out the possibility.
[00:41:12] SY: Number two, best advice I’ve ever received is?
[00:41:15] DV: I think the whole concept of time boxing is quite useful. The idea is that everything takes some amount of time and has some amount of value. And I think as a software engineer, it’s very easy to start going down rabbit holes where in order to solve X, you have to solve Y, and in order to solve Y, you have to solve Z. And by the time you solve Z, you kind of forgot why you were doing it in the first place. And so I think the idea of a time box is that you want to implement this feature and maybe it’s important, but it’s not so important that you’d be willing to spend a whole week working on it without working on anything else. So the idea of a time box is that you sort of set up the idea in advance that I’m going to work on this, but if it seems like it’s going to take more than a day or more than a week, then it’s probably not worth the effort. And so just mentally, I think there’s a lot of value in having that in your head as you’re working on a problem that if you go too far down a rabbit hole, if it winds up really spiraling out of control in terms of complexity, maybe it’s just not worth solving the problem.
[00:42:23] SY: Number three, my first coding project was about?
[00:42:26] DV: Well, the first things I wrote myself were all little computer games, but the first programming project I got paid for was somebody who was connected to me, just through the community I grew up in, and this was back in the ’90s. He had purchased a shopping cart system for his website and just for whatever reason, it wasn’t working, he couldn’t figure it out. So he somehow got in touch with me and hired me to track down what was going on. He told me that if I wanted to buy any books or anything like that, he’d be happy to pay for them.
[00:43:01] SY: Nice!
[00:43:01] DV: And so I wound up learning Perl through that project, which is an interesting programming language that maybe I wouldn’t recommend learning now, but it was quite popular back then. Over the course of working on that, I learned a lot of Perl. I read a lot of this code and I still remember eventually what the problem was. He had copy-pasted an email address into the code, and in Perl, like @ sign has special meaning in a string. And so @ sign was throwing things off. So the solution was just to escape it, to put a backslash in front of it. So it probably wound up being quite a few hours, but in the end it was a one-character fix that got his shopping cart working. So that was pretty satisfying.
[00:43:45] SY: Number four, one thing I wish I knew when I first started to code is?
[00:43:50] DV: I would say that I wish I knew how important it was to read code instead of just writing it. When you’re starting to learn how to code, so much of the focus of classes is on writing code, which is important, but you actually learn a lot by reading other people’s code, learning how programs are structured and also reading your own code. Once you’ve been writing code for a while, I would highly, highly recommend reading code that you’ve written, let’s say, a year or two earlier, just as a way of gauging how your coding has progressed, maybe in ways that you’re not explicitly aware of, also having a sense of like what would be helpful for making your code more legible for other people. When you read other people’s code, there’s sometimes a sense that you have of like, “Oh, I would never write code this way. This is so terrible.” But then if you go back and read your own code, well, there’s no one else to blame. So for instance, when you’re writing, you should always have a reader in mind. And the reader I try to have in mind is myself, and say like a year or two, when I have completely lost all context on what the situation in this code is and I want to leave some notes that will help me reconstruct it. And I think that’s a helpful frame to have.
[00:45:06] SY: Wonderful. Well, thank you so much for joining us, Dan.
[00:45:09] SY: Thank you.
[00:45:16] SY: This show is produced and mixed by Levi Sharpe. You can reach out to us on Twitter at CodeNewbies or send me an email, firstname.lastname@example.org. Join us for our weekly Twitter chats. We’ve got our Wednesday chats at 9 P.M. Eastern Time and our weekly coding check-in every Sunday at 2 P.M. Eastern Time. For more info on the podcast, check out www.codenewbie.org/podcast. Thanks for listening. See you next week.
Thank you to these sponsors for supporting the show!