Developer Marketing Does Not Exist, Baruch Sadogursky

In the sixth episode of Dev Interrupted - the Hebrew Edition, Yishai Beeri, CTO at LinearB chats with Baruch Sadogursky, Principal Developer Advocate at JFrog about all things Dev Advocacy and Relations.  WTF is dev advocacy anyway?! How does it relate to engineering? How do you interface with engineering managers, and will answer the question...is developer marketing even possible?!

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.

In this episode, we are happy to host Eti Dahan Noked, engineering manager at Wilco. Hi Eti, how are you?

Yishai: In this episode I am happy to host Baruch Sadogursky, Principal Developer Advocate at JFrog. Hi Baruch, how are you?

Baruch: Hello, hello, hello Yishai, thank you for the hospitality. I am very happy to be on this podcast.

Yishai: I'm very happy that you could join us, and today we'll dive into the questions of what developer advocacy is, what the role is, etc., but as always I like to start by asking, tell me a little about how you got there, what was your path from the beginning of your career until today, What are the main things you touched and did, so we get to know you a bit.

Baruch: Yes, so I started as a java developer 22 years ago, in the early 2000s, and one of my first workplaces was a company called Alpha CSP, it's a consulting company in the java field where I grew into a developer, consultant, architect or whatever it's called. And at some point around 2006 the Alpha CSP team decided to write an open source product that was supposed to help Alpha CSP customers but not only. To bring a little bit of order and organization to this issue of software dependencies, of dependencies in Java in particular, so just at this time Maven started to gain serious traction as a build and package manager in the field, and one of the things that was missing was exactly this issue of a dependency manager that can sort out all these matters. Then a team of Alpha CSP took and wrote an open source product that was called Artifactory over the course of a few months, suddenly it turned out that all the who’s and who’s in the industry––like Google, and LinkedIn, and Facebook use this product. And the guys came up with an idea that it might be possible to make money from it, there was a very small team of 4-5 people, so they left Alpha CSP to start a company around Artifactory, it was the founders of JFrog Shlomi Ben Haim, Yoav Landman and Fred Simon -  some of the developers who actually wrote Artifactory at that time joined them. It was 2009 and after two years Shlomi contacted me, said Baruch, it's time for you to join JFrog as well, so I told him fine, tell me when I start, on what date, I'm ready to come. He said fine but keep in mind that we need you for a new position. I'm a java developer then, don't know anything other than that, I asked him ok, but I don't know what you're talking about. He said listen, the problem is we don't know either, we don't know what to call it, we know what we need, we need a foreign minister for JFrog. Yes, we need a foreign minister for JFrog. It's a tool, Artifactory, is an open source tool intended for developers and we need someone whose job it is to talk to developers, hear what they have to say about the product in order to make the product better and tell them about JFrog and the product, really the Minister of Foreign Affairs. So I said to him well, do you think I can help with that? I would be very happy, he said yes, come on, come join, just come find us a name, we can't write in the contract “foreign minister”. Go, look up what it's called. So I started searching and I understand that there really is such a position and there is such a job, such a job, it is called, I remind you, we are talking about 12 years, so the whole subject of developer relations and developer advocacy was not yet so easy to find on Google.  And then it would be called a technical evangelist and then I say Shlomi listen, it's called an evangelist and Shlomi, a Jew, a traditionalist, tells me Baruch, get out of here before I kick your ass, I'm not calling you a priest under contract at JFrog. So I said ok, fine, I'll go look for more, I went and that's when at Google they started reframing the role, it's not really reinventing the position, in developer advocacy, and then I go back to Shlomi. I told him listen, here, I found on LinkedIn - there is a position at Google which is exactly what we need, look, it's talking about the product with developers, it's getting feedback, bringing it to the product, it's exactly that and it's called developer advocacy. Shlomi says listen, you're nuts, you wanted to be a priest, now you want to be a lawyer? Like what? Is there no normal name for this position? I told him listen, that's what there is, Google, what...so he tells me good, fine, at least with that I have less of a problem. You want to be a lawyer? Be a lawyer. And that's how I became the developer advocate of JFrog and that was in 2011, so now we are 2022, 11 years later, it's Principal Developer Advocate at JFrog.

Yishai: Okay, so in a moment I will ask you a little bit about what happened over these years and how it evolved, but you came from a hands-on position, you wrote code and then he says come and suddenly do the job of foreign minister. what were you thinking? Tired of writing code so let's go talk? What was going through your mind?

Baruch: Yes, it was very, very clear to me from the beginning that this position must be a very technical position, and it is a kind of hybrid role, yes? So it's true that there's more to really talk about - talk to developers, tell them, listen to them, etc., etc., but it's not in place of the technological part, yes? This means that as soon as the developers want to speak the technical language and as soon as the other side, the person talking to them, the developer advocate does not have this technological basis, this conversation cannot take place. One of the reasons why developer marketing does not exist and there is a book called “Developer Marketing Does Not Exist”, one of the reasons that marketing for developers does not exist, is because marketing is not meant to be technical and developers do not want to deal with anything that is not technical. And this is why developer advocates must be technical.

Yishai: So you have the skills, you had the skills. But your day to day has gone from writing code to doing I don't know, posting or talking to people.

Baruch: Presentations, yes, write presentations. Not just write code, yes? I mean in the end this skill set is a skill set that is always changing, it is not a welder who learned to weld 50 years ago and today all that is better is having more experience. Our field is constantly changing and if you are not up to date with technology skills then you don't have the skills. It's not that everything I learned about Java in the 2000s is enough for me to talk about what JFrog does today, of course not. I mean the technical and hands-on learning on and writing code isn't going anywhere, so it's true that I do it less, it's true that I do a - it's in other areas, it's true that instead of making commits to the product itself, my code is more about integrations, plugins, making our product work with things that happen in the community, but I can't not write code at all, because then my knowledge becomes irrelevant and the audience, which is the developers , feel these things immediately.

Yishai: Okay, so you start working at JFrog, in a position that is new not only to you but new to the world, you hardly know what it's called, tell me maybe about the first challenge or the first time you understood what the position really is? Again, as someone who comes from something a little different.

Baruch: So yes, one of the biggest problems is to shut the fuck up, you come to a company in a job that is mostly focused on telling about us, and you are enthusiastic about what the company does otherwise you probably wouldn't have come, and you think that the solution is really excellent and the technology is excellent and it really solves a lot of problems for the developers and then you run to tell everyone. “Hey, look how awesome!” and it doesn't work like that. What you hear is someone that is trying to push something on us, and of course their interest is not our interest––and they want to sell to us, etc., etc., and that's how you sound and it's horrible. And it took me a lot of time, years, to learn that’s now how it’s done.. That even if I know for sure that the solution we're giving is the right solution for this specific problem I'm looking at now, and there's no reason in the world why our solution shouldn't be taken or used, you have to know not to say these words and instead gently and with discussion have the intention to lead these people to the well, so that they will drink on their own, instead of pouring buckets of water on them and making them only feel that they are drowning.

Yishai: Why do you think developers are so opposed to someone saying my product is good? Is it because they are burned out from so much bullshit? Or because something in the way they think, in the way we consume technology, you say I want to figure it out alone, I want to try it by myself, and if I didn't do it with my hands then I don't believe it?

Baruch: I think both. First of all, over the years companies have tried classic marketing techniques in their discussion with developers and it doesn't work because it's not real, because it doesn't come from technological information, because it doesn't come from an understanding of the market, because it comes from like selling anything else, like selling canned goods. And the market - this technological one, because it is much more complex and it requires from people in the market a much deeper understanding, we also expect from those who sell to us or those who offer us something that the conversation will be at this technological and in-depth level. The gimmicks of traditional marketing do not work because it is not the level of discourse that exists in the industry, and of course the more you do it like this then it creates more antagonism from this direction and people want it less. And then they already see this fluff no matter what you do, and even when I come in the best way, really when I think about their problem and that's what that I have in front of my eyes, I say listen this product is really the best product to solve your problem, it sounds the same. It's bullshit what they are trying to sell us, they are trying to push us, and this is not something that I know is good for my product and this is where this demand comes from of Hi, I want to try it on my own, I want to figure out on my own that this is what I need, I won't take the word that Go because you are biased, because you are paid money for saying this, because we don't believe someone who has an interest and all kinds of such and it seems like such logic, of course it is at the moment, this pendulum is very much to one side of no matter what we are told We won't believe it, but there is something in it on a certain level.

Yishai: Look, the code, if I wrote some kind of integration or used it, I was able to run some kind of system with code that I brought up, it's not lying, the system doesn't get paid, it doesn't have an opinion, either it works or it doesn't.

Baruch: That's true, on the other hand it's not necessarily everyone who tells you that this product is good for you is lying, it's a pendulum, yes? You don't have to take everything you are told at face value, on the other hand if you are told that, I don't know what, there are canned goods today that these canned goods are not necessarily there are all kinds of substances in there that are not good for you, you must now go to the laboratory and check that, you know. There is truth in advertising and sometimes there is no truth in advertising and the truth in advertising is somewhere in the middle, and right now, unfortunately, the industry is very, very antagonistic to anything they try to sell to, all kinds of things you know what? I don't understand, like deleting the core part of the links, I don't have an answer for why this is happening other than hey, we hate marketing, which is weird and bad and not good for anyone, but you know, it is what it is.

Yishai: Okay, so you are starting a new position, as mentioned, not so well known, you look back and also what is happening now at JFrog in this world of developer advocacy, can you put signs for who this position is suitable for? Who is not suitable? What do I need to have in order for me to succeed in such a role?

Baruch: Yes, I think that today we already know how to put a finger and say hey, you will both succeed in this and love it and I think that the combination of skills that we are looking for here is rare and that is also the reason that today when the world understands the importance, the world...the industry understands the importance of developer relations, everyone is looking for developer advocates and can't find one, one of the reasons it's very difficult to find is that there really is some combination of skills that usually don't exist in the same person - technical people are usually introverts and all they want is to be left alone and let them to play with their code, the developer advocates are exactly the opposite - you have to be very extroverted, like people, like to talk to people, and this is a combination that is very, very rare, very rare.

Yishai: You say it's a kind of progression for senior developers or architects, people who have technical depth but who nevertheless love people, not people-haters, this could be a path for them.

Baruch: I think this is a very, very good track for those who are not looking for the classic management of managing people, and here I can tell you that many, many technical people would not want to manage people if they knew how exactly this thing is the opposite of writing code or working with failures. People are accurate, machines are consistent feedback and algorithm driven, and people are just the opposite, not consistent and driven by...and don't work the way we want them to work, which makes managing people a very, very frustrating experience for most technical people, and this is also another thing that the industry is slowly learning. Until a few years ago even, in most companies the only progression path was after some stage of senior developer or something like that, fine, go manage people, you're so good, why aren't you a manager yet? And the results are terrible - most of the good technical people are very, very bad managers, and this is also changing, and those who hate it, of course, it is also changing, we now have tracks for individual contributors and really developer advocacy is an excellent option for a track of progress for an individual contributor, As long as you really love it, you really love people, you love community, you love talking, you love listening, you love being with other developers and not just sitting in the same room with noise cancellation headphones.

Yishai: You see that people as developers or as hands on people are also active in the community, write on reddit, live the media, this is some kind of good indicator of who might also be a good developer advocate?

Baruch: Unequivocally, those who are in the community because they want to be in the community, and they do it at the expense of their private time and without it being part of their role, are the ones for whom developer advocacy can be a great career path, and that's also what we are, that way We find them, yes? When we talk about, I have startups that I help in developer relations as an advisor and as a mentor and they all try to recruit and it's very difficult, what we do with them is exactly to look for those who are already in the community, who are in reddit, who are in slack, at a meetup and try to tell them hey, you're doing it anyway, why don't you get paid for it?

Yishai: Actually, a developer advocate also works with such people who are part of his mechanism to reach the general public, you activate in some way or cooperate with such people.

Baruch: Right, there are the champions and the external advocates and call them what you want, it's the people in the community who do this work anyway and if they're enthusiastic about your product then you have here A great opportunity not only for the recruitment of developer advocates who will do it for a salary but also these community champions who will actually help you reach the community without being hypocritical, hey, he gets paid, obviously he will only say good things about them.

(transitional music)

Yishai: In this podcast we talk a lot about engineering managers, about engineering management, and I'm interested in the interface between the engineering managers in the organization and the developer advocates and the leaders of the developer relations, where things meet, what this interface looks like between two different positions that serve the same organization ?

Baruch: developer advocacy or developer relations as an organization within the company is one of those organizations that basically touches everything, and we can go one by one and every other organization in the company and see how developer advocacy works with them and helps them, and I'll give you some examples, in marketing this is something very, very clear , Yes? In the end, we are the ones who work before the marketing panel and work with the community and in general on awareness, but not only, probably also the product, the community feedback that developer advocates bring into the product is the most valuable feedback - the most important thing for a product is recruitment, as soon as people know about the company and know good things about the company and the technology within the company, people will want to work for it and R&D, and this is exactly where we come to this topic of technology managers - we are the voice of R&D within the community, We want people to think good things about R&D within the community, we want our company's R&D to get the credit for the great things they're doing, and that's exactly how we can help the tech teams, we're also the ones who bring them into the spotlight and to the front of the stage and say hey, these The people who actually do the work and make the product so well that, I hope, the community likes and knows how to appreciate. So wherever you look, we can help as developer relations, and R&D and the managers within R&D are no exception.

"Community feedback that developer advocates bring into the product is the most valuable feedback"

Yishai: And what does it look like or where are there frictions or situations where it is not clear how to work together? Specifically with development managers, where are the difficulties?

Baruch: In front of development managers we sometimes sound like the, how shall I say it? The spoiled kids who cut the line and suddenly have demands that the whole company must fulfill, and this is how it can sometimes feel, and here what you need to remember is that it is not our demands, in the end what we bring to the organization when we say hey, we need this and we need the This, this is ultimately what we hear from our community, and if there are any fires now that we know from the community that we as a company must put out and we bring them to the attention of the organization and the heads of the technological teams, it's not because we feel like it, but because there really is some kind of problem that we need their help To solve for the community, not for us, developer advocates, as private individuals, but sometimes of course it sounds like there isn't, once again these developer advocates want something from us when we actually have other plans.

Yishai: So you seem to be pushed to priority, pushed to the road map in a way that might look like something pirated.

Baruch: Exactly, right, and why are you even telling us what needs to be done, and here we have to remember that it's not us, yes? In the end, everything we do, we tell you what the community says, and if now there is some feature that doesn't work properly, even though you think it should, there's nothing to fight with us, we didn't decide that it doesn't work properly.

Yishai: And on the opposite side, at the stage when the feature is still being built or the design is being done, they make sure to call you so that the cycle can be shortened. That way if you already have some insight about how people want to consume it, how to properly build it , or you do it wrong and then you come in as the hardest critic…

Baruch: Both, of course everything related to working with the product, I think the team of developer advocates and developer relations is the most important resource of a product to decide what to do, when and how, because in the end the whole purpose of a product is to score a stamp for what the community wants when they release this or that feature, and the only ones who can tell them hey, this is how the community wants it or doesn't want it, is the developer relations team, the smart product teams will listen to the developer relations team , invite them to these conversations, and not only to hear but also to propose and offer it back to the community and say listen, we want to do it this way, check if it holds water, check what the feedback will be, and of course this way companies save a lot of time, a lot of money , and hit better what the community wants.

Yishai: On the flip side, you have to explain the shortcomings, okay, develop something, it's never perfect, it's never 100% what the community needs, you're in a position where you have to explain the gaps both internally and externally, say well , you can still use it, it's still useable, you come off as the bad guy in both ways.

Baruch: Yes, so inside is much less of a problem because in the end we are my colleagues, we know how to work together, we understand that even when I yell at them that it is this crap you have developed, in the end we are all here for the same thing, we want the The benefit of the organization, outside of course it's a problem and it's a problem because on the one hand you really represent the company and you want to say hey, guys, well, well, it's not perfect, but in the end it's useful and it's good, on the other hand your reputation is on the line and that Also says the reputation of the company, because from the point of view of the community you are the company and the company is you, and trying to bullshit your way through something that doesn't work is going to hurt everything, and on the other hand your bosses, especially in marketing, won't exactly be happy to say hi, we know That this thing doesn't work. It's a very, very narrow line, a very narrow path to walk - on the one hand to be authentic and say yes, this thing isn't perfect, on the other hand not to say hey, don't use our product, and that's sometimes very, very tricky, very tricky.

Yishai: One of the topics that interests us and the topic of developer relations, developer advocacy touches on it a lot is at the end of the developer's experience, what is today a buzzword that is catching on, developer experience, we see the developer experience on two levels - also the developers who use our APIs, our SDKs, our products, this world of developer advocacy that you live in. What is the experience of a developer from the community who wants to use my tools, but there is also the angle of what is happening For the developers at my company, what does the day-to-day experience of R&D look like with us, do you see any connection? Do these things touch each other? Because at the end of the day, the community that works with JFrog API's does not necessarily encounter the same difficulties as a developer in JFrog who comes to make a release. Is there a touch? Or is it two different worlds of the same name?

Baruch: Of course these are completely different experiences, and it is true that the developer experience is first of all intended for the outside, yes? I mean if we have a product intended for developers, when we say developer experience we mean the developer experience which is the user experience, yes? The UX, we call it developer experience to emphasize that our users are developers but we are referring to users outside, and I think that the experience of the developers of this product is a kind of afterthought only now recently, especially after Corona and suddenly with all the great resignation and the whatever silent resignation and all these buzz words that now suddenly pop up, and burn out of course, now suddenly start thinking about it, yes? I mean, yes, it's probably important to us how our users feel when they use our product, but suddenly it's also important how our developers feel when they develop our product, and this, as I said, is new, it's new and it's not because suddenly everyone is very touchy, feely and take care of our employees, but because suddenly it hurts the business and the burn out and the resignation and the whatever affects the quality of the products we develop and how quickly we can bring them to the market and suddenly everyone has, suddenly everyone cares how the key is within the company feels.

Yishai: Say, is it at all possible for a developer who lives in a bad experience, I actually put emphasis on his technical experience, like how much effort he has to put in to set up a local environment or make his code eventually enter the code base, if my development environment It doesn't work well and it's very difficult and my experience is very cranky, can I even release a product whose experience for the developers they use will be good? That there everything will flow, that there everything will be testable and stable and fast, is it even possible to do that? Or is my experience as a developer inside an organization the type of thing that puts a cap on what I know how to put out? When it comes to API products, developer products.

Baruch: I think it is possible, it will just be very, very expensive and very, very difficult and probably not the first time. These things are indeed separate things, in the end you can through, if there is a good product team and a good development team and a good developer relations team, you can build a product that will be good for developers even if the writing process of this product is a nightmare. The problem is not there, the problem is how much it will cost, and how much it will cost also from the point of view of what is the chance that developers who are struggling to do something, in the end will produce the good thing the first time, how long and how much money will the we work of OK, well, it doesn't work now, let's make it work, and of course it will, the internal experience will cause a very, very frequent turnover of personnel and how much time and money it will cost to onboard all the new people, how much knowledge is lost when the teams change so quickly, and at the end of That's what, that's the risk. Yes, I will give you an example, we are now building a house and it was supposed to be ready in March, but now we're in September, it's not ready yet. And it's not because they didn't know what to do in the first place, it's because the human power was not good, the human power changed, whoever came there no longer knew or knew less what to do, Then it changed again and those who came after them had no idea what we talked about with the first guys, etc., etc., and in the end it will be exactly the house we want, only it will take twice as much time and twice as much money, and it's exactly the same , it's exactly the same, if we have good people who are satisfied with their work, know what they do, know what needs to be done and their work satisfies them and it's fun for them and they can be productive, that way the final product will be on the market much faster and much cheaper, which is what matters us.

Yishai: And what do you see, again, hear from the development teams around you or feel through your customers and users, where are the biggest challenges in the developers' experience? In the experience of someone who is now building a product or specifically building products for developers? Where are the pains? Where are the areas that are the most...apart from bad managers who are themselves developers who were unfairly promoted and didn't want to be managers and all these challenges, where is the pain?

Baruch: Yes, there are many, but one that I think about a lot now is the so-called on my mind, call it developers in post DevOps world, what I mean is that it's okay, we had, we have DevOps a lot, a lot of improvement in how we are Writing software, this whole issue of observability, of microservices, of servers, of cloud, Kubernetes, Containers and what not, completely changed how the software is built. I would say, not necessarily written but built, everything related to after the code is committed or merged, looks completely different today than it did a decade ago. For the better. But it doesn't necessarily mean that the day-to-day or the connection of the regular developers, those who write code, to this whole revolution of DevOps, this connection is strong enough, it even happened, and I think one of the most prominent examples on this topic is incident management. Think about how today's incident management is much more complex on the one hand, and much more productive on the other in everything related to ops and DevOps. The whole issue of observability and post-mortems and self-healing and wherever you look, it's a well-oiled machine.  Crazy, monsters who do lots and lots of amazing things in this field, whoever is in incident management today is just like he was a decade ago, that's the key. Woke him up at 3 in the morning, told him “listen, we think we have a problem with the code”, as if we checked all the systems and the systems are fine but we think there is a problem with the code, good luck.

Yishai: Of course, I know, I wrote this bug last night, I know exactly what broke.

Baruch: Yes, exactly, and it hasn't changed and it amazes me and I think that this, this thing, together with, in general with the whole field of developer experience and here really the important word is developer, it's still there, it's still from a decade ago, the software has become to be very very complicated, the way the developer works has remained almost unchanged, I think the last amazing innovation we had in this area is git and Github if you will, and pull-request and nothing new since then has happened in the area of ​​development And it's amazing, especially when you look at this whole DevOps thing flying forward decades.

Yeshi: It's interesting because DevOps is indeed a huge influence of open source there, but DevOps was almost born to serve the business used case, those who activated and ran and built and use DevOps are first of all the businesses that wanted to improve or greatly improved their form of Building and deploying workloads, on the other hand, the second revolution which is about a similar age, which is git and Github and the world of pull requests was born from open source, it was born from how I do collaboration when there is no money and An organizing factor other than a desire to write something cool together, and pull requests were originally intended at least for people who don't get paid, certainly not from the same company. I wonder if this difference has any contribution to this result that it stopped quite early, the pull request looks exactly like it did in the big open source projects of the past and on the other hand DevOps is progressing like crazy - dozens of tools and wanderers and whatever you don't want.

Baruch: I think that today the pull request is very, very even in the business world, yes? Today also within the company,

Yishai: Everyone uses it, everyone is there, it wasn't built for that,

Baruch: Even if you have internal projects, they are not, right, the question is whether it really is, the fact that it doesn't come from there means that something is inevitably missing. I think the problem, this concept, the workflow built from pull requests is a very, very healthy work flow, yes? It gives us an opportunity to really isolate areas that are more risky to enter into some branches and makes other people want to look at it before they make a decision whether to enter it or not, which I think happened, and that's a reason why the pull request is like this now a bit A pain, or not a little, a pain, and not necessarily something we are happy to do, the fact that thanks to DevOps the software we build has become very, very complicated and complex and today pull requests are something that is almost impossible to assess with a human eye, we are now looking at changes and how much our ability Assessing how this change is going to affect very, very complicated systems is a limited ability, and the more complicated the software is, the less and less we feel that we can have an opinion on what we see in this pull request and I think the problem is, I don't see a solution for this at the moment, yes ? I don't see a solution where we say okay, we as humans can manage with software that is becoming more complex day by day, and pull request was really an answer to this problem at some point, but the complexity of the software is increasing, pull request is the same pull request, it is still expect the person or two people to get out of the context of what they are doing, enter into the context of what another person did and understand whether what they did was good or not, and I don't know if we can still do this.

Yishai: So you're actually describing a situation where the increasing complexity in the pull request eventually hides a context that is sometimes difficult to grasp and at least difficult to serve the original purpose of "Wahla I see and I can do some vetting which is a good change, on the other hand we see lots and lots of trivial, very small pull requests, which are basically a waste of a reviewer's cycle that needs, as you said, to get out of the context and even know that it is waiting for him and go do it, for something that is a no brainer and has no benefit to a person , beyond the fact that the tests pass and everything works, maybe it's just a change in the documentation, maybe it's white space, some extreme cases,

Baruch: But the problem is that we don't have a computerized way to differentiate between these two used cases.

Yishai: Yes, everything looks the same, everything gets the same treatment, and then this treatment on the one hand, voila, I get a large pull request, full of lines of code or complex and I say I have no chance, I'll just rubber stamp it, come on, it seems to me OK, there are no glaring flags, and on the other hand I also have to do a similar process for pull requests which are a waste of time.

Baruch: Me, I wish there was some kind of system that would help me with the context, yes? I think that's exactly the biggest problem, one of the things I'm excited about right now is really the innovations in this field, in this specific field, and I think that Linear-B, the company you work for, is trying to solve exactly this problem of how do we make it easier for the people who are still looking About these pull requests, and right now I don't think we have any better alternative than looking at pull requests, how can we get these people to better understand the complicated pull requests and give up or do some automatic process of acceptance for a more trivial pull request.

Yishai: Yes, it's not by chance that I'm talking about these issues, it's of course very interesting to us. You talked before about the DevOps world and you talked about the post DevOps world for developers, DevOps like this very roughly talks about machines and automated processes - I have CI, I have actions, I have scripts, I have Jenkins, there is no code , code out, the tests always go through the same thing, in all the companies I've ever seen, all the tests have always run the same way, or not, but by and large it's machines, it's code, and when you talk about this issue of the development process and the acceptance of code through pull request As you said there are people, I suddenly have to think about, not about how I sew machines but how I sew processes that are automatic to, and people. That the pull request was also affected by whether the person is currently tired, whether the person has already made 10 reviews today.

Baruch: True, did he eat.

Yishai: Is he not responding because he is on vacation, so something else needs to be done. There is, in my opinion, a somewhat (unclear) element here...

Baruch: It's still full, it's much less horrible, it's much less horrible than this semi-automatic acceptance or I don't have the strength, it looks fine, and actually there are horrible things in there that he didn't look at - because he was hungry.

Yishai: Also, I'm not sure we'll build sensors for hunger, but there's something special about the fact that you're driving people, you're scheduling or somehow doing this process, it's related to people and code, yes? The tests also have to pass, maybe the tests that pass are input to the reviewer, the fact that I have nothing to review before the tests pass, for example, and on the other hand I lead people, people are not the same, they are not always available, they have many things on their minds and the context switch, is expensive. So where I can lower the context switch or eliminate it, I gain disproportionately, it's not like a CPU context switch, we're not there yet.

Baruch: Exactly, and I think it's also what LinearB does that is very, very important, very, very expensive, and really, as I said, I'm looking forward to innovations there that can achieve SREs progress in this area of ​​DevOps also from the side of developers, and like that we talked at the beginning with Yishai, telling now how excellent and helpful Linear-B is will not help anyone because no one will listen to us, because we get money here instead, the only thing we can say is go look at it, if you feel that the problem we talked about is A real problem and the developers have somehow been left behind in terms of their user experience as part of this DevOps process, and if you agree with us that one of the problems is really that the pull requests are the same as they were a decade ago that the software we need to look at is several levels more complicated, you might find Something interesting there, stay tuned for what Friday is doing, what Linear-B is doing and also what I talk about a lot and maybe together we will find a solution that works for you in one way or another.

(transitional music)

Yishai: Towards the end, give me one piece of advice or one thought for those who want to become a developer advocate or advance in this field, what, one thing to pay attention to in order to succeed or to decide if it's for me or not, something you would have liked to have known a decade ago when you started.

Baruch: Yes, so I think that really what we talked about before, a person should ask himself whether working all day, day after day, with people, with the community, is something that does it to him, and here it is very, very simple, who does it He knows it and whoever doesn't do it knows it too and this is something that says yes or no whether a developer's field is your field. Very, very simple, very, very effective, and that's the only question that needs to be asked, everything else can be learned. Does it make you work every day with people, it's something you're born with and if you don't have it the suffering isn't worth it.

Yishai: Welcome, thank you very much, it was lovely and really interesting, I think that the issue of developer relations and developer advocacy has not yet completely become a commodity and many developers are thinking and asking themselves, wait, is this right for me? it interests me? I think this episode can be really helpful for them to understand that.

Baruch: I'm happy, thank you for hosting me and if anyone listening to this episode has questions, you can find me on Twitter, @jbaruch, I would be happy to answer, and if you are thinking about conversion, about this field of developer relations. Also, come and say hello, as I mentioned there are a lot of open positions that I would be happy to help those who are thinking about making it a real profession. Thank you.

Yishai: Great tip and help for our listeners, thank you.

(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:

• JFrog
• Artifactory
• Maven
• WeWork