Woof! The Art of Dogfooding! Yaniv Shani, VP R&D Lightrun

Episode Transcript תמליל הפרק

Hebrew, then English בעברית ואז אנגלית:

Yishai:         Welcome to “Dev Interrupted", LinearB's podcast which discusses everything that hinders the daily work of engineering managers. I'm Yishai Beeri, CTO at LinearB. We are happy to bring you the podcast in Hebrew where we host leaders in the industry to talk about everything that interests engineering managers, those who work with them, and those who want to one day manage an engineering organization.

Yishai: In this episode I am happy to host Yaniv Shani, VP R&D at Lightrun, hello Yaniv.

Yaniv: Hey, what's up?

Yishai: What fun you came at short notice, you delivered!

Yaniv: Fun, fun.

Yishai: And today we will talk about dogfooding. Before that I want you to tell me a little about yourself, how you got this far, a few words about your career so far, and then we'll dive in. 

Yaniv: How fun. I'll tell you about my career and I'll also put in a little, as a trigger for the conversation, some interface points of dogfooding during the process. 

Yishai: Go for it.

Yaniv: So basically I've been in the industry for 25 years, I studied at Reichman University (in the precasts), and at the very beginning, at the end of the first year of studies, that's how I started working in the industry. My first position was at a company called VCON, a company that actually developed Polycom style "video conferencing" systems and the large systems that we used to see in meeting rooms, which today no longer exist, and I specialized in the field of voice over IP, a lot of communication, a lot of image processing, and I think its name. Actually, if I look at it in the context of the conversation, for the first time I actually experienced a product and the first aspects of dogfooding. I really believed in the field of video conferencing, I was sure that it was the next thing in communication, and later on, and we may come back to it later, as a user, who started using it not only as a developer, just doing tests that the communication works and watching video, but really as a real user who tries make a call, I realized that something is not working.

Yishai: It took about 20 years...

Yaniv: Yes, it took about 20 years, I think the two main problems I felt is that the conversations are set up, these conversations require a very high emotional involvement, you can't talk about this about this and that. Heavy conversations, and there was no eye contact in these devices either. I think we fixed it with the laptops, we also fixed it with the accessibility of things and the ease of setting up, but to me it's basically like this, a first anecdote about dogfooding and we'll touch on that later. After 8 years at VCON, I made a shift to another domain. I joined the development center of Sun Microsystems, a company that was a leader at the time, today it has unfortunately already been swallowed up by Oracle for the Java body. Actually, here in Israel we developed virtual machine solutions, and I actually entered the field of Java for Mobile, what used to be called J2ME, and I led projects of implementing the virtual machine to the devices of the manufacturers. A position I held for 8 years, a company I worked for 8 years, and eventually I led the development, a global development body that was responsible for actually developing and implementing the Java virtual machine for mobile. 

Yishai: So before we dive in, let's help define, for those who may not know, what dogfooding is?

Yaniv: Okay, I don't...I don't have any ownership of the term, but in general dogfooding, the meaning of this is to use a new service product developed by the company and test it before it is available to all customers.

Yishai: And why do we call it dogfooding, dog food, historically - because of advertisements for dog food that the advertisers' dogs were the first to taste.

Yaniv: If I look, here, at some dogfooding anecdotes I do remember from my Sun days. This is one, we are talking about the development of the virtual machine. And the part that intrigued me in the development process is that the developers wrote it in such a way that the compiler would actually check itself, the ahead of time compiler that we had in the hotspot implementation, as part of the compilation process, would actually build itself and do ahead of time compilation. And it was a very, very important milestone, after developing within the same compiler, to see that basically everything works as it should, so that was my first experience of dogfooding from Sun.

Yishai: The compiler compiles itself into the VM.

Yaniv: Yes, actually doing a ahead of time compilation.

(transitional music)

Yishai: So maybe we'll start with how I, as a manager, identify the opportunities, how I find when it's worthwhile and when it's right to dogfood the products I'm building.

Yaniv: Good question. First, I'll start from the end. I know that for me, when I'm the customer of the product I'm working on, it's like my dream job, and that’s a conclusion that took me a relatively long time to reach. Let's really look at two examples that are mine from the past, the example of Sun and the example of Lightrun at Sun actually. I think there was a mistake here, that they tried to force the entire organization, we are talking about an organization of tens of thousands of people to use a product that doesn't work, and if we really are not the ICP (ideal customer profile), nor did they try to listen to the problems bottom up. There it was a lose-lose situation, because it hurts productivity. The perception is not good, so I think that dogfooding should not be at all costs. First of all, we need to really see that the product we are actually developing, we as a company can really be a relevant ICP and not try to create a situation where we actually force ourselves to use the product just so that it is good for us for business reasons or,

"I think that dogfooding should not be at all costs. First of all, we need to really see that we as a company can really be a relevant ICP..."

Yishai: To say that we did it.

Yaniv: Yes, as part of the testing process. So that's one facet, to see that really, to try to see that we can be a relevant ICP. 

Yishai: I would perhaps add to that, dogfooding in my eyes when the organization that develops it uses it.

Yaniv: True. 

Yishai: Not necessarily the business company, in the end you didn't develop "Star Office", and you had no influence over it, 

Yaniv: True, true.

Yishai: So at least the core of dogfooding means that the one who develops it is the user.

Yaniv: True, in these aspects it is actually the best, but situations happen, both at JFrog, and at Sun, for whatever reason, they want you to use internal products, and do it in a different way. In some organizations I saw that they did it in a different way, that I wasn't the developer either but I had the ability to influence and give feedback, and the goal here is to do QA and help us as a company test the products better, but definitely. The ultimate dogfooding, in my opinion is also the simplest, is actually that you use your own product. So that's one thing that was important for me to emphasize. Second thing, dogfooding, from my experience, there are technological complexities here, let's take Lightrun for example, our Lightrun product actually allows you to debug live applications directly from the developer environment and update them with additional insights, add logs, receive snapshots of information, metrics, etc. To dogfood it is not easy because it is actually a product for developers which is a plugin that goes into the IDE, and actually in order to debug itself you have to do something technical here in order to not confuse the developer. How can you actually debug the plug-in by the fact that you integrate the dogfooding through another plug-in. 

Yishai: You debug the plug-in, while your client debugs his code.

Yaniv: Yes, it could also be that I am also debugging myself, as if in the process of developing some feature I have a problem that I can't solve and I have to use Lightrun to solve it, so there is some kind of double debugging here and the user experience is not the most comfortable. So one of the things is important, for dogfooding to really be successful, is knowing how to make your product accessible to yourself, sometimes you... it's not easy, and one of the things we did at Lightrun so that there would really be very good adoption here, is the ease of use of dogfooding. It's a little difficult for me to explain the details, but we have technological challenges here, we invested a lot to make it easy and simple.

Yishai: So you say you invested, you chose to invest in a capability that is actually not transferable to your customers.

Yaniv: True.

Yishai: Only for the benefit of dogfooding.

Yaniv : True, true, that the spinning up of our solution will be easy, knowing how to run several plugins on the same computer, something that the customers use less, so that the ramp up of the developers will be simple. And other customers are not using, there is no need, but we as a customer have special requirements and in order to reach a level where the users will not actually have to do very complex boilerplate to use our own solution, but will experience it the way they want. And then they will actually really enjoy the product easily, and this required effort. It was not simple.

Yishai: It's interesting that you say I'm ready to invest and build something that is, some kind of start-up,

Yaniv: That's right.

Yishai: Only for the benefit of dogfooding, and it's not that I use the product as is. 

Yaniv: That's right, because the value of this is so so great later on, that you have to make some initial sacrifices here because otherwise it will actually harm its internal adoption.

(Transitional music)

Yishai: How do you integrate the issue of dogfooding into the process of releasing a feature, is it the lifecycle of capabilities that are being built?

Yaniv: Nice one. Integrate it all over, maybe we'll give a little background, a little about the product, and then actually, about its various use cases, and then we'll actually tell you how it fits into the process. So in general, what Lightrun knows how to do is to connect developers to the live application, a connection that is not only a connection on the physical side, but simply to create a relationship with the code you develop. The most obvious use case to explain is actually a troubleshooting use case. You have a problem, your application runs in production, there is no debugger, because it is a distributed application and you want, as part of the process of getting to the root cause, to add logs to receive values ​​of variables, etc. Lightrun knows how to do all this. But Lightrun, if I go back to its core premise, it knows how to connect the developer to the live application. So it knows how to do many things beyond that, it knows how to do verification for a new feature. You “canary rolled out” a new feature, do you want to see how it behaves? Then you can add insights. You have a CI that is broken and we know that it is often difficult to debug CI. So you can debug CI. There are stress environments, performance environments where from time to time you come across performance problems, you can debug them. So we have a lot of use cases for the product. And one of the things we decided, dogfooding is found everywhere. Because you don't know where the next problem will be and where the need will be. So basically we set up an environment, which is a full Lightrun environment and as an on-prem client. We have taken ourselves to the extreme, in that we actually allow Lightrun support to be introduced into all aspects of our software development lifecycle. I mean all the QA environments, the environments of our feature branch, dogfooding in the agents, in the CICD pipelines, we also have dogfooding, in SaaS. All of our SaaS is monitored, in addition our product contains all kinds of third-party services, for which we also, because Lightrun also knows how to monitor not only our product, but also third-party products, so we introduced dogfooding to them as well. So first of all our goal was to produce ease of use so that dogfooding our product, would be widely spread across everything we use on a daily basis, as part of the development process and monitoring of faults. So that's one thing, the other thing, in terms of the software development lifecycle, in the release process of the version we have all kinds of milestones, we optimize and improve them every time, but we actually have a code freezing process before the minor version, and then we actually update the environments. Our staging, checks them, and before upgrading the client which is the P0. Actually, the version is already supposed to be released, it's actually upgraded to dogfood status, as a significant milestone. It doesn't make sense in our mindset that the new version will meet an external customer before it meets ourselves, so actually it's something that's an important milestone.

Yishai: So basically every version has a stage where it runs for the first customer, which is the dog food environment,

Yaniv: …and then it goes out to, exactly, the other customers. And we know it, there's nothing to do, many times we check very well regression, functional testing, but what to do, the migration was screwed up and processes like that, it really helps you prevent situations of failure of migration problems, etc., and it saved us quite a few times actually when dogfooding, and used internally by us.

Yishai: Yes, we, if I will share a bit at LinearB, we are constantly dogfooding the product and almost every feature has its own lifecycle. I mean, we do a roll-out for features with feature flags, and there is a definite stage in the process of maturity of a feature that says it goes into dogfooding, this is not only for the benefit of QA but also okay, feedback is it helpful , are the consumers, which are us, it can be the development manager, it can be product people, team leaders, developers, how do they experience it. And in many cases we do it relatively early. The dogfooding stage, the feedback from these users, which is us, changes the feature and the final stitching of the product and the experience, because in the end our users are developers, so I want developers to give me feedback. Then it goes to early access for some customers, and there is also a feedback cycle there, but each feature has a stage that is defined and the sales people know it, oh, this feature is already in dog food, this feature is coming soon , and it serves us very well in understanding OK, this is how it should be built. 

Yaniv: I completely agree. So it's about our SDLC, how we integrate, but I really want to talk a little about the day-to-day use and the impact on the developers. We made an early and large investment in the process, internally, to really integrate this environment across the board, and actually make it as accessible as possible. And actually from there we decided to really do a process of daily use and adoption, we are talking here about a product that is a new category, and one of the big challenges is actually to change habits. It's not easy for people to change habits, and it was hard for us at first too, and today we already see that it's actually our DNA changing and we really use it like our widely used customers, and we did a few things along the way. So first, we decided that this is something we really want to embrace strongly within the organization and I decided that in order to do this we really need some champions from within, who will really help produce early adoption and the mindset shift, we called them Dog Fathers. We have representatives from each team, one representative that we hold a weekly conversation with, the purpose of which is basically we go over the weekly usage, everything is monitored with us of course, and we are really productive, looking at the things that come up from the field. I mean also from the usage from the analytics, we also actually have feedbacks that come up from the JIRAs, and the goal is, beyond the use, to actually bring bottom up to surface innovation features that come up, and the most fun thing is actually these meetings that distill the ideas and give the developers then, who proposed the ideas, time to work on these features. There are some examples in the latest version that we released that really resulted from inputs that came from the day by day usage of the product. 

Yishai: So you first touched on the question of measurement here, I assume it's the same measurement that you do to your customers.

Yaniv: Exactly the same, I mean we have the,

Yishai: same tactics and goals that customer success activates, 

Yaniv: dog food is like...

Yishai: Another customer.

Yaniv: Like another customer, all the same monitoring that a regular customer has, the dogfooding has. 

Yishai: Maybe an idea, I don't know if you do it, it's not always trivial, but it's interesting to run customer success on customer zero as well. I mean, there's a kind of customer success manager that will manage the same cadence with this client, it could be interesting.

Yaniv: Right.

Yishai: It creates another axis. And the second thing you brought up is actually the initiation of features and capabilities Or flagging gaps, from this group of users, that they can also on the way to know OK, I already know how to realize the, how to solve the problem for myself.

Yaniv: True.

Yishai: So you are actually managing to create another channel of input for the product?

Yaniv: Of course, of course. 

Yishai: What does this do for the developers, their ability to influence like this?

Yaniv: So that's amazing. Look, that's one of the things that, first in the recruiting process we’ve talked about. That you really have the opportunity to work on a product that you are also expected to wear the hat of the product, come with the ideas, it's challenging, it connects you. There is the book everyone knows by Marty Cagan. About product, okay, that talks about... that you want to... in product people, product people who are missionaries, not mercenaries, and this is where you really create the real connection of the developer with the product. I kind of think that it's really the ultimate win-win, and it's fun, like you know, that you're working on a feature that you are, then you get to provide input and feedback for, and it doesn't have to be the most radical thing, but it's things that we don't pay attention to until you actually use the product and you, when you use it as a real customer, you experience it and it gives a significant say here.

(transitional music)

Yishai: So I want to dig a little deeper into the world of developers, about the developer experience, when they can and are systematically successful to work with the product they are building and dogfood it. I have seen, and continue seeing, how it helps and affects the recruitment process, which you also mentioned. Where else do you see the effect of this on the developers? The benefit, or maybe the opposite, that the fact that they need, are forced , to work with the product they are building. How does it affect their day-to-day life and their experience as developers?

Yaniv: It affects a lot of layers. First, it connects them to the product, secondly, it opens our eyes to new use cases, maybe in the future I will tell you about all kinds of problems, but actually our product is very basic in terms of capabilities, but on it you can create all kinds of use cases and a number of use cases came from the developers themselves.

Yishai : It's a benefit to the company, what does it do for the developer? That this use case came from them?

Yaniv: A lot of pride, I push innovation, I think my job as a developer is to create, and here I really create business innovation with real value, so that's one facet. Another thing, look, developers, one of the things you see, is that they don't always know how to connect the focus of what they are working on, the priority of what they are working on, to the organizational focus. And through dogfooding and things that come up, they really know how to differentiate between what is important to take care of, and how to properly prioritize their tasks. So this is something else I see, and good ambassadors also tell friends, like. Once you really use your product and it works, you go and tell your friends, and quite a few of our business opportunities also really come from the developers themselves who meet and do a bottom up spreading of their solution.

"I push innovation, I think my job as a developer is to create, and here I really create business innovation with real value..."

Yishai: Yes, I also saw empathy with the customer.

Yaniv: True.

Yishai: It is difficult to reach them in any other way, the developers in many cases have to support the customers, directly or indirectly, and, while I am working on a feature, my empathy, my thinking about the user, since I am the user, is on a completely different level . And developers, even those who like to think of themselves, I'm only technical and I'm not interested in business and I'm not interested in people, even these extreme cases, in the end they do care, and when they see, when they built something and they use it, then they also have the achievement of voila , I built something and it lives in production and has usage, for example. Me, I really enjoy what I've built, I see the same with me in the past, I completely agree that it makes a fundamental difference for developers.

Yaniv: I agree, and I even have some concrete examples, I mean we released a version a week ago, a new version of the product, with a lot of emphasis on dev experience and requests that came from the customers. And there were quite a few problems and enhancements that we developed that both came from customers and we experienced them at dogfooding, ourselves. It causes much greater empathy because some of the problems, I remember we arrived, we saw them in the dogfooding only later, and then their priority was not really high, but once the developer also experienced it first hand, it really made them connect. It is also much more significant to come up with a better solution, so definitely, it is very helpful. Here in this case there are some concrete examples, but we don't need to dive into them, but we really saw it in our latest version. 

Yishai: I think another challenge that is true for companies In general, it is true for development organizations in particular, this connection of the why, why do we do something at all. I think that a developer cannot do a good job without understanding the why, and there is always a challenge of how this “why” permeates from above and how. This context, where are the company's priorities, why do we do what we do, when the developers experience the usage themselves, they are the innovators, 

Yaniv: True.

Yishai: They understand the why in a way that you cannot compete with. 

Yaniv: True 

Yishai: …and I see that developers who are connected to the why are happier developers, more productive, happier and more connected, all these things in the end, in my eyes, affect the developer experience in the most direct way there is. 

Yaniv: I agree, that's why I’ll also go back to what I said even about myself. That I really came to the conclusion relatively after a long time, at companies that I can really dogfood properly, this is the most suitable place for me, and I also think that I am looking for such people, because then I am really very connected to the why and I really have the possibility to have a very significant influence on the product vision, about the direction, etc., so it's really like this aspect that really comes from dogfooding.

Yishai: I want to ask you about - a little more about the engineering  organization. 

Yaniv: Yes.

Yishai: In companies that build products for developers or engineering processes, in this case also Lightrun, also LinearB, we are in this space so it's easy to dogfood. How does this affect people who are in adjacent disciplines, for example product people, even sales people, customer success. There is some effect of, as if we sell to an engineering organization, so we choose people with a certain background, people who know how to appreciate this dogfooding or even use it. Where did you see this expand beyond the engineering team?

Yaniv: Look, for us it goes through several layers, one, we expect that everyone who works at Lightrun at least at this stage, knows how to understand the value of the product. And in positions that are more adjacent disciplines, even in the interview stages, we ask them to install, try and see if you succeed. And we're looking for the people with that skill set, okay? It is true that you will not write code or you will not be a user, but at least you will understand the value of the product and go through the process of installing it, so product people we interview, support people, even SE people, go through this path. So that’s one layer. On another level, look, people, it's surprising, and not surprising, but with such technological products, your customers, one of the first questions they ask, do you dogfood? As if to say this is one of the questions quite a few times, when I get on calls, and of course sales people, it's actually your testimony yourself that is very important, and we are very proud of what we do, we also show it in the demos, okay? I mean to the customers, yes, we do and here, look how it looks with us, it also allows you, a salesperson, SE, to also show how to build a system correctly, how to define it correctly. So yes, it is a philosophy that is very critical, certainly for the engineering body, but it also has an effect on the wider circles, and dogfooding is used as a product of other personas. 

Yishai: We have taken it a step further where we can, and we try to make it happen as often as possible where we require an engineering background from people in the product organization, or in the customer success organization, even in sales, that you have an engineering past is key.

Yaniv: True. Here, too.

Yishai: I mean you know, you lived this life, even if in the end it's not the career you chose, it's part of the required skills, and we see that it makes a difference, again, in empathy and the ability to understand the product. A second area for us as a SaaS product is our demo. When the sales people do a demo for customers, it is always live and it's always on the dogfooding production. I mean, LinearB on LinearB, it means that at the beginning of the demo they don’t know what they will see, I mean maybe they checked a few minutes before, but this is live data of what is happening with us today, and if our development behaves a little differently today then the data will look different. And everyone is used to working with this demo environment. And then it creates a problem on the other side of the dogfood if for a time, there is, say, a feature that has reached the dogfood stage and it is not yet fully mature and you have to see 'Wait, how does it not screw up the demo?'. Because now salespeople who have not yet been trained on this feature, suddenly see it and suddenly have to demonstrate it and maybe it is not 100% ready for the level you want to demo. So it's a challenge from the other side, but we also refer to this side of sales for dogfood, meaning where here, LinearB is using LinearB, with full transparency, this is what you see, this is what is in the demo. 

Yaniv: The most authentic, the most genuine, and when you really, like, really present how you are as a customer, then there is a point...we are ultimately very critical of ourselves, that's how I see it, and if we managed to convince ourselves that it works, then there is a point, there's a good chance there's something real here. But this undoubtedly causes challenges. Undoubtedly, I also understand the challenges you say, to use it and integrate it requires an effort that is a transition of the effort of another customer who uses it. 

Yishai: I'm interested in how you deal with or propose to deal with, say, different levels of dogfooding or pockets of dogfooding, to give an example of a challenge we experience, but it probably exists in other places. You mentioned support for IDEs, something that Lightrun provides, there are a few different IDEs out there and maybe your development organization likes to work with VSCode. So the level of dogfooding to support IntelliJ will be very low because you will not now start artificially, say well, 10 people work on IntelliJ just for dogfooding, in our product we have support for Slack and MS Teams, we internally work with Slack , so almost by definition, dogfooding and I would say even raising the maturity or support of features in MS Teams is one step after, because we don't live it, so it's harder for us to support, and even harder for us to dogfood. How do we approach these questions? In the end a complex product has all kinds of integrations, you won't be able to use everything all the time.

Yaniv: So my approach will be authentic.

Yishai: Going back to Sun.

Yaniv: Yes, it goes back to Sun, I mean don't create a situation, let's take it to the extreme, that because we want the dogfood to work, you force the green team to use Slack, and the blue team to MSTeams, why? Because it's convenient for us to use them as test subjects for the feature, no, LinearB should continue to work as the engineering organization regularly works, and actually integrate the LinearB product based on the existing deployment, this is how we do it at Lightrun. The additional use cases, the capabilities, the support for IDEs, various runtimes, which are not supported by us, it is actually tested as part of the QA, but we invest the efforts to integrate what we can and that is relevant to the organization, as part of the dogfood. It's the,..

Yishai: I liked the approach of the be authentic, I think in general, and developers have an allergy to things that are not authentic, 

Yaniv: Right.

Yishai: And when you try to make something so that it's not really dog​​fooding, with dogfooding you have to come hungry, if you’re eating the dogfood just to taste it, for QA? It's not good enough.

Yaniv: True.

Yishai: Should be for use, not just for QA. And maybe sometimes the gap can be bridged by, well, let's find some friendly customers or close companies even if they won't pay, and they will be your dogfooders for footprints that you don't live in your engineering organization. That there they will be authentic, and you will create a relationship with them so that they can give you the dogfooding experience, albeit a bit from the outside, but don't be blind to these areas and say ‘well, I only have QA’ and as you described, say in Nice or in a company that there is no connection between your experience and the experience of the customer. 

(Transitional music)

Yishai: Towards the end, give us your recommendation for a manager in an engineering organization who may not be doing dogfooding today or not enough, how/what, how to start, how to move from zero to one, where it is relevant but there is no such habit or there is no such habit yet. Where to start or how to approach…?

Yaniv: Okay, so I would first start by trying to understand if I am a product manager in a company whose product I am developing is it relevant to me as a company, basically if we are an ICP yes or no–– ideal customer profile. If we are not an ideal customer profile and my developers are not users of the product, there is no point in investing in dogfooding.

Yishai: You return to authenticity.

Yaniv: Yes, definitely returning to authenticity. If so, then you have to understand that this is a project, it is a project that is like any other project, there is an investment here at the beginning. And you really have to understand, it depends on the product, there is a level of assembly, complexity that can be in its accessibility, in its deployment, and in general there are products that also require a change of state of mind and conduct, so there really is a process of product adoption here.

Yishai: What's more, each of your customers will have to go through this too, so you learn that from there as well.

Yaniv: Exactly, you learn from it. Try to identify champions from within the organization.

Yishai: I liked the name Dog Fathers, it's great.

Yaniv: Yes, champions within the organization who will actually help you push it bottom up, help embrace success, for example we had several very significant events recently that we are doing special sessions on at a very wide level, because we generated a lot of insights, a lot of ideas, really to embrace it, so that this thing is really embedded in everyday life, and I highly recommend it.

Yishai: Do you think it's too soon? Or you would say this, if it is possible from day zero to start with...

Yaniv: As soon as possible... as early as possible. Once you have, I think, once you're already selling the product and you're ICP potential, you have to be the P0, the customer zero.

Yishai: Excellent. Yaniv, thank you very much for coming.

Yaniv: Thank you.

Yishai: It was excellent.

Yaniv: Nice.

(transitional music)

Go to devinterrupted.com to subscribe, you can also find all our episodes in English there. I remind you that we at LinearB are in rapid growth and are recruiting for a variety of positions in all fields. Visit linearb.io/careers to find your next challenge. I'm Yishai Beeri, we'll hear from you in the next episode.

(Closing music)

Links to the nifty tools and resources mentioned in the episode:

• Lightrun
• Marty Cagan: Inspired: How to Create Tech Products Customers Love
• Visual Studio Code
• MS Teams
• Slack