#63 - Being an Effective Generalist & Building Good Developer Experience - Deepu K Sasidharan

[00:01:03] Episode Introduction

[00:01:03] Henry Suryawirawan: Hello, everyone. I hope you’re doing great today. It is really my pleasure to be back here again with another new episode of the Tech Lead Journal podcast. Thank you for taking your time tuning in and listening to this episode. If this is your first time listening to Tech Lead Journal, don’t forget to subscribe and follow this show on your podcast app, and also the social media on LinkedIn, Twitter, and Instagram. And if you’ve been listening and enjoying this podcast and love the type of content that I’m producing, will you support the show by subscribing as a patron at techleadjournal.dev/patron, and support me in my journey to produce great episode every week.

Every now and then in the tech industry, we often hear about the debate between becoming a polyglot developer versus a specialist developer or technologist. And this kind of debate sometimes becomes a source of confusion, especially for people who are about to or just starting out in the tech industry. When I started my career back then, it was also a similar problem. Although the technology choices and languages were much lesser back then. My guest for today’s episode is Deepu Sasidharan. Deepu is a polyglot developer and a Senior Developer Advocate for DevOps at Okta. I’m inviting Deepu to hear some perspectives from a polygot developer and someone who has successfully done it for quite some time.

In this episode, Deepu shared why he consciously becomes a polyglot and generalist developer. He emphasized the importance of knowing more than one thing, be it programming languages, frameworks, or tech stacks in the current rapidly changing technology industry, when every week or month new things are being invented and thus more things for us to learn. Deepu also gave practical tips for new engineers who are starting out their career, and shared his technique to learn new stuffs, including new programming languages by building personal indexes. I’m sure this technique may resonate with a lot of us, and it is an effective technique that I frequently use for myself.

Our conversation then moved on to discuss about the current interview practices trend, and why Deepu thinks it is broken and needs to change, especially to make it more inclusive and less biased. Towards the end, Deepu shared about developer experience, a topic that he’s highly passionate about, on why it is now becoming more important to have a good developer experience, and he shared some golden tips on how we can build a good developer experience.

I enjoyed my conversation with Deepu, learning his perspective on being a polyglot and generalist developer, and his insightful tips for building a good developer experience. And if you also like this episode, please leave a rating and review on your podcast app, and share some comments on the social media on what you enjoy from this episode. Your reviews and comments are one of the best ways to help me spread this podcast to more people. And it is my hope that they can also benefit from all the contents in this podcast. So let’s get our episode started right after our sponsor message.

[00:04:46] Introduction

[00:04:46] Henry Suryawirawan: Hey, everyone. Welcome back to another new episode of the Tech Lead Journal. Today I have with me a guest named Deepu Sasidharan. He’s actually a Developer Advocate at Okta. Okta is like a product for security, single sign-on, and things like that. Today Deepu has gladly joined this podcast to share his experience. So we’ll be talking a lot about developer experience, developer advocacy, and a few things about him personally as well. For example, being polyglot developers and things like that. So welcome to the show, Deepu, looking forward for this conversation.

[00:05:16] Deepu Sasidharan: Yeah. Hey thank you, Henry. Thank you for the introduction. Happy and glad to be here.

[00:05:21] Career Journey

[00:05:21] Henry Suryawirawan: So Deepu, maybe in the beginning for people who don’t know you yet, can you introduce yourself? Maybe sharing about your highlights or turning points in your career.

[00:05:29] Deepu Sasidharan: Yeah, sure. I think I had a pretty interesting career path. Non-standard, I would say. Probably not that much. These days I’m meeting a lot of people who had similar paths as well. But at least I thought it was non-standard. Because I started out as an electrical and electronics engineer, that’s what I studied in college. I was quite fascinated with robotics, and I really wanted to become a robotics engineer or an astronomer. This is the path that I saw for myself, when I was in high school or when I was in college. So I was like, okay, either astrophysics, astronomy, or robotics. But yeah, it seems like the universe had different plans for me.

I think back in India when I was finishing my college, it was also the time of the recession. I think the 2008 recession. So jobs were not that many to be found. Especially in robotics, that was becoming impossible to find at that point. So I was like, okay, I need to pay the bills, student loans to be repaid. Okay. I need a job. Seems like IT companies are still hiring a lot, so why not I just give it a try? I think Tata Consultancy was one of the humongous IT companies in India, which hires like in hundreds of thousands every year. So they were hiring in my college and I was like, okay, I’m going to give this a shot. So I tried and somehow I did it. I was surprised. I don’t know anything about programming, unless you count a little bit of Flash and ActionScript that I have done in order to create some 3D stuff for random things.

I started, actually started learning programming at their training. They had like a six months boot camp kind of thing. So I started learning Dr Scheme. That was a programming language that I actually seriously started to learn. I did some C++ before that. I learned a little bit of C++ but that was mostly to help my girlfriend back then. So I wasn’t actually interested in learning that. I actually started paying attention when they were teaching Dr Scheme. And I figured, Hey, seems like I’m good at programming. So I was like, okay, this could be an interesting career, and then I started working on Java projects. That was my first standard language that I started to work with. Yeah. I started enjoying programming as well, so I thought, okay, this is not bad. This is nice. I quite enjoy programming, and I like the challenges there. I like the technology stuff. So, I’ve made a career out of that.

I also worked in Singapore for five years. I know that you live in Singapore, so that was quite nice. It was again with Tata Consultancy. Then I moved to the Netherlands. Joined a startup here. That is when I started going out of my comfort zone of Java, JavaScript and started plunging into other languages, widen my tech bandwidth overall. Then I actually started liking trying different languages, doing different things. I figured that I get bored easily, so that kind of helped me going. So, yeah, that was my career. So now I ended up at Okta. I just joined recently as a Developer Advocate. From a developer, I plunged into the Developer Advocate career path because I also figured I enjoy doing multiple things like, being a developer, being a community person, you know, talking to users, talking to community, building communities, teaching, writing, and all these things. So I think developer advocacy is the only role where I could do all of these and get paid for that. So that was an obvious choice for me.

[00:08:25] Being a Polyglot Developer

[00:08:25] Henry Suryawirawan: Thanks for sharing your story. I think very interesting that you said in the beginning, you did not come from a Computer Science background, and then you had to learn programming languages along the way. And in fact, looking at your current profile, your current blog, for example, you associate yourself as someone who can use multiple languages or what people call polyglot developers these days. So it’s very interesting, like how did you achieve that? Because there are so many developers who want to be polyglot, but probably there are challenges, right? Learning new languages, probably not so easy for some of them. So maybe we’ll just go through that journey together with you about being a polyglot developer. So first of all, how do you actually overcome the challenge of learning multiple languages?

[00:09:05] Deepu Sasidharan: Yeah. Before that, I think most people in tech, especially programmers, I think they are polyglot. It’s just that we don’t acknowledge it that way. Because I’m pretty sure that it will be hard to find someone who only works in one language, right? Every programmer in their career path would have worked with at least two, three languages. It’s just that they’re comfortable with one, and so they just call themselves as a Java or JavaScript engineer, but they would always end up working with few other things, at least like some scripting with some language or something like that. So most of us do that. I think the only difference is I predominantly try to do that like, consciously try to keep switching languages, and I don’t have preferences in terms of, hey, this is the language I would do everything, that kind of thing. I tried to choose the language based on the use case and or the purpose. So I think that probably is the only difference, and I’m probably comfortable with doing that. I know I can be equally productive in these languages. I think that’s the only difference.

I don’t think it’s that difficult. Of course, it takes a little bit getting used to in the beginning. Because when I started out, as I mentioned, I did a few languages in the beginning, but I never used them frequently. The only languages I frequently used were Java and JavaScript. And then I started writing, doing code in Go and Scala and Groovy, and these kinds of things. Didn’t stick too much with the Scala or Groovy. I did a lot with Go, and then I started doing stuff with Rust. So I figured, okay, I can do multiple languages and I can pick up more languages easily once I start doing more language. So it’s like a chain reaction, right? So once I learned Go, it was easy for me to pick up another language. And once I learned Rust, then I started looking into something for C#. Once you know four or five languages, it’s quite easy because you start seeing patterns. Like if you know Java, C# is quite easy to pick up. It’s quite similar. All these modern languages, they have something or the other from the other, right? All these languages are copying each other. They’re getting features from one to another. So now they are so homogenized that it’s not like learning something entirely from scratch. It’s more like looking at the language and seeing, hey, okay, how much of this is similar to the ones that I already know? How much is new? And what is the part that I need to learn? So that’s my approach.

My advice for people who would like to be comfortable in multiple languages would be to learn the base concepts of programming itself. So be good in those, like, learn those properly, then learn the language semantics, not syntax. I never learned language syntax because I think now we have enough tools and technology around us where we actually don’t have to by heart (remember) a language syntax. Every IDE will help you with the syntax. You don’t have to learn. That’s why I focus more on the semantics and the concepts that the language offers. For example, when I was learning Rust, I was more interested in learning about the unique memory management that Rust has, and the features that Rust has, which is not found in the other languages I knew. So those are the areas I focused on because, for the other part, I don’t have to learn how to write a For loop. It’s a For loop. The syntax will differ. That’s it. Other than that, it’s For loop. So those kinds of things you can just reuse, you just rely on your IDE for syntax. In the beginning, it would be a slightly steep learning curve, but once you start doing that, you will notice that it’s becoming easier and easier. It’s like practice, it becomes easier, and after a few languages I’m pretty sure you can pick up another language in the week.

[00:12:05] Should We Become Polyglot Developers?

[00:12:05] Henry Suryawirawan: So, thanks for sharing that tips. I like the way that you mentioned that focus on the language semantics, not syntax. And also the base concept programming, I think almost any language would still apply except maybe few paradigm difference. But in the first place, do you think that everyone should go into this polyglot mindset? Because is it advantageous in your point of view that we have to master a few programming languages?

[00:12:28] Deepu Sasidharan: Again, it would be hard to say that this is the goal, you know, silver bullet kind of thing. But as a person who has been in the industry for over a decade and was quite interested in technology trends, and someone who follow and write about technology trends, one thing I have observed is that entire world is becoming more and more digitalized, and COVID has helped fasten that. The world is digitalized, and every company wants to be an IT company. It’s unavoidable that in the future maybe five years down the line or 10 years down the line, IT is already the biggest industry in terms of job market and all those things, but it’s going to keep on expanding. There’s going to be more rapid innovations and the amount of innovations is going to double. It’s going to double, and it’s going to go exponential. It will be hard to keep up with stuff first. So if you are someone who is only focusing on one thing, like a language or a particular framework, it would be easy to be in a position where you’re not required. Because you never know when something new comes up and destroys something which was already there. I mean, we never expected something like Kubernetes to be this widespread, right? Like when we were doing enterprise servers and this kind of things. So those kinds of sudden technological innovations could wipe out something that you were focusing on.

So if that happens, and if you are not a generalist, then it might be difficult for you to move on, get adapted, and find a new job and these kinds of things. I’m not saying it is impossible. Of course, it would be possible to learn something new and move. But that could put you in a much harder position and your options would be much more constrained. But if you’re a polyglot developer or a generalist. I’m a generalist, polyglot later. So if you’re a generalist, and if you’re good in multiple things, then you have a lot of options. You have a lot of career paths to choose from. Today, I don’t think it matters to be an expert in just one thing. I don’t think it matters as much as it’s used to be. So if you are good at few things, even if you’re not an expert in just one thing, but good at few things, I think that is still quite valuable. I found it quite advantageous because I have multiple paths to choose from. I always have multiple options. Even if I look for a job, I have multiple options I could take, because you also gathered this experience in these multiple things.

But on the other side, it’s also not for everyone, I would say. Matches with my personality, probably. But doesn’t mean that it would match with everyone. Probably I have a little bit of ADHD, so it goes well with this. But probably not for everyone. So I can’t just say that, hey, this is the way, but this is also a good way. It didn’t use to be considered a good way because I know that when I started out my career, everyone would give me advice that, hey, focus on one thing. Learn one language, learn these frameworks and be good at that. Don’t try to do everything. That is wrong, I would say. This is also a very valid career path. I know a lot of people who are generalist polyglots who are doing really good. So if you think that this is your cup of tea, that this is the things that you want to do, and if you get bored easily of doing one thing, then yeah, this is a perfectly valid path as well.

[00:15:14] Tips for New Engineers

[00:15:14] Henry Suryawirawan: Thanks for mentioning about the balance between being focused on one thing versus multiple things. But for youngsters who just started their career, and as you can tell in the technology industry these days, there are so many things. Not just in one programming languages, but there are other concepts, like from infrastructure, cloud, frameworks, even devices and all that. So it seems like for people who just started, this can be really overwhelming. What really will be your advice? Actually, I know, like for people like you and me, we have been in the industry around for quite a number of years. We have been exposed to multiple things. But what about for those youngsters? Is it wise for them to start straight away with multiple things? Or is it just to focus on a few things in the beginning?

[00:15:53] Deepu Sasidharan: Yeah. For someone starting out, I would say that the better would be to go one by one. Because you start doing multiple things at the beginning, indeed would be overwhelming, and it would be hard for you to get established in the beginning. So in the beginning, I think it would be nice for people who are starting out to focus on one language, or I would say don’t focus on just one framework kind of thing. That probably won’t be a smart choice. But at least take one language, learn few things in that language, learn few frameworks or stuff in that language, get little bit established in that, and then diversify. So it should be like a tree. Your learning path, in my opinion, should be like a tree. Start from one point, you just branch out. If you try to do everything in parallel, then probably it might be harder to focus. It might be harder to establish in one thing. That’s what I did. I just branched out.

That is what I do now. I don’t try to learn two things at the same time. I learned one. Once I am okay with that, then I tried something else. And so I branch out kind of thing. I think that’s probably a smarter choice, I would say. And especially if you’re starting out. If you start with one language, and a year down the line, if you think that, hey, probably, this wasn’t the best option. You still learned a lot, like in terms of concepts and experience, you can apply that in another thing. So you’re not going to miss out on anything. The important thing, especially for the trend that we are going in, and for the direction that the industry is going in, would be definitely to bet on at least two things, not just one. You never know. I think some languages that we know that they are going to stay around for a while, like JavaScript, they’re not going anywhere. They’re going to be around for at least another 10 years. But the newer ones, like for example Go or these kind of things. It is quite widely adopted and everything, but you never know when that interest and that hype train will die down. So you don’t want to put all your effort into something like that.

I would say, if you’re starting out now, it would be nice to maybe start out with the very established language, like Java, JavaScript, Python, or something like that which has a lot of legacy. Also, because of that, it’s safe to assume that it will be around for another at least another decade. Because it will be hard to get rid of things which are there for a long time. So it would be safer to start with something like that, because you also have a huge ecosystem and community which would help you to learn. Then you can diversify into newer languages. Be up to date with the new trend as well. Because I do believe modern languages, like Rust especially, are going to displace a lot of these languages that have been around for a while. It might not happen overnight, but there is already a momentum and it will happen. At some point, there are going to be newer languages. And with newer generation of programmers and engineers coming out, it’s going to be more and more adopted, and they’re going to displace the older ones. But you still have at least a decade, I would say.

[00:18:29] Learning a New Language

[00:18:29] Henry Suryawirawan: So I know this next question might not be applicable for everyone, but can you share your normal flow? How do you learn new language? Because you have been mastering a few languages. So when you pick up a new one, what would you do? Maybe some tips for people who probably will find your way is suitable for them?

[00:18:46] Deepu Sasidharan: Yeah, definitely. I don’t know if this is like a proper way that would work for everyone. It’s just something that works for me. So I don’t know how far this can be generalized. But for me, again, when I started off with Java and JavaScript, that was different. But later when I started learning new languages, my approach is always to first, take the language and compare with the languages I already know. So when I started learning Go, the first thing I did was compare it with JavaScript and Java, and see how much I can reuse the knowledge? What are the things that are similar? Okay. These are similar. Okay. Callbacks in Go look quite similar like JavaScript, so I don’t have to start from scratch. I already know how callbacks works. I just need to know the syntax of it. Maybe if there are edge cases or exception scenarios. That worked out quite well for me, because I figured I could learn things faster.

Again, as I said, I don’t focus on learning the syntax. I just focused on learning the concepts. When I encounter a concept, I try to compare it with what I already know. Then it’s easy for me to say, okay, this is the difference. For me, it gets ingrained faster when I do that kind of comparison, and the more I do that, it becomes natural for me. For example, after three, four languages, when I started learning Rust, I expected the learning curve to be exponential because Rust has a lot of advanced language features, and it’s known to have a very steep learning curve. But I didn’t feel that way. In the beginning, it was a bit overwhelming, especially some of the new concepts. But in a week, I was extremely comfortable except for a few advanced concepts. I was like, okay, yeah this is familiar, doesn’t seem hard, and when I actually started building something concrete in it, it was quite easy for me to get started and apply my knowledge from other languages.

Of course, there will be times when I had to look up a specific thing in that language, but still all that knowledge from the other languages, did help me because you could always think about, hey, how would you do it in that language? Okay, let me compare how you do it in this language. Then you see patterns. For example, if you’re doing a threading in Rust, this is how we do threading in Java. So let’s see how it differs from Rust. You learn about, okay, you can do threading much more nicely if you are using, say, for example, shared channels and stuff like that. That’s the way that I do. I don’t know if it will work for everyone. Just starting out new probably might be harder because you might not have a lot of languages that you can compare with.

Another thing I do is I learn in the open. I tried to learn in the open, and I tried to learn by teaching as well. So, for example, whenever I write a blog topic, I try to write about something that I’m not extremely good at. So I take something which I know enough, but I am not an expert. Then the first thing is, okay, I need to write about this. I make an outline and I’m like, okay, these are the things I know, these are the things that I’m not really good at, or these are the things that I need to improve. Learn that first and then write about that. Then I keep repeating, and I keep repeating that unless I’m satisfied with the content that I have produced. That kind of helps me learn as well. I think producing content is a very good way to learn as well. Because that kind of pushes you to get the best content out of what you don’t know or doesn’t know. Especially if you’re trying to get out of something that you are not an expert in, then that forces you to learn, look up, and since you’re writing about that, it gets ingrained. So these are the things that kind of helps me learn.

[00:21:43] Henry Suryawirawan: Thanks for sharing this one common trick, like learning in the open, writing about something that you are not expert in. Because a lot of people have this misconception that if you want to write something about a blog, or maybe publish something, you have to be good at it. You want people to think that, okay, you’re the expert, get the likes and things like that. But actually sometimes it’s not true, right? Thanks for sharing that tip so that you can also learn by doing and publishing it openly. You do the research. You learn from the way and also people give comments. I think that’s also something not to be missed. Some people could give that critical comments for you to also grow.

[00:22:16] Building Index for Learning

[00:22:16] Henry Suryawirawan: So you mentioned a couple of things about using tools. This is, I think, also something that cannot be missed because, for example, tools are plenty these days. There are IDEs, auto-complete, maybe documentations. Maybe you can share a little bit on this. Because I know you have this concept about building a search index for yourself, so maybe you can share a little bit about it.

[00:22:35] Deepu Sasidharan: Yeah, definitely. I’ll talk about being a generalist because this ties back to that. At least personally for me, the amount of data that I can store in my memory is limited. I’m not very good at remembering stuff. I don’t have a photographic memory or anything. I’m quite absent-minded. I forget stuff a lot. But I figured what I was good at was making indexes. So I could vaguely remember stuff, but not in detail. So I build indexes. That’s how I’m also able to work in many languages, work in many different domains, or keep switching from whatever language based things to DevOps or whatever. I’m extremely confident that I can get into any technical domain, and I can pick it up in a week and start writing about that stuff, for example. I can pretend to be an expert in something in the week. So I don’t try to memorize stuff or I don’t try to become an expert in something. I just try to index that. So if I come across something, if I come across a new tool or a new feature in a language, or like a new framework, I’m like, okay, this exists, and I know what it relates to. Like a Kubernetes tool, for example, if I see something like k3d, for example, I’m like, there is something like k3d. It is for Kubernetes and it does this. That’s the end of it. That’s how much I want to remember. I don’t want to know anything more than that. So I put that in the index, and the next time when I have a need for something like that, then I could look in my index. So that is when I go to Google or go to their documentation site and I look what does it exactly do, and how to do it? So that has helped me a lot.

I honestly don’t have any shame in saying that I Google a lot. Most of us, I think everyone do that. And if you say that you don’t do, then probably I wouldn’t trust you. It is smarter to use all the tools that you have to be more productive than to try to do everything yourself. For me, that is a smarter way. So if you have internet connection where you can look for stuff, why do you want to store that in your memory? Memory is more precious. Data hard disk are cheaper. So use your memory for a more precious things and put all these things in, in, in, let it all be in the internet, which you can look up anywhere, anytime. I would say, more people should just be open about that, so that especially people who start out, they don’t get overwhelmed, or they don’t think that, hey, there is so much thing I need to learn. How am I going to learn all these things? How am I going to put all this into use? Only things you should be good at is your logical thinking and your problem-solving abilities. You shouldn’t be hired for being a fact memorizer. You should be hired for being a problem solver. How you solve the problem is up to you. It’s nobody else’s business.

So that’s also why I think I’m quite against the hiring practices in our industry. I write about that in my blog. I always reject interviews whenever they say, hey, there is a live coding part. No! If you’re not convinced that I’m good enough for you by looking at my profile or by talking to me, then probably you’re not good enough to judge someone who’s technical, then I don’t want to work there. Because that is not how I’m going to work. So if you want to evaluate me, then this is how you should evaluate me. Not with the white boarding and live coding.

[00:25:27] Broken Interview Practices

[00:25:27] Henry Suryawirawan: We can actually go to there because we know that interview sometimes is, you can say it’s broken sometimes. The trend of the industry is going that way. Plus, there are new SaaS products, like HackerRank, or maybe whatever that is. Can you maybe elaborate why do you think the interview process is broken? Because it seems like so many big tech companies, startups and all that, they seem to drill a lot in all these algorithms, white boarding. Maybe you can share a little bit more.

[00:25:53] Deepu Sasidharan: I would say it’s a toxic culture. Especially from all these big companies. Because, again, as I mentioned, it’s not realistic. Why can’t you just give your future employees the same tools and the same environment that your current employees have? Because you want them to work that way. If you want someone to work in certain environment, why don’t you give the same environment when you evaluate them? Maybe they’ll perform better. I have a huge anxiety when I have to do something in front of someone else, especially a stranger. And I’m pretty sure I have imposter syndrome, because whenever someone suddenly comes behind me, and if I’m writing a code, then I just freeze. It’s just anxiety.

There was a study from a university, which also showed that this kind of interview practices is more biased towards women, especially. They put the same set of women through live coding and coding in the comfortable environment, and all of them perform much better when they were in the comfortable environment, with someone not watching over them. So I think these kinds of interview practices, they’re quite old. They all come from maybe before we had all these tools and smart IDEs and stuff. It was probably from the time when everyone who was doing Computer Science was someone who did Computer Science in the university, or from the time when most of the work was writing algorithms and stuff. But nobody’s writing algorithms every day these days. If you’re in some sort of research role or some specific positions, and maybe for those positions, it’s fine to do that kind of interviews. But why do you want to drill someone about knowing algorithms, and being able to memorize and repeat something in a whiteboard for building web sites? So that’s unrealistic. And it just puts anxiety and performance anxiety, and these kinds of things in people.

Nowadays, at least with the awareness of mental health and everything, it’s a known fact that when you put someone under pressure, they’re not going to perform better. That is like the worst myth, that if you put someone under pressure, they’ll perform better. No, that’s not the case. If you put someone under pressure, they are going to perform worse. So why do you want to do that in an interview? Whenever I was in this job searching phases, first thing I would ask you. Okay. What is your process? If the process has these kinds of red flags, I’m like, no. I don’t want to work in that company. Of course, I know that it’s probably is not something that everyone can do, especially if you’re desperate for a job or if you’re starting out. I could do that because I had a solid profile where I know that I would have multiple options I could choose from.

But on the other side, I know if you’re just trying to get a job, it might not be a realistic way to just reject interviews. But that’s the sad fact. That’s where I think that our industry as a whole should change. There is this website called “They Whiteboarded Me” where people write their experiences about these companies, and there is an index of all the companies which does this and all the companies which doesn’t do this. You can know if someone is technically good enough or not just by talking to them. If you’re unable to do that, then probably the problem is on your side, not on their side. If you are technically good, then you should be able to tell if someone is technically good or not just by talking to them.

[00:28:32] Henry Suryawirawan: Thanks for sharing this “They Whiteboarded Me”. I think it’s interesting website. I haven’t seen it before, so maybe I should check it out. But yeah, I agree. Sometimes all these interview practices seem to be influenced by the big tech giants. Everyone just seems to follow suit. But yeah, there are many ways of how interviews can be done, right?

[00:28:50] Importance of Developer Experience

[00:28:50] Henry Suryawirawan: Maybe let’s move on from this controversial topic for people who think they have the right way of interviewing. So you seem to have worked in a lot of developer experience set up. Previously, you work in open source projects. Now you are a Developer Advocate, and previously as well. You seem to have interesting ideas about developer experience. Can you maybe in the first place explain what is actually developer experience and why do you think we should care about it?

[00:29:15] Deepu Sasidharan: Yeah. I think this view also solidified when I was working in my previous company. I used to work for Adyen, where we were building out a developer experience team. So I was always interested in developer experience because of my association with JHipster, which I co-lead with a few other awesome folks. We always used to care about how the experience would be for our end users who are developers. In my previous companies, part of my job was also to think about that. Like we were building tools to make that experience better for developers. So I think that experience has solidified that view for me. Developer experience is extremely important in today’s IT world, or even in the future when IT is going to be more and more widespread and every company is going to be an IT company, and there’s going to be more companies building tools and services for developers. So developers are going to be like a huge market or market of user base which has to be handled slightly different from general user base. User experience for developers is not exactly the same as user experience in general. So that’s the takeaway.

It’s similar to how user experience was looked at 10 years ago. 10 years ago, user experience was not something that you would always factor in when you’re building an application. I have been in projects where user experience was not cared for at all. 10 years ago, nobody would care about that. UX people in general in development teams was not that common 10 years ago. But now, it is unimaginable, right? Now, if you’re building a user-facing product, and if you don’t have proper UX folks in your team, then people are going to laugh at you. People are going to be like, are you even serious about building? So that shift has happened in terms of user experience. People know the need for that. Everyone has realized how important user experience is for success of your product. It is standardized. User experience is a must have now.

I think the same transition has to happen for developer experience. Because there are lots and lots of companies that are building services and tools for developers. These companies have to treat developers as the primary users and work towards their user experience. So it’s slightly different from general user experience, right? Because these are for technical products. Things that you might consider great for normal user experience might not be applicable here. If you’re building a CLI tool, your general user experience guidelines might not be a hundred percent applicable. It might be slightly different. I mean, on a CLI, people might want things differently, so you have to cater for that. If you’re building a service that is consumed by developers, then you’d have to think about the experience of using your APIs, or the experience of using your SDKs. Developer experience here would be the inverse of how annoying it is to use your product, I would say.

I wrote about these things in my blog. I recently wrote about what developer experience is, and why it is important in detail. I think I wrote about all these topics in my blog. So I think that is the shift that needs to happen in developer experience. In terms of making sure developers using your product are not annoyed. So the less annoyed they are, the more happy they are going to be, the better developer experience they are going to get, and the likely chances of them recommending the product to their colleagues or their friends, or just spreading the good words by word of mouth, which is quite important, right? Especially in a developer circles, it is quite easy to find people who are extremely opinionated, and probably you would have seen that. All of us in the IT world would have seen that. When people like the product, they are very opinionated about that, then they will defend that product. It’s not going to benefit them in any way. We have this tribal mentality when it comes to all these things, right? Like, if I like a language, I’m going to defend that. So that’s going to happen. Why that happens is because these products, they care about the developers and they have built that experience so that the people using the products have become so loyal, that they are ready to defend your product to a stranger and they are ready to go fight the stranger on the internet to defend your product. So that is the kind of developer experience you need to build. If a company is building products for developers, and if you’re not going to take care of that, then it’s going to be very hard for you to be successful. Especially given developers are much more demanding audience than general users.

[00:32:55] Building a Good Developer Experience

[00:32:55] Henry Suryawirawan: I agree that developers can be more demanding and even more quirky sometimes. They have no reservation for putting bad comments over the internet and all the forums. When you say a good developer experience, or maybe even annoying developer experience, can you give some tips for people who are building APIs, CLIs, all these developers centric products and services? What would be your tips in order to ensure good developer experience?

[00:33:18] Deepu Sasidharan: Yeah. So again, this is not something that is a silver bullet, right? This is not like the exhaustive list of things that you have to do. This has to do a lot with context, the use case that you’re trying to solve, the type of product. So that needs to be taken into account. For example, if you’re building APIs as the product consumed by developers, then some of the things that should be taken care of, because it’s going to be annoying otherwise, and if something is annoying, then that’s not a good developer experience. So, I think sticking to highly adopted standards and conventions. That’s something that people overlook because when you’re starting out, especially for startups building stuff, it’s easy for teams to be go all fancy and try to come out with something new and shiny like your own conventions. It might be okay if your API is going to be the standard. But if it is on a use case or a domain that already exists, then maybe it’s better to stick to conventions. I’m not saying copy someone else. I’m saying stick to standard conventions. For example, standard error schemas when you’re doing error. There are many standard conventions for that. Stick to standard API guidelines, for example, stick to REST guidelines, for example.

This kind of things would be minor things, but the amount of impact it would have on developer experience is huge. Imagine me being a developer. I have zero interest in your fancy stuff. I use your product to get my work done. So the fastest I could do it, the best experience I’m going to get. The least I have to learn, the better for me. But if you are introducing a product, that I have to learn a lot, that’s going to be annoying for me because I need to waste my time learning your product. Why should I learn your product? I shouldn’t have to learn your product. It should be intuitive. I see your product, and if I already know how REST APIs work, then it should be intuitive for me to use that. I shouldn’t have to learn few things you did differently because you thought it would be cool. No, that’s not going to cut it. That’s going to be bad developer experience for me. So for APIs, that’s going to be a huge thing, sticking to conventions and highly adopted standards. Good error handling. If I’m using an API and if I cannot figure out what’s going wrong, if I had to call up your support to know what’s going wrong, then that’s not a great experience.

Consistent and easy-to-use documentation is extremely important for APIs. Like providing API docs, or docs that you can actually try out APIs. Providing SDKs and libraries for APIs, again, very important. Because if I’m using your API, I don’t want to build all these SDKs myself. If you can just provide those, I will just happily use that and forget about your API at all. So the sooner I can forget about the API and move on with the next step, the better it is for me. Provide as much help possible for developers to make sure that they can integrate with you in as little as time as possible without having to learn your product. That’s going to be great developer experience. They are going to recommend your product to other people. They’re going to, “Hey. This was awesome. I could integrate it in half a day and get the work done. So it is awesome.” So that’s the kind of developer experience you should be aiming for.

But if you’re building developer tools or products, then it’s going to be a different focus. Like good UX matters in that. If you’re building an IDE, a good user experience matters, but not like traditional user experience, but it should be tailored towards developers. You should put in things that developers like. Like developers like dark mode. Okay, just provide them switchable themes. That’s good developer experience because then people are not going to be frustrated. Because there are going to be people who like dark mode, there are going to be people who like light mode. Just give them both. Provide customizability. People are opinionated. Don’t try to push people into certain things. It might work for some products, but it’s not going to work for every product. Some products might be lucky enough that they push for certain opinionated flows and it just worked for them. But if you try to replicate that, the chance of it working is going to be quite slim. So try to provide more customizability. That’s good developer experience.

Again, make it easy to use and install. If I have to use your product, I shouldn’t have to go through multiple hoops and jump through multiple hoops just to get it installed and started. That’s going to be really bad first impression already. That’s already going to demotivate me from liking the product. So make it easy to install anywhere. Make it cross-platform. Make it available in all those well-known package managers, so anyone with whatever workflow they have can easily just find and install the product. The list goes on. Depending on the domain that you’re trying to tackle, there are lot of things you can do. There are researches done on these. There are great products that we know and love, which we can take as inspiration and follow their lead.

[00:37:22] Henry Suryawirawan: So maybe if I can just add one more. The one thing that I always get annoyed is when I work on a product that has specified something in the docs, but it doesn’t work as advertised.

[00:37:33] 3 Tech Lead Wisdom

[00:37:33] Henry Suryawirawan: So, thanks Deepu for your sharing about this developer experience. Unfortunately due to time, we have to cut it short. So, before I let you go, normally I have this one last question that I always ask all my guests, which is to share the three technical leadership wisdom. This is for people who want to learn from your journey. So what will be your three wisdom to share with people?

[00:37:53] Deepu Sasidharan: I think the one thing that I keep telling to people, especially juniors and people who are starting off is, to not get married to a technology or a framework or to a language. Don’t get married to stuff. Because you see a lot of people who are so religious about the language that you work in or a particular framework like React. They spent so much focus and energy on just proving to people that, hey, React is the best kind of thing. I used to do that. That’s why I’m sharing this, because I used to be that person. I used to be very religious about the technologies that I use, the frameworks I like, the languages I like. But after like a decade, you start realizing it doesn’t matter. Technologies are going to come and go. Frameworks are going to come and go. I used to be a huge fan of AngularJS. Look at Angular JS. Whatever Angular we have currently has nothing to do with AngularJS. It’s gone. New frameworks will come and go. Especially in the JavaScript world, there is so much churn that things just come and go in months. So don’t get married to frameworks. Don’t get married to a particular technology. Not even languages, and not even paradigms.

I hate seeing when people are like, I’m so much into functional programming. That is the only way. No, that’s not the only way. There are multiple ways to do stuff. You might like it, but don’t be that close-minded like that. There could be times when imperative programming does much better for you than functional programming. Especially if you are writing a very performance intensive logic, and you have to tune every possible millisecond out of that, then don’t write functional programming there. It is a valid way of programming as well. Or if you want to do OOPs, do object-oriented programming. Doesn’t matter. So don’t get married to these things. It’s not going to help you in the long run. It might feel good in the short term, but in the long run, I think it would help you much better if you are open-minded about things. Try different things. Use the right tool for the right situation. Lot of people try to have one tool and use it like a hammer on everything. But I would prefer to have multiple tools in my tool kit and figure out if the problem is a nail or if it’s a screw, then use the right one. Because I can get the job done much faster and in a much better way than doing a generic tool. That’s why I also believe in being a generalist, because if you know multiple things, then your horizon expands, and you become more pragmatic. You start seeing problems as problems, and try to give solutions, and you don’t try to treat every problem as something to be solved by something that you already know. Don’t get married to anything related to technology. Be open about it, switch around. Go with the trend if you want to. That’s fine. But change with the trend also when the trend changes. Don’t get stuck to something.

Second one, I would say, would be to rely on tools. This is something that we discussed, right? So I rely on tools a lot. I rely on my IDEs. I predominantly use VSCode for anything non-Java, and I use IntelliJ for Java. That’s my preferred toolset. I can’t imagine writing code without these. I can’t imagine writing Rust or Go or JavaScript without VSCode. If someone asked me to write it in a Notepad or Google Doc, I’ll be like stuck. I’ll be like, I have no idea what to do. So I rely heavily on tools. For me, that’s a good thing because my job is to do this kind of things using a tool. I should optimize for what I should be doing realistically, not something unrealistic. I’m not a competitive programmer or something to do things on those kinds of LeetCode or HackerRank, or those kinds of things. No, that’s not what I’m going to do day in, day out. So I need to optimize for what I do day in, day out. And day in, day out, I’m going to work on an IDE or a code editor, writing programs or doing whatever. I use all plugins possible to make my workflow simpler and faster. If a tool can do certain things. Great. Let the tool do it. I started using the Copilot feature from VSCode. It was great.

Of course, don’t just blindly follow these things. It’s perfectly fine to use Stack Overflow, Google, or something like Copilot, but the only thing is don’t just blindly take whatever it gives. Look at what it gives, see if it works for you. If it works, just use it. Similarly, use the tools provided by the language ecosystem. Like for Rust, I always use the linter called Clippy and this kind of things. Because it gives me nice suggestions and it makes me improve myself. It gives me suggestions that I didn’t think of. I get to improve because these tools are becoming much more smarter than us. So I’m pretty sure at some point, these tools are going to be much smarter than us, they can write all the code for us. If that happens, I should be able to utilize that and don’t become obsolete. So I should adapt to working with these tools and make myself future-proof. That would be the smart thing to do, I would say. So, yeah, rely on tools.

The third thing would be to write simple code. Most of the times you don’t have to use fancy features or you don’t have to write extremely fancy looking code to get the work done. The simpler the code is, the better it is to maintain, the better it is for other people to read. It’s overall better. So, there is always a simple solution to problems. It’s always trying to find the simplest solution. Don’t try to find the fanciest or most complex looking solution. I have seen people doing that. Especially in programming, there is this urge to show off all your programming skills, right? Especially if you are working with languages like Scala or Rust, where there are a lot of language features. It’s easy to just get swayed and try to be as cool as possible in terms of solution. You saw the fancy feature? Okay. I need to use this feature here. Then in the end, you end up writing code that is quite unreadable and complex to start with. Probably, it might be solving the problem, but it is introducing a lot of other problems on the side. Maintaining that code is going to be really bad. So if you can just get that done with the simplest of the feature possible, please do that. That’s going to save a lot of time for a lot of people in the long run. So yeah, so those are the things.

[00:43:10] Henry Suryawirawan: Yeah, I like about the simplicity as well. So I learned also recently, few episodes before that actually a simple maintainable code is good for teamwork. I’m sure a lot of developers these days work in a team rather than solo. So, thanks again for the wisdom, Deepu. So for people who are interested to know more about you or follow you online, where can they find you?

[00:43:29] Deepu Sasidharan: I would prefer Twitter because I’m most active on Twitter. So you can find me on Twitter as deepu105, and on my website as well. So I write about all these things on my website. So you can find it at deepu.tech. I have a blog with mostly technical stuff. But I also write about developer experience, hiring in our industry, being a better programmer and this kind of things.

[00:43:52] Henry Suryawirawan: So thanks again for your time, Deepu. I wish you good luck with all your work.

[00:43:56] Deepu Sasidharan: Yeah. Thank you. Thank you so much. It was so nice of you to have me, and I’m so glad I could share these things. So yeah. Thank you.

– End –