Ben and Ryan are joined by RJ Tuit, Head of UI Platform and Client Architect at ClickUp, formerly an engineering director at Microsoft. They talk about ClickUp’s vision for a comprehensive productivity platform, the complexities of measuring productivity and UX in software development, how to navigate the hype around AI, and more. Plus: What it was like scaling Microsoft’s cloud services to meet the unprecedented demands of a global workforce in quarantine.
ClickUp is a work and chat platform designed to streamline workflows and make people more productive.
You can find RJ on LinkedIn or explore his posts on the ClickUp blog.
Shoutout to Stack Overflow user Hemant Singh, who helped the community understand pause vs stop in docker.
[intro music plays]
Ryan Donovan Hello, everyone. Welcome to the Stack Overflow Podcast. I'm Ryan Donovan, your host, and today I'm joined by Ben Popper. How are you doing, Ben?
Ben Popper Hello, Ryan. I am here, hosting the Stack Overflow Podcast in my new role as the Stack Overflow Podcast Host: nothing else.
RD That's right.
BP But I will be sticking around for a bunch of episodes every month. I've loved having this gig over the last six years, I've loved doing it with Ryan, and they can't get rid of me, I'm not going anywhere. So good luck with that, write in all the hate mail you want. We'll talk more at the end of the episode about other ways you can find me online and what I'm up to. But this is a place to talk all things software and technology on the show, and today we are lucky to have RJ Tuit from ClickUp. He is the Head of Front End UI and Client Architecture over there, formerly of Microsoft, so we're going to learn a little bit about what ClickUp does. There's a lot to do with sort of centralizing all the activity that happens across an enterprise into a single chat platform, and then now– this is 2025– layering on some agentic AI or some AI assistants to help make that even better. So without further ado, RJ, welcome to the program.
RJ Tuit Thanks for having me, Ryan. Thanks, Ben. It's a pleasure to be here.
RD So at the top of the show, we like to kind of get a sense of our guests’ origin story. How did you get into software and technology and how did you get to the role you're at today?
RT It was one of those weird ones where I think I started out when I was 13 on a VIC-20. It's actually here, I don't think you can see it but I can grab it from here. This was the actual Commodore VIC-20. I have a tape deck too with old cassette tapes.
RD I had a tape deck back in the day on my C64, so good crew of ancient mariners.
BP It has the aesthetics of a typewriter, not a computer. I like that.
RT Have you ever seen that it's brown? All these devices are brown. Do you know why they were brown?
RD Why?
RT Because everyone smoked, so if you made something white, it turned brown. So if you made it brown, it stayed brown.
BP That's right, you want it a nice tobacco juice brown.
RT Exactly. That's always so funny to listen to. So I got lucky enough that my parents in the Netherlands were wealthy enough to get me a VIC-20. They saw me play with a computer at some other friend’s place and they were like, “He seems to like that a lot.” So they got me that, then moved from that to breaking my dad's computer many, many, many times over. I learned my programming there, went from that to Pascal to Borland Delphi, I think, and then did all kinds of weird stuff in software, a little bit of 3D studio modeling, a little bit of Photoshop and Illustrator, a bit of video stuff, but all the while kind of stayed on this web-based development. I think it was called Fusion originally, that was kind of the big one for me– Fusion and PHP. I did a startup in my early teens– not early teens, early twenties. One was Sweetlakenation, which is a social network. The other was an online e-commerce website for vinyl, which was interesting. It was together with one of the biggest online EDM producers in the Netherlands back then. That was my first foray into e-commerce and large scale web. And then I did that for a while, failed at it miserably– let me say that upfront. We all should have our failure stories. I had no idea what I was doing, honestly. I failed at it miserably, kind of went into consulting, realized that I needed to learn so much more about the business world and just how you build things at scale before I could ever go back to doing something like it. I did consultancy for I think five or six years and started getting into– you guys probably know this as being podcast hosts– one of the best ways to get jobs was to go to conferences and speak. That was almost the absolute best way to do that. So I slowly started getting into that, made it into a bunch of conferences, made it to Mix 06 which was in Vegas, I think, and ended up at a table with a Microsoft employee. He was like, “Do you want to work at Microsoft?” And me, being an ignorant Dutch guy, I was like, “Oh, it's just an American being nice to me.” The gregarious people in the world think Americans are just like, “Oh, yeah, friend.” But an hour later I had an actual interview request that I got flown into I think a month or two later, which I bombed terribly, which they gave me another try which I kind of bombed, but did good enough that they let me in. And from that moment on, I worked at Microsoft, moved to North America about 17 years ago.
BP Did the interview questions you bombed have any relation to the work that you actually did once you got in there?
RT No, of course not.
BP No. Just checking.
RT I ran interviews for 15 years at Microsoft, and up until the last moment I was there, it was still running these interview questions that I know I would be excluding a whole bunch of people that would be doing perfectly fine, but we don't have anything better. It's bad, but unless people want to come work for us for two weeks before they take the job, I still don't really know what the solution to that problem is.
BP It's an interesting question. Maybe apprenticeships or something like that are part of the answer. And so now you are at ClickUp– set the stage a little bit there. How did you make the transition from Microsoft to ClickUp? And for folks who are listening and don't know, how would you describe it succinctly?
RT So starting at Microsoft, I kind of made my way through, worked on MSN, worked on Bing. In my time at MSN, we got to rewrite MSN. It was kind of my first foray into large scale. It was like half a billion users a day across the world and you're trying to rewrite something for that, first time Azure, first time cloud, were kind of the first ones trying to go in that area. Built that, redid that, and then the team in control of MSN, they were the leader there, and I'll bring him up probably a lot because he's been very influential in my career. His name is Brian MacDonald, and Brian MacDonald was, just to give a history, he built Project, sold it to Microsoft, built Outlook, retired, came back to do Azure, and then did MSN. And then he was like, “I want to build something new like Outlook. I want to go build Microsoft Teams.” So he went from MSN to start, it was originally TeamSpace– I have some logos here. We even have a version where it was called Microsoft Office Chat Teams or something, something terrible Microsoft, those massive names.
BP Microsoft Office Chat, there's Yammer in there, Teams.
RT There was a version of that that was Yammer, absolutely. Skype too, by the way. We had all of those. Brian started that, brought us along, and that was mostly back then Slack compete. There were three or four groups within Microsoft that were building a chat Slack compete. It was seen as a danger to the company, a danger to the Office bundling strategy. If you get someone else in there, someone else can start bundling. So doing that for about one to two years, and that's where the crazy scale kind of came in. That's from when we were 10 people serving no one to a million and then 10 million and then 50 million, and then in the end when I left two years ago it was 250 million users, and the organization was 2-3,000 people. So that crazy scale-up was probably the most interesting that I'll ever see in my life. With COVID thrown in, that was crazy times– COVID during being at Teams. We were just about at that plateau where we were going to start doing quality and be done with development and then COVID hit and they were like, “Whatever, just do whatever, turn off features, make it work. Countries are coming online tomorrow, whole countries. Go figure out how to make it scale,” and we're like, “But we're running out of data center space.” “That's fine. Disable stuff, whatever you need to do.”
BP Wow. That's an interesting hyperscaler story, I like that. They weren't also like, “And we're building more data centers,” because isn't that always the case?
RT Well, they were, but they take like a year to build. So we had no room. They had planned for them, they had planned them two to three to four years ahead because there's all these things that need to happen. They went way faster back then, but it wasn't the next week type of solution. We literally were running out of space all across Microsoft. It was crazy.
BP So you just shift onto somebody else's cloud?
RT They were running out of space too.
BP You couldn't multi-cloud it. One thing Ryan and I have talked about so many times and it's interesting to hear you say this, is how do you pay down technical debt, how do you keep yourself from getting the sort of software bloat and sprawl? Forced deprecation due to data center concerns because of growth is a really interesting moment to be like, “Well, what are people using the least? We’ve got 50 features in here, cut the bottom five, just because.”
RT Exactly.
BP That normally would be such a difficult decision to make, somebody who made that feature would stand up and defend it. But did you feel like in the end, maybe it was actually good for the product?
RT I think it was good for the product. Honestly, it's the only time in my career in enterprise software that I've seen more than a single feature being killed, both at Microsoft and at ClickUp. I don't think I've ever seen anyone go, “Oh no, that's too low usage. Let's just get rid of it.” It doesn't seem to be a thing. This is the only time in my career where we made a list and leadership was like, “Check, go do it,” and we're like, “Okay, delete code.” You know how much software engineers love deleting code. It's such a fun thing to do.
RD And now at ClickUp, you're also dealing with a lot of scale, is that right? Dealing with millions of users?
RT It is millions of users, and in the same way, we kind of need to go back. When you're talking about scaling, when do you pay down debt, when do you not pay down debt, to me, that's actually the most interesting thing we do in our industry. Because perfect architectures are easy. I can define your perfect architecture tomorrow, but we're never going to build that because we don't have an unlimited amount of people, unlimited time, and generally when you're in a competitive landscape, you have even less time because someone else is going to move faster than you, depending on where you are. It's probably the biggest lesson I learned at Microsoft and am now applying at ClickUp, where you walk that fine line between, “I do enough to not make it fall over, but I don't do too much to slow down the business too much.” And there's going to be a moment where that flips where you go, “Now we need to stabilize and we need to have no longer quality issues,” but in SaaS specifically, and in a space where Teams was and now ClickUp is, we're kind of in the same space. It's even bigger, more competitors, but you don't really have that luxury to go, “Oh no, we're going to go pay down debt for six months.” If you do that, you've lost a whole swath of new customers and you're not going to be able to get the business to the place it needs to be. And probably, I'd say the hardest thing that we do as software engineers and software engineering leaders is doing that, letting things fall by the wayside, letting it happen and going, “Yep, I know.” And engineers go, “But, we're doing this bad thing,” and I'm like, “Yep, I know. We're watching it. We're watching it every day.”
RD Doing strategically bad things to make sure the business succeeds. It’s interesting.
BP Maybe we can segue here into a little bit of what the business does. I was doing some research and this is certainly an experience I've been familiar with at many companies I've been at– the overload of different services and notifications that you get from different departments or even within your own department that force you to be constantly context switching. I'm in Slack and get a notification about a Google Doc, but I have to update the Monday sheet which will go to the Airtable, which pings the JIRA ticket. And it's just like, “Man, there's got to be a better way.” So what is sort of ClickUp's philosophy and how does this play out in maybe the MVP version of the product, if you could describe it?
RT You just named all of our competitors, which is kind of crazy to think about, every single one of those–
BP Sorry, that was not intentional.
RT No, but it's good because you're actually describing it. To me, when I try and explain ClickUp to someone, it's sometimes hard to explain how large of a space we're in because we're in all those spaces. We are chat, we are task management, we are docs, we are meeting, we are calendar. We are all of those things combined. I'm going to go back a little bit because the story here to me is fun. In Teams, the reason it was started is because Brian MacDonald came up with this idea of MetaOS. He had seen the Windows thing, and then he'd seen the iOS praise, and it's this thing where if you have this operating system– it doesn't need to be a physical one, it can be a virtual one that has everything in it– that's where you have market attach– not just a great user experience, but where you truly get market and people attach. And Teams originally was set up to be this– this app of everything. We started out with chat and then we added in meetings and then we added in SharePoint for files and then we were trying to do calendar and other things and that ran into both organizational and other issues because everyone has their own. I don't know if you've talked to any Google or Microsoft or other big company people, but you run into these. The VP of X and the VP of X both own a problem and integrating is not in their favor. And then COVID happened too, and then COVID made everything meeting and chat and we kind of lost that vision of this one productivity hub, the one place where you do 90% of your work– not 100%, because you want depth places, because trying to do everything 100% is going to not have you succeed. You want maybe even 80%, 80% of your work and all the tools in one. So the reason I left Microsoft was that it became too big and too large and it was bureaucracy, but the reason I joined ClickUp is because once I started talking to Zeb, I realized that his vision was that. Even though they started out as a Jira compete probably, just as Teams started out as a Slack compete, division was always, there is this one app that is going to do all of them. And back then when ClickUp started doing that which was almost six years ago, it was a radical idea. None of the VCs liked it. You know how SaaS has been for the longest time. You need to go deep, singular problem solving, and that's the thing that the VCs want to fund because they understand that, and doing too much things allows you not to focus. But the ClickUp focus has always been trying to solve the holistic product problem of what is your day to day workflow and not end up in these places where a Microsoft and a Google and even a Salesforce end up, which is honestly iframing stuff. That's how they scale. They have hundreds of engineers here and hundreds of engineers there, and the way they scale with each other isn't by having them all work in one code base, it's by basically giving each other iframes, which works mechanically, but it never gives you this cohesive experience where you can go, “No, I want a chat in which I want to insert a doc and a card, and then I want to be able to close that ticket right there that triggers a calendar event,” and that all visually just kind of works. That has always been that vision of ClickUp, and for me when I try and describe ClickUp, I take a lot of words to do it because I don't think a product exists today that is what the ClickUp vision is. And we're getting very close. We've added chat, which is rolling out. We've added calendar, we've added sync ups, and we only have a couple of more small things to do and then the broader surface area of ClickUp is there. And you can kind of see that when that happens– I had the same thing happen in Teams– at some point you realize that you're spending 90% of your workday, me as a person building Teams or building ClickUp, you're starting to spend 90% of your day in the product and it just happens at some point. It's very hard to explain. I recognize it now because it's happened twice, but there's this moment where you go, “Oh. I spent 80 to 90% of my time in the product while developing the product.” And that's that super strong product feeling and just kind of getting to that place where you go, “Oh, this is going to work.” When this happened in Teams, I realized we had something, and the same thing has been happening in ClickUp where we've been a great product so far, but that part is what makes it amazing.
RD The messaging, the chat apps, are such a key part of it and you start attaching things to that chat app. I remember at my last job trying to do internal documentation, I was like, “Where do you go for answers?” and it was Slack for 2/3 of the people because that's where everything happens.
BP One thing I'm curious about as you're bringing all this stuff together, you mentioned spending 80% of time and then sort of feeling like you've gotten into a flow. I enjoy editing video and audio sometimes because I end up just doing two-three hours inside of one thing. I'm not constantly pinging back and forth and checking email and shooting off a Slack and then writing a paragraph in a Google document and then running that loop over and over again. Do you have ways that you try to measure flow state and attention and productivity and then feed that back to your customers so they can understand the impact the tool has?
RT We do, and it's a very contentious subject as you guys probably know, because there's also a lot of people that think it's being used as work tracking, which is why we've had a lot of discussions internally on how to actually do it. Because it's difficult. Is the boss going to start using it as a way to see if I'm doing enough work, or is the person going to use it to make me more productive? Those are two very different views on that same problem. They solve the same problem, they use the same data, but it's really important that we fall into one category and not the other. Because if you get too many users hating your product, it doesn't matter what the bosses and the companies want, you're probably going to not get there either. So you have to walk that fine line, which we spend a lot of time internally discussing– what is that right measure that we can do? We have another piece of the product that isn't out yet, which is Teams, which actually tracks teams’ usage of the product, and we even import external data. So we have GitHub data because we have search across. So one of our products is that you can actually import data from other companies and then search through them. We have a large search index and we also use that data to aggregate statistics from that as well. So if you're thinking software engineers can get, at some point, very close to what VX can do, which is give you a number of PRs, but also how much did you chat about those PRs? What is the documentation you've written about them? Which tasks were associated with the PR, which for us is already linked. The way that my workflow is is like, “I am in ClickUp. I create a task, which gives me a button to create an actual GitHub PR and that PR then automatically gets linked,” and anything I do in both gets updated on both of them. And then when it closes, the same thing happens. That ticket closes it properly, gets the status set through all the rings. So you can see how we have all that information in ClickUp. We've been playing with it internally a lot to see what the valid data points are. I don't feel like we fully hit it yet, but we're close. It's very difficult to define productivity as a single number across everyone.
RD And like you said, it's hard to keep that as a measurement and not as a target. I want to go back. There's something in your initial pitch about the scale of things you're working on where you start finding bugs in other people's software. There were two that I mentioned. You found one working on Teams and found a bug in Chromium that was there for a while.
RT Chromium was here, the other way around, but yeah.
RD Okay. And then you found one in Akamai that was 20 years in hiding. Can you tell us about those bugs?
RT So like you said, when you start doing things at scale where both your code base starts getting really large in a space that was never really intended to have that much code, combine that with hundreds of millions of users, as you get into these weird problems that no one's just ever run into the scale yet, or it's been there but no one's been large enough to observe it. The Akamai one was kind of one of the latter, where we were probably the first large enterprise app that was completely web-based, and then we were Electron-based. And so we were experimenting a lot with what that looks like, because the world we used to come from being at MSN was single bundles, don't download too much, try and make it very efficient to start up. When you go to web apps, that trade-off becomes very different and we were kind of exploring what that looked like. And one of our explorations was that we can make everything faster if we just– I don't know when HTTP 2.0 came out, but when HTTP 2.0 came out, it no longer mattered how many connections you made. They were all going to go over the same connection, and therefore we could now, instead of giving you one large bundle and dealing with that, we could just give you the bundles as tiny as they are. So we started scaling that down. What that meant is that every user started downloading hundreds and sometimes thousands and sometimes 10,000s of files every time they connected to Teams, and we shipped every week so this started happening at a really high cadence. And we started to see in these bundle downloads, random failures across the board. It was probably like 0.1%, but it was enough at our scale that users were complaining. And very often it was solved by a refresh. It was really hard. So we spent all this time trying to dig in, trying to add logging, trying to add other things in. I don't even know. We spent months, I think, tracking this one down because we thought it was something in our code. We were like, “What did we do? What is happening?” We replaced Webpack with some custom downloader, we added in all kinds of plugins to see if we could detect it. We even added custom C++ in Electron to see if we could maybe find it there. In the end, what it ended up coming down to, and I don't remember– I was thinking before this podcast who was the one that found it? I think it was Sofian, but I'm not 100% sure. They ended up going just digging. You know how some engineers just can actually dig into full stack and you have these amazing people that can go top to bottom? He ended up looking at a networking library and just running at scale of those networking libraries and seeing what happened, and we came to a place where I think one of the Linux network stack libraries has a bug in there that occurs one in a million times or something. I tried to look up what the exact bug was, but it was something that existed for 20 years, something that we've all experienced, but it generally is one request out of a million, not specific to one user so it's a different user every time, so each of us here sees it every six months and when you do, you probably go, “Hey, whatever, it's my Wi-Fi,” and hit refresh. But we were at that scale where it was happening often enough where we basically found a problem in an Akamai library that then got fixed within– this is the funny part. Most performance in software, as you guys probably know, the hard part isn't fixing it. Fixing is easy. It's finding it, and that's one of the absolute hardest things to do, and that requires real talent. That finding of things, people who can do that well, they are special. I treat them as very special.
BP So RJ, one of the things I wanted to ask is that I think anybody who's worked at a company that avails itself of enterprise software products pretty quickly becomes familiar with the sprawl and the notification overload that you talked about. And the appeal of ClickUp is kind of obvious, it's all in the execution. But one of the things that I saw when I visited the website was that a lot of emphasis, at least in the marketing on the homepage, was on bringing AI into the mix and how that would add value. So I think our users are a little bit sick of hearing AI, but I also think that Ryan and I increasingly are seeing it productized and even used inside of Stack Overflow in a way that's not baloney, where it's like, “Oh, that actually helped us do something we couldn't do before. It made it faster, cheaper, whatever.” So talk to me a little bit about how ClickUp is using AI and where you think there’s substance instead of hype.
RT I like that. I think problem one is that we call it AI. I think for most software engineers, that's where it grinds us the most where we go, “But that's not the AI I was reading about in sci-fi books. It has nothing to do with it.” This is an LLM that knows how to regurgitate content very well and it does it in a way that is really useful. I use it every day. But all those AI things you're saying it does, it doesn't really do. I don't know if that's what you guys are feeling a little bit, but that's what I feel talking to other software engineers. That's kind of what we get tired of.
BP I think I know what you mean, sort of anthropomorphizing it and we're on the road to the singularity and AI agents are going to take over.
RD It's just the hype of it, right?
RT Yeah. And it's hard for engineers, we don't generally like hype, especially if we understand what's going on. If you understand how an LLM works, it's not magic. We don't necessarily fully understand what it creates, but what it does and what it's good at and what it's not good at is relatively well-documented. Unless we have another massive revolution which we had with the original LLM, this is about where things are going to stay and they're going to incrementally get better. To me, bringing that to ClickUp, the thing that I think makes ClickUp specifically good at what today we call ‘AI’ is that we have a lot of data, we have a lot of user content, and that's the problem that most companies are dealing with that are trying to do something AI. If you're just piping ChatGPT with their content into your product, then that's part of that hype cycle that I go, “Interesting.” But if you look at ClickUp, you look at how much data we have of you, we have all the stuff that you just talked about about usage and how people work, all of your content, all of your information is in there. We even take in a whole bunch of other data from other places. So if you put an LLM on top of that, it can have the same fidelity that ChatGPT has, but on your content. And that's where, in my mind, AI is useful. I use AI everyday. I use it in Cursor and VS Code and Copilot and some of the others because it's useful as a code regurgitator that is better than me, but in ClickUp I use it every day to create tasks. I no longer create my own tasks. What happens is, we have a chat, we talk about things for five minutes, and then we go, “Okay, this is the work we need to go do.” I hit right mouse click, I say, “AI, create task.” And honestly, 95% of the time, based on what it knows, it knows how to create it, who to assign it to, which space to put it in, which status to assign. And that to me is useful AI, it's just saved me 10 minutes of work.
BP Sort of like an admin for the meeting that's giving action items to the correct people. Great.
RD Yeah. You still have to review it though.
BP Yeah, you can review them quickly. If they're not right, tweak it.
RT I personally love AI, but it's the hype around it that is difficult to deal with sometimes.
RD Why do you think people focus on the hype as opposed to the technical details of it?
RT Because it gets you funding.
RD People love the hype. They don't want to be bored by the implementation details.
RT Well, you kind of have to. To be able to do the work, which there's a lot of work that needs to be done, you need to get paid, you need to sell these amazing things and therefore you need massive hype and the massive hype will get you VC dollars, and the VC dollars allows you to iterate and see if you can find a solution. This is the core of Silicon Valley into a three-sentence Cosmos.
BP And even beyond that, now you go to sell to an enterprise and they're like, “Well, we have budget, but it's mostly budget for Gen AI tools. Do you have that in your product?” and you're like, “Yes, we do. It does everything we said before, but now it fits into your Gen AI budget, so there you go.”
RT Exactly. Gen AI and federated search, those are the key terms.
RD Federated search, I’ll be on the lookout for that one.
BP RJ, is there something that your team has done over the last year or that you're looking forward to building on this year that you'd like to share with our audience? Just something you think for developers who are listening, team managers, CIO, CTOs, one thing where you were like, “Man, that was a really cool product we put together,” or, “I'm really excited because this year we're going to try to roll out X.”
RT The funny thing, the first thing that comes to mind is something we already did, but that was a short one. It's the one you asked about that we didn't get to, which is being able to find the Chrome memory leak and being able to help hotfix that. That was, from an engineering perspective, interesting. But from a this-year perspective, I think what we're going to be spending a lot of our time on is performance tooling. Performance is always this interesting, super important, but kind of side aspect of software engineering that the tooling is very rudimentary. Yes, you have memlab to run your memory leak tests, but it's kind of limited. You don't have that for a lot of other things. You don't have that for your style recalculations, you don't have that for your other things that you would get out of a Chrome performance profile. And with the complexity that we have as ClickUp, that's where all of our performance issues are. This is always the discussion I have. People go, “Oh, memory leaks. Just go unsubscribe to all your observables.” I'm like, “Those memory leaks are fixed. We fixed those a long time ago.” That's not what we're stuck with. That is a component in a component owned by a different team with a component and another component that backreferences something that backreferences a component that if someone changes something somewhere in that chain, this whole three plus window gets leaked and we're screwed.
RD Just port to Rust, just port to Rust.
RT Rust will solve it, or whatever other framework. We're in Angular and React, so probably Vue is going to solve it.
RD Yeah, Vue, Svelte, Elixir, any of them.
RT So that's the one I'm probably most excited about. I think we have the right people. I've hired a couple of fantastic folks over the last year that are really the best in their fields in this industry, and we're going to be able to actually write some tooling that I've been wanting to write for about a decade that is going to allow us to catch some of these performance issues early on and directly point to, “Here was the problem. Here, engineer, go fix it.” Or who knows, “AI, go fix it.” I'm joking kind of, but that is the part I'm probably most excited about.
RD It's interesting that companies don't always care about performance until suddenly it matters. You get to a sort of scale where suddenly it's, “Oh, this is a problem.” I saw a video that was like, “Here's all these big companies talking about rewriting their entire application stack for 10-15% performance gain,” and at that point it matters, right?
RT It does. It's what I did at the end of Teams. We rewrote it from AngularJS to React to get that 15% performance gain. Exactly what you said. But we already owned the market, the competitors were already no longer there, and then you can take your time to spend two years rewriting. You don't always have that luxury.
BP RJ, Ryan, we're going to put a timestamp on this– Tuesday, January 21st, 2025. RJ, we'll have you back in a year. If you have a mid-level engineer who’s AI, we’ll obviously have to discuss it. I know you were kidding, but also we're not kidding. We'll see. We'll see how this year goes.
RT Have you seen the LinkedIn ad of someone trying to hire an AI agent? If you haven't, look it up, it's hilarious. It's terrible and hilarious and kind of scary.
BP Another piece of the hype that everybody hates is that every time I go to YouTube, it's like, “Seven ways to make $10,000 in three weeks with AI agents,” and then they just build some toy app that breaks and it's like, “No, everybody can do that.” This is not going anywhere for the long term inside of a company.
RD Exactly. But my favorite ads are the ones that combine the blockchain to it where it's double hype.
RT And then you're forgetting maybe some AR/VR. Add them all together.
RD Now you're about to get funded. You better stop talking.
BP Once we get to the crypto bots, the actual robots, we're in trouble.
[music plays]
RD All right, everybody. This is the end of the show. Thank you for listening. As always, we'd like to shout out a user on Stack Overflow who came on, dropped a little knowledge, and earned a badge. Today we'd like to shout out Joshua Fox for earning a Lifeboat Badge. They came in and they got an answer score of 20 or more to a question that had a -3. They saved this question with their Lifeboat. And the question is: “Get the current hour and minutes from Instant.now()” If you're curious about how to get the current hour, go check out this question. It's already helped almost 20,000 people.
BP Very cool. As always, I am Ben Popper. I am a host of the podcast here at Stack Overflow. This will be the first episode that we are changing things up a little. I am over at a new startup– Builder.io. You can check me out on Twitter, you can learn about that, but I'll still be doing lots of things with the Stack Overflow team and content which I'm very excited about this year.
RD I'm Ryan Donovan. I am still Editor of the blog here at Stack Overflow, cohost of the podcast. You can find the blog at stackoverflow.blog, and if you want to reach out to me with episode ideas, criticisms, comments, further questions to ask, you can find me on LinkedIn.
RT My name is RJ Tuit, or as my mom called me, Robertjan. There are still some people who know my actual original name. I work at ClickUp. I am the Head of Front End and Client Architecture. If you want to find me, you can probably find me on LinkedIn. There aren't a lot of RJ Tuit’s. I think there's literally one, so it should be easy. Come check out ClickUp. It's an amazing product that is not as well known among software engineers as it should be, but it will be in the next year. I think we're going to have a breakout year this year. Try it out, it's there to make you more productive. ClickUp.com.
RD Well, thank you for joining us, RJ, and thank you for listening. We'll talk to you next time.
[outro music plays]