If you're a gymnast and if you are good in multiple things, then you have a lot of options. You are 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 you 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 this. Multiple things. Hey everyone. My name is Henry Surya Barragan. And you're listening to the
tekhelet journal. The show will be bringing you the greatest technical leaders practitioners and thought leaders in the industry to discuss about their Journey ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your personal work. So let's dive into our Journal. 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 package, you know podcast.
Thank you for taking your time tuning in and listening to this episode. If this is your first time listening to technology, you know, 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 technology?
Not Dev slash 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 Technologies. 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. 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 deep with such either Run. Deep Blue is a polyglot developer and a senior developer advocate for devops a table data. I'm inviting the boot to hear some perspectives from a polyglot developer and someone who has successfully done it for quite some time in this episode Deepu shared why he consciously becomes Polyglot and generalist developer.
He emphasized, the importance of knowing more than one thing, be it programming, languages Frameworks or tax tax. In the current rapidly changing technology industry. When every week or month, new things are being invented and the small 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 Being 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 do people thinks it is broken and needs to change, especially to make it more inclusive and less biased towards the end Depot. Share about developer experience.
A topic that he is 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 liked 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 In this podcast. So let's get our episode started right after our sponsor message. Are you looking for a new cool swag tekhelet Journal.
Now offers you some swags that you can purchase online. These wax are printed on demand based on your preference and will be delivered safely to you all over the world where shipping is available. Check out all the cool swag is available by visiting technology. No, dot f / shop, and don't forget to break yourself. Once you receive any of those tracks. Hey everyone, welcome back to another episode of the tekhelet journal. Today. I have with me, a guest named Depot.
Sajida, run. He's actually a developer Advocate at akka. Akka is like a product for security single sign-on and things like that. Today. The pool has a 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. Of the pool looking forward for this conversation. Yeah. Hey, thank you Henry.
Thank you for the introduction. Happy. I'm like to be deeper maybe in the beginning. For people who don't know you yet. Can you introduce yourself? Maybe sharing about your highlights of turning points in your career? 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 path cell, but at least, I thought it was non-standard because I started out as electrical and
electronics engineer. That's what I studied in college. Which I was quite fascinated with the 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. I was like, okay, either Astro, physics, astronomy or properties. But, yeah, 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
decision, the 2008 recession. So, jobs are not that many to be found, especially in robotics that was becoming impossible to find. That point I was like, okay. I need to pay the bills to downloads to be repaid. Okay, I need a job. Seems like it companies are still highly clock. So why not? I just give it a try. I think that a consultancy was
one of the humongous. It companies in India, which hires like in the 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 actions to that. I have done in order to create some 3D stuff for random things. So they started actually started learning programming at their training.
They had like a six months bootcamp Aid of thing. So I started learning doctor scheme. That is a programming language. Actually, seriously started to look I did some C++ before that. I learned a little bit of C++, but that was mostly to help my girlfriend bank. So how was it actually interested in learning that I actually started paying attention when they are 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 Started working on Java projects. That was my first standard language that is cutted 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 made a career out of that. Yeah, you 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 start up 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 or photo. 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 by. Dr. I just joined recently passed 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 gold where I could do all these and get
paid for that. So, that was obvious choice for me. 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 have 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 over people call polyglot. A these days. So, it's very interesting.
Like, how did you achieve that? Because there are so many developers who wants 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 developers. So, first of all, how do you actually overcome the challenge of learning multiple languages? Yeah. Before that. I think most people in Tech especially programmers.
I think they're polyglot. It's just that we don't acknowledge it that way because I'm pretty sure, 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 and cheer, but they would always end
up working with fear. The 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 dominantly 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 it kind of thing. I tried. Choose the language based on the use case and or the purpose. So I think that probably is the only different and I'm probably
comfortable with doing that. I know, I can be equally productive in this language. So 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 a mission, I did a few languages in the beginning, but I never use them frequently. So only languages are frequently used, where Java and JavaScript, and then I started writing doing coded go and Carla, and Ruby.
And these kind of things during stick too much. With the scholar do we? 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 they 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 rest, then I started looking into something for see shh, once you know 45 languages, it's quite easy because you start seeing patterns, like if you know Java C sharp is quite easy to pick up. It's quite similar. All this modern languages. They have something or the other from the other and And all these languages are copying each other. They are getting features from
one to another. So now they are so homogeneous that short likes learning something entirely from scratch. It's more like looking at a 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 basic concepts of programming itself.
So be good in those like learn those properly, then learn the language. Amanda, it's not syntax. I never learn language. That's because I think now we have enough tools and Technology around us where we actually don't have to buy her. A languages 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 of force. For example, when I was learning worst.
I was more interested in learning about the unique memory management that rosters, and the features that rust have, which is not found in any other language aside. So those are the areas I focused on because for the other part, I don't have to learn about How to write a for loop. It's for the syntax already for that's it. Other than that, it's for. So those kind of things you can just reuse, you just rely on your ID or syntax in the beginning. It would be slightly steep
learning curve. But once you start doing that, you will notice that of it's becoming easier and easier. It's like practice, it becomes easier and after few languages, I'm pretty sure you can pick up another language in a p. So thanks for sharing that tapes.
I like the way then you mentioned that focus on the language, semantics not syntax and also the base concept programming, I think almost any Which would still apply except maybe a 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 few programming languages? Again? It would be hard to say that this is the girl, you know, Silver Bullet kind of thing.
But as a person who has been in the industry for over a decade and we quite interested in technology Trends and someone who follow and write about technology Trends. One thing I have observed is that until World is becoming more and more digitalized and covid has helped fast. And that world is digitalized and every company wants to be an IT company. It's unavoidable that future may be five years down the line or 10 years down the line.
I key 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 Innovation than the amount of Innovations is going to double. It's going to double and stone will go exponential way to 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 we are, not requiring because you never know when something new comes up and destroys something, which is already there. I mean, we never expected something like Cuban. It is to be this widespread. Right? Like, when we were doing Enterprise servers and these kind of things.
So those kind of certain 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 New job at these kind of things. I'm not saying it is impossible. Of course, it would be possible to learn something new and move, but that would put you in a much harder position and your options would be much more constraint.
But if you are a polyglot developer or a generalist, I'm in general is all included. So if you are a generalist and if you are good in multiple things, then you have a lot of options. You are 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 you used to be. So if you are good at few things, even if you're not Spot 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 gather 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 used 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 you learn one language learn these Frameworks and be good at that. Don't try to do everything that is wrong able to say. This is also a very valid career, but I know a lot of people who are General is 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. Thanks for mentioning about the balance, between being focused on One Thing versus multiple things, but for youngsters who just started a career and as you can tell in the technology industry, these days there are so many things not just in one programming languages, but they 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 would 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. As 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? Yeah.
For someone starting out. I would say that the better would be to go one by one because if you start doing multiple things by the beginning, indeed would be overwhelming and it will be hard for you to get established in the beginning. So in the beginning, I think it would be nice for people starting out to focus on one language or I would say don't focus on just one framework kind of thing. That probably Don't be a smart choice, but at least take one language.
Learn a few things in that language loan, few Frameworks or stuff in that language, get little bit established in that and then diversifies. So it should be like a tree, your learning, path. 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 know, I don't try to learn two things at the same time. They don't want once. I'm okay with that. Then I try Something else. 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 was in 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 they are 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 are starting out now, it would be nice to maybe start out with a very established language, like, Java, JavaScript, python.
Down or something like that, which has a lot of Legacy also because of that, is it safe to assume that it would be around for another place another ticket 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 to help you to learn, then you can diversify into newer languages be up to date with the new trend of Sir because I do believe modern languages like rust especially are going to displays a lot of these languages that has been around for a while. It may 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 are going to displace those words, but you still have at least a decade. I've seen. 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 Bleep will find your way, is suitable for them. 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 it 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 both looks quite similar like JavaScript, so I don't have to start from scratch. Already know how callbacks
works. I just need to know the syntax of it. Maybe if there are rich cases or exceptional 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 focus 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. Do that. It becomes natural for me. For example, after 34 languages. When I started learning rust. I expected the learning curve to be exponential because thrust as 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 few advanced concepts. I was like, okay. Yeah. This is familiar with doesn't seem hard and when I actually started building something Concrete in it, it was quite easy for me to get started. Apply my knowledge from other
languages. Of course, there would be times when I have to look up 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'd you do that language? Okay, let me compare how you do
it in this language. Then you see patterns, for example, if you're doing threading and rest, this is how you do threading in Java. So, let's see how it differs from Russell. You don't know what, okay, you can do threading, much more nicely. If you are using say, for example, share 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.
You probably might be harder because you might not have a lot of languages that you can compare. With. Another thing I do is I learned in the open, I try to learn in the open and I try 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. Make an outline and I'm like, okay.
These are the things. I know. These are the things. I'm not really. Check out. These are the things that I need to improve. Learn that first and then right about that, then I keep repeating and I keep repeating that analyst am satisfied with the content that I have produced that kind of helps me learn ourselves. I think producing content is a very good way to learn ourselves 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 are trying to get out of something that you are not an expert in then that forces you to learn new curve. And since you're writing about that, it gets end grain. So these are the things that kind of helps me long. Thanks for sharing this one, common trick, like learning in the open writing about something that you are not expert in.
Because lot of people have this misconception, that if you want to write something about a block, or maybe publish something, you have to be good at it. You want people to think that, okay, you're the expert, the other likes, and things like that, but actually sometimes is 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. Yeah. Would be if that critical comments for you to also grow. 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, their IDs on the plate, maybe documentation. 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. 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. He is limited 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 develop. So, 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. Examples. They can pretend to be an expert in something in a week. So I don't try to memorize stuff for. I don't try to become an expert in something. I just try to index the.
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 axis and I know what it relates to like a Cuban. It is tool for example, if I see something like k3d, for example, I'm like there is something like a 3D. It is forgiving. It is 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 is 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. It is smarter to use all the tools that you have to be more productive than Try to do everything yourself for me. That is a smarter way. So if you have internet connection where you can look for stuff, what do you want to store that in your memory memory is more precious data? Hard disks are cheaper. So now use your memory for more precious things and put, all these things in, let it out. We leave the land, 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 this? Then 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 fact. Memorizer. You should be hired for being a problem. Solver and 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. Know if you are not convinced that I am good enough for you by looking in my profile. Talking to me then. Probably you're not good enough to judge someone to his 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 arrive. It means not with the white boarding and live coding. You can actually go to their because we know that interview sometimes is you can say it's broken. Sometimes the trend of the industry is going that way, plus their new SAS products, like, hacker rank, or maybe whatever that is. Can you maybe elaborate? Why do you think that 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, but boarding, maybe you can see a little bit more. 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 the? Maybe they'll perform better. I have a In science, they even 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 an Society. There was a study from University which also showed that these kind of interview practices is more biased towards women, especially they put the same set of movement through live coding and coding in their comfortable environment and all of the performed much better when they were in a comfortable environment with someone not watching over them. So I think these kind of interview practices. They're quite old.
They all come from maybe before we had all these tools and smart IDs and stuff. It was probably from the time, when everyone who was doing computer science, was someone who did computer science, their University or from the time when most of the work was writing, algorithms and stuff, but nobody is 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? Drew someone about knowing algorithms and being able to memorize and repeat something in a white board for building websites. So that's unrealistic. And it just puts hands it and performance anxiety. And these kind 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 will perform better know. That's not the case. If you put someone into the pressure, they are would perform worse. So why do you want to do that in an interview whenever I was? As in this job searching faces. First thing I would ask you. Okay. What is your process? The process as these kind of red flags? I'm like, no don't 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 are just trying to get a job. It might not be a realistic way to do reject interviews, but
that's a sad fact. That's why I think that our industry as a whole should change there is this website called a white border where people write their This is about these companies and there is an index of all the companies which does this. And all the companies which doesn't do these. You can know if someone is technically good enough or not just by talking to them. If you are unable to do that, then probably the problem is on your side. Not, not their style.
If you are technically good, then you should be able to tell if someone is technically good or not just by talking. So thanks for sharing this day, whiteboard, it me, I think is interesting website. I haven't seen it before so maybe I should check it out. But yeah, I agree sometimes, all this interview practices seems to be in Lawrence by the big Tech Giants. Everyone's just seems to follow suit. But yeah, there are many ways of how interviews can be done. Right?
Maybe let's move on from this controversial topic. Hope you would 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 Developer Advocate and previously as well. You seem to have interesting ideas about developer experience and you may be the first place explain what is actually developer experience and why do you think We should care about it.
Yeah, I think this view also, solidified, when I was working in my previous company. I used to work for a DM baby. We're building out a developer experience team. So I was always interested in developer experience because of my association with Jake hipster, which I call it 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, Ian's a solid effect that you for me developer experience is extremely important in today's it world or even in the future when I T is going to be more and more widespread and every company is going to be 90 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 users user experience. For developers is not exactly the same as user experience in general. So that's the takeaway. Similar to how user experience was looked at 10 years ago. 10 years ago user experience was not something that you would always Factor it when you're building an application.
I have been in projects where user experience was not cared for at all. Ten years ago. Nobody would care about that. You explain 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 us? Happened in terms of user
experience. People know the need for that. Everyone has realized how important user experiences for success of your product. It is standardized user experience is the must have them. 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. It for normal user experience might not be applicable here. If you're building a CLI tool you are General. User experience guidelines might not be 100% applicable. It might be slightly different mean on a CLI people might want things differently. So you have to test for that. If you are 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 SDK 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 developed for Expediency is. And why it is important in detail. I think I wrote about all these topics in my block.
So I think that is the shift that needs to happen and developer experience in terms of making sure developers using your product are not annoyed. So the less I know it. They are the more happy. They're 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 word 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, You would have seen that all of us in the ideal world would have seen that when people like a product are very opinionated about that, then they will different 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 resent that.
So that's going to happen. Why that happens is because these products, they care about their 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're ready to throw fight a 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 are not going to take care of them, then it's going to be very hard for you to be successful. Especially given developers are much more demanding audience. Then General users. 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 a picl eyes, all these Developers? Trick products and services. What will be your tips in order to ensure good developer experience? 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 means to be taken into account.
For example, if you're building apis, that's 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 something that people Overlook because when you are starting out, especially for startups, building stuff is easy for teams to be Go Fancy and try to come out with something new and shiny. Like the own conventions. It might be okay if your APA is going to be the standard, but if it is on 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 There are many standard conventions for the stick to standard APA guidelines. For example, stick to rest guidelines. For example, these kind of things would be minor things. But the amount of impact it could have on developer experience. These 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 am 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 because he could waste my time. Earning your product. Why should I learn your product? I shouldn't have to learn your product. It should be intuitive a co-product if I already know how rest API is worth.
Then you 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 good. No, that's not going to cut it. That's going to be bad developer experience for me. So crepey eyes. 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, they have to call up your support to know what's going wrong, then
that's not a great experience. Assistant an easy-to-use documentation, that's extremely important for epa's. Like providing the APA dogs, or dogs that you can actually try out the APA. Providing sdks and libraries for epa's, again, very important because if I'm using an API don't want to build all these sdks myself. If you can just provide those, I'll just happily use that and forget about your EP at all. So the sooner I can forget about the API and moon with the next up the better.
These provide a smooth help possible for the 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 are going to hate. 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 of products, then it's going to be different Focus. Like good ux matters in that. If you are building an ID, 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 them. Was like dark mode.
Okay, just provide them switchable teams as good developer experience because then people are not going to be frustrated because there are going to be people who like that mode. There are going to be people like life, just keep 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 in Papillion, it flows and it just worked for them. But if you try to replicate that the chance of it working is going to be quite slimming. So, try to provide Add 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 be motivate me from liking the products. So make it easy to install anywhere, make it cross platform. Make it available in all those well-known package managers. So anyone with water overflow, they have can easily just find
and install the product. The list goes on, depending on the domain that you're trying to There are a lot of things we can do. There are researchers done on these. There are great products that we know and love which we can take us inspiration and follow their lead. 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 specify something The Docks, but it doesn't work as advertised.
Thanks Depot 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. As all my guests which is to share, the three technical leadership is done. This is for people who wants to learn from your journey. So what will be your tree wisdom to share with people.
I think the one thing that I keep telling to people especially Juniors and people are starting out is to not get married to a technology or 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. They your kin or particular framework like react, they spend so much. Percent energy on just proving to people that he 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 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 angularjs whatever. Angular we have currently has nothing to do with languages. It's gone.
New Frameworks would come and go especially in the JavaScript World. There is so much stone 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 are not even parody of the, I hate seeing when people are like 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. Then imperative programming does much better for you than function. But especially if you're writing a very performance intensive logic and you have to tune every possible minute. And 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 opes, do checked 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're open-minded about things, try different things, use the right tool for the right situation. A 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 us 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 to, that's why I also believe in being a generalist because if you know, multiple things, then you are horizontal expands and to 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, sits 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 some thick and one I would say would be to rely on tools. This is something that we discuss, right? So I rely on tools a lot. I lay on my IDs I predominantly use vs code for anything non Java and I use IntelliJ for Java.
That's my preferred tool set. I can't imagine writing code without these I can't imagine writing rust or go or JavaScript or css code. If someone asked me to write it in notepad or Google doc. I will 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 these kind of things using a tool. So I should optimize for what I should be doing realistic, not something unrealistic.
I'm not a competitive program or something to do things on those kind of reach code, or a current or those kind 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 that day in day out. I'm going to work on an ID or a code editor writing programs, or doing whatever. I use all plugins possible to make my work for simpler. And Foster, if a tool can do certain things rate that the to do it. I started using the copilot
feature for vs code. It was great. Of course, don't just blindly follow these things. It's perfectly fine to use stackoverflow, Google or something like co-pilot for. The only thing is don't just blindly. Take whatever. It keeps. Look at what it is. 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 clicky and these 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 as 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 Right. 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 its overall better.
So there is always a simple solution to problems. So it's always try 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 with a lot of language features. It's easy to just get swayed and try to be as as cool as possible. In terms of solution.
You saw the fancy features. 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 term.
So yeah. So those are the things I like about the Simplicity as well. So I learned also, Leave you episodes before that actually a simple maintainable code is good for teamwork. I'm sure a lot of developers this day work in a team rather than solo. So thanks again for the wisdom people. So for people who are interested to know more about you or follow you online. Where can they find you? I would prefer return because some most active on Twitter.
So you can find me on Twitter as we pull 105 and on my website as well. So I write about all these things on my website so you can find it at the boot Dot. At Tech. I have a Blog with mostly technical stuff, but also write about developer experience, hiring in our industry, being a better programmer and these kind of things. So thanks again for your time Depot. I wish you good luck with all your work. Yeah. Thank you. Thank you so much.
That was so nice of you to have me and I'm so glad I could share these things. Yeah. Thank you. Thank you for listening to this episode and for staying right till the end. If you're highly enjoyed, please share it with your friends and colleagues who you think would also benefit from listening to this episode. And if you're new to the podcast, make sure to subscribe and leave me your valuable review and feedback. It really, really helps me a lot in order to grow these podcasts better.
You can also find the full show notes of this conversation on the episode page at technology. No, the death. Site, including the full transcript, interesting quotes, and links to the resources and mentions from the conversation. And lastly, make sure to subscribe to the show's mailing list on technology. No, the deaf to get notified for any future episodes. Stay tuned for the next technique Journal episode. And until then. Goodbye.