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.