The chop must advise learn. Kotlin.
That was predictable.
Well, being a good developer. That's a very loaded
question. It starts with the definition of
good. Being a good programmer developer takes several
qualities. First of all, that's attention to
details. Programming is all about small, small videos, like things
that you in
casual communication or in text, when you omit a comma or flip
a word, stuff like that, it doesn't really matter
in your non development life. But in programming,
like just one character in your code or
off by one somewhere can be
a difference between code that work incorrectly and code that doesn't
work. So attention to the small details is really what
makes professional developers different.
And that's the quality that's needed to become good
software developer. I enjoy working with
extremely good and at the same time very junior developers
who arguably know very little, right?
But the way they approach
the tasks at hand, the way they learn,
so the way they are curious and hungry to
do things and it's an amazing experience and I love them as contributors
and they're great developers. They're just great junior developers. So first thing
I'll say is that the greatness in this question to
me doesn't equate with experience necessarily,
especially years of experience. If I think about this,
first thing that I'll say, and again,
this is my personal opinion, this is not like a recipe, but first thing I'll
say is a fundamentals.
If you're using a data structure like a library list or a
map or something, do you know how that's working? What kind of algorithms
are implemented there? Why is it fast? Do you
know how memory is managed in the runtime you're using?
Do you know what kind of things are done under
the hood to manage concurrency, for example, like synchronized threads
and so on and so forth. Do you know how things work
under the hood in general? And looking into that
makes you a better engineer because you learn from other engineering
decisions made by other people. It makes you, it exercises your
mind in an analytical way that you really need working on your
own code. And it also makes you just knowledgeable.
It's much easier for you to figure things out and make connections where they're
unobvious. I remember a question I was interviewed by a startup CTO
some 12 years ago. He asked me a question that I then kept asking in
my own interviews that I liked very much. Question is simple.
So for web developers, imagine on the webpage there's a button,
you click on it. Next page comes what happened
between the button click and the next page? Think about it
for a second. Right? That onion can have five layers or
a thousand. You can spend five minutes answering the question, or you
can spend an hour and not be done halfway through because of how many
things happen or can happen then, depending on what level you decide to stop
and speak about. And the more layers of that onion you can stop
and talk about. Knowingly, the better you understand
that system and the better web developer you'll be.
Right? Things like network protocols, things like database
architecture. With so much of software
available today being open source, you can be kind
of the hood of pretty much any technology that you use. And you should do
that. And you should read books and watch presentations about how this type
of software works. And I think that the
main benefit that brings is that it can help you resolve problems much
more confidently and much more quickly than just if you just poke
at things and see, like, if I do this, does this work?
No. Okay, let me try something else.
Don't tie your identity to a specific
technology or set of practices. So I see a lot of people saying
that I'm a Kotlin developer, or I'm a Python developer,
or I'm an Android developer, and people who say that
kind of thing, that people who are not Android developers or not Kotlin developers are
not like me. And probably sometimes I see them as kind of
competitors or enemies or something like that.
Or maybe I say that they are stupid and don't know what they are doing
and instead they should be using the best language on the planet,
which is Kotlin. I don't think this is healthy.
I don't think this is good. I think that it's much better to just
identify yourself as a developer and learn the tools. Learn what
tools exist, learn tools, what tools can benefit you in
which cases and use the best tool for the
job and base your identity on
something else and not on that. Believe me, during your career you will have
to learn many different languages. And it is wonderful.
Each language language is different. Each one can teach you something
new and change how you approach programming overall.
For example, I wrote very different code when I coded in
Java. Then when I learned Objective C, it changed.
When I first touched Swift, it's once again changed and
each language placed its mark on me.
So learn different programming languages, embrace them and
stay open. Don't be afraid to learn something
unnecessary. So, for example, speaking of Kotlin,
a very common question of people who start to learn Kotlin
is do I have to learn Java? And this,
do I have to learn? I think it's not the best way to put things
like Will learning Java make you a better Kotlin developer?
Yes, definitely. Because you will be easier able to understand the APIs of different libraries
that you probably will want to use. You'll better understand
how this whole environment works, things like
that. You will better understand why some things in Kotlin are the way they are
and not something else. So don't be afraid to
learn something that isn't necessary.
As we advance our careers as engineers and it doesn't matter
whether you're a consultant engineer or a product engineer,
you will be working with people like more and more.
Inevitably you'll be reading the requirements,
their stories, their comments. You'll be writing the same thing.
You'll be speaking, you'll be communicating, you'll be explaining,
presenting. You'll work with people a lot,
sometimes more than you work with code, especially if you measure your time minutes
in the day and sort of best.
Engineers are also just great at
working with people in everything that that entails.
Don't stick to one career. You're not doomed
to be a software developer for your whole life.
Take me as an example. I learned to be an
information security specialist, then I became an Android
developer, had to switch to iOS development, then I became
a team lead, did some backend development, then I became a
manager and then a product manager. And now I'm leading
a development of a programmin language.
And that's actually great because in each role you
learn different skills that may help you in the main
one if you decide to return it. For example,
if you'll become a product manager, you will be much better in
understanding what and why and for whom you are building.
It will drastically help you to become a staff plus engineer
because you will not just write code, you will think about business needs or
for example, if you are becoming a team lead and then decide to
stop doing it. It will teach you other essential
skills like how to plan your time and time of
other people, or how
to make decisions in uncertainty
or other things. So don't stick to one's career.
Your life is long. You can try different things and find
a one that suits you the best.
When you're young, it feels like you can work 20 hours
a day or 18 hours a day or something like that.
And it's a lot of fun to
write software. You may end up like with your
day job and your hobby project, like working for eight hours on
one thing and then another eight hours on the second thing.
And this is kind of fun. I did a little bit of that when I
was younger, but I think it's very important to not
focus on that, not close your eyes
to other things, other fun ways to spend the time, other ways to take care
of your body, your emotional
state, your mind, read things,
go for a walk, do some physical activities. I think finding
a healthy balance between all of these will allow you to sustain your productivity
and sustain the joy that software development brings you for a much longer
amount of time. Keep learning new things, go deeper, go wider.
Look at how things are done nowadays. If there is a new big
trend, look into it. Like nowadays, that's generative
AI. Look into that. It will help you stay up to date.
It will help you be a better engineer and also just aim higher.
In general, a lot of people underestimate themselves and just don't
try things they could have succeeded at. And you
should do that. You should try, you should experiment with
the things that you feel are out of your league. You should apply
to jobs you think you're not good enough for,
and you should prepare for those interviews and get the job you can.
So that's like top piece of advice that I can give and
learn.