🎞️ Videos → Beyond Compile Times: Leveling Up Your Developer Experience

Introduction and The Problem of Context Switching0:00

Okay. Hello.

Good afternoon everyone. My name is Nattaaek. You can call me in Thai Egg. But for foreigner I would say you can call me Egg, like a chicken egg. So it easier for you to pronounce my nickname. So today, the title is a little bit clickbait to you guys, but it was from GPT.

I would like to sharing about how Agoda approaching

to help developer experience, developing their application easier, less context switching.

Mainly I will talking about the context switching. Does anyone know about context switching before? Okay, one, a few people.

Examples of Context Switching and Their Impact0:48

So without further ado, let's get start. I think my session will not taking that long. Who have you ever facing this before? Oh, why I cannot run it.

So basically like you have project, right? Now you would like to run your client-side. You start to type and then you wait.

Tiktok tiktok, very long time, right? So what do you do while you are waiting?

Some people would say they go to pantry and grab some coffee, matcha, or even like a snack or drink, right? So you just go back and forth. Someone just turn around and talk to their colleagues about the life, daily life, or even like just talking about the work, for more like efficiency development, or checking an email about like does our boss sending some email or something like that. Last one was like you checking the Slack, maybe helping other developer, or someone just keep chasing you about how can we build this, how can we do that, something like that, which is they supposed to go to on-call person or someone else which should not be you, and you just kind enough to answer them. And even worse, you have IG, right?

Now nowadays we have like IG, TikTok that have sound too.

So basically like this kind of application actually built really good to keep tracking you to their application, right? You just like keep scrolling scrollingๆ. I think it called like a doomscrolling nowadays. So it really consuming your time. Basically, if it was me, I took like at least 20 or 10 minutes in order to escape from this application, which is like very unproductive in my opinion.

The Cost of Context Switching: Productivity, Errors, and Job Satisfaction2:59

Actually from the research, there are a lot of people that trying to research how long does it take in order to like get back to do the deep work, deep focusing work. It's around like 20 minutes in order for you to get back to like a deep focusing mode, which is quite long, right? Like you scrolling something, by like you just try to 𝚙𝚗𝚙𝚖 𝚍𝚎𝚟 𝚙𝚗𝚙𝚖 𝚋𝚞𝚒𝚕𝚍 and then you just keep scrolling 10 minutes and then you need to wait like a 25 in order to get focusing on back to work again, which is really like crucial and unproductive in my opinion.

So that this one we call like a context switching, like you do something, you wait, and then you do something else. Yeah. Let me interview you about like a type of the context switching. This is just my own opinion. First one was like the technical context switching that can causing the context switching. One is like the build time. You can see this, our real application, it took like a 3 minutes in order to just 𝚢𝚊𝚛𝚗 𝚜𝚝𝚊𝚛𝚝 or 𝚙𝚗𝚙𝚖 𝚜𝚝𝚊𝚛𝚝. Really long, right? And what is the real application, a little bit legacy, but yeah, it is how it is. And the next one is like when you trying to do the test, 𝚢𝚊𝚛𝚗 𝚝𝚎𝚜𝚝, something like that, or do the unit test. Right now, our application took like a 5 minutes, run just one single test case. Really painful.

Another one was like non-technical. I'm not sure everyone got this kind of meeting same as me or not. This is my calendar. So I cannot even barely find the time to coding, even I'm not manager, I'm just normal engineering.

Another one was like non-technical as well, but work from home edition. If you guys have like your companion at your home, this is my two lovely cat that they keep come chasing me every time when I trying to working, try to get my attraction. So basically like I need to play with them in order to let them go away, right? Or like if you live with your family or your wife or your partner, basically like you might get asking, "Go wash dishes. Go wash your cloth." something like that. So you need to go there or hanging your cloth. So there is a lot of context switching that happening everywhere.

Technical Context Switching at Agoda and Data Collection5:26

But today, we will talking only for the technical one because non-technical one, I don't think I cannot fix it.

Cool. What and before we going to like how we fix, what is exactly causing by the context switching? From the engineer perspective, actually it was reducing the productivity, right? Like you switching, do something, when you go back, it's kind of like very hard for you to keep focus. Maybe you also forgot what you did. Something like that. Increase error rate, like since we are engineer, we working on fixing something or developing something. If you context switching, it also increasing the error as well. For the creativity,

I think we working with like very smart business people. They come with very weird idea that will help driving the business going further, making more money. So we also need to follow them too

with our creativity implementation as well.

But like if we are context switching in order to catch up with the original idea that you thought about to implement, it might be hard. And also job satisfaction, basically like on every company, they are the scorecard that we might need to follow and fulfill the KPI or OKR, individual or the team.

So basically, if you have less productivity, you might not be able to reach to the goal that you expected to be.

Next one is from like a company perspective. This one I grab from Glassdoor. Just average with my supreme mathematics skill. Basically, like normal salary in Thailand, average from Glassdoor, I'm not sure it's true or not. But yeah, it's around this one. So I divide with my math skill, it's going to be like 262.5 Thai baht per hour.

Let's assume that like you got distract two times. And that means you need to recover from the context switching around one hour. And you have like four members in your team. Roughly estimation per year, the company need to pay for that context switching is around like 370. A lot money, right? Greater than my bonus.

Agoda's Approach to Fixing Context Switching: Data Analysis and Tooling7:55

So let's talk about how as Agoda,

we trying to fix the context switching from the engineer. Basically, as we know that, okay, that is the build time that slow. Is it only just me or only just you or is the whole company-wide or like just department-wide? So first of all, we need to gather the data first, whether to prove that this is the real big issue. So we have developing the plugin. This is open source. It's called Agoda Dev Feedback. I think I provide the link below. It's open source. If you guys use and feedback, feel free to PR welcome.

Basically, what this one doing is it will capture the data on the build lifecycle

of the build tool such as Webpack or Vite. So let's say like you do 𝚢𝚊𝚛𝚗 𝚋𝚞𝚒𝚕𝚍 on the Webpack. Once it compiler going to the end, it will providing you some JSON file like this. So basically, this JSON file will contain a lot of things, such as like CPU, RAM, how long does it take, who did implement, who did this execution, and many more.

Visualizing Build Data and Identifying Bottlenecks9:19

So at Agoda, we also trying to developing another service called the ingestor. So we have like an ingestor to just simple API that retrieve that JSON file as a body. And then just save to the Hadoop. That's it. Simple as that. Then every time when you build, you will have the JSON, and then we will passing the JSON body as the request to the ingestor. Ingestor save to the Hadoop table. And then we plot it into the Superset dashboard.

This one we use Superset. You can use Metabase or whatever that you can plot. This is how it looks. There is like the name here, list of the people. So we can monitoring whether this guy working or not, how many times that guy build. No, I didn't mean to do like that. So basically, we trying to check like maybe this guy took like

33 seconds in order to building our project. It also can help be like our repository health check, whether how does our contributor feel. And then we can try to optimize based on that, try to helping them to reduce this time in order to build. So they will have fast feedback and have less context switching. And there is the trend over there. As you can see, there is around like 25 seconds to 30.

That was the build Webpack. So basically, our application right now, we using the Webpack, which is coming from the create-react-app. And then we do eject. Which is very messy Webpack right now, and we barely touch it because we don't know what it is.

Seeking New Build Tools and A/B Testing with Vite11:11

And then one funny thing is like previously,

they remove some of the table here. Previously, it has the way to check which operation system or which CPU or RAM that running this.

And we found that like there is around two or three guys that use very old model of the CPU or RAM. We just asking them to request to the IT support, and they will get new replacement, and their life will easier. But like if the normal developer that developing right now, how do we trying to fix that? First thing is like we seeking the new build tool. I think you guys might be able to guess what it is. Can someone guess it? Vite, right? Yeah. Basically, we try Vite. But at Agoda, we cannot like just go ahead, like yolo, migrate to Vite and deploy to production. It's kind of like very crucial. So we need to do kind of like AB testing as well. So basically, we have like two bundles, that build from Webpack and build from Vite. And then we running as an experiment, 50/50, and then see the result. This is the result. You guys see like the yellow? At least like it coming down from 25 or 30

down to 10 seconds. This is like a very good sign that we help developer experience developing in our local environment or even like CI, we also making build faster as well. So CI/CD process is faster.

Yeah.

Tracking Test Times and Non-Technical Context Switching Solutions13:03

And then we also not just doing only the build.

We also tracking the test. So every time when you run test, we also capture everything and we can see whether this kind of test taking two seconds. Is it too long in your opinion? So if it's too long, shall we optimize it? So we can have a story or technical improvement in our backlog and trying to improve every single sprint.

Okay, then that's it for the technical part. Actually, I would like to share the bonus one. This is just my own opinion, like how do I solve non-technical context switching. It might not work for you guys, but this is what I do.

The first one is for the meeting marathon. I do block busy and busy this time. But you see that it doesn't work for me, right? There are still many meetings that trying to steal my busy time. Or another way is we do the notification snooze. So basically when Slack is coming in or new email coming in, I will not get any notification at all. So I will not get context switching trying to go back to Outlook and checking email or answer some Slack channel. I will have some period to answer. But if it's crucial, they can just walk to my desk and ask.

What about IG? So actually the way that I did is

I have following some particular account. This one is called close IG hourly. Basically, I just follow this guy. Every time when I scrolling the reel, they're going to show up showing some clickbait reel that I would want to watch, like someone dancing, someone do something. And then it will end up with the quote that go back to work, something like that. So this works for me, but I'm not sure it may not work for you. This is soft core. I also have hardcore edition as well. The hardcore edition is I use this kind of application. Basically, I use Opal, the right one. So it blocking the time to going to IG and Facebook or YouTube, something like that. So if I would like to really want to go there, I just need to snooze for five minutes, and then I can go back to work. This is how I would proceed to the non-context switching thing.

Q&A: A/B Testing Methodology, Webpack to Vite Migration Challenges, and Invasive Monitoring Concerns15:53

That's it, actually. Is it too fast?

How much time left? Actually, ten minutes left.

So you can do anything else. Actually, I don't have anything, some pop quiz, something like that.

But anyone have any questions so far?

Yep.

Thank you ครับ, just a question about the A/B testing for the webpack and Vite. Just curious on how you perform the A/B testing because from what I understand, I'm quite familiar with the A/B testing by setting up some cookie on the user side and we measuring the result. But from your side, how you perform this A/B testing? By asking developer to, "Hey, 50% could you guys use webpack and another 50% you are using Vite?" So basically at Agoda, we develop our own in-house a lot of thing. A/B testing also one of our tool. So basically, every time when you visit agoda.com

or some other page in Agoda company, you will get allocate directly when you hit the API. We will have the backend that will grab the experiment allocation for you, whether you get A or B. We have allocation type, two type. One is the user type base. Another one is the property type base because we serve hotel as well, right? So it's on our backend. And then we have a lot of thing that outside of my area to check whether

this A or B should win, something like that. Is it answer your question? No, right?

Actually, I mean developers have the options to build the project by webpack or by Vite. อ๋อ okay.

Let me tell the architecture right now for our application. We use Razor View. You guys know Razor View, right? It's from C#.

And then Razor View is we have server-side rendering. We have our React application, which is we build both Vite and webpack. Once we build those, we will have two bundle at the same time. And then we have the experiment on the Razor View that connect to the experiment platform that we have to check whether you should use bundle Vite or webpack bundle. That's how we did. A little bit gymnastic way, but it works.

Thank you ครับ.

Thank you for your questions and for your answer as well. Anyone else have any questions?

Are there any chance libraries this can be invasively used against developers? For example what if I don't want to work for eight hours and you monitor how long this guy does a build and run

test? It's invasive monitoring, right? Yeah. Yeah, right. Are there any ways to prevent it? I don't think so. Right now from my head I don't have any solution to prevent this kind of thing.

Okay, thank you ครับ So I want to ask a bit away from the topic, but I would ask how was your experience changing from webpack to Vite? I think it's quite easy in my opinion.

Basically our challenging was not coming from the official library that you can download from the npmjs package. The most challenging that we facing so far is the module federation. We use micro frontend on some particular place. So this one is kind of like very and Vite doesn't support it out of the box. So we need to develop our own plugin in order to make it work. The second one was our own in-house.

Actually we are very bad at the packaging. So when we have a lot of breaking change and some breaking change doesn't support Vite. So we need to fix that most of the time. That was the challenging but if normal flow is super easy. And I didn't try RS pack yet because it just recently released after I already migrate to Vite.

Thank you.

Thank you ครับ Anyone else? Okay, not yet. Thank you so much นะครับ Thank you so much ครับ Thank you so much.