EPISODE 1740

[INTRODUCTION]

[00:00:00] ANNOUNCER: ESLint is a static code analysis tool for identifying and fixing problems in JavaScript code. It helps developers maintain code quality and consistency by enforcing coding standards and detecting issues such as syntax errors, stylistic problems, and bugs. Nicholas Zakas is the creator of ESLint. He joins the show to talk about working at Yahoo in the early days of the web; learning from JSLint, creating ESLint, separation of parsing and rules, and more. 

This episode is hosted by Josh Goldberg, an independent full-time open source developer. Josh works on projects in the TypeScript ecosystem, most notably TypeScript ESLint, the tooling that enables ESLint and Prettier to run on TypeScript code. Josh is also the author of the O'Reilly Learning TypeScript book, a Microsoft MVP for developer technologies, and a live code streamer on Twitch. Find Josh on Bluesky, Mastodon, Twitter, Twitch, YouTube, and dot-com as @JoshuaKGoldberg. 

[INTERVIEW]

[00:01:14] JG: Hello, everyone. With me today for Software Engineering Daily is creator and maintainer of ESLint and leadership coach for developers, Nicholas Zakas. Nicholas, welcome to Software Engineering Daily. How's it going?

[00:01:24] NZ: It's going great. Thanks for having me. 

[00:01:25] JG: We're excited to have you here. Just to start us off, could you give us a brief overview of who you are and how you got into tech?

[00:01:32] NZ: Yes. Well, as you mentioned, I'm the creator and one of the maintainers of ESLint currently and a coach for software engineers. I got started initially - say my first language was actually basic on an Apple 2e clone, not the actual Apple 2e because it was too expensive, and kind of quickly found my way into Windows Gooey programming with Visual Basic 3.0 and did that for a little bit before discovering the web and then falling in love with HTML and JavaScript, CSS didn't exist at the time, and decided to focus my career on that. I spent several years learning as a developer and actually on a UI team, rather than as a part of the engineering team before officially moving over to be a software engineer and focusing on front-end architecture for web applications. 

[00:02:35] JG: How did you get into frontend in the web in the first place then? That's kind of a big jump. 

[00:02:40] NZ: Yes. In college, I actually started tinkering around with this new thing called a web page because prior to that everybody just kept touch on it AOL, and I really became fascinated with how to put up a web page as a way to keep in touch with my high school friends when we were in college. Set up a basic web page first on AOL like members. aol.com/ whatever it was and set up a guest book, so people could leave messages. Yes, my small group of friends from high school basically kept in touch with that little web page, just leaving guest book comments. 

Over time, I started seeing like little animations on other web pages, and so I wanted to figure out how that was done. At the time, the way that was done was with some very simple JavaScript, and I just got hooked on it. It just seemed amazing that you could create something that is supposed to be static. It's just a page, but then you can start to add some interactivity to it. When you hovered over an image, it could swap to a different image. That was really exciting to me, so I went through and made sure all of my images had hover effects. 

I just kept going deeper and deeper, and JavaScript was developing more and more. Every time I saw a new article online, a new book came out, just immediately dug into it and tried to figure out what else I could do for this little web page. 

[00:04:24] JG: A lot of people take for granted now that we have extremely dynamic network request and response-heavy web pages. But it is beautiful to think of the simpler times when every image had to have a hover effect, and that was roughly the extent of the interactivity. 

[00:04:38] NZ: You had to wait like 30 seconds for the hover effect to be shown because it was actually downloading another image over a 28k modem, unless you learned how to use JavaScript to preload the image, which was very exciting when I figured out how to do that. 

[00:04:55] JG: Those were the days. We still have a lot of the same troubles and problems these days of getting folks to pre-load images and requests and resources as they are needed. You started getting into JavaScript in the web. How did you get into open source?

[00:05:09] NZ: The first open source project I worked on was at Yahoo called YUI. That was their front-end framework that was actually pretty popular for a while there. I wasn't actually part of the YUI team. I was just an adjunct contributor, but I did create the testing utility and the cookie utility and worked with them on how to get that stuff out. There was the SourceForge era, and then we were all very excited when GitHub launched. 

I remember the discussion actually with the YUI team of should we stick with subversion when we go public? Or should we try this new thing called GitHub and this new source control system called Git? That seems to be where a lot of projects are going. The decision was made to go with Git and GitHub, and that was really my first foray into open source in any sort of reasonable way. From that, I found my way into some other little projects and then eventually made my way to ESLint, a large project. 

[00:06:28] JG: Do you ever missed the days when you had time to just work on smaller projects and you weren't consumed in open source by these big titles like ESLint? 

[00:06:36] NZ: I do actually. I have an extended list of projects I'd like to write that it never goes down. I just keep adding new things to it. But I do try to carve out a few hours each month to just kind of hack on some things for fun that, hopefully, a lot of people won't use, so I won't feel the pressure to actually do anything with it but just to explore different problem areas and try different things. 

[00:07:04] JG: You can tell someone has been an open source maintainer for a while sometimes because for many of us, we get to the point where the more successful the project is, the more likely it is we want to go do something else that's the opposite level of publicity. You got into web. You got into open source. Hooray, GitHub. How did you get into linting as a space?

[00:07:24] NZ: My jump into linting also began at Yahoo. Douglas Crockford worked at Yahoo, the creator of JSLint. All of the projects inside of Yahoo used JSLint in order to validate code before pushing to production. That was pretty useful because, as I said, I created the testing framework for YUI. Before that, there were no tests that people were running against their JavaScript. There was only linting. That was the only thing protecting our code as it went out. When I became the front-end tech lead for the Yahoo homepage, we were trying to enforce certain practices on the team and became pretty apparent that with a distributed team, we had 20 front-end engineers in four different countries that we needed some automation in order to do this. 

I created a custom version of JSLint. I went into it and added in all of our standards on the project that were separate from the generic standards that were built into JSLint. We would run that on all of the JavaScript code as a way to communicate what was expected in your code to everybody on this team no matter where they were. Whenever we came up with a new standard, I would go in and hack in a new rule. It was very painful, very difficult because JSLint was not made to be extensible and to add other rules into it. It's basically just a parser that has rules interspersed within the parser itself. You actually have to go into the parsing logic in order to add rules, and that was pretty difficult. 

From that point, I continued on. When the fork came out of JSHint, I contributed to that a few times, talked with the maintainers several times about problems I was having, ideas I had, and different directions that maybe the project might want to head in. Ultimately, I didn't get too, too involved with that project. Then Nicole Sullivan and I came up with the idea to create the equivalent tool for CSS which was CSSLint. That I wrote from scratch so that the parsing and the rules were separate. But because of the tooling at the time, all of those had to be compiled into a single JavaScript file to be run on Rhino. 

Even though the parsing logic and the rules were separate and you could add custom rules pretty easily if you wanted to mess around with the source code, you could just clone the repository, you could define your own rules, and then you could compile it all into to your own single JavaScript file and run that. When I decided to go forward then with ESLint, I just took that to the next step of the parsing is separate from the rules. But also the rules can be separate from the overall package and loaded at runtime. Yes. That represents almost a decade's worth of linting experience before ESLint became anywhere near as popular as it became. 

[00:11:02] JG: You're splitting out the parser which is the thing that takes in text, let's say, a .JS file and turns it into what the linter would deal with. Can you tell us a little bit about what is it that the parser outputs that the rules then use?

[00:11:15] NZ: Yes. The parser outputs an abstract syntax tree, AST. I think it's important to note that not all parsers create an AST. That is just the way that we do it. Parsers don't have to output anything like the parser that is in JSLint and JSHint. It doesn't create any sort of artifact of the parsing. Everything is just done right in line with the parser itself. But in ESLint, we started out using Esprima which was a JavaScript parser written in JavaScript that would generate an AST. Then the benefit of that is that we can traverse the AST and look for certain patterns. Each rule in ESLint just looks for certain patterns within the AST. In that way, we can keep the rules decoupled from the parser itself by using the AST as the interface that they both work with. 

[00:12:15] JG: Rules have no idea how the AST they're given, this little representation of code, was created. It's just they're given it, and then they're given the hooks to be able to say query for all variable declarations kind VAR so that they can then complain. You should use letter const or whatever the rule is meant to do. 

[00:12:31] NZ: Exactly. Yes. 

[00:12:33] JG: Great. I think it's really speaking to the power of customization and the plug-in model that so many people have created so many different things to use ESLint for. I personally have a template that has something like a dozen plugins created for ESLint that do all sorts of different things. Do you have any favorite plugins or things people have customized ESLint with that you weren't expecting them to use back in the day?

[00:12:56] NZ: Yes. There's - one of the things I was hoping for and has happened is people defining best practices for different frameworks using ESLint which was pretty cool. I expected that to happen for web applications. What I didn't expect was that it would also be used for mobile applications because of React Native. Because when React first came out, ESLint was the only linter that could parse JSX. 

That's why the React Community moved from JSHint to ESLint but didn't realize that that same code could also be used to create mobile applications with React Native because all of a sudden, we were getting bug reports and feature requests from mobile developers. They're like, "Hey, can you add this to ESLint?" Like, "Well, sure. But why? What are you -" "Well, we're doing React Native, and we have this mobile application. We're using it." That really just blew my mind. 

[00:14:01] JG: There's another set of additional functionality that's changed in ESLint over the years, what's considered formatting versus style versus logical. When ESLint first came out, there was no Prettier. There was no auto formatter. How was your opinion of what ESLint should or shouldn't be used for changed over the years? 

[00:14:19] NZ: When ESLint started, I didn't have a clear idea of what it should and shouldn't do. To me, I was just going to return the AST and some additional syntax information to rules, and rules could figure out what they wanted to do with it. If they wanted to look at potential problems, they could do that. If they wanted to do styling, they could do that. It really didn't matter too much to me. 

The history of linters and JavaScript was that they would do both. JSLint and JSHint both did formatting and correctness checks. In fact, when ESLint first came out, JSHint had just announced that they were planning on deprecating and removing all of their formatting rules which in hindsight should have been a flag to me. But going forward, a lot of the requests we were getting were, "I want to use ESLint. But in order to do that, I have to have all the same rules as JSHint as a starting place." I said okay. We'll create all the same rules that JSHint has if that's the thing that is preventing people from swapping over, and we will just see what happened. 

I started to see fairly quickly that the formatting preferences that developers have are varied and incredibly personal. People would get straight up upset if ESLint couldn't support their favorite way of indenting things just out of the box. How could you possibly create something that was so inferior that it wouldn't indent things the way that I indent them all the time? Early on, I thought, well, there's got to be just like a finite number of formatting rules, and we can just add options and whatnot. 

As JavaScript evolved and added more syntax, there were more and more formatting rules. That meant more and more preferences that we were trying to address, more and more options for rules. The rules were getting larger and larger. The number of rules kept increasing, not doing anything that is preventing errors, but just so people could have the proper spacing around new syntax and eventually came to the point where I realized that this was taking up too much time. The maintenance overhead for maintaining those rules was just way too high. 

We eventually decided with the help of there being formatters like Prettier and dprint that ESLint is not best suited for formatting source code. That is additional overhead that you add into your linting run that at best is not doing as good a job as dedicated source code form matters. At worst, it is complaining to people about things that should be automatically fixed. I don't know any developer who's like, "Oh, thank God. ESLint told me that this was indented three spaces instead of four." Now, the expectation is like, "Well, just fix it. I don't care about that. I just want to move on and get my code working." 

We decided eventually to deprecate our formatting rules and just focus on more of the correctness rules because I think that that is where ESLint's strength is. Trying to be a formatter in addition to that when there are just far superior tools isn't a good use of our time. 

[00:18:18] JG: Do you have any opinions on the sharp rise and gradual decline of stylistic and opinionated presets in the community such as ESM plugin Airbnb?

[00:18:28] NZ: Well, it's interesting. I think that the style guide plugins initially were the solution to the problem of there not being good source code formatters. Early on, I think it was hard to get people to understand how important it was to have a single style guide for your whole code base. I remember fighting that battle very early on with some of the teams that I worked on. They're like, "This is table stakes. We should not be debating this stuff." I remember I was in one conversation where we spent an hour debating spaces or tabs for indentation. It's just a huge time sync. 

Airbnb, I think there was also something called idiomatic JavaScript at some point. Then the Google style guide came out. I think those were great initially because it told a lot of developers like, "Hey, these big companies, they take this stuff seriously, and you should, too." But there was no way to programmatically enforce those until ESLint came along. I think it was natural for those folks to migrate to ESLint to say like, "Okay, there's no other way that we know of that we can enforce this style, so ESLint is the way to do it." 

I think early on, that was a very big selling point for ESLint. It's like, "Hey, you like the Airbnb style guide. Install this. It's just going to do it for you, and you don't have to re through the multi-page document that they have." I think over time, we have matured as JavaScript developers to realize that there is probably not one ultimate style guide that makes sense. It just matters that you're being consistent with whatever it is that you're doing. Highly opinionated tools like Prettier coming along and just saying like, "Look, we'll give you a couple things to tweak. But generally, this is the way your code is formatting." 

I think a lot of people started to look at it as like, "Oh, yes. I guess it's really not that big of a deal if it's not exactly the way that I would do it by hand." I think that that led to that decline in the popularity of the style guides and the ESLint plugins, although those are still, especially ESLint plugin Airbnb, still very popular. But I think that people are just starting to realize now that it's okay to just have a style that you don't have to talk about and just apply it automatically, and you don't need to think about it anymore. 

[00:21:09] JG: That's very true. It's, I think, a testament to the youth both of web development and the broader software industry that we're still figuring out things like how do you effectively apply formatting in a codebase that that isn't just a solved problem. I want to take things a little higher level, so we can transition over to your leadership for developers coaching side. 

Let's start by talking kind of broad next steps for ESLint. One of the great things about ESLint is that it can be used to kind of effectively transmit styles and best practices across a team. Where do you see that fitting into kind of the leadership role for software developers on being able to help folks be their best?

[00:21:48] NZ: The goal of ESLint is to help provide some structure around your code. Every rule that's in there or every rule that you choose to add is saying that a way of doing something is important, and we want to make sure that we have enforcement of it as automatically as possible. That allows us to not worry about whole categories of problems anymore because we know that ESLint is going to catch it for us. 

I think as software engineers and, especially as you start to move up into the senior and staff and principal levels, you run into a similar problem with the teams that you're working on is that there's going to be best practices you want people to follow. There's going to be good ways to do things that you know will work and bad things that are known to break. Figuring out how to get that onto your team, figuring out how to create a structure, how to create guard rails so that your team can work most effectively becomes a huge part of the job. 

I like to tell people that you reach a certain point in your software development career where software development is not the most important part of your job. It actually becomes a means to an end, and that end is delivering a product so that sometimes you might write code to do that. But sometimes, you might be defining processes. Sometimes, you might be setting and communicating expectations to people and then holding them accountable when they don't meet those expectations. 

That's challenging. It's not a skill set that you were developing writing code eight hours a day for most of the week. It's a very different skill set. For a lot of us, we're just thrown into it like, "Hey, by the way, you're the tech lead. Go lead tech. Have fun." That's how I kind of found my way into this coaching role is a lot of people have trouble with that transition, simply because they were never taught or trained on any kinds of tools in order to assume that leadership role without actually being a manager. 

[00:24:21] JG: That was a very common trap where people use the tools that are comfortable for them. When I first became a staff developer, my instinct was, "Great. Now, I can enable all the lint rules that we have that enable practices that I specifically want." Then, of course, that rubs people the wrong way, and it's not an effective way to transmit practices. 

Let's say that I'm taking you on as a leadership coach to help explain what it is a leadership coach actually does. I have this problem where I'm trying to enforce opinions on the team, and it's not going well. What are some of the pro tips or strategies you might take to help me?

[00:24:54] NZ: This is very common, especially with new leaders where, again, somebody comes along and says, "You're the tech lead or you're the staff engineer. We trust that you know how to do things best or at least better than most of the other folks." You're expected to teach them how to be just as good as you. Go do it. I ran into this personally where I got - when HTML5 was first coming out at Yahoo and the director said, "We need guidelines for how we're going to use HTML5. Nicholas, go off and do that." 

I went off and ton of research, ton of prototyping. Put together this massive document of all the ways that we could leverage HTML5 and deliver that to director. He was like, "Great. Deliver that to the team." I deliver that to the team, and they're like, "Hey, you never talked to us about this. What are you doing? I disagree with that. That's not the way I would do it." I'm like, "I don't get it. I thought I was in charge. I thought people would just listen to me." 

The truth is regardless of what type of leadership position you're in, you need to earn that trust from the team before they will follow you in any particular direction. The way that you do that is by involving them in the process before the decision is made. That's the building consensus in order to move forward. You need to accept that building consensus takes time. It's a lot of work, and you actually have to care about other people's opinions. Faking it doesn't work, but you really cannot move forward until you get the consent of the team to do so. 

I typically advise people, when you're in a situation like this, first thing to do is identify who is most likely to be your ally. Go and talk to that person and confirm if they're on board with what you have in mind. If not, see what you can adjust to get them on board because once you have one other person on board, then it's no longer just you trying to dictate. There's a growing consensus that this is a good way to go. Then you go to the next person and talk to them individually and see if you can get them on board. Once you get enough of those people, bring everybody together to discuss. Then you're able to move forward. 

As part of that process, it's important to also outline the roles everybody will be playing because if this really is a decision that you want to make by consensus, you want it to be that everybody on the team agrees to go along with it without any reservations. Then it's important to state that upfront like, "We are making this decision as a team." It's also okay to say that, "I am making this decision individually, but I am consulting all of you. I want to hear your opinions. But then I'm going to synthesize that information and make the final decision myself." In either case, you're well on your way to getting that done. You just want to set that expectation up front so that they know how the final decision is actually being made. 

[00:28:38] JG: In larger teams, especially distributed one, it can be very difficult to communicate that decision across different, say, product areas or types of folks. Let's say you're trying to, I don't know, enable some infrastructural upgrades, and not everyone really understands what they are or why they're useful. People have different views on which directions and investment areas should be made. How would you go about trying to resolve those tensions between disparate groups?

[00:29:05] NZ: The initial thing, again, is to talk with people before you roll out the changes because you will get the most anger and the most push back if changes are made that people are not aware of. The very first thing is to let people know that change is coming. We're going to be making a change that we believe is beneficial to the organization. We're going to be talking with a bunch of stakeholders. If you think that you have some important information to share, please reach out. Love to discuss with you. We'll let you know as the process is ongoing what is happening, where we are. 

Then give regular updates. Whether that is email, whether that is Slack, whether there is some internal Internet app that the company uses, most companies have some place to share information with a larger audience. Over communicating as you're going through it helps a lot. Once a decision has been made, documenting that decision is really helpful. There are formal structures out there, architectural decision records. But you don't need to have something that is already defined. You can just write up a document that says, "Here's what was decided on this date. Here's the person who made the decision or the group of people that made the decision. Here are the factors that were considered as part of this decision. Here were the alternatives that were considered, and then this is why we ultimately went in this direction."

So that when those questions come up, because they will, there will always be somebody who's like, "Oh, I was unaware that this decision was being made. I really wish I had been involved. I really wish I had known." You can say, "Well, I'm sorry that we weren't able to involve you. That was definitely not intentional. But here's the record of the decision and why it was made. If you have any questions about that, let me know." You can continue building up frequently asked questions section on that document as those questions come up. 

Generally, engineers are very logical people. If you can show them that you considered their concerns, even if you didn't talk to them directly, even if they don't agree with the final decision, they are more likely to disagree and commit. To steal a phrase from Amazon, say like, "Well, okay. I mean, I guess I couldn't have affected that decision. They did actually talk about everything that I was concerned about, and they just made a different decision than I would have made." 

[00:31:55] JG: To steal another phrase, could you tell us what the Peter principle is and how to try to mitigate it?

[00:32:01] NZ: Yes. The Peter principle is the idea that you keep getting promoted until you finally reach a level and a job that you're not good at. This is not specific to the software industry. This is a general business principle that as you get higher up in an organization, the job fundamentally changes. If you're a software engineer, you start out and you're spending most of your time writing code. You get promoted to senior software engineer, and maybe you need to take on some additional tasks. Maybe you become the sprint leader. Maybe you are managing the task board. Maybe you're asked to sit in on product meetings. You get promoted to staff engineer. All of a sudden, you're in a lot of meetings. You're expected to be organizing multiple teams. 

This is not what you went to school for. Your BS in computer science did not prepare you for coordinating across multiple teams. Maybe you're good at it, and maybe you're not. But it is a different job than the one that you started out in. At that point, you have a decision to make which is I'm going to take on this challenge, and I'm going to adapt to this new role, knowing that that means leaving behind some of the stuff I really enjoyed, leaving behind the six-hour blocks of time to code in order to organize things within my team or across teams. Or I don't like this, and I really want to go back to what I did before. 

It's not uncommon to go through that several times in your career. When I was at Yahoo, I wanted to be promoted to the level of architect really, really badly. I made my way through several s at Yahoo, finally got promoted to architect. Yes, I got there. This is great, until I discovered what it actually meant to be an architect at Yahoo which was meetings every day. You're on this committee. You're on that committee. Somebody's asking you to take a look at this problem. But just guide the team. Don't actually get involved because you don't have enough time to be writing code. Go and talk with this executive about this issue. Those people in this different product don't have enough technical expertise on their team. You need to go fill in over there. 

Yes, within a few months, I was just, "This is not what I wanted to do." I had no idea that the goal I was striving for was actually not what I wanted. I left Yahoo, reset, tried to figure out what I actually wanted to do. When I joined Box, I was able to tell my manager like, "This is what I want my role to be. I cannot be in meetings all day every day. I need to have some time to code. I don't mind if I'm not doing it every day, but I need to stay in the code." Being able to better define that job at the start let me be a lot happier when I joined there, until eventually that role started to drift, too, as they tend to when you're in a more senior IC role. I needed to kind of reset there as well. 

[00:35:27] JG: Do you wish that you'd had a coach when you were striving to be an architect at Yahoo to help explain to you what that role actually entailed?

[00:35:34] NZ: I do. To Yahoo's credit, I had some of the most important mentors of my life at Yahoo who definitely helped me grow from that senior level to that staff level, to that principal level. I wouldn't have been able to do that without them. But as I moved on in my career there, my mentors started to leave. As I was getting towards the end of my time at Yahoo and towards that bigger promotion, I no longer had that council of elders, so to speak, that I could fall back on and ask them about like, "Is this what it means to be an architect? Can I change this in some way?" I had no idea if I had any power to change what I was working on or if I needed to just suck it up because that's what it was or if I needed to leave. 

Yes, definitely having key mentors at those moments in your career can make a huge difference. That was one point in my career where I definitely was needing one. 

[00:36:43] JG: I'd like to start wrapping up and bring things a little more full circle. Are there any particular leadership points that you find do or do not translate between corporate work and developers at companies versus open source landscapes and developers?

[00:36:57] NZ: Yes. Well, I think going back to the concept of building consensus, that travels very well. It doesn't matter if you're an employee at a company trying to get people inside the company to do something. Or if you're in the open source world where you have no levers to pull because everybody's volunteering, and all you can do is say, "Hey, would you do this? Will you do this? Will you please do this?" 

Learning how to build consensus among a group of people is, I think, the one skill that travels with you no matter where you go. Even if you happen to change industries, just understanding that, everything gets done through people, at least until our AI overlords arrive and take over everything. But for now, everything gets done by people. Learning how to get everybody on the same page is something that's going to work very well no matter what you're doing. 

The stick side of that carrot and stick equation in the corporate world, it can work very well to say, "Hey, either you live up to expectations or it's time to move on." In some cases, that is necessary. If you've given people the feedback, they have not risen to the occasion. Then a lot of times in the corporate world, it's just not worth the time, the money, and the effort to keep trying to pull somebody along that is falling further and further behind. 

In the open source world, that does not work at all. Anytime you try to apply pressure on people, they just go away. They're like, "No. You know what? This isn't my job. I'm not going to deal with this. I'm going to go do something else. I don't have to work on ESLint. In my spare time, it's something for fun. Don't try to make it more than that. Don't try to make it a job because I just won't do it." 

[00:39:00] JG: It is unfortunate. If only we had more funding and more sustained people who are committed to open source, but great. I have no more technical questions for you, Nicholas, but I do want to ask one last thing. Can you explain your relationship with the musical instrument known as the ukulele?

[00:39:16] NZ: Yes. I guess it's properly called the ukulele as I learned when talking with other people. Yes. It's 2020, and we're all in lockdown, and I'm in California. My closest family is in Arizona, so pretty much stuck by myself in my place feeling like I needed something to focus my mind and attention on. I also felt like at that point in time that music was very important to me. It's like the one thing. I could just turn on some music and feel a little bit better for a little while. So I started thinking maybe I could teach myself a musical instrument. But I had no idea what to do. 

In the past, I had tried piano and guitar, and both had the same problem is that I found it hard to convince myself to practice because they're both big instruments. You had to be in a specific position. I just would walk by every day and be like, "Uh, not right now. It's too much effort." One day, I was watching Carpool Karaoke, James Corden and Billie Eilish. They were in the car, and Billie Eilish just had a ukulele across her chest, and she was just playing it in the car. I was amazed. I was like, "Wow, that's beautiful music and very little space needed to create that and to use the instrument. Maybe I can try that." 

I went on Amazon, ordered ukulele starter kit, got that delivered, and just started going through YouTube videos. I made an agreement with myself that I was going to practice every day, even if it was just for 10 or 15 minutes. I knew that I would be terrible to start. I knew that this would be very difficult, and it would probably sound awful, and I would probably hate doing it for a while. But I also felt like it was important to do something that was difficult that I wasn't already good at, just to remind myself that I could do things if I just stuck with it. 

With musical instruments, the interesting thing is it really is just a matter of putting in the reps and letting your brain and your body learn how to move in that way in order to create the music that you want eventually. That's what I did. Just every day, 10 or 15 minutes, longer if I could stand it. But sometimes, the noise coming from it was so bad that I just couldn't. I kept doing it, just doing beginner exercises, simple cords, simple strums, single down strokes, and just kept at it, and kept at it, and kept at it. 

Then one day, music came out all of a sudden, and it wasn't a gradual transition. It was like one day it was terrible, and the next day it was not bad. It actually sounded like music. I kept going and learning more strumming patterns, learning more chords. I wouldn't say that I'm particularly great at the ukulele right now. But once you know four chords, you can play 80% of all pop songs. I'm there, and it still is a nice fun part of the day. Every time I look at it, just remind myself that, hey, sometimes, you just got to put in the work and be patient and trust that you're going to get there. That can carry over to a lot of different places in life. 

[00:43:12] JG: You found that your brain somehow wired the neurons correctly. Now, this is a core part of you. 

[00:43:17] NZ: Exactly. It is just a part of my brain now. That will be there, hopefully, for a long time. 

[00:43:25] JG: That's beautiful. Nicholas, I truly wish we could have had two more interviews. There's so much to dig in with ESLint. We didn't even touch on the core rewrite that has recently started in earnest. Leadership coaching is, of course, a huge topic. If people wanted to learn more about you, about all the stuff you're doing, is there anywhere on the Internet you'd recommend they look?

[00:43:44] NZ: Yes. You can stop by my website which is humanwhocodes.com. I have a page there specifically about coaching. You can also follow me on Twitter @slicknet. I'm on there most days, so reach out and say hi. 

[00:44:00] JG: Excellent. Well, that's all we have for now. This is Josh Goldberg with Software Engineering Daily and Nicholas Zakas. Cheers, everyone. 

[END]