The One Who Got Hired to Work on Open Source
23 abr 2020
Tech Editor @ WTTJ
Tim Neutkens is the co-author and lead maintainer of the React-based framework Next.js, as well as the co-author of the MDX library for dynamic markdown documents. We caught up with him at the December 2019 edition of dotJS and asked him to share with us how he found himself in the world of open source and how that led to him being offered a permanent role working on Next.js.
Learning through practice
I started building my own websites, basically starting out with WordPress and doing pretty simple websites for friends of the family, or friends who had businesses they wanted to promote. After high school, I had to do this internship because, in the Netherlands, you have to do a pre-bachelor thing to go on to do a bachelor’s in some cases. So I did this IT management degree, which included half a year of internships, and I ended up at this digital agency, and the people there were basically like, “We actually don’t know if you can program because you were doing this IT management stuff, but we’ll give you the chance to prove yourself.” I started there when I was about 17, and I just started programming stuff internally, building internal tools. And then, eventually, they offered me a job and I decided to take that instead of doing a bachelor’s in computer science.
Discovering open source
We were using all these open-source tools, like WordPress and Magento, and we were building a lot of custom plugins for WordPress and I ended up putting some of them online, on GitHub. That’s how I got introduced to this approach of, “Oh, you can put this stuff out in the open and people will find it useful in some cases.” Then, in my free time, I just got more involved in other projects that I found really interesting. I ended up working at ZEIT [now Vercel] to work on Next, but as a result of that I ended up co-authoring a bunch of libraries that ZEIT was building internally, or I advised on several projects. One of them was actually already out—it was called Hyper. I started doing good first-issue-type issues, which is what maintainers mark as, “These are the easy ones that you get started with in order to contribute more to the project.” They were things like changing documentation or updating three lines of code within the codebase. But they really helped with learning how this codebase works and also learn more about JavaScript because I wasn’t doing JavaScript at the time. Starting to contribute to open source meant that I basically… It might sound really weird, but I didn’t have to know everything that made up this framework, this tool, I just had to know where to fix bugs and then apply that and then get gradually into contributing more to the project and discovering how it works.
When it all comes together through open source
While I was at ZEIT, Guillermo [Rauch, the company’s CEO] had an idea, which was let’s make a markdown format that can actually hold dynamic elements—he had been thinking about that for two years or so. Then there was another person, John Otander, who over the weekend, had built the whole implementation for that library—we call the format MDX. And so I saw that post and I reached out to John, and I was like, “Hey, do you want to work together on this stuff?” Because there were a lot of optimizations that could be made, like massive improvements in how the actual architecture of the thing worked. So I reached out to him and I was like, “Hey, I can actually help on this because we need it for ZEIT.” And he was like, “Yeah, sure, let’s collaborate.” So it was a really good open-source story because we put the actual spec for it out in the open and then someone else—someone completely random, we had never met him before—just went in and was like, “Oh, I built this thing over the weekend because I found it interesting and I was super-intrigued by the idea.” Then we refined it over time—we did many weeks of development on it together and ended up with an implementation that performed well and can still be improved over time.
Getting hired to work on Next.js
I was about 20 at the time, and I had worked on Next.js—the thing I now work on full-time—for almost a year by then. And I was working on it pretty much full-time while also doing my job, so I was doing a crazy amount of hours on the project, just because I found it super interesting. It wasn’t as popular as it is today, but for me, it was just really a learning thing. So eventually they made me co-author of Next after I made a significant amount of contributions to the project, and then, eventually, I sent a message to Guillermo, like, “Hey, if you ever are looking for someone, then please reach out to me because I would be pretty interested because you’re working on all this open-source stuff that I’m helping out with.” A few months went by and then he reached out to me. He was like, “Hey, do you want to come to San Francisco, to attend a conference we’re organizing”—which was the first edition of ZEIT Day—“as a guest?” So they flew me out to San Francisco, introduced me to the whole team, and then Guillermo offered me the job. For various reasons, I ended up not taking it. I waited another six or seven months, and then I was like, “I really want to do this thing—to work on Next and actually make it work—I’m sure I want this.” So I joined ZEIT at the end of 2017, basically two years ago now, and I was the only person working on Next full-time at the time. And I basically ended up maintaining it by myself for over a year, until we started hiring more people onto the team, and then I became the lead maintainer. I am now in charge of deciding on the roadmap and making sure that everyone is working on the right stuff that we want to put out. And I’m talking to customers, or people who use Next, and I’m like, “Hey, is this going to work for you? Why is it going to work for you? Why is it not going to work for you?” And then I can relay that to the team and tell them, “Oh, actually, these companies are doing this in a completely different way from how we have been thinking about it just because we don’t know their insights.” So it really helps that I can go out there and talk to others to see what they’re doing or what they want to do and get that feedback back to my team.
Seeking help from experts
In terms of scaling the project itself, I knew a lot of JavaScript already, mostly from when I started contributing to Next itself, because I had worked on Hyper and other projects. But then I learned a lot about compilers, how they work, how Babel works under the hood, for example, or how Epic works under the hood. I contributed a bunch of stuff to both projects to improve memory usage, and basically, there’s just a lot of… I think the realization I came to when I started scaling up the open-source stuff that we do is that a lot of projects out there are being maintained but they could also use some help from people who have a lot of expertise. So the specific things that we learned from Google Chrome engineers are mostly related to how to reduce bundle size and optimize the way that JavaScript is output to browsers. So, say what we currently have in Next is maybe one JavaScript bundle for a page, the Google engineers started investigating how they could apply to a chunk of pages. So, basically, if one module is shared between two pages, how to make that a separate JavaScript file that’s only loaded when those pages are requested, instead of putting them into a common bundle where you’re shipping this massive chunk of JavaScript to all users.
Not letting yourself be distracted by negativity
One thing I would advise myself, going back, is to not give too much weight to people’s opinions, because it could be that it’s just one person being super-vocal on GitHub or Twitter, or I don’t know where—Reddit, or something like that—and they could be really unpleasant. They might mean well, actually, but they could be communicating in a really harmful way, but that’s still just one person, and there are thousands of people using your software and so there are some who don’t have any issues, or they’re not telling you about their issues, but mostly, people who have issues will actually go to GitHub and submit an issue. So it’s really about learning how to deal with all that.
The UI frameworks trend
I guess the thing I’m most excited about is the pace at which improvements are being made, without all the standards that people already use being affected. So, for example, UI frameworks like React, Vue, Angular, Ember, Svelte—those have really taken off and gotten really big. Almost everyone’s using them. They improve the whole experience and make it accessible for beginner programmers, but also for companies that want to build really large apps. Basically, we saw that a lot of people use React, Vue, Angular, Svelte, for example, or Ember, and that was further verified through MDN—Mozilla Developer Network, I think. They basically did a survey of 28,000 people, and 72% of them said they were using a UI framework like the ones I mentioned. I hope that Next will be around for a while—with the framework churn, the ways things go in JavaScript world, it might not—but I really like what I’m doing right now, so I hope that I can continue improving people’s lives by making better developer tools.
This article is part of Behind the Code, the media for developers, by developers. Discover more articles and videos by visiting Behind the Code!
Want to contribute? Get published!
Illustration by WTTJ
Photo: Welcome to the Jungle
Follow Welcome to the Jungle on Facebook, LinkedIn, and Instagram, and subscribe to our newsletter to get our latest articles every day!
Más inspiración: Coder stories
We can learn a lot by listening to the tales of those that have already paved a path and by meeting people who are willing to share their thoughts and knowledge about programming and technologies.
Keeping up with Swift's latest evolutions
Daniel Steinberg was our guest for an Ask Me Anything session (AMA) dedicated to the evolutions of the Swift language since Swift 5 was released.
10 may 2021
"We like to think of Opstrace as open-source distribution for observability"
Discover the main insights gained from an AMA session with Sébastien Pahl about Opstrace, an open-source distribution for observability.
16 abr 2021
The One Who Co-created Siri
Co-creator of the voice assistant Siri, Luc Julia discusses how the back end for Siri was built at Apple, and shares his vision of the future of AI.
07 dic 2020
The Breaking Up of the Global Internet
Only 50 years since its birth, the Internet is undergoing some radical changes.
26 nov 2020
On the Importance of Understanding Memory Handling
One concept that can leave developers really scratching their heads is memory, and how programming languages interact with it.
27 oct 2020
¿Estás buscando tu próxima oportunidad laboral?
Más de 200.000 candidatos han encontrado trabajo en Welcome to the Jungle
Explorar ofertas