[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.

[MUSIC BREAK]

[AD]

[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.

[AD ENDS]

[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.

[MUSIC BREAK]

[AD]

[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:07] It’s hard to believe that JavaScript is 25 years old this month. Why not celebrate the occasion by sharpening your JavaScript skills? Pluralsight is making five of its expert-led JavaScript courses free each week in December. So you can learn something new, whether you’re a beginner or advanced. That means you could theoretically take 25 free courses before the start of 2021. If you were wanting to do a frenzied movie montage thing where you transform your entire life in the time it takes to play a shortened version of Eye of the Tiger, or you could just have a pleasant time learning something new and start next year with Gusto. Go to javascript.com to get access to some really helpful JavaScript resources and start building new skills for free.

[AD ENDS]

[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:17:06] DV: Sure. So. The tagline for TypeScript is JavaScript That Scales. So TypeScript is a language that’s built on top of JavaScript. It sorts of occupies an interesting niche in the system because it’s not an independent language. You’re always using it in a context where you would normally use JavaScript. So for example, a webpage or a Node.js application. We were talking earlier about how software at scale is a little bit different than just the sort of small project that you would write on your own. And there’s things that you do to make software sort of scale up to larger code bases, to working with multiple developers. And one of the things that you typically want to do is incorporate a static type system. So that’s what TypeScript does for JavaScript. So the idea with a static type system is that you can run JavaScript code. And if you do something that’s not legal, like for example trying to read a property off of null or undefined or calling a function with invalid arguments, it will fail at runtime. If that happens in your user’s web browser, then maybe you lose a sale or they just assume that your website’s broken and you lose a customer. So that’s pretty bad and you don’t want that to happen. And so the idea with a static type system is that you can model that sort of thing while you’re developing your program and have it catch those sorts of errors for you. That’s sort of what TypeScript tries to bring to JavaScript. Type systems have a lot of other advantages too, in addition to catching errors. The way I think about it is there’s the type safety aspect, but then types also have benefits in terms of making your code readable. Right? So if you have ever been in the situation where you’re writing a function or editing a function or trying to call a function and you don’t know what to call it with, that’s the place where a type system can help you out because it forces whoever wrote that function previously. Whether it was you or a coworker or maybe you two years ago and you’ve completely forgotten about it, it forces you to document that. And so types help for legibility of code for humans. They also help improve tooling. I sort of think of this as code readability for machines. And having types in your programming language makes it so that your editor can report errors to you, but also it can offer things like auto-complete in your editor that are extremely valuable just for your personal productivity. And so that tooling, when you’re using TypeScript, it has kind of a nice feel to it because you feel like your editor is kind of there along with you and it’s trying to help you out. So I think that sort of editor integration is one of the things that makes TypeScript a really enjoyable language to use.

[00:20:06] SY: So TypeScript is all about types. Can you explain the concept of types and typing to our audience?

[00:20:13] DV: Types are kind of describing what you expect a value to be for a symbol. So for instance, in JavaScript, you can create an a variable and then assign it to a string like hello and then assign it to a number like 10 and that’s fine. But if you are expecting it to only be a string and you assign it to a number, that’s actually a problem. So a type is a way of kind of defining the range of possibilities of a variable. So if you make the type of that variable string, then assigning hello to it is fine. That’s a string, but assigning 10 to it, well, that’s a number, so that’s not okay. That’s not following the declared type. And so that’s kind of the essence of what a type system is. You can really capture quite a bit about the expected behavior of your code using types and you can get quite elaborate about modeling the possible range of values that are allowed by a type. And so TypeScript gives you a lot of tools for doing that.

[00:21:16] SY: Tell me a little bit more about the application of TypeScript. Why would I choose it over just plain old JavaScript?

[00:21:22] DV: I think the key is really in that tagline, that TypeScript is JavaScript that scales. So I think the point at which you want to use TypeScript is when you start thinking about getting to scale with your application. So the scale could be the size of your code base, scale could be maintaining your code over a long period of time where it’s hard to keep it all in your head without forgetting. Scale could also be working with some number of other people who are going to be contributing to your code base. The trade-off is that with TypeScript, you do have to write out a little bit more code, right? You have to write out types for all your functions, for your data structures, which I think is something that you should be doing anyway, but you do have to do that explicitly with TypeScript, which you don’t with JavaScript. Especially at first, it might feel like it slows you down. But over the long run, I think the benefits are pretty enormous in terms of not getting to a point where your code base is confusing and unmaintainable.

[00:22:23] SY: So if you are starting a brand new project, and frankly, you don’t know if you’re going to have scaling issues, like you don’t know if it’s going to get popular enough to have those problems, would you recommend starting from TypeScript from the very beginning anyway? Or does it make sense to start with JavaScript, then use TypeScript at the point of scaling? At what point do you bring TypeScript into the equation?

[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:23:39] DV: I think the best way to play around with TypeScript, if you haven’t used it before, is to go to the TypeScript Playground, which is a tool on Microsoft’s website. One of the fun things about TypeScript is that TypeScript is written in TypeScript and that means that it compiles to JavaScript, that means it runs quite happily in a web browser. So the TypeScript Playground is a text editor in your web browser, and it runs the TypeScript Compiler. You don’t need to set up anything. You just go to the TypeScript Playground. And as you type TypeScript on the left, you see the errors, you see auto-complete, and then you also see the JavaScript that it gets converted into on the right side of the page. I think it’s a pretty nice way to get a sense of how TypeScript works. I think one of the nice things about TypeScript is that they really prioritize the language services as well as developing out the features of the language. And what the language services do for you is that’s the tool where if you type the name of a variable and then a dot, it figures out what all the properties are, what all the methods are on that variable. It will provide auto complete for you. It will surface all the errors for you. If you hover over a symbol, it will tell you what its type is and give you documentation for that symbol. They really prioritize making that both useful and making it very fast. So when I first started using TypeScript, one of the things that surprised me was I would read the release notes of TypeScript when every few months, when a new version came out, and they would mention new language features, but then they would spend just as much time on things like improving the latency of the language service or introducing new refactorings. And it puzzled me at first, but then over time, I kind of realized that even though reducing the latency of the TypeScript language service by a few milliseconds, maybe that’s not a feature that’s going to get headline news in the programming language community. But in terms of your day-to-day experience of working with a language, that is actually what makes it really pleasant to use, if TypeScript can keep up with you without getting bogged down and as always very fast to offer suggestions. I think TypeScript does a very good job of being quite smooth and fast as you’re writing code.

[00:26:00] SY: So does TypeScript have any competitors besides JavaScript? Are there other alternatives we might want to consider?

[00:26:07] DV: Absolutely. So type systems are pretty fundamental to scaling up software projects. So I don’t think it should come as any surprise that people have been building typed JavaScript systems for years and years. So there’s a whole history of these. For people who used to write flash programs, I believe flash had a typed form of JavaScript. Google developed its own typed form of JavaScript called the “Closure Compiler” that I used there, which was an early version of typed JavaScript. Facebook has its own version of typed JavaScript called “Flow”. But I think if you look at just the market share of projects, I think TypeScript is really by far the dominant typed form of JavaScript. And I think it really is that focus on the language services and making it really pleasant to use. I’ve used many forms of typed JavaScript over the last 15 years. And I would say that TypeScript is by far the most pleasant to use.

[00:27:08] SY: What would you say is the biggest criticism of TypeScript?

[00:27:12] DV: There are quite a few criticisms of TypeScript out there. One is that people will say that TypeScript is not JavaScript, which I think was something you heard a little bit more a few years ago. One of the fun facts about TypeScript is that the guy who created TypeScript, Anders Hejlsberg, he’s a developer at Microsoft. He also created the C# programming language.

[00:27:34] SY: Oh, wow!

[00:27:34] DV: And before that, he created Turbo Pascal. So he’s been doing this for a long time. So I think one of the criticisms back in the early days of TypeScript was that it felt like writing C# in JavaScript. It’s sort of forced you to adopt more C# like patterns. But I think that’s sort of less of an issue now. I think that TypeScript has kind of clarified its relationship with JavaScript and become more. It really tries to capture the ways that people use JavaScript in the wild. I think JavaScript has also become more like C# over the last say five years adding features like classes built into the language and a module system. I think in terms of other criticisms that TypeScript that people have, it definitely does add complexity to your project to get it set up. So everyone using JavaScript has some sort of stack that they’re on, whether they’re using Webpack or something else to run their code. And however you’re doing it, if you want to use TypeScript, you have to incorporate TypeScript into that. I think the good news there is that because TypeScript is so popular and widespread, almost any tool that you use, you will be able to find some sort of TypeScript integration. And another criticism of TypeScript is that JavaScript is a very dynamic language. And there are some patterns that appear in JavaScript libraries that are just quite difficult to capture in a type system. And so if you use those patterns, then you’re probably going to have a harder time using TypeScript. I think that also though has become much less of a concern over the years as TypeScript has gotten more powerful and been able to capture more patterns that appear in JavaScript.

[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:29:25] DV: I wouldn’t pick TypeScript as your first language because TypeScript is based on JavaScript. I think in order to make effective use of TypeScript, you should have a pretty solid foundation of JavaScript. But that being said, if you’re going to work in JavaScript, 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 is going to be a pretty good investment. If you find yourself writing JavaScript and getting frustrated that you’re reloading a page in your browser and you keep on getting errors about such and such is not a method of undefined, then maybe that’s a good time to start thinking about learning some TypeScript.

[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.

[MUSIC BREAK]

[AD]

[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.

[AD ENDS]

[00:31:52] SY: So let’s talk about your book, Effective TypeScript. What was the impetus for writing it?

[00:31:57] DV: When I joined Google in 2006, they gave every new engineer a copy of Effective C++, which sounds like a great book deal. So if anyone wants to arrange something similar with Effective TypeScript, definitely talk to me. But I really enjoyed that book a lot. It was kind of unlike any other programming book that I had ever read. I think most programming books, especially back then tended to be geared more towards people who hadn’t necessarily written code before or weren’t familiar with the language. So most books I read were like Learn How to Program C++, Learn How to Program JavaScript. But Effective C++, it assumed you already knew how to program C++ and it was about not how you program C++, but how you should program C++. It was about usage. And it was quite helpful because instead of saying, “This is how this feature works,” it would say, “You shouldn’t use this feature or you should use this feature.” And so it was quite good at helping me avoid traps and learn how to write code that was understandable and would work well going forward. It was also extremely helpful for offering feedback to other people on their code in doing code reviews, which is a pretty common thing within companies. So I got a lot of value out of that book and it’s a whole series. There’s other effective books as well. There’s an Effective Python, there’s Effective JavaScript, and there’s Effective Java, is another famous one. So when I started working in TypeScript, I did a search and it was like, “Oh, I wonder what they say in Effective TypeScript.” And of course, there wasn’t one. Over the course of the next year or so, as I got more comfortable with TypeScript, I started to realize, “Well, there probably should be an Effective TypeScript.” And I looked around and it’s like, “Well, I wonder who’s going to write it,” and realized, “Well, maybe it should be me.” So I got in touch with O’Reilly and I had to write a book proposal and I spent I’d say most of 2019 working on the book on and off. I think the subtitle is something like, “62 Ways to Improve Your TypeScript.” So each item offers clear advice and then goes through why you should do that using concrete examples. It’s designed so that you can pick it up and read an item at a time. I’d say an item is similar in length and structure to a blog post. But over the course of reading the book, you should have a better sense of how TypeScript works and what the features of it are that you should use, how you should use them, and what some of the features are that you should avoid.

[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:37:23] DV: Yeah. I think TypeScript is a very actively changing language. And if you’re new to software, I think it’s a pretty exciting place to be. They come out with new releases of TypeScript every three months or so, and there’s often pretty significant changes in those new releases, interesting new features. So there’s sort of two models of programming languages out there. There’s the programming languages that are standardized and built out by committees. JavaScript is one of those, but then TypeScript is more of the sort of jokingly called “The Benevolent Dictator for Life Model”. So Anders, if he wants to implement a new feature in the language, will just go ahead and do that. So sometimes there’s really surprising new features and it’s very exciting when that happens. So I think there’s going to be a couple of those in TypeScript 4.1, which should come out in another month or two. So I think it’s a great language to get involved in because it’s still changing and there’s a lot of excitement and still a lot of interesting new features being added.

[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:39:27] DV: So not quite advice, but maybe more just like a vibe that I was exposed to a lot when I was a new developer. I think there’s often sort of a reflexive cynicism that people have about new things like, “That idea will never work out,” like, “This is so silly. Why are people doing this?” Often new ideas don’t work out, but sometimes they do. So I think when I was a newer software developer, I tended to be more cynical about new things. So some examples of that would be Node.js, when that first came out, I just wondered, “Why would anyone want to write server code in JavaScript?” And now I do it every day. Or when Google started working on Chrome, I just thought that was crazy. Why did the world need another web browser? But now it’s a pretty wildly successful product. When I was living in San Francisco, some friends of mine, they started working on this online video game that people were going to play on their phones. And I thought it was pretty silly. I was skeptical that it was going to go anywhere, but then it turned out they had a photo sharing feature that they built into it, and people seem to react to that. Now that’s Instagram. Right?

[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, hello@codenewbie.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.