Netlify Scheduled Functions with Simon Knott
Simon Knott discusses Quirrel's acquisition by Netlify, the launch of scheduled functions, Blitz.js toolkit pivot, and remote work life.
Episode Description
Simon Knott discusses Quirrel's acquisition by Netlify, the launch of scheduled functions, Blitz.js toolkit pivot, and remote work life.
Episode Summary
Simon Knott returns to the show to discuss the acquisition of his job queuing project Quirrel by Netlify, explaining how the deal came together through a Kleiner Perkins introduction. He recaps Quirrel's core purpose—solving the problem of scheduled and recurring jobs in serverless environments where traditional polling-based job queues can't work—and walks through how its code-first developer experience has now been translated into Netlify's new scheduled functions feature, currently in beta. The conversation explores the broader concept of in-source configuration, where infrastructure needs are inferred directly from application code rather than maintained in separate config files, a pattern Simon sees as having significant potential across the platform. The hosts and Simon swap stories about the painful workarounds developers previously relied on for scheduled builds, from Zapier hooks to GitHub Actions wired to cron expressions, all of which scheduled functions now replace natively. The discussion then shifts to the Blitz.js ecosystem, covering the decision to move from a Next.js fork to a framework-agnostic toolkit, the relationship between Blitz's zero-API data layer and tRPC, and how SuperJSON fits into that picture. Simon also reflects on balancing university coursework with full-time work at Netlify, the benefits and challenges of remote work across European and American time zones, and the internal enthusiasm that greeted cron jobs at Netlify.
Chapters
00:00:00 - Quirrel's Acquisition by Netlify
Simon Knott shares the story of how Quirrel was acquired by Netlify, beginning with an introduction made by Bucky Muir of Kleiner Perkins. After a call with Netlify leadership, it became clear that Quirrel was a natural fit for the platform. Simon expresses his continued excitement about the role and sets the stage for a deeper dive into what the acquisition means for the product.
For listeners unfamiliar with Quirrel, Simon recaps the core problem it solves: job queuing and scheduling in serverless environments. Traditional schedulers rely on constantly checking a table of jobs, which requires a persistent runtime. Since serverless apps aren't running around the clock, Quirrel offloads the scheduling to an external service that calls back into the application at the right time, preserving the serverless model while enabling features like nightly data cleanup or event reminders.
00:02:38 - Scheduled Functions and In-Source Configuration
Simon discusses what has changed in Quirrel since its early days and how its core cron job functionality has been brought into Netlify as scheduled functions. The feature preserves Quirrel's code-first developer experience, allowing users to define schedules directly in their function code using cron expressions rather than managing them through external configuration. The feature is currently available as a beta in Netlify Labs.
The conversation expands into the broader concept of in-source configuration, internally called in-source declarations at Netlify. Simon connects this to Sean's article on the self-provisioning runtime, where platforms infer infrastructure needs from the code itself. He gives the example of redirects currently living in Netlify.toml that could instead be co-located with the function source code, arguing that many types of configuration belong alongside the code they relate to rather than in large standalone config files.
00:07:07 - Internal Excitement and Real-World Use Cases
Simon describes the enthusiastic reception cron jobs received inside Netlify, where employees had long wanted this basic building block. He recounts how his job title in Slack became "Chief Cron Officer" after the all-hands announcement. Internally, teams quickly began using scheduled functions for things like triggered site rebuilds and lightweight integrations.
The hosts share their own experiences wrestling with scheduled builds before this feature existed, from wiring GitHub Actions to cron triggers to using Zapier webhooks. Simon highlights that while those workarounds technically worked, they created maintenance headaches and made project handoffs unnecessarily complex. Having scheduled functions live in the same codebase as the rest of the application dramatically simplifies collaboration and long-term ownership.
00:11:10 - Platform Flexibility and Developer Accessibility
The discussion turns to whether scheduled functions lock users into Netlify's ecosystem. Simon clarifies that nothing prevents developers from using Netlify functions purely as plumbing to trigger external APIs, which aligns with the Jamstack philosophy of decoupled services. The functions can serve as lightweight orchestrators that make requests to services hosted elsewhere on any schedule.
Chris raises the question of whether a UI-based dashboard for creating cron jobs might be on the horizon. Simon acknowledges that making the feature accessible to non-coders is something Netlify could explore, though the current implementation is code-only. He also notes that schedules can be specified in the Netlify config file as an alternative to in-code declarations, offering some flexibility in how developers set things up.
00:12:58 - Blitz.js Pivot and the Rise of tRPC
Anthony steers the conversation toward Blitz.js, which is transitioning from a Next.js fork into a framework-agnostic toolkit. Simon explains the history: Blitz started as a compile-to-Next framework, then became a fork, but keeping pace with Next.js's complex and ever-growing codebase proved unsustainable. The team identified three core strengths—the zero-API data layer, easy database integration, and the community—and decided to extract those into a standalone library.
Simon then introduces tRPC, which delivers a similar type-safe, zero-API experience in a framework-agnostic way. He notes that tRPC's creator was an early Blitz contributor who took the concept in an independent direction, even using Blitz's SuperJSON library for data serialization. The conversation touches on Brandon's new company Flight Control, described as a modern Heroku alternative, and the growing full-time maintainer team now working on the Blitz toolkit transition.
00:18:38 - Open Source Ownership and Remote Work
Chris asks where the line falls between what Netlify acquired and what remains Simon's personal open source work. Simon clarifies that Netlify owns the Quirrel brand and the projects within its GitHub organization, but everything remains open source and freely usable. His work on Blitz.js and SuperJSON is separate from the acquisition.
The conversation shifts to remote work, with Simon sharing how Netlify's roughly even split between European and American time zones creates a manageable meeting window in the European evening. He values the asynchronous, written-first communication culture, which allows anyone across the company to contribute ideas regardless of team boundaries—something he finds far more collaborative than a traditional office setting.
00:21:36 - Disconnecting, Time Zones, and University Life
Chris and Simon discuss the challenge of switching off when your office lives in Slack and never truly closes. Simon admits it was difficult initially but says he has gotten better at disconnecting, though small habits like checking email for a login code can pull him back into work mode. The hosts commiserate over daylight saving time mismatches and the eternal pain of working with dates and calendars in code.
The episode wraps with Simon sharing that he's still completing his bachelor's degree while working half-days at Netlify. He talks about using Netlify in a university project and watching a traditional German project partner struggle with FTP uploads after experiencing the ease of deploy previews and automatic optimization. He closes by praising Netlify's generous free tier for students and solo developers, and highlights Netlify Identity as a personal favorite feature for quickly building internal tools.
Transcript
00:00:00 - Christopher Burns
This one's an interesting one. It depends on how you can answer it, however you want.
00:00:13 - Anthony Campolo
Simon, welcome back to the show.
00:00:15 - Simon Knott
I'm honored to be here. Thank you.
00:00:17 - Anthony Campolo
We have exciting news. You've been acquired. I think both you and Quirrel, kind of the company you're now part of, Netlify, have an official scheduled jobs feature, so we'd love to hear what you've been up to since we last spoke and what's going on now that you're at Netlify.
00:00:33 - Simon Knott
Definitely. What do you want to know?
00:00:35 - Anthony Campolo
So my first question would be, did they approach you about the acquisition?
00:00:39 - Simon Knott
Yeah. So the introduction was made by Bucky Muir of Kleiner Perkins, and he's one of the investors in Netlify. He reached out to me a couple of months ago and was like, oh, this sounds like an interesting project. I have this company that I'd like to introduce you to. They're interested in a partnership. Then I took them up on that offer. I had a call with Mathias and Chris. We found that Quirrel fit perfectly into the product. I was very excited about working there, and I still am. And then I joined the company, and now I'm there.
00:01:06 - Anthony Campolo
That's great. And for listeners who did not listen to our original Quirrel episode, why don't you explain a little bit of what Quirrel is and what problem it's solving?
00:01:15 - Simon Knott
Definitely. So Quirrel is a job queuing solution. The typical problem is, imagine some full-stack application, for example, a full-stack Jamstack application. At some point, it will need a job queue, some kind of system that allows you to either run specific things on a scheduled basis or run them repeatedly. For example, if you want to clear out old data every night at 1 a.m. or something, that's what you use a scheduling system for. If you're developing an event-ticketing merchant, and you want to remind your customers that they have an event coming up, then you need a scheduler because you need to schedule the reminder. That is a problem that has historically been very much solved. We've had solutions for that for 20 years, but we didn't have a good solution for serverless deployments, because the typical way that job queues work, or that scheduled jobs work, is that you just write all of them in a big table, and then every couple of seconds you sort by the date when they should run and execute the ones that are due.
[00:02:15] But that only works if you can check that every couple of seconds. And in serverless deployment, where things are not running 24/7, that is not possible. And that's where Quirrel comes in. Quirrel basically takes all that scheduling and moves it to a different service, and then it will call your application to execute things at the right time. So your application still runs serverless, and you get all the nice benefits of not having to worry about deployments. That's what Quirrel does.
00:02:38 - Christopher Burns
One of the big things that we spoke about when we first had you on the episode was Quirrel was very much in its introductory phase. How has Quirrel improved since then to now? Further, what has currently been introduced into Netlify's platform, and what could potentially move over in the future?
00:02:59 - Simon Knott
So last time we spoke, that was the early phase of the rough trajectory of where it should go. Feature-wise, it was clear, but there were some features that weren't there yet. I'm not sure if, for example, cron jobs were there already. Since then, some small features have been introduced to Quirrel. I've polished it a lot. Documentation has improved, but feature-wise not a lot has changed. Because really, I want Quirrel to be small and precise for the job it solves. I don't need Quirrel to solve the gazillion other problems at Netlify. We introduced scheduled functions, which are mostly cron jobs. That is one of the features that Quirrel had: cron jobs. So what it allows you to do is write a normal Netlify function, and you can specify that that function should be executed once a day or once a week or every hour on some schedule. And you can express that in the cron expression format that maybe some of you have seen already. That is the first feature we built.
[00:03:53] It is very much inspired by Quirrel's developer experience. One of the really key things that I think make up Quirrel are the code-first principles. So if you want to define a cron job, you import it from Quirrel. That is what you did in your code, and you exported a cron job. That's it. We now have the same for scheduled functions on Netlify, which is really huge to me. That is possibly the one thing I'm most proud about: the way the developer interacts with Quirrel. And now the developer interacts with scheduled functions. We have ideas about other features we'd like to build. Part of those features are things that you already know from Quirrel. Part of those features are things that are only possible because it is now part of Netlify and it's now part of the platform, but we're unsure yet what exactly to build. Currently, scheduled functions are in beta. You can enable them in Netlify Labs and try them out, and we're currently just letting people try them out and gather feedback and see what other features are requested and what other features we should build.
00:04:53 - Christopher Burns
Have you seen the real functionality of Quirrel expanded since it's migrated over to Netlify? Have you seen more interesting use cases? Is more potential currently being explored? Is this just like the start of the idea, with Quirrel as the seed of it all?
00:05:12 - Simon Knott
I think what it really is a seed for is the idea of configuration in code. Maybe some of you have read the article last year by Sean Zugzwang. It was called the Self-provisioning Runtime, and in that article he describes this concept where developers just write their code and then the platform it runs on will infer what runtime is needed, what databases are needed, what message queues are needed, what kind of infrastructure is needed. That is, more generally, the idea of configuration via code inferred from code. And that is super interesting to me. What I can say is that this whole idea of declaring a scheduled function in code was built with that idea of reading config from code in the background. So internally, we call this in-source declarations or in-source config, ISC. That is only an internal name. I don't want anybody to refer to it that way externally. That's the name that will never be in docs. It's just for us internally. But I think that shows what potential is there. So one idea could be, at the moment you have this Netlify.toml file where you put in certain configuration that you want to have.
[00:06:18] And one idea could be, hey, maybe that's a thing that should be in your source code instead. For example, if you look at Netlify functions at the moment, what you can do is have a redirect in your Netlify.toml. So you could say, hey, I want a Netlify function called foo. I want that to be available under slash or something, via a redirect, for example. That could also live in your function code directly. That's just a rough idea I had at the moment. It's not something we're exploring. I'm not saying that's a good idea, but that's one of the possible things that we could build with this. Yeah, I think that's super interesting because config files are nice for certain things, but there's a lot of config that you want to be co-located with your code, that should live with your code, and that should not live in a super long, super big config file. And that's why I like this pattern.
00:07:07 - Christopher Burns
Have you seen that since Quirrel has been acquired by Netlify, that internal teams at Netlify have been like, we needed just that to do our feature, right?
00:07:18 - Simon Knott
Yes, absolutely. When I joined, the first call I was on was where I was introduced to the company. Every Monday, we have this call where everybody is on and new hires are introduced. There was a hype train of people shouting cron in the chat because people were so excited about finally having cron jobs. After that meeting, I jokingly changed my job title in Slack. I am now the CTO, Chief Cron Officer. Yeah, people were very excited about cron jobs. It sparked a lot of interest in things like, for example, doing scheduled builds. That's one thing that you currently can do via scheduled functions, where you write a scheduled function that then every day or something triggers Netlify to rebuild the site. That's one thing that we currently allow customers to do themselves with scheduled functions, but it might be that we want to ship something similar. And there has been a lot of interest internally, because cron jobs really are one of these basic building blocks that can be very helpful in making other features work.
00:08:12 - Anthony Campolo
Yeah, it's interesting you mentioned doing a scheduled build, because this is something that I was working on with a couple of friends, like an events calendar kind of website, and we needed the site to rebuild after an event happened so previous events would not be shown as upcoming. And I remember at the time, this was like the beginning of 2021, we were talking about it, and they're like, yeah, we want to figure out a way to do a scheduled build of the site. Like, how do you do that? And I'm like, yeah, how do you do that? Shouldn't that be a simple thing? Like, you can't just do that on Netlify. And then we went down this rabbit hole of figuring out how to get a GitHub Action attached to a cron job, and then that would run a Netlify build command. And we had to build this thing out. And now, as you say, that's just built into the platform.
[00:09:00] So I'm curious, are you seeing other things that people had their own bespoke workflows for that they're now migrating to scheduled functions?
00:09:09 - Simon Knott
What we've seen internally is people building a lot of internal tools using it. For example, a small thing that I've been building is we have this website called Hawaii Default. I think if you haven't read it on Twitter, now is the right time to join Netlify, because we'll be going to Hawaii in September. It's a huge internal thing. People are making all sorts of little gimmicks about it. And one of these gimmicks is Hawaii Diff. It's a website that shows you how many days it is until we go to Hawaii that uses on-demand builders, so it rebuilds every day. That is one thing. But you could, for example, build your event thing with only builders. What I've built is a small Slack integration that sends a message to our internal Slack channel every day about how many days it is until Hawaii, rather than hours; that would be a bit spammy. That's one thing we've built. And generally, there's a lot of these small plumbing-together things that people have started building with scheduled functions.
00:10:05 - Christopher Burns
This is a side note. You're going to be very shattered from the time zones.
00:10:09 - Simon Knott
I will be. I'm planning to take vacation somewhere in the middle before going to Hawaii. So that will make things a bit easier.
00:10:15 - Christopher Burns
Many locations in America, unless you go the other way.
00:10:18 - Simon Knott
Maybe, maybe.
00:10:20 - Christopher Burns
Cron jobs and these kinds of things, I've had it myself. Back in Gatsby 2 days, you're like, we just need to rebuild the website every night, just run it. And it's like, how do you do that easily? I think we set up a Zapier hook or something like that. Yes.
00:10:35 - Simon Knott
That is one of the very crude workarounds people do. Some people use a GitHub Action that runs on a cron schedule. Some people use a Zapier hook. There's a million other solutions. I think there's also cron dot net or something, or some online services that do it. There are ways to do it, definitely, but none of them are particularly easy to work with. It's easy to set it up, but think about some project you're building, maybe with an agency, and you want to hand that off to another team at some point. It would be so much easier to just give them the scheduled function that is part of your normal repository, part of your normal code base, than having to give them access to the one Zapier hook you've been writing.
00:11:10 - Christopher Burns
So with the migration over to Netlify, does this mean that these cron jobs, cron functions, become like a Netlify exclusive, that you have to host your full application on Netlify? Or could you call out different parts to outside of Netlify? Where does that kind of landscape currently sit?
00:11:28 - Simon Knott
Technically, there's nothing stopping you from just using functions on Netlify and then making the request somewhere else. There's nothing technically stopping you from doing that. That is, in some aspects, part of the Jamstack, right? Jamstack is JavaScript, APIs, and markup and a bit of other things. But this whole idea is that APIs can be hosted somewhere else. We see Netlify functions also as a plumbing tool, with the API running somewhere else and only the plumbing that does a request every day or something on Netlify. That's totally fine.
00:11:57 - Christopher Burns
I'm super excited to give them a go. It's one of those things where you know you need to do these things. Wouldn't it be great to send a report to your customers every week? And it's like, I'll just push it to tomorrow. That'll be a task for tomorrow. And it's like, in your head, you're like, well, creating the report, that's the easy thing. But working out how to do a seven-day timer on computers, that is too complicated for me. So really teaching people how to do it as easily as possible would be dead cool. Right now it's a lot of functions as code, logic as code, whatever it's called.
00:12:29 - Simon Knott
Logic is code. That's code.
00:12:31 - Christopher Burns
Yeah, yeah. Are there any plans to build a more user-friendly dashboard where they could just make cron jobs from a UI?
00:12:40 - Simon Knott
That is definitely something that we could explore. I know there's ideas about making the dashboards easier, making dashboards more accessible to people who don't code, but at the moment it is code only. But what you can do is you can specify your schedules in the Netlify config file. That is one thing you can do.
00:12:58 - Anthony Campolo
Currently, there have been movements in the Blitz ecosystem recently to change gears a little bit, to now being more of a toolkit. A back-end toolkit is kind of the idea. So I'd be curious to hear a little bit about that, both for our listeners who don't really know about that. And I'd be curious if you're involved at all with that, because it sounds like something that could actually work pretty well with the type of things that Quirrel does.
00:13:20 - Simon Knott
Blitz.js, for the people who haven't heard of it, is a framework for building full-stack React applications. It is based on Next.js. So, like in a couple of words, take Next.js and add a couple of features that are really helpful for building full-stack applications. In particular, easy database access, a very easy way to build APIs in a way where you don't really feel you're building APIs, and then a bunch of ecosystem things around it. That is Blitz.js. And it started as a compile-to-Next.js framework. So you wrote your application in Blitz.js. It felt very similar to Next.js with a couple of features sprinkled on. And then there was that Blitz compiler, which took the application and compiled it to a Next.js application, and then it could run everywhere where Next.js runs. That was like at the beginning. And then we quickly felt problems with that whole compile-to-Next approach, and that it made it harder to build certain features because you couldn't change things inside of Next. And then Brandon forked Next.js and made Blitz.js a fork of Next.js, still very similar to Next.js.
[00:14:24] And all the things that work in Next also work in Blitz, but technically it was a fork, and at the time that was the obvious thing to do. But we found that it was very hard to keep up with the changes in Next.js. Next.js internally, I don't know if you've looked at the code base. If you haven't needed to look at it, you can count yourself happy. It is a very hard code base to work with. I totally understand where it comes from. Like, one of the things that are really significant in Next.js is that it basically hasn't dropped support for any feature they've built. They haven't had any major deprecations or breaking changes, and that is really great. But also, the reason that their code base is hard to work with has slowed Blitz.js down a lot. At some point, we found that the main things that make Blitz.js Blitz.js are things that can work on top of Next. I think we identified more or less like three things. The one thing that makes Blitz is the zero API data layer.
[00:15:21] The API you don't have to build because it doesn't feel like building an API. The other thing is the very easy database integration. And then the third thing is the community. The idea is if we can build a library on top of Next.js, then we can really do the things that Blitz is best at, and potentially we can even offer those things to Remix users or to users of Vue or whatever. Personally, I think Vue is a bit more of a long shot, given that it's not based on React, but that could be a thing in the future. These efforts to build a Blitz toolkit, which will be a library on top of Next.js, and then Blitz.js, the framework, will go into sort of an archival or legacy mode. We will still maintain it. We will give it security fixes and all those things that you expect from your framework, but there won't be any new development on it. And we will have a very easy migration path to migrate to the toolkit. I think that will work fine.
[00:16:19] We've been very good at building codemods. Maybe you've heard of Blitz recipes, which is more or less a way to install libraries very easily. And we have a lot of experience with codemods in that Blitz recipes thing, and I'm pretty sure that we'll build a good migration path there. And then the Blitz team is growing. Now that Brandon has founded a company called Flight Control, that company will basically be a Heroku 2.0. So it makes it very easy to host your application on AWS without having to learn all the complex things in AWS. They also hired people specifically to work on Blitz.js. So now I think there are two full-time maintainers, Alexandra and somebody else.
00:17:01 - Anthony Campolo
Dylan just got added, I think.
00:17:03 - Simon Knott
Dylan, yeah, they're working on maintaining stuff. Yeah, I think it will be good. And Brandon is basically leading the whole Blitz.js 2 thing.
00:17:11 - Anthony Campolo
Yeah. I saw also that tRPC might be involved with the rewrite. I'd be curious if you know anything about that, and if you can kind of say what tRPC is. tRPC is kind of a mind-bender.
00:17:20 - Simon Knott
Yeah, definitely. So tRPC is, I don't know what the T stands for, but the RPC stands for remote procedure call. I guess the T is for TypeScript. What tRPC does is it basically delivers the same zero API data layer that Blitz.js has, but in a totally framework-agnostic way. It makes use of some very cool features in TypeScript that allow you to define your API as a couple of functions that always run on the backend, and then access it on the client, and you have the same function signatures. You know that that function takes in a couple of parameters and it will return whatever model it returns, and it's type-safe. Maybe the T stands for type-safe, I don't know. That's what tRPC does. And that's basically why I find it so interesting. It's basically a lot of the ideas behind Blitz.js's zero API data layer taken out from Blitz.js. And I think, I'm not super sure about this, but I think that Alex Johnson, who is the maintainer of tRPC, got the idea from Blitz.
[00:18:16] He was a maintainer of Blitz in the first couple of months, and I think he then took the idea and decided to build something outside of Blitz with it, which was great. And they even used some of our libraries. SuperJSON, that is the library that I'm working on, that is my part of Blitz.js. They use that to transfer JSON or non-JSON values over the network.
00:18:38 - Christopher Burns
SuperJSON is actually really cool. We spoke about it last time on the podcast. Where do you feel like the line is drawn in terms of what is transferred to Netlify as intellectual property and what is still your own? Is all of your Blitz.js stuff, SuperJSON, that's all still separate to Netlify?
00:18:58 - Simon Knott
Absolutely. Now, Netlify has bought the property. Netlify owns the copyright to the project, to some of the projects that are like part of the organization, like literally the projects that are in the GitHub organization and the brand name and all these things. But Quirrel is still open source and it will stay open source, so you're totally fine to use it. It's just that it has another owner in the license now.
00:19:20 - Christopher Burns
Really cool. How does it feel to work at a very remote-centric company as a European? I'm also European, and I'm spending a lot of my days speaking to a lot of people in America. You kind of feel like you're more sleeping on that schedule than your own at this point.
00:19:36 - Simon Knott
Yeah, personally, I have to say I love it. I love it for a lot of reasons that weren't super apparent to me in the beginning. Let's first talk about this whole time zone thing, right? At Netlify, at least when you look at engineering, there's pretty much a half split between European time zones and American time zones. That means there is a 2- to 3-hour window in the European evenings. So for me, that's 5 p.m. to 7 p.m., pretty much where all of the meetings happen. It's not a lot of meetings at Netlify, but when there are meetings, they are in that time frame. For me personally, that is fine because that is not the time where I'm super concentrated. I have my high-concentration hours typically more in the morning, and I can use those for heads-down coding, solving problems. And then in the afternoons I can talk to people to coordinate on what we're doing. So for me, it's very fine.
[00:20:27] It does mean that from time to time I work till seven or something, but not every day. And that is fine because the whole other remote-centric stuff is so great. I love that I can just go grocery shopping in the middle of the day. I love that I can just browse through Slack whenever I want. Frankly, that is one of the most impactful things that was not obvious to me in the beginning. If everything happens in written communication, in Slack messages, or in GitHub issues, then it means that you can contribute to everything. That is a very great thing at Netlify, especially in engineering. It is very common that people from entirely different teams chime in and have great ideas about things you're building and can help you out, whereas in a non-remote setting, you would have needed to be lucky that they're in the same room so they can hear your struggle, so they can hear the questions you're thinking about, only to realize that they have input to that. And with that whole remote-centric written communication thing, it's like you have over 200 people at your disposal, or something like that.
[00:21:31] They read the things you worry about every day, and that is very powerful, and I like that a lot.
00:21:36 - Christopher Burns
Do you find it easy to turn off? For example, your team, half your team may be in America, so you've just done your busy day. You've got tons of questions waiting to be answered, and it's your end of your workday. Do you find it hard to turn off? Because I know I do. As a co-founder of a company, it's always like the workday never ends.
00:21:56 - Simon Knott
Yeah. So I found it hard in the beginning because, yeah, really, work never ends. There's no point where all people are gone from the office, because the office is Slack and the office is open 24/7. But I've adapted. There are times when I know I'm pretty good at disconnecting. I've gotten better. Sometimes I have this thing where I open my phone and I look at my emails because I need to know that one login verification code that got sent in. And there's this one headline that I'm reading in this one mail that's making me think about, oh, that's what I need to work on tomorrow. I think I need to find a way to stop that. Maybe the solution is just to have a different email app for work email on your phone. But I have learned to cope with it. But nonetheless, this is harder to do than at an on-site company.
00:22:43 - Christopher Burns
Exactly, because this is one of the things where we're seeing it go both ways, like everyone back to the office and no, working around the world can really work. I think one of the biggest things that I see, and what I strive for from these kinds of companies, is that you don't discriminate on pay because that country is a cheaper country. You respect people's downtime when it's after their workday, trying to schedule things with time zones. Time zones are hard. Why can't everybody in the world just agree? Like, my workday is 1 a.m. till 9 a.m., everyone just agree on the 24-hour clock and everyone's just at a different time on the 24-hour clock.
00:23:22 - Simon Knott
Maybe we're on the right day recording this, because today is the day where the daylight saving time shift has happened, but not in America and Europe. So this is a weird week.
00:23:31 - Christopher Burns
Yeah, exactly. And how do you even keep up with it with calendars? Because the calendar doesn't know. This is a $1 million idea. Just solve time zones across company-wide fixed time.
00:23:41 - Simon Knott
Fixed time. Yeah, but on the other hand, the one thing that software developers learn is don't work with calendars, don't work with time. You will just be destroyed in the process.
00:23:50 - Christopher Burns
I've been building a date picker and it's the bane of my existence. Like I built it from scratch. I built like the month. Pick a year, pick a thing. Two calendars side by side and like, this works great. And then you're like, but what happens if they pick the dates in the wrong direction? Oh, yeah, everything breaks. Then you got to do like, use effects to watch it, to switch it around. And you're like, you're spending all day just writing like catch statements to be like, do this if they do that. And it's like, calendars, they are hard.
00:24:18 - Simon Knott
I've read enough articles about the miracles of time zones that I know I will never want to work with that.
00:24:24 - Anthony Campolo
I imagine you probably got your hands pretty full with what you're working on already, but is there anything else in the open source world that you're kind of hacking on these days?
00:24:32 - Simon Knott
Not really. I'm doing some Blitz.js work from time to time. I will be speaking at BJ's, at the Belgian JS conference, in May. And yeah, I have this university project that I'm working on where we're trying to fight COVID.
00:24:43 - Anthony Campolo
I was going to ask you about that. If you finished school yet, or if you just got hired while you're still in college.
00:24:49 - Simon Knott
Yeah, I was hired while I'm still in college. I'm in my fifth bachelor semester now, and I pretty much do half my day at Netlify and then the other half is university. There are definitely interesting challenges at university, but the Netlify ones are more fun to work on and, to be honest, a lot more interesting. But university is nice because you're around your friends.
00:25:09 - Christopher Burns
Well, I bet it's interesting explaining what Netlify is to them. I've noticed that even if you speak to another programmer talking about JavaScript on the internet, hardly anybody knows. We think Jamstack is like this massive thing, but it's still like a massive echo chamber. People in PHP land have no clue what Vercel and Netlify are doing over here.
00:25:27 - Simon Knott
So I think some people at my bachelor's project, for example, they know what Netlify is because we're using Netlify at that project. So we're building this dashboard and it obviously is deployed using Netlify. What's super interesting there is we have this project partner, and the project partner is, let's say, like a traditional German company. They're not exactly bleeding-edge on technology. And they wanted us to upload our dashboard files every day to an FTP server, which is fine. Like, you just embed it into your CI system and it's all right, but you lose all the nice things that Netlify gives you. You lose deploy previews, you lose the ability to comment on deploy previews. You lose the ability to just, I don't know, have good compression algorithms without doing config and all these things. They really feel like, now that they know how easy it is to use Netlify because they didn't really need to do anything for it, and how error-prone and hard to work with the other end of the scale is, they're a bit sad, to put it that way.
00:26:30 - Christopher Burns
I just hope that when you're doing those projects with your friends, you're just like, I'm just going to enable this really secret, like, do not use command. It's going to speed up the bundle ten times.
00:26:41 - Simon Knott
No, I haven't, because that is really impressive to me, actually, because most of the features that are helpful are free to use. I think Netlify does a really good job, especially for student projects or for those small personal projects, of not charging for the things that solo developers don't need and charging for things that companies that are actually making money need.
00:27:03 - Christopher Burns
I used to say my favorite feature was the forms plugin, but now it may be cron jobs.
00:27:08 - Simon Knott
Yeah, the forms plugin is really cool. One thing that I personally really like is Netlify Identity, the built-in authentication system, because it makes it really easy to build internal tools. Internal tools, that's the thing I enjoy most, like if something allows you to build internal tools quickly, because I see how helpful that can be for projects or for companies, and how hard it typically is to do.