Relicans host, Aaron Bassett, talks to open-source aficionado, technology advocate, co-lead of JHipster, creator of KDash and JDL Studio, and author, Deepu K Sasidharan, about what is developer experience and we we should care.
Should you find a burning need to share your thoughts or rants about the show, please spray them at email@example.com. While you're going to all the trouble of shipping us some bytes, please consider taking a moment to let us know what you'd like to hear on the show in the future. Despite the all-caps flaming you will receive in response, please know that we are sincerely interested in your feedback; we aim to appease. Follow us on the Twitters: @PolyglotShow.
Jonan Scheffler: Hello and welcome to Polyglot, proudly brought to you by New Relic's developer relations team, The Relicans. Polyglot is about software design. It's about looking beyond languages to the patterns and methods that we as developers use to do our best work. You can join us every week to hear from developers who have stories to share about what has worked for them and may have some opinions about how best to write quality software. We may not always agree, but we are certainly going to have fun, and we will always do our best to level up together. You can find the show notes for this episode and all of The Relicans podcasts on developer.newrelic.com/podcasts. Thank you so much for joining us. Enjoy the show.
Aaron Bassett: Hey, everybody. Welcome to another edition of the Polyglot Podcast. I'm Aaron Bassett. I'm a Principal Developer Relations Engineer here at New Relic. And I am joined today by Deepu, who is...well, there are a lot of things [chuckles] that they're doing. They're an open-source aficionado. They're a technology advocate. They're a co-lead of JHipster. They're the creator of KDash. They're the creator of JDL Studio. They are an author of Full Stack Development with JHipster. Yeah, I'm running out of breath just trying to list it all. But rather than me giving a full introduction, Deepu, tell people a little bit about yourself.
Deepu K Sasidharan: [chuckles] Hey, Aaron. Yeah, thanks for the great introduction. I think you pretty much covered everything. Basically, I'm a developer at heart. So I'm a polyglot developer now. I started off as a Java developer, but then I think after 13 years with that, I started moving on to new things. And now I like all languages and stuff. So yeah, basically a developer at heart, and I like to do all this community stuff, of course.
Aaron: There's still something to be said for your first love, though really when it comes to programming languages sometimes. Would you still say that Java has got your heart or?
Deepu: Yeah, it's kind of like that. Java helped me make a career, so I do have a soft spot for that. I cannot honestly say it's my favorite language now because that would be Rust. I think it's pretty hard to like something else once you have fallen into the Rust rabbit hole. I have heard about that before. But I experienced it; then I realized, oh, okay, this is what's happening with other people. Because I read someone posting on Twitter that once you go into the Rust rabbit hole, you cannot come out of it, and it's apparently true. [laughs]
Aaron: That's funny that you say that. The last interview I did on the Polyglot Podcast was with another developer who was in the middle of transitioning from Python to Rust. Is Rust eating the world? Is that what is happening? Am I behind the curve here?
Aaron: Should the next book I pick up be a Rust book? What's going on?
Deepu: I don't know, but yeah. I think personally, for me, it's the inner nerd. Having worked with multiple languages, having been a developer for 10+ years, I think you start getting certain perspectives. You stop getting too attached to certain things that you might have been attached to in the past. For example, all those framework wars and shouting about hey, this is great. This is great and stuff like that. I think you can relate to me on that. After certain years, you don't care about those kinds of things that much. But once I started doing Rust, it was like, ooh, damn, this is good. It's so much fun, actually. I think that's the best thing.
I would still not use Rust for...say, for example, if I'm to start a company tomorrow, which is building a web application or some sort of microservice or whatever, something as a service, I would still probably build it with Java because the ecosystem is so stable there. So if I'm a capitalist and I want to make money out of my thing and be stable and everything, I would still build it in Java because Rust is quite immature in that aspect. The ecosystem is booming, but it's quite new. So it's not as stable as Java or anything.
But if I have to just nerd out and just have fun, then I think it's hard to beat, at least personally. I'm pretty sure this is going to be different for different people. But personally, I had so much fun in Rust, which I didn't have in a long time. It's been a while since I woke up early in the morning. I'm a late sleeper, and I wake up really late as well. But when I was building KDash, I would wake up in the morning, like 6:30 or 7:00. I will just wake up, and I'm like, okay, there’s something in my mind. I need to go and code. I didn't have that for a long while. So that's the fun part.
Aaron: Yeah, and I guess when you were talking about having to think about starting your own business, and what you would do there, there's definitely an ecosystem as well. The community, how difficult is it going to be able to find developers? That kind of idea as well. You can't just look at oh, this is a language that I like the most. This is the one I enjoy coding or developing in the most. It's like, okay, well, which one can I hire people? Which one, as you said, is stable? Which one has a big ecosystem of packages that I can pull from? There are all of these kinds of considerations as well. So that's interesting that you have those multiple considerations that would factor in before you go; okay, I'm starting this new project in this language. So also the language stuff then, I really want to talk to you a little about the JHipster. Could you give me just a little overview of what JHipster is then? I know it's not Rust. But beyond that, what is JHipster?
Deepu: I would love to rewrite JHipster in Rust though, but I don't think the community would agree. [laughs]
Deepu: Anyway, so JHipster is a rapid application development platform. That's what it is. It's a development platform. It started out as a scaffolder, a simple scaffolder built using Yeoman, but it has grown humongously. So it started as a Java AngularJS scaffolder. But now it can do Java, Node.js, C#, a lot of other things, and multiple things on the front end like React, Angular, Vue, and all those things. So it's a full-fledged rapid application development platform. So basically, you can get...I don't like to use this word enterprise-grade but that kind of production-grade, but let's say production-grade applications in under 30 minutes.
And so you get all the skeleton, not like a skeleton that you have to fix or anything. You can create something using JHipster in under 30 minutes, and you can actually deploy that to production. It would have everything working like authentication, user management, your CRUD part, all those things perfectly working. And then the only thing you would have to do is code in your business logic, your UI stuff like rebuild the UI however you see fit and do your business logic. Everything else is there. So basically, the blue is there, so that's what JHipster does.
And we started off doing web applications, Java applications, but we have grown way past that. Now you can do complex microservices. One of the demos that I normally would do in conferences it's kind of a thing that you can wow people with. It's like build a really complex microservice, like three, four microservices, a gateway, a registry, a full-fledged monitoring, and everything, and deploy that to Kubernetes in like 30 minutes. Create and deploy in Kubernetes in 30 minutes, and then you can start using it like an e-commerce website.
I can build a fully functional e-commerce website in under one hour in JHipster with payment and everything there. I have done that, actually. I have done that and uploaded that as part of a blog post. Of course, I used my current employer to do the payment part, so it was done for that purpose actually, like to demonstrate that. But I used JHipster to build that, and it took me less than an hour to model it out. Actually, modeling the schema took the most time, and then it's just firing up a command. It generates everything, redo a little bit of the UI part, like add a screen for the shopping cart. And that's it; I’m, done. I have a fully functional e-commerce microservice. So yeah, that's the power of JHipster.
I don't think a lot of people realize that unless they actually try it out and see that okay, it can save you so much time in terms of all the blue coding that you will do. It's like repetitive coding. For any greenfield projects especially, you would have to do a lot of repetitive blue coding, so it saves you from that. Of course, it's not going to help you write your business logic. You have to do that.
Aaron: [laughs] For that you need a GitHub Copilot.
Deepu: [laughs] Yeah. JHipster and Copilot, you can probably do everything without having to do anything else.
Aaron: Yeah, I'm just looking at the different options there are for JHipster. And honestly, I'm just having a lot of fun just reading through this. There are things that I have no idea what they are [laughter]
Deepu: Yeah, I don't know as well for some of their items. [laughs]
Aaron: I used to work at MongoDB, so obviously, I recognize MongoDB, but then there is Mongock which I had to go look up. And I'd never even heard of that one for managing version control. Different schemas in MongoDB. Weird and wonderful names of some of these products as well; it’s great. Caffeine, what does Caffeine do? [laughter]
Deepu: Honestly, from the time that...so I think I have been working with JHipster for six years now. They have been co-leading it for maybe four or five years maybe. I lost track of time. But now, the community has grown so much that I cannot even keep track of what's happening. I think it's pretty much the same for most of the core contributors and the other leads. People are coming up with stuff, adding stuff, changing stuff. So sometimes I look at it, and I'm like, hey, what's that? It wasn't here a week ago. What is this new option? So yeah, I think we are now at a point of option overload.
So we are even discussing we need to cut back on options. We support too much stuff, and it becomes very difficult to maintain. For example, there is Couchbase. Somebody really convinced us to add Couchbase, and the person added it, and then the person just disappeared. So now there is nobody to maintain that, so we also have those kinds of issues. But the most of used stuff is extremely solid, like Cassandra, for example. We were the first of these kinds of platforms to actually support Cassandra as a database.
And back then, even Spring or any of those wrappers didn't support Cassandra. And we ended up writing our own layers for that, and which I think then some of it went back to Spring. So those kinds of things work really well. And of course, there are options like Mongock and Caffeine, some of it which even I'm not familiar with because I don't use those that much. But yeah, it's insane the options they have. I'm pretty sure Caffeine is a cache.
Aaron: Yeah, that makes sense. It is something that a lot of people don't appreciate sometimes is whenever you do run an open-source project, we refer to them as drive-by PRs. Somebody comes, they drop a big PR for a new feature or something that's not being discussed. They've gone, and they've put in a lot of work, and they've written a lot of code. And then this PR disappears, and there's been no prior discussion about whether you even want this feature added to it. And then you feel bad rejecting it because they have put a lot of work into it. Well, why would you turn it away? Why wouldn't you take this person's work? And it's like, well, because you have to maintain it after that point.
Deepu: Yeah, exactly.
Aaron: Yeah, they put a lot of work into it, but there's a lot of work still that has to happen and continue to happen to maintain that code once it's added to the codebase. And you do feel like a jerk turning those away and being like, "I'm really sorry. We can't merge this at this time. Please open an enhancement proposal, and we'll consider it." And so I'm also on the board of the Django Software Foundation, and the technical board gets a lot of these kinds of things coming through, so we're aware of them as well. So yeah, it's a pretty thankless job sometimes being a maintainer for an open-source project. So kudos to you for running such a large one as well.
Deepu: Yeah, I think open-source maintainers are one of the least appreciated folks. And most of the time, people just take them for granted. Most of these things we do in our free time. It's not like we get paid to do any of this. We do this in our free time for the passion of technology and stuff like that. And still, there were so many instances where people are writing issues and cursing us and stuff like that. They would ask for a feature, and we'll be like, "Sorry, we can't do that," then they'll go on cursing us and stuff like that. And sometimes, what annoys me most is some people just come in and demand stuff as if they have paid us to do this or something like that. They just demand stuff. [laughs] Yeah, it would be nice to get more thanks for what we do.
Aaron: Yeah. We've had death threats and just horrendous things coming through emails. And it's like, folks, this is not some big, faceless corporation that you're writing to here. There are six volunteers that run the Django Software Foundation. [laughter] We meet up once a month to discuss topics around supporting the rest of the foundation. It's not a big group. Just because Django is a pretty well-known framework, et cetera, don't think that there's some huge body behind it; it’s not. It's just regular volunteers. And we read your emails, and they're horrid. And you just have to move past it, and you get on, and you do it.
Deepu: Yeah, exactly.
Aaron: It is a pretty thankless job. We do it, though, because we have a love of the community. And it's gotten both of us where we are today and allows us to do the work that we do. And yeah, I shouldn't say that all the community is bad. I wouldn't be part of the Django community if it was all as bad as the vocal minority are. And they are a minority, which is a thing we try to keep in mind as well. So along with the JHipster, it is a big project. I've seen there are JHipster conferences. You have a JHipster book that I think is now on the second edition. Is that right?
Aaron: So it takes up, I'm assuming, a lot of your time, but you're also in developer advocacy. You're in developer relations same as I am. And you recently wrote a post on Dev.to about What Is Developer Experience, and Why Should We Care? So can you give us a synopsis of that article then?
Deepu: Yeah, sure. I have to mention that the community around JHipster, especially the core team members, are awesome. They are awesome. So I used to spend most of my time on it, but once we set up that community and once we had the community going with the core team and everything, things started becoming easier. Nowadays, I don't spend that much time as I used to because there are a lot of people to work on stuff, so it's great. So I have to thank them for that.
Aaron: [laughs] Yeah.
Deepu: For the developer experience part, yeah, I mean, I think it's a very underappreciated area. It kind of reminds me of 10, 15 years ago how user experience used to be. Nobody used to care about user experience. Some people knew about that. Some bigger companies did something around it. But most other companies didn't care about that. They just build something, put it out there; if it works, it works. Nobody cared about how the user felt or what the experience was. But it changed. I'm pretty sure maybe 15 years ago, or even ten years ago when I was working as a consultant, user experience was not something that you would come across. You wouldn't come across user experience engineers or UX designers. It's very rare to see them. Even companies having that as a department was a minority.
Aaron: Yeah, it typically fell under your front end and your client's-side developer or your designer. They were also supposed to do all your...it was always combined if they even identified UX as being a separate skill. It was always you'd be hiring a UI and UX designer. There was never a separate role just for UI.
Deepu: And in most companies, they don't even do that. The front-end developers just build whatever they like. There isn't much thought into how the UX should be or anything. They just build something that does the functionality. I was a consultant and building these kinds of things, and most of the stuff was really bad user experience because there was nobody designing user experience, just developers making a mock-up, somebody approves it. "It looks good. Okay, fine. Okay, go ahead with it." But then things changed, and people started realizing the importance of it. Now it's unavoidable. Now, if you say, "Hey, I'm going to build a product without UX,” people will laugh at you, right?
Aaron: Yeah. [laughs]
Deepu: That is where the developer experience is going as well. It is underappreciated, and people don't recognize the importance of that, especially since the trend is changing. I think you are in the same role. So you also know the importance of this. Maybe 5, 10 years ago, developers didn't have as much influence as they have now over product decisions or acquiring decisions and stuff like that. I was a consultant working for a major airline and stuff like that. So I have seen decisions being made by management then forced down to developers.
I think ten years ago; developers wouldn't complain that much. But I think now, especially in the West, I think, especially in the West, I think developers have a huge voice now. I have been in situations where I have seen deals falling through just because developers didn't like a product or they didn't agree to a particular product. I have seen that in big companies happening even in enterprise companies this happening that everyone agreed to the product, sales cycles and everything went well. They convinced the management or VP of engineering or whatever to buy the product. But even after signing the product, once the implementation started, the developers were like, "Yeah, we hate this. We don't want this." And then the deal fell through. So I think that is happening more and more, and people are realizing the influence that developers have especially if you're selling a technical product, because they are your primary audience.
So developer experience becomes akin to user experience. So if you're not keeping your primary audience, which is developers if you're not keeping them happy, then, of course, they are not going to recommend you, or they are probably even going to oppose using the product. And if most of the developers start opposing using the product, then the company doesn't have any other way but to replace it or something. I mean, we have done it in my previous company. We didn't like a particular product that was being used, like, let's say, a chat application. [laughs] We didn't like it. We opposed it. The management bought it. We didn't like it. We kept opposing it, and then they had to change it because most of us are unhappy with it. They had to switch to another product. So I'm pretty sure you would have come across these kinds of stories all the time.
Aaron: Oh yeah.
Deepu: I think companies are slowly realizing that.
Aaron: Yeah, and it can be very much developer-led as well. And now we have these consumption-based models for a lot of what we use. I remember the days when if you wanted to change your provider, it was a considerable investment because a lot of times it was like, oh, we're actually going to put some metal into a server farm somewhere that is going to run whatever it is you need it to run. Whereas now it's like, okay, well, I don't need to make this big upfront investment. It's all consumption-based. I, as a developer, can sign up with my company card. And I probably don't even need to go fill a purchase order or anything like that because it's going to be under 50 bucks a month while I try it out.
And once it starts to get to the point where you're like, okay, well, now we need to look at service agreements and purchase orders and stuff like that, well, your developers are already bought in, and they're like, "We're using this service. We just want more features," or "We want more bandwidth," or "We want more...," whatever. "Here's what you need to pay for it." It's like, well, it's already integrated into all of our systems. Now it's just a money decision. But yeah, I think that's been a big part of it as well, where developers can get started themselves without ever having to talk to senior management about it.
Deepu: Yeah, true. And I think going forward in the future; I think developer experience is going to be bigger and bigger. And I'm pretty sure at some point it would be almost on par with how user experience is treated these days because every company is building developer relationships these days because I think they are realizing the importance of keeping the developer audience who's using their product happy. And I really believe that developer experience is a big part of advocacy because if your product is not nice to use, if you don't have a good experience using the product, regardless of how much advocacy you do, how much content you create, it's still going to be annoying for the developers, and it's not going to have that much of an impact. I hope that it becomes as important as the user experience. [laughs]
Aaron: I used to work for a company that actually changed their developer relations. It wasn't even called developer relations anymore. They did away with that department entirely, and it was changed to platform and developer experience, and part of that was developer relations. They saw that you need to have this entire wide-ranging approach to your whole developer experience. And yes, having advocates there, people who can go out into the community and speak to your developers and garner feedback, et cetera, is important. As you said, it's only a tiny bit now of the full range of the developer experience. So, how do you think that that's going to change things then for people like us?
Deepu: Yeah, I think it's good for us because I think half of what we do is also developer experience. We are managing the expectations of the developer audience. I mean, of course, we do also the part around content creation or advocacy and evangelism and these kinds of things. But I think knowingly or unknowingly; we are also doing a lot of developer experience things. Because whenever we are gathering feedback and getting it back to our product teams and trying to improve something, we are improving the developer experience because it is based on developer feedback. So we are working on that.
So I think as a role, I think it's good that developer experience the importance becomes more and more realized so that there are more advocates working on improving that stuff. And I think it also helps us to have wider teams. For example, I know that there are certain companies where developer relationship is entirely focused on just advocacy. So hopefully, that would become a bit more of teams where there are advocates, there are developer experience engineers, so you have a tighter integration between your feedback cycle. So you don't have to always fight with the product all the time. Certain things your team can just improve like improving APIs, for example, or standardizing APIs, and these kinds of things. These could be things that can be driven by developer experience teams.
I think one of the problems probably you also face when you have a developer advocacy team and a product team is prioritization. You identify certain issues that impact developer experience because you want your developers to use your product in a nicer way. So you identify this, and you try to bring it back to product. And there is always the prioritization conflict. They also have their hands full with other stuff. There are features that need to go out and things that you bring that don't look like a bug. Okay, it works as expected, but it would be nicer to work this way. So it becomes nice to have these kinds of things. So there is always that conflict, and we always spend time, and then there are compromises.
So imagine if this becomes a standard that okay, there are developer experience teams, which includes advocacy. There are engineers who would work on these kinds of stuff so that you don't have to bother product that much unless it's a big change that needs coordination and stuff. So I personally think that it becomes easier. It's also slightly the way that we work at Adyen. So we have a developer experience team. So we have advocates, we have engineers, front-end engineers, back-end engineers working on improving products. We have people working on standardizing API specs and stuff like that. So I think that the model is good. So I think it brings more diversity in what we do.
Aaron: So this is one of the big questions then. It comes up all the time in developer relations, which is, where should that org live then? Is that under product? Is it under engineering? Is it under marketing? Is it its own top-level org? Where do you think this sits?
Deepu: Definitely not under marketing; I would run away [laughter] if it's under marketing. Because I think traditional marketing also has never really worked with developers because traditional marketing also heavily relies on a lot of buzzwords and using fancy terms and sugarcoating and stuff. And developers see right through most of it. And it has personally never worked for me when I see traditional marketing. So I would assume that it hasn't worked that well. That's why people started creating developer advocacy teams rather than evangelism teams. So definitely not under marketing because there is going to be a lot of conflicts of interest if it is under marketing.
Product sounds like a good idea because then you get to have some say in the product roadmap, I would assume. So it sounds like a good idea. But then, to me personally, the differences between engineering and product is kind of murky depending on the company and stuff, right?
Aaron: [laughs] Yeah.
Deepu: Some companies don't even have a separate product org; they have engineering. Product is under engineering, so it would make sense for advocacy or develop experience and developer relationship, in general, to be under that as well, but anything other than marketing, I would say. [laughter]
Aaron: I've worked in teams that developer relations teams have sat under all of those different ones. And yeah, it definitely impacts the approach about how they tackle developer relations. Being under product, especially what you're saying with having this kind of developer experience, seems like it would be a logical place so you can feed into that product life cycle.
Deepu: Exactly. Yeah, no offense to marketing.
Aaron: No, of course not. [laughter]
Deepu: Because that also works. You also need that top-down approach. But what we are trying to do with advocacy is we are going bottom-up. So if you have a great top-down approach with your normal sales cycles and marketing, and a great bottom-up approach with advocacy and developer experience, then you are setting it up for better success. Yeah, you need to have both.
Aaron: One of the best campaigns I ever run was at a company where we did a joint campaign between developer relations and marketing where we would do webinars, one on a Monday, one on a Wednesday. And the one on Monday would be...both are the same product, but the Monday one would be aimed towards the business decision-maker. So that was your more traditional marketing, and we'd go out to them. And at the Monday one, we would be like, "Hey, we're going to do a technical webinar about this on Wednesday." So then you would have them see the benefits of the product. And then they would go to the developers and go, "Hey, watch this stream on a Wednesday and tell us what you think of this product."
And on the Wednesday one, there would be no marketing. It would just be like, here's how I implement the products in some code. I'm going to add it to Django, or I'm going to add it to Flask, or I'm going to do it in Express or whatever else. You might do it in some framework. Show the actual code to get the product running. And that would be the Wednesday one. And that was a nice combination of developer relations and marketing, each bringing their own strengths and their own ways of approaching that kind of funnel. So yeah, we're not beating down on marketing.
Deepu: [chuckles] No.
Aaron: There's definitely a use for both. So if you were joining a new company and they didn't have a developer experience or a developer relations team in place, what would be your priorities then? They've not done anything around this before previously. What would you go okay, this is the first thing we have to do?
Deepu: Of course, it depends on what kind of product your company sells. If the company is selling products that are used by developers like an IDE or something, or if it's a service that developers integrate into their product like my current company, I think it is important to have developer experience and developer relationships.
I would say a company that is building services that other developers use to build their own stuff. I think for these kinds of companies, developer experience matters way more than advocacy, to begin with, I would say because you have to build that portal. If the experience of building an integration to your product sucks and you focus fully on content creation and brand building and all the community building, then it's not going to have a good impact. It's not going to have the full potential of the effort that you're putting in in that aspect. So I think in those kinds of cases, I would probably concentrate on building developer experience first, and that you can even do if there are no specific developer relationship teams.
You just start to identify hey; these are the...you know, be a customer zero and try things out and be like, hey, you're a developer. So what are the things that annoy you? Get some of the developers who are building the stuff on board, ask them to, hey, try this out. What annoys you? See, these things annoy you. And of course, these are working as expected, but it annoys you. You have to jump through hoops to make it work. It's not a good experience. If someone goes through that experience using the product, why would they like it, or why would they spend their effort recommending that to someone or something? So if they get a chance, they might ditch you, and the next company they go, if there is an opportunity to use this product, they will say, "Yeah, I didn't have a good experience with that." So that's not good marketing for you.
Aaron: Yeah, you only ever get one chance to make a first impression.
Deepu: Exactly. Exactly. So I think I would concentrate on convincing the teams, the development teams. If there is no separate developer experience or relationship team, I'll try to convince the development team to put more focus on developer experience and especially when you're building out something new, or if you have a chance to refactor stuff that is already there, maybe, then yeah, take that opportunity to improve it a little bit. You don't have to go full-fledged, changing everything but step by step, baby steps, maybe standardize things. Use a standardized error schema, for example, on your APIs or standardize your APIs so that similar-looking things behave similarly and have a similar schema. So it's easy to follow standards. It's easy to do.
Follow industry standards. Don't try to go over smart and try to do your own thing. Fine, it's okay to be smart, but you don't have to show that in the things that you build so that it makes others' lives difficult. Nobody wants to learn a new thing to integrate into something. If it works as expected, like an industry standard, then they'll be much happier. And they'll be happier that they can finish that integration faster and use the remaining time for something else. So why would you make someone's life harder? If you make it easier, they'll advocate on behalf of you. They'll tell their friends, "Hey, this is a great product. It was so easy to integrate." I think the best product integration experience is that if you can just do it in an hour or two, you didn't have any trouble. You didn't have to think about it. You didn't have to learn it. If you don't have to learn something, then that's the best experience.
Aaron: If I can use your API and guess at what the different method names are going to be like, if I can just be like, oh, okay, well, so that one was get streams so I'm thinking this one might be get clips or this one might be get users, or it follows some kind of convention, and I don't need to go look at your docs. I can just go yeah, if my gut is telling me it should be this, if my gut is right nine times out of ten, it's the right API, that's a great API. I don't mind if every now and again I look up the docs, but I am definitely at let's just try it and see. And if your API is intuitive enough that that try it and see approach works majority of the time, yeah, I'm going to love your products. [laughs] As long as whenever that 1 out of 10 times where it doesn't work, your docs should be pretty good as to why it doesn't work just to get me up to running again.
Aaron: But beyond that, yeah, most of the time, discoverability beats out docs.
Deepu: Exactly. Exactly.
Aaron: Discoverability beats out docs most of the time for me anyway. I know different people have different approaches, different ways of learning. That's my particular kind of style.
Deepu: A happy developer is one who doesn't have to leave his or her IDE. If you can do everything within your IDE without having to look up something, that's the best case. And of course, I guess stability; I think it's a highly underappreciated thing in API design, especially. It has to be guessable; if you can guess it, great. That's why I hate when I try out a new language, and they do certain things which are done in a certain way in most of the languages differently. And that really pisses me off because why did you have to do that? Why did you do that? Why don't you just follow what everyone else does? Why did you have to go change the way certain things work? Like, why? [laughs]
Deepu: Yeah, I can imagine. [laughs]
Aaron: Yeah, not having the feature…I know a lot of people complained that Python didn't have a switch statement. Honestly, when it comes to these kinds of things, whether it be an API or a language, I'd rather not have a feature than have something that is easily confused.
Aaron: It's going to add to that cognitive load for any new person coming into Python.
Deepu: Exactly. People don't consider that the cognitive load. The load that it takes to relearn stuff it's not easy for everyone. I mean, for some people, it might be easy just to relearn things and get readjusted, the muscle memories and all those things, but it's not easy for everyone. Yeah, I don't think those kinds of things are considered. If everyone considers these kinds of things when things are designed, I think it would be much, much better cases.
Aaron: And we wouldn't have so many problems with context switching as well. That is such a difficult thing, which a lot of developers come up against these days. We're on the Polyglot Podcast. [laughter] A lot of developers are polyglots. They are going to be learning multiple different languages, multiple different frameworks, and having these minor variations where something could be standardized, as you said, just adds to that difficulty in context switching.
Deepu: But I think especially in this age and era, I think it's quite hard to not be Polyglot because it's much more demanding. Look at the requirements for a full-stack developer. Imagine having that job requirement ten years ago; people would laugh at that. "Look at that. Are you trying to hire ten people?" But nowadays, it's so common to see a job requirement where you have to know three, four languages. DevOps, you have to learn three cloud providers and like 100 other frameworks. That's becoming so common. So being polyglot is becoming so common. And I think career-wise always for most people I think it also makes sense to be Polyglot because nowadays, you can't just trust one language to be around forever, giving you a stable job and everything. It's changing.
Aaron: Unless you're one of those developers who only does Fortran, and they're just right there supporting legacy systems. And that's it, and that's all they do. [laughter]
Deepu: And getting paid insanely for being the handful of people who can do Fortran. [laughter] Yeah, that's another option.
Aaron: The only exceptions I know.
Deepu: But I don't think you can do that with Java, for example.
Aaron: No. [laughter]
Aaron: Yeah. If it does get to those days where Python is that obscure, then yeah, as somebody who's very deep in the Python ecosystem and is hopefully helping to promote it, I've done something very, very badly wrong.
But yeah, we are coming up on time, unfortunately. I just wanted to give you a little bit of time. I did mention some of the things at the start that you're involved with. Obviously, we've talked a little about JHipster. We talked a little bit about your book. But I wanted to give you a few minutes at the end just really to give a shout-out. Is there anything in particular, other projects you're working on that you're looking for people to help out with, or you just want to promote?
So I actually started building this project called KDash. I started it as a clone of K9s. I think you probably are familiar with K9s. I got inspired by that, and I was like, okay, what if I can do the same in Rust and try to make it faster and slightly, a personal preference, slightly different UI. So that's how I started KDash. So it's a terminal dashboard for Kubernetes. So it's completely done in Rust. So it was my learning opportunity for Rust, and it went quite well, I would say, because it was complex enough to learn a lot of aspects of Rust. And it wasn't too over complex, so that it would be a barrier to learn from.
Aaron: It had a kind of finite amount of work that needed to be done. It couldn't just keep growing and growing and growing.
Deepu: Exactly. So, yeah, that's something that I've been working on, and I made a stable release a month ago or something. So it would be nice to get more contributors there. So it's having some pretty good what do you call it? In terms of GitHub stars and stuff. It's having a pretty good going, but I would be really happy to have more hands-on-deck, especially people who are trying to learn Rust or trying to get into the DevOps tooling. Because I really believe Rust is perfectly suited for Kubernetes tooling way better than Go.
Go is good but if I have to write something on Kubernetes, I would 100% go with Rust rather than Go because of the insane benefits that you get there, especially in Kubernetes. If you want to run sidecars and stuff, I think Rust should be the number one choice. You don't have any disadvantages that you will get with C++ kind of thing. And you'll get all the advantages as well. So why wouldn't you? You don't have any runtime. Go is light, but you still have the overhead of having to run GC and stuff like that. But with Rust, I think it's going to be suited for running sidecar kind of things on Kubernetes or running tooling for DevOps and tooling in general. It's going to be great. So if anybody is willing to try it out and give feedback, that's welcome. If you want to learn, so please come join me. It's on GitHub.
Aaron: You've got issues marked up on GitHub as well as good first issues, so that's great for anybody who's just looking to get started and contributing to open source. I love to see projects that have those kinds of things marked up. And then it's KDash on GitHub. And people can find the links on your personal site as well, I'm assuming.
Aaron: And that's at deepu.tech.
Aaron: Great. We'll make sure that these kinds of links and stuff are all in the description for the podcast as well for anybody who's listening along.
Deepu: Awesome. Thank you.
Aaron: So please do go check those out. Links to JHipster and KDash, et cetera are all on there as well as your book and links to your Dev.to posts and stuff. There is a lot of great information, a lot of fantastic projects for people to go check out on your site. I know I came across a lot of stuff I hadn't seen before. I have to admit I'm not in the Java ecosystem. So looking into JHipster ahead of this interview was actually really enlightening for me, discovering a lot of the tooling I hadn't seen before. And so, yeah, even if you're listening to this podcast and you're not in the Java ecosystem, I still highly recommend going and checking JHipster out. It is very interesting tech. And yeah, great project, so well done, you. A lot of kudos.
Aaron: Yeah, I guess even looking at how to set things up would be...if you're not very familiar with those ecosystems or deployments or setting up the services, looking at how he does it is a great way to learn. But yeah, we are out of time, unfortunately. It's been a great conversation. Thank you so much for joining us, Deepu. I've learned so much during our very brief conversation here. And I have a lot of stuff myself to go and check out, especially since everybody keeps recommending Rust to me. So maybe KDash is how I finally get into it. [laughs]
Deepu: That would be awesome. You are in the DevOps space as well with New Relic, so that would be awesome to have another veteran's eyes on it, and yeah, that would be great, actually.
Aaron: Yeah, rather than just giving you a drive-by PR on the JHipster to add New Relic. [laughter] Hopefully, it will be different. Well, thanks, everybody, for joining us. It has been a great conversation. I really enjoyed it. And I will see everybody the next time I'm hosting. Please enjoy the rest of the Polyglot Podcasts. Also, don't forget to check out our other podcasts. They're all available at developer.newrelic.com/podcasts.
Deepu: Thanks for having me.
Aaron: It's been a pleasure.
Jonan: Thank you so much for joining us. We really appreciate it. You can find the show notes for this episode along with all of the rest of The Relicans podcasts on therelicans.com. In fact, most anything The Relicans get up to online will be on that site. We'll see you next week. Take care.