The Weekly Dev's Brew

OSS, TypeScript, Linting and Everything in Between (with Josh Goldberg)

• Jan-Niklas • Episode 2

Share episode

Jan-Niklas interviews Josh Goldberg, a developer who transitioned from Microsoft to full-time open source work in the TypeScript ecosystem. Josh shares his daily routine, work structure, and insights on balancing passion projects with professional commitments.

The conversation covers Josh's current projects including Bingo (a repository templates tool) and maintaining legacy projects like Yeoman. They explore linting philosophy, TypeScript's significance, common developer mistakes, and tools like Prettier. The discussion also touches on TypeScript enums, type narrowing, AI's role in coding, and how open source contributions drive personal growth while creating valuable networking opportunities.



takeaways

  • Josh transitioned from Microsoft to open source for passion, not money.
  • He structures his open source work similarly to a 9-5 job.
  • Balancing work and personal projects is crucial for mental health.
  • Bingo aims to simplify the process of creating repository templates.
  • Yeoman remains relevant for certain users despite its age.
  • Maintaining legacy projects can be rewarding and insightful.
  • Linting is customizable and should be adapted to project needs.
  • Typed linting can enhance code quality but may slow down performance.
  • Developers should not block builds on TypeScript errors during local development.
  • Community trends show improvement in coding practices over time. There are three common forms of static analysis: linting, formatting, and type checking.
  • Formatting should be automated to reduce cognitive load on developers.
  • Type narrowing is a foundational feature in TypeScript that should be mastered early.
  • Enums in TypeScript can lead to confusion and should be used cautiously.
  • Unnecessary type annotations can clutter code and reduce TypeScript's effectiveness.
  • AI tools should assist developers without making decisions for them.
  • Open source contributions can lead to personal growth and better time management.
  • Conflict resolution skills are essential in open source communities.
  • Networking through open source can lead to valuable opportunities.
  • Valuing one's time is crucial in balancing open source work and personal life.


Our fantastic Guest

Josh Goldberg is an independent full time open source developer. He works on projects in the TypeScript ecosystem, most notably typescript-eslint: a powerful static analysis toolset for JavaScript and TypeScript code. Josh is also the author of Learning TypeScript (O’Reilly), a Microsoft MVP for developer technologies, and an active conference speaker. His personal projects range from static analysis to meta-languages to recreating retro games in the browser. Also cats.

BlueSky

fosstodon

GitHub


Chapters

00:00 - Intro
00:38 - Josh's Journey in Open Source
01:38 - Daily Routine and Structure
02:24 - Transparency and Community Support
03:15 - Passion Projects and Work-Life Balance
05:00 - Personal Interests Outside of Coding
06:46 - Project Prioritization and Passion
08:10 - Understanding Bingo Project
31:04 - Enums in TypeScript
42:59 - Personal Growth Through Open Sourc

Thank you very much for listening!

We are also pretty much on all social media platforms, so make sure to like and subscribe!

Homepage - https://www.weeklybrew.dev/

BlueSky - https://bsky.app/profile/weeklybrew.dev
Instagram - https://www.instagram.com/weeklydevsbrew/
TikTok - https://www.tiktok.com/@weeklybrew.dev
YouTube - https://www.youtube.com/@theweeklydevsbrew
LinkedIn - https://linkedin.com/company/the-weekly-dev-s-brew

Hey everyone, this is Jan-Niklas and welcome to the Weekly Dev's Brew. Today I'm sitting down with Josh Goldberg, a developer who's managed to turn open source contribution into a full-time career while becoming a crucial voice in the TypeScript ecosystem. From maintaining TypeScript ESLint to breathing new life into Yeomon and other similar tools. Particularly, the thing that I like the most about Josh is that he literally wrote The Definitive Guide to TypeScript. Great book, I can highly recommend reading it. And having that said, Josh, welcome. Very happy to have you here today. Thanks for having me. What an intro. I might be wrong with this, but if I remember correctly, you originally worked at Microsoft? That's correct. That's correct. So, how do I say this nicely? I assume you made a lot more money working at Microsoft than you do with open source. You know, normally when someone starts with Microsoft and then, how do I say this nicely? It goes a little bit of a different direction than that. It's nice to go the financial compensation route. Yeah, that is accurate. I mean, obviously it's not about financial. I mean, for financial aspects, you wouldn't go this route. Yes. I am not going into open source for the money. I went into it because I love the work. I love being able to contribute to the web ecosystem, and it's some of the most fascinating, intellectually stimulating subject area I've ever seen. So, I personally would struggle with this lack of structure, right? You're completely in charge of your entire story yourself. Oh, today I'm going to work. So, tell me, how does your daily routine look like? Sure. I try to give myself structure because, yes, I would be lost without it. I have year-long goals, the equivalence of a personal OKR, Objective and Key Results. There are a few projects that I'm in particular excited about for this current year. I break those goals down into how long, how many months I think each will take, and then I work within that. I also try to treat it like a 9 to 5, or in my case, because I wake up early, something like a 7 to 4. So, it really doesn't feel very different from when I was at Microsoft or later at Codecademy. The main difference is I don't have a boss or manager or a mentor. It's just me on the internet. Okay. So, that's honestly one thing that I really appreciate, how transparent you are. If you go to Joshua's blog, which I'll put in the show notes as well, you can read literally everything about your, as you said, your goals, your compensation aspect from the last years. And that's one thing that I personally very appreciate because it helped me help you in a way through JetBrains. So, I just wanted to use this to say thanks for that because I think it's, obviously, most developers know that full-time open source is not as luxurious as you might think it is. But it shares some insights on that that I otherwise wouldn't have. So, thanks for that. So, let's talk a little bit So, let's talk a little bit about your projects. If you, I like to compare my open source project. Well, my open source projects are more like passion projects, side projects, right? So, like, usually what happens when I work on those, it's like, oh, I get super excited about one thing, work on it for a couple times, and then get either sidetracked with something else or lose interest. So, A, the first thing I would be super interested in is, like, what is your passion project right now where, if you could, would spend, like, 100% of time on? spend, like, 100% of time on? That's a great question. I'm going to rudely sidestep it, and I'm sorry. Go for it. My big personal journey the last few years has been trying to separate out code as a hobby from code as work, or even more broadly, separate out work-life balance or balancing that stuff. I used to have these passion projects. That's how I got into open source. If I had my way, I would just work on full-screen Mario and full-screen Pokemon, my terrible ports of Nintendo games to modern browser tech and usability. Nice. But these days, because I'm doing coding, because I'm doing open source as a full-time job, I need stuff other than that in my spare time. You can't spend all your waking hours working on something. That's how you lose your mind. I can honestly just second that, because when I moved over here in the US, I was working crazy hours because corporate America. And that literally open source was the first thing I dropped, because I was like, yeah, I'm looking at 10 hours at a screen or more writing code. I don't want to write code outside of that. So I got into gardening or something like that. Yeah. Okay. But now I'm curious, what is your not work, your not code thing you're passionate about then? Well, we just bought a house and moved to a new city, as you and I have talked about. That's a lot. Both of those are a lot of work trying to catch up with your friends. So you went full-blown DIY. Can I see you fixing electric in the basement or what kind of... I've made a big notion table of local contractors and auto shops and such. That's the current extent of my DIY. I did, though. I'm proud of this. I picked up... Well, I bought a learn-to-juggle kit. And I can't say I can juggle yet, but I have been slowly learning the fundamentals of juggling, which is very rewarding and frustrating, much like coding. That is cool. You have to show that to me at some point. Once I can actually juggle three balls in the air, then I will show you and everyone else in the world I'm going to be the most annoying person about it. I can't wait. I don't think... I think most people will be like, okay, this is cool. You know who else does stuff like this? Phil Nash, also in the conference scene, yo-yos, like, really, really well. And it blew my mind where just out of nowhere, he pulled one out of his pocket, a nice yo-yo, and started doing all these tricks with it. I want to be that guy. I want to have that kind of, like, random, weird... Yes....random, unexpected hobby. Yes. Yeah. So, usually, we're from JetBrains. When we go to a booth, we have yo-yos. And then an AngularConf, Chau Tran, who's also on the Angular Plus show with me, he grabbed one of those and was starting, like, exactly how you said it. I was like, that is so cool. So cool. Okay. But coming back to open source for a moment. Just for a moment. Sure. How do you prioritize? Like, okay, I get the aspect of OKRs. But how do you prioritize? Like, okay, today I work on TypeScript ESL. Today I file a super cool proposal for TypeScript. We also need to talk about the Sigma thing, but that's a different thing. Today I'm going to revive Mocha. Like, how is that process? It's an art, not a science. I like doing exciting things. A big part of why I'm here is because it allows me to go out and do whatever happens to interest me this day, week, month. So part of it is just, I'm bored of what I was doing. Let's go do something different. I use that kind of, like, ADHD energy to go and hyper-focus on something for a little bit. So oftentimes when there's a big proposal or project, it's just because I got bored of the last thing and this is what I, for reasons no human could comprehend, now want to do. But I do have kind of mapping back from, like, the bigger objectives to my day-to-day. Like, if, for example, I'm working on Bingo right now, a project, and I need certain things in Bingo for my other project that relies on it. So I will be working on these consistently throughout the week. Like, so let's, I know Bingo is one thing that you're very passionate about right now. Passionate in a career sense. Talk me through it a little bit because I was, like, from the landing page that you shared with me, I was not, like, fully grasping it. Like, what is Bingo? What need does it fulfill? Or what itch does it scratch at the end of the day? Yeah, this is a hard project to explain. If it was, like, a linter, I could compare it to other linters. People know what a linter is. But the closest equivalent to Bingo is Yeoman, which, amusingly, I'm now co-maintaining. But people haven't used, for the most part, Yeoman in web dev for a very long time. But the general idea is writing a repository template is an awful process, and it is not easy to do well. Yes. That problem breaks down into two areas. One is that the very act, first, the creating a template, there's no good tooling for that. We have low-level things like Mustache or Handlebars, little templating libraries. But being able to, you know, like, have it be responsive as stuff updates, you know, like, to what's in your package JSON. Or being able to have little blocks of tooling that can be individually toggled off and on. I have Vitest swapping out for Jest. They both impact package JSON. How do I mix and match? So, first of all, Bingo gives you a really nice engine for setting up templates and then having systems in order to have more rich templates. So, I know you're not super, like, in the Angular scene, but is it somehow like the scaffolding capabilities of the Angular CLI, where you can, like, ng-new create, kind of like... So, Angular, they differentiate between ng-new, ng-generate, and ng-update. Ng-new is, like, creating a new project where, like, the template is fairly static in that sense. Ng-generate are, like, small pieces of code, like components, for instance, or those kind of tests. And ng-update is then, okay, you made a version jump. Here are the changes that we need to do. And there are, like, different mechanisms. Like, some are AST-based. Some are just, like, creating new files. Is it somewhat to that, just in a more generic, like, outside of Angular context? Or how can I... Like, a... NPM create, but, like, a little cooler. A lot cooler, actually. Yeah, fun fact about create. That was the original name of this project, because I got the create package name. Yeah. Turns out, npx create, which tells npm to fetch the latest version of the create package if it's not already locally and then run it, is confusingly similar to npm create, which is the built-in npm command to find the npm package with create-something in its name and then run it. So I renamed it to bingo to save everyone the confusion. But to actually answer your question, you can think of it, yes, similar to the Angular ng scaffolding creating migrating. The difference is, and I think this is a really interesting philosophical reflection of Angular, Angular has its one way of doing things, which is quite good for the Angular way of doing things. Debatable. Well, looking from the outside, I'm quite envious of how much your ecosystem gets for free, you know, all these migrations. And I never shut up about how much I love your DI built in. Same. Same. This new version of Control. But my way is better. No offense. My way has more features. My way, because I've separated out from Angular, I don't have the dependencies or dependence that you do, you folks, royally speaking. I can do all these really cool, rich things. I can experiment and iterate. So, yes, it is analogous, but it is a different philosophy or set of philosophies. And it has some features that are just fundamentally incompatible with the Angular way of doing things. Why bingo? two reasons one what a fun word what i want people see see this is this is actually a learning i got from linting when you work in an area that people actively despise you need to make it as fun and poppy as possible that's part of why i put emojis everywhere and smile and ha ha ha you know like you can either fall asleep or learn about linting those are in an exciting way those are your two options so similar here no one really wants to think about oh scaffolding a new typescript repo setting up lint and test and and knip flows for you that's not appealing to most developers but if you put a fun name on it like bingo that is you know a nice way to improve it for people as an experience this is like very marketing-y in a way right yeah is that in a way right yeah um is that something you actively learned throughout your open source career is that something you were interested before is that just a necessity to for you because like most people when they are most developers particularly when they hear marketing they're like yeah the first and the third uh it is something i've actively learned both in learning to appreciate why it's useful and necessary and also learned how to do and yeah it is a necessity i think when you say marketing there's a big swat a range of what that could refer to i'm not trying to go out and like buy ads on stack overflow or or whatnot but what i do think is like really valuable and important for any project to do is to respect that people come in without initially knowing the project and if you can't educate them in an approachable and friendly way what the project is if you don't make them feel welcome they're gonna bounce they're gonna leave so bingo which is like a fun name and like a good expression of aha it works is i think actually an important aspect to consider for the the project on that for the the project on that note i have a i do have a question for you how do you feel about like this silly face youtube thumbnail marketing thing i'm i'm conflicted i'm not sure of my opinion yet i've tried not to think about it too much because the whole area of deverell influencers it angers me but there are also people i really like in it like you are someone who who does produce content and who i like otherwise i wouldn't be here Shruti Kapoor is another example yeah um so i i find it hard to criticize the negative aspects without accidentally criticizing the things that like you and Shruti and others do i think it's good to make content approachable and a lot of people will not consume content if it doesn't have that personal face yes but i do see this trend in the industry of people prioritizing hot takes and emphasizing the like the bs emotional reaction which you then see in the face reactions i yes i i 150 agree with that uh i i think at the end of the day the silly face itself is just a means to make the video more approachable in a way it's like you you also would put an iphone in a fancy box it's the same kind of thing it looks nice so the experience is better um and that just makes it more approachable the i think the content and then is more relevant like okay is this just is this like genuine how you feel about certain things or is this having an opinion just to be for the sake of being different yeah okay but sorry that there was a very very big tangent um coming back to bingo so i remember you have the create typescript app um repository are you trying to replace that with bingo is that something that you want to use for like is bingo basically like a baseline for your create typescript app um or or how do those fit into your OKRs quick question yeah and it's the latter that bingo is the foundation the framework upon which create typescript app cta is built kind of like how you wouldn't replace your front-end app with react but you would you would swap out a lot of what 10 15 years ago you might have written as view state management logic and just use react for that yeah bingo came out of cta in fact what happened with cta versions 0.x and 1.x is i built a whole bunch of specific logic you know the generate eslip config function which takes in all these different options and it was this horrible mess over time as i added more and more things to it so as many developers inevitably do when they have a big project they extract out some kind of framework or engine which then became bingo okay interesting okay but now i do have to ask that because we now have create typescript app bingo and then you also now took over stewardship of yeoman which i remember very dearly but i acknowledge that a lot of people that watch this video might not even have heard about it because it's like like i feel like 10 years ago it was like the hot stuff where like oh this is so nice you can just scaffold an app or you can create components um and it was very like broadly supported in the ecosystem like there were angular support there was express there was react was kind of like just on the verge at that point um so the verge at that point um so how how does that a how and b why yeah i i will have a blog post on this eventually uh it's just been famous yeah um why do i maintain old legacy projects why am i one of the three or four uh team members now of mocha why am i one one of the two to three members of yeoman when these don't actually fit into my primary okr around making web development easier and more powerful it's because well two three three reasons one it is useful there are people who use yeoman like the vs code extension guide is an example the jhipster company like is another example that like there are still users of yeoman um mocha is is dependent upon by ESLint typescript a whole bunch of packages mocha is very big in like the open source space so i know rx shares also used it for quite a while i'm not sure if they still use it but yeah it's it's very easy to set up and very convenient for those purposes yeah also great theming mocha you know javascript and all yeah i love it um the second is that i find it really interesting and slash get political personal insights and benefits out of it like it's really fun to go to a code base and won't fix 70 of the issues because they've aged away and they are now out of scope for maintenance mode i like that but uh but how does maintenance but how does maintenance mode look for it i how does that look like are we talking about like security issues are we talking like um making your life maintaining it a little bit easier by slapping typescript over it or like what does it look like depends on the project definitely security issues that's probably the most important thing to make sure that you know users aren't about to get hacked because of a bad update making sure packages can be pushed to by the maintainers and not anyone else uh but yeah for mocha we are targeting like quality of life features things that bring it in line with modern standards yeoman to a lesser extent also but honestly the yeoman ecosystem is much more fragmented and multi-packaged than mochas it's really mostly getting them to not crash anymore yeah okay so okay just just for yeah okay so okay just just for my overview and that's probably not an extensive list but you have bingo you have typescript eslint and i'm not saying you're the only one on all those but that's that's what you're working on right you have um yeoman you have mocha did i miss anything i'm on the eslint team i'm not a maintainer or tsc technical steering committee but i'm on the committer team and and this is how you started your journey into open source with typescript eslint eslint kind of things or was there some something before where you're like that's the cool shit uh and then just eventually ended up doing linting my first project that saw anyone looking at it other than me really was full screen mario it was oh yeah before mentioned shenanigan it i didn't even mean to make it open source i just liked how github was easy free code hosting that was it reasonable and then eventually i discovered the joy of other people sending me bug fixes that was very nice um i got into linting because i posted full screen mario online uh or it got posted online as well and people rightfully told me this code is trash what are you doing you need to use a linter formatters weren't yet popular in js at the time so that's how i got into linting but what i really got like the main projects i got started with were actually in the tslint ecosystem but typescript equivalent to eslint that later got killed and replaced by typescript eslint I'm a big fan of linting but i feel like linting every so often goes to like these waves of like oh you shouldn't lint your code it just makes you slower oh you should actually lint in ci but not local so um i don't i honestly i think linting is probably a thing that i feel like the ecosystem is the most split on in a way and and some of the linting words are also just very opinionated so i think that's part of that but what is your philosophy about linting how do you look at it yeah uh what a big area um yeah i think take your time it's one of my favorite things yeah i think linting is incredibly powerful and important and if you disregard it because there are rules you don't like you're holding it wrong uh the point of a linter is that it's super customizable and it does what you want and you can turn it off if it does stuff you don't want or you can turn individual rules or extensions plugins off what really kills me is i see a lot of people including some big names who know their stuff and get heard say kind of immature statements like you should not lint or you should delete your eslint config full full stop no context i think that's immature i think uh i think that there are times places projects people where that makes sense uh there are plenty of people who do not benefit from eslint uh you know they know better or their projects aren't the type that benefit from it or no one else touches their code but the bigger a project gets the more people who work on it the more useful these things are and i don't think it's fair to prescriptively say you should or shouldn't use linting in such an abstract sense so okay i i feel like particularly over the last two or three years um linting got somewhat of a bad rep for being slow which i personally never felt that pain because at the end it's running in a ci and if that takes a minute longer that's fine for me i don't there are other things in the ci pipeline it takes longer than linting um so how do you look at like the performance aspects of linting you see i have felt that pain and i agree with people that linting today is is oftentimes way too slow where i do differ from a lot of people is on the cause of that a lot of people think that the reason why linting is slow is because eslint is written in javascript and if we switch to native speed linters we will get significant performance improvements which is true that is part of it uh but the real performance bottleneck in the vast majority of production uses of eslint is from typed linting because eslint is not architected to support typed linting the way typed with eslint does uh a super majority of the time in most code bases i've seen that take more than a few seconds to lint are from in often incorrect or even optimized versions of my my lint config is supposed to use typed linting and typescript is slow yeah so but at the same slow yeah so but at the same time you're also an advocate for saying use type aware lint rules yes because most of the time of course not all but most of the time it's worth it okay yeah i agree typed linting is really powerful and this is another thing that kills me that people don't turn it on because it's too slow and then they say linting is useless they haven't investigated the useful lint rules they don't um i i'm very excited about typescripts being uh ported to go you know 10x faster and so on i'm also excited that the native speed linters like biome deno land oxc lint are all investigating or even starting to add typed lint rules i think that that's a really good move for the industry yeah cool um okay i kind of want to bridge that gap because i i love talking to you particularly about your typescript knowledge like every time when we chat about typescript i feel like i leave with knowing more about typescript than i used to know before so with everything you've seen i mean you you you've wrote or you worked on typescript eslint you worked on tslint you wrote a book which i have nothing but respect for i would never have enough passion to write a book um what is one thing that you see people do that you think is just just plain wrong don't don't do this uh and and i it's a little bit uh and and i it's a little bit black and white i obviously like software development is always more nuanced like it depends exists for a reason but yeah it depends you know and why i am what is it why mmv or mileage may vary yada yada yada um don't block this answer don't block your local dev server on typescript type errors yes yes it's it's a it's inconvenient because oftentimes you will have type errors when you're just messing around locally and b it means that you have to wait for type checking to finish before you can have your local development which is obscenely slow in especially larger use cases that that honestly was one thing where i had like the biggest eye-opening moment because the angular dev server used to do that in like former versions and then i was working on a vite project and i was like this is so magical yeah and like because the the way that i work at least is often like i hack something together just to make it work um and then i make it work and then i iterate over it and make the code look nicer and like make it more maintainable and stuff and for that purpose it's just so good to to like obviously it needs to compile but type errors and stuff doesn't matter at that point yeah so yes i fully agree that's is that still a thing that you see quite commonly not as commonly um commonly not as commonly um it's one of the one of the nice things about staying in open source trying to be in the you know the cultural zeitgeist or whatnot for a few years is is you see patterns come and go and especially bad patterns like uh using a linter for formatting uh or blocking dev server builds on on types of type errors bad you know with like quotes and asterisks they're the types the worse it is the more likely it is that the community tries to stomp it out so yeah i think the community has gotten better at this and a lot of other unhappy things which is a nice nice trend to see i i do have to circle back to that because you you now touched on that like two or three times with like the linter's to formatting um draw linter's to formatting um draw me a picture with words what are we talking about here sure so there are three common forms of static analysis in the web world today it's three common forms linting formatting type checking formatting doesn't change your logic and almost always does not change the ast the representation of like literally what is in your code file formatting like indentation white space new lines linting is stylistic stuff like naming or whether you should use you know um one code construct or another excuse me and then light uh type checking is you know type script like this you said number but you gave strength formatting is something that people used to use linters like eslint for because you know you can write a lint rule to ensure indentation that's fine but what we've discovered is that linters are inherently structurally bad at formatting uh something like prettier or dprints which builds like a one pass model where it just reads in your code into the ast and then poops back out the results onto the page of formatting it are much faster and much much cleaner yeah so was that the cleaner yeah so was that the reason why i think because i think with the latest major version of eslint this got separated for like compatibility reasons and like its own package for people that still use it um but it's not part of eslint core was that like part of the reason or where is that coming from yeah um eslint yes as you said used to have a lot of formatting rules and uh those are now split out uh Anthony Fu uh over from vite and vue ecosystem worlds was kind enough to take him on into his eslint stylistic project i think though that there's like a root i don't agree with this mentality that i i'm happy to see people slowly moving over towards over time some people which is that i want to spend as little time and energy as possible thinking about formatting and stylistic concerns why do i care about this i'm i'm not writing code to have clean code i'm writing code to do something so as much as we can automate that stuff the better yes so i don't want to use eslint rules that allow me to concretely definitively manipulate every little preference of formatting because i shouldn't be caring about that formatting in the first place it's a waste of time having that said does that mean you slap on prettier and call it a day on your projects or are you more in that sense like i don't care about formatting in general i think you should use prettier i definitely use prettier or an equivalent formatter right right it formats for you so you can type whatever garbage you want and it consistently formatted code is beautiful it's easier to read you don't have to worry or think about things you don't have weird unexpected changes from whitespace and prs definitely okay okay i because that's what i assumed but i've also talked to um some people that say okay the formatting of code provides meaning to it so having something automating it takes away that meaning which is a valid argument in a way but i fully agree particularly with like code bases where more than one person touches it having something like prettier where it's like ensures consistency so you know what to look for is great benefit yeah i i would like to benefit yeah i i would like to i i have to circle back to typescript like i can just not talk to you and not talk about typescript even though i like talking about linting with you because it's very inspiring in a way like the the way you look at it but you just know so much about typescript i i have to so what is a typescript feature what is a typescript feature or pattern uh doesn't really matter that you think is criminally underused in today's ecosystem type linting or overused or overused oh man i think in general type narrowing the feature is something that people i wish they treated and considered to be like a foundational you should really master this first thing but tends to be relegated to advanced sections of guides agree it's a really really nice thing though and like properly using type narrowing lets you avoid so many of the confusing patterns like on like as assertions that people put into code that really make it hard to read okay i to read okay i might still have to figure out what you think is overused i know what i think is overused well what do overused well what do you think is overused oh you know well it's not even overused it just is a mistake from the start enums in itself should have never landed in typescript um so useful though i would have i would have devil advocated you either way but okay okay okay so why do you think enums are useful what you can do with enums that you cannot do with other existing typescript primitives or patterns you can do all sorts of stuff with existing typescript stuff outside of enums it's just inconvenient to which is a fact a string literary types are very convenient they are but they don't have as good find and replace or rename or go to definition very debatable and we're now touching territories that i feel passionate about we can't talk about the shortcomings of the typescript language server but no i'm literally not a language issue agnostic of whatever language server or service you're using if you use a typescript enum uh and you say you know fruit enum with with apple equals apple banana equals banana cherry equals cherry and you find all references on let's say banana it will give you that whereas if you have just the string literals you know in a union apple or banana or cherry and you want to find all references on banana conceptually that doesn't make sense because what if you have other literals that just so happen to also be banana so again we're touching on something and we should probably not touch on but there are tools out there in the ecosystem that differentiate between string literal types and just strings that happen to happen the same and you can distinguish this just saying sure but also you cannot use uh you could use objects an object notation for itself uh it wouldn't generate the same amount of boilerplate that enums generate and we could use const enums but then we cannot use isolated module so um this this is something that should be solved in javascript at some point i i agree with that i would be happy a if it's compatible because i don't want to have like another decorator mess it's not going to be compatible i'm so sorry Jan-Niklas it's there's no way in heck and and that's exactly what i'm i'm thinking but yes i think i i would be okay if the enums concept would land in javascript then i would be okay with having enums in typescript but i'm very much against the idea of having a typescript only feature that does not exist in a language i agree i think that objectively right now um i try to avoid enums whenever possible because much like decorators we know there's something coming down the line there is a proposal for enums in large part championed by people on the typescript team problem is when type you came out it didn't have narrowing it didn't have literal types or unions even that's there was no good way at the time to do what is covered by enums but to be fair at that time also string enums were not existing and number enums are just so so useful like i think we can agree on that too i don't know man typescript have you typescript's code base heavily uses number enums and bitwise logic okay i can i can see i can see that but then they can use it internally i don't care about that yeah just don't export it yeah yeah and honestly the fact that typescript is probably one of the biggest exemplars of enums and bitwise logic brings up the question of well is that something you should be writing in javascript code if you need to optimize so heavily for your memory management well or go or go yeah um okay okay i shared i shared my opinion and i mean that's pretty known how i feel about enums but at this point i feel like i every time i have the uh the possibility to rant about enums i'll i'm very happy to but coming back to you what is your criminally overused typescript feature uh unnecessary type annotations probably fair so i did this when i was new yes so am i reading between the lines that you are in the camp that prefers type inference when possible yeah yes same i like from my perspective i was like very much like oh no you should explicitly it makes it easier to read and stuff but like the minute you have like a code base that is like grown a little bit and you want to make changes having type inference is so much nicer because you get to know immediately the places you have to change instead of just like diving through function by function that's i like it a lot yeah for sure typescript is really good these days in ways that it wasn't when it first created was first created it can infer some beautiful types for you to the point where if you're writing explicit types you consistently you will eventually just force typescript to be less powerful and and reduce its knowledge of your code base which is very counterproductive very much agree is there a lint rule for this there is it's not super powerful though it's hard to write a lint rule for that that's what i was wondering yeah because sometimes people want a type intentionally to be wider more general than the inferred type and it's hard to know when people do or don't yeah that makes sense so okay i i'm because i mean i can talk so uh you you were just talking about like the typescript code base you i have seen proposals from you in the typescript code base explaining how um how pure functions should um or could work for making signals more useful or like more ergonomic basically so what is something if you were on the typescript team i mean you used to work my work for microsoft so it's not like out of the blue um that you would love working on oh boy well you'll working on oh boy well you'll probably ask me for a more specific range but the website and the documentation in general it's so bad it's uh yeah it's better than it used to be i will say uh their v2 of the website is really nice but they have effectively feature frozen mostly the the current website they just don't have the budget to work on it which is and and i i get that i i love how detailed they are with the release blogposts those are really really helpful um but release block posts are not docs yeah it's weird like uh for example the learning typescript article that i wrote on branded types i didn't want to write that article why is describing like this common this known pattern and falling to some random person's book blog because this there there's a lot of stuff in typescript beyond the foundations that just does not have documentation in any first party resource i funny enough i did a conference talk and was mentioning branded types and no one was like or like no one approached me was like oh yeah i've used that for years that's dead obvious like everyone was like you can do that yeah and it's such a nice feature particular for type safety like the amount of issue or the the amount of issues i had of like oh i handed in uh address id instead of like the location id into that function they're both just strings um so yeah branded just strings so yeah branded types also probably one of the things where i would say it's kind of underused people should use that more yeah yeah i wish there was um i wish there was a good way to do them in typescript itself i don't i don't think anyone's figured one out that's so good that the team would really feel excited about it that's true my guess a little hand rolled still kind of like we used to have the um in the switch block the assert unhandled case oh you probably you probably did that too where you had like a function that took never as an argument and therefore when you when the uh control flow ended in that default block you know okay you cannot pass an argument to never amd typescript was smart enough that if you had an exhaustive check it would not go to that never block um but yeah that got handled with compiler options which i'm very happy for um but yeah i would like to see something like branded types and uh kind of like you have utility types like record or something you can handle it all it yourself but having like a branded type would be nice i don't know i uh what i really want is a glossary i want i want every term that people use like discriminated union what the hell does that mean is this is this so worried something to have a place where we define what the term is and then if we want to update the term like if we figure out a less you know hair raising term than discriminated union we can update it in one place yes yes that is a really good one a glossary would be nice and but some of those things are also really hard to um to google for like if you have like the the exclamation mark for like uh non-null assertions you see that exclamation mark on the code press but you cannot google for like what does exclamation mark mean in typescript yeah for sure um no it's hard that's actually you know what i i don't like relying on AIs because uh for for fundamental learning things because they get so much wrong but this is an area where it was kind of just about to say oh yeah i uh so i think i talked about this before with Mark on this podcast but i think AI for learning is kind of dangerous uh because you might rely on that without putting in the work of like going through the struggle but that's in the how developer most developers i know at least learned by like i have a problem i need to figure out the solution and if ai tells you the solution you don't have that experience you don't have that pain and i think pain is a good motivator for learning every high school gymnasium in the states pain is weakness leaving the body whatever non-problematic version of that we're saying that okay i'm now a little okay i'm now a little curious because and for the record you touched on AI not me um are there ai tools that you use in your workflow to keep up with like because github itself for like notification and stuff is also kind of eh um but are there tools that you use that help you in your daily workflow yeah i've turned back on copilot a few weeks ago um the last few years ever since it was released i would every few months turn it on try it out get annoyed at how it was net negative and turn it back off and this time it's stuck i think it's gotten good enough i think my philosophy for using these things that you should never let an ai make a decision it's never a driver it is it's a fetcher it will it you should not use it to explain the docs to you you should use it to find the docs and then get to them um it can summarize but it can't create and then i treat it as in my editor just autocomplete like if i want to write an annoyingly long function or switch case or something i i will wait for copilot that extra half second to fill it out for me yeah i i'm not a big fan of like this vibe coding mentality uh to be super honest i like to see ai as a tool in our tool belt as software developers to like assist us make us more productive um and make us more productive um and that includes things like i have this massively big code base and i need to fix this bug i have no idea where i'm able to start for help me find the place generating software is at the end of the day still very complex mechanism in itself and having it completely auto generated without having the fundamental understanding how things work i think it's just a liability issue yeah i i hear a lot of shades of you know when stack overflow and similar got popular of you you shouldn't lose the ability to learn or the to seek but this is a great tool in doing it and eventually i think that vibe coding at least some variant of it will become a reasonable thing to do once the ais are much better than they are now but currently with the tools we are given i do not trust the ai to write code that i would not just write myself yeah i i mean just write myself yeah i i mean i i experiment with those kind of tools every so often um and i like that they show the diff where i can like go through and be like okay i would have i would have done that too that makes sense this is utter garbage let's remove this um um i do want to circle back uh because we're going close to the hour mark here um i want to circle back to open source for a minute i want to take away like the technical aspect of open source and focus more on like the human side of it like is there anything where you notice personal growth within your journey and i mean you're doing OKRs so yeah you have a very measurable you know the third measurable you know the third reason that i take on these old projects like mocha and yeoman is for the money okay oh i i can see that paid labor kind of like the cobalt developers that are now fucking rich yeah yeah yeah my lamborghini comes from legacy software uh i yeah it's valuable labor and someone should be doing it and i am now one of those people one of the personal growth areas to answer the question is i've gotten a lot better at valuing my time in myself um there's this hard balance between thinking too much of yourself and getting annoyed when people question you to assuming that you are a public servant for everyone and everything and not being comfortable making demands or telling people no or asking for money that's been a big growth for me i think yeah i think that's in a way really difficult to like balance that because at the one hand you have a vision for the project in a way so you need to tell people like hey it's open source you can fork it if you have a different vision than what i have but on the other hand people are using it people are relying on it so you want to be like this kind of service organism in a way that's interesting how did you find the balance there because this is nothing that you're like overnight you get like an epiphany and be like this is where i draw the line all of a sudden all my emotional traumas and triggers are gone no it's a it's a slow growth um a lot of people are nervous myself included to stand up for themselves because you know they've been rejected in the past or um they don't want to make a fool like i i come in with a lot of imposter syndrome and i assume everyone else knows better so like why would i say no to someone who's my my better um another thing is and this is actually i think probably more relevant to a lot of listeners uh as well um conflict resolution or non-violent communications someone is posting angrily on a github issue what what do you do how do you turn that into a positive learning slash teaching moment um this is all kind of mixed together and you know being able to logically evaluate a potentially emotionally charged exchange where much context is lost and turn it into something positive i i had similar learnings in my dev rel role i can i can empathize uh circling back to your Lamborghini though if there's anyone in the ecosystem that i would wish to have a lamborghini even though it's a stupid car and certainly you because i mean like a leaving like the comfortableness of like a FAANG company fam fang even microsoft is not a fang company but that always irritated me microsoft deserves to be in the acronym yeah i agree well i'll just put them in there even though it's not in the acronym but um i mean it's a big step i assume you and your partner were somewhat concerned i would at least um so and you're doing great work for the community so thank you very much for doing all that and i i would be happy for you to have a lamborghini i would really highly advise for different car because lamorgin is so stupid but well you know what it's the internet meme so yeah yeah i i'm not worried about the financial side of things um for a few reasons one is that i have good savings from my time at microsoft and then i actually told my manager that i had finalized my decision to leave codecademy i think it was one week before the announcement to the two of us went in that we were getting acquired very good monetary strategy on my part by accident another is that this is kind of an investment in me that i have raised my profile my knowledge i my reach uh my abilities in coding and when i do go back to industry if and when i'm going to have a much nicer paycheck as a result yes i i very much hope so for you and like one thing that i think honestly is criminally unarrated for another on the open source side that is like often overlooked is the network that you built within yeah you and i would never talk otherwise like i wouldn't say that you're pretty nice guy thanks well just to be clear we would not have been introduced was the correct way to say what i'm trying to say yeah yeah like that i wouldn't have been able to go to conferences and do all this stuff if i wasn't you know talking about typescript and doing open source work like that's just not something that would have happened yeah yeah we got at a conference and then we like walked your kid around the the courtyard because you know we were just chatting and it was nice and now we're doing it again here yeah this was great thank you so much for joining me i as i said in the beginning every time i talk to you i feel more inspired i i i love talking to you you're such a scarily optimistic person so again thanks a lot for joining me today and yeah see joining me today and yeah see joining me today and yeah see you next time and hopefully we meet again at a conference it's been a while since we met in person yeah we should make it happen but yeah no thank you so much for letting me come on rant about linting and promote my projects i i really appreciate it it was fun good glad and with that said thank you very much for joining today see you