How do I become a good backend developer?
hey guys so today we are answering a
subscriber question and the questioning
question was Frederick how do I become a
good back-end developer so let's get
into it well this is a big question a
very very very big question so I can
only touch on the things that I think
are probably the most relevant for well
for back-end developers so one of the
first things that you really need to
have a good understanding of in order to
be a good back-end developer is
architecture
so the actual bare bone basics of coding
is just one part of learning how to be a
good backhand developer but most of what
you're going to find is that you're
gonna spend a lot of time maintaining a
fairly large system and in order for you
to understand how to do that in an
effective manner it is vital that you
understand not only software
architecture at the code level but also
at the infrastructure level with
services and distributed system
monoliths all this stuff all these
people who come and like you throw out
the term micro services and I think
monoliths are like have
absolutely no idea what they're talking
about and that is the right you knowing
the differences and knowing when one
solution is better than another that is
architecture like making informed
decisions not going on a type train or a
trend way with everybody else so that is
one of the first things and in order fee
I would strongly suggest that you have
looked at a fairly old book called
domain driven design it will teach you
one of the most important lessons when
it comes to being good at software
architecture and that's all I'm gonna
say you can have a look at the book it's
going to help you a lot in your career I
can promise you that second apart from
having a good understand of architecture
and you know good practices and all that
good stuff is going to be to understand
business requirements to have a really
really strong and good understanding of
how the things that you are building
correlates to the business because if
you are bad at community communicating
with your stakeholders
other domain experts because it's very
unlikely that you are going to work on a
system where you are the only person who
you know who's maintaining that and
you're the only person who basically
dictates how it's gonna work
it's very likely that you're going to
have business partners or other
employees around in the office who have
a say in these matters and your ability
to effectively communicate with these
people and make them understand the
limitations and like the considerations
that you have to make and the stuff that
they have to I can understand their side
of the whole thing is absolutely vital
because the system that you are building
is a reflection of the company itself
and that ties into this domain driven
design mindset that I've I touched on
earlier so that I will say is the
absolute one of the most important parts
after that understanding I cannot stress
enough how important how important it is
for you to have a business mindset you
need to understand the business because
you cannot build a good system without
understanding the business it's it's
well it's that important I would say and
lastly I would say that in order for you
to be a good back in developer having a
well having a pragmatist mindset is a
very good thing as well it's and I would
say that this has it this is this is not
just for back-end developers this is
true for all areas of software
development being a pragmatist and
trying to keep things as simple as
possible is a very key component into
all of this because it's there is
extremely likely that the system over
time will grow to be it just you know
it's going to grow exponentially
complicated and having an understanding
or like a and kind of acknowledging that
all relic immediately and understanding
that is riding soft good software it's
not about being smart it's not about
trying to be clever impress anybody with
your code or trying to you know flame
somebody in a
cover you because they're not using
single quotes or by like whatever
they're doing right it's just not
productive behavior and being able to
understand that and trying to go for
simplicity as much as possible and
sustainability is a much more it's a
better bet because the it's inevitable
it doesn't matter how amazing software
you write you are going to have a system
that is so complicated that not one that
no one single person can can have it all
in their heads that's the sort of system
sizes we're talking about when you work
for a company that actually makes money
from something you mean even the small
apps that you may have on your phone are
likely more complicated than like that
one person can actually understand there
are exceptions of course but having that
mindset you just the egg pragmatist it
you know software development it's not
about you trying to impress somebody
it's not about you it's not about the
craft it is about delivering business
value it is about money it is about you
shipping code that is sustainable and
that is a very good fit and a very good
reflection of the needs of the company
that you are working for and that is
very contextual some people who don't
like this because the purists among us
feel as often at least from my
perspective than from what I can see
they feel like the craft of software
development is more important that the
business value that it provides and that
is not true
I'm sorry to say we are build that we
are making software in order to produce
a result I solve a problem for a company
of some sort and that is the harshness
of the reality if you just want to write
software because you enjoy writing clean
nice code then you have to do that on
your own time most likely or get a job
where this is something that is
encouraged so that's probably what I
want you to take away from this so what
I want you to take away from this is the
first and foremost in order for you to
be a good back in developer you need to
have a really good understanding of
software architecture that is absolutely
key learning how to write the code it's
just the basics learning how to you
use the correct network protocols or
like the right architecture for your
infrastructure if it's micro services or
just services or monoliths or whatever
that is extremely important because I
can trust me every single company has a
different set up all of them they call
them they use the same term sometimes
but all of it looks different than the
way that the business wants things to
work is going to be a very you go you're
going to see a strong connection between
the way that the business work and how
the code is actually structured at their
architectural level and not just at the
network level of course but also at the
code level and having a good clean
architecture second thing and these
three they all kind of tied together you
know the second part is to understand
the business have a business mindset you
will see I promise you that you will see
that the way that the company works is a
reflect the code is a reflection of that
so just you know have best practices
with you learn how to write things
really really well but you need to you
need to remember that the the way that
you structure your code should be a good
fit for the company it doesn't matter
what some person on the internet says or
some book tells you if that's a bad fit
for your company that's why you need to
be able to make an informed decision and
have a really strong good understanding
of the company and its needs because
that's when you can make the really good
decisions on behalf of the company
regardless of what those are they might
be bad decisions in the eyes of some
idealist tik-tok person somewhere but
that doesn't matter because they're not
working at your company anywho the last
part is to have a really pragmatic
mindset to understand that you are
writing software for a purpose of some
sort it's not about being like having
flawless code reviews and pushing for
the absolute best practices it's about
shaping value and structuring things in
such a way that it's enables other
people to be productive it's about
simply you write the simplest code that
you can write because nobody like
honest-to-god nobody cares how clever
you are especially not when you're
clever code turns out to become turns
into legacy because of some unforeseen
new requirement that your
super solution doesn't accommodate a
been there many times I've seen people
who are praised for their genius and I
can already see I already know that once
this is in once their genius solution is
in well it's once it's in it's going to
stay there and I can already know from
previous experience that it's just a
matter of time before it becomes a big
issue for the company it's happened so
many times that it's not it's almost a
self-fulfilling prophecy so don't make
that mistake try to write things as
simple as you can possibly make them
loose coupling all this good stuff these
are good practices to follow and I'll
give you one last one and that is to
remember that software is not about the
software is not about software code is
not about code it is about solving a
business problem keep that with you and
the rest will start to fall into place
once you get a little bit of experience
have a great day
