[Music]
Too many values to unpack!
[Music]
[Applause]
You just use stack overflow to make
things work somehow, now you are thinking
you are the smartest programmer on the
earth.
That's the number one mistake that most
of the junior programmers make,
which is the moment they are given a
task, a Jira story in their software
development project, they immediately
start writing the code. So they don't do
enough thinking before they write first
line of code, and while they're writing
the code also, they just go to stack
overflow copy paste the code and make
things work somehow.
There are four dimensions of this
thinking process that I want to talk
about.
The very first dimension of that
thinking process is think like an end
user. Let's say this little panda is the
end user of your website, then ask why
does this panda need to add that new
button on my website.
People argue that my business manager
has done enough thinking and given me
this beautiful requirement document and
my job is to translate that requirement
document into a working code. Well! Again
wrong. You are not a stupid code monkey,
whose job is to
translate some requirement document into
a working code. You are
a
problem solver. As a full stack engineer
you need to be understanding your
business problems, and
writing
good code that can actually solve those
problems. And sometimes
not writing a lot of code can help the
end user better. He's your end user. You
see his face!
I have a friend who was given a project
to work on and he thought
we should not be working on this project
because there is this existing solution,
which we can just customize it and use
it and he spent a lot of time in
thinking before writing the first line
of code and the project got cancelled, he
saved a couple of million dollars for
the company. See as a programmer, it's not
like you have to write code. Sometimes by
not writing code, you can be helping your
company and that thing comes if you have
a good business understanding, which
requires that you have a lot of
discussions and meeting with your
business manager.
If
it is possible try to do shadowing
sessions
with your end user. So that end user is
using your software, you're sitting and
you're asking questions. You see them
using your software so you understand
their habit patterns better
and things like that, and you don't have
to think that will I look stupid if I
ask this question. No question is a
stupid question. That's how you build
domain understanding. That's how you
become a better software engineer. The
second dimension of that thinking
process is Data Structures and
Algorithms.
Without data structures and algorithms
you cannot be a good programmer period.
If you want to improve your data
structure fundamentals,
watch my tutorials on youtube, where I
have given tutorials on both- data
structures and algorithms, along with the
exercises and there are few other
resources that you can follow such as an
awesome website called Gigs for Gigs.
Gigs for Gigs website has a lot of good
resources, free articles on data
structure and algorithms and you can
practice
different type of
dsa
problems on this website. Other than data
structures and algorithm they have a lot
of material on interview preparation. I
myself have referred to this website
whenever, I have appeared in any job
interviews. These
these
questions are excellent and if you solve
it, your
chances of getting selected in any
company will increase.
And they have a lot of courses as well,
that you can explore live courses, online
courses both. And just take those courses
learn those things and make your
programming skills better.
They cover a wide range of topics from
C++, Java, Python, competitive programming.
Recently they added machine learning as
well check it out. Majority of the
content on this website is free. So you
have a bunch of customer records and
these records have the country that the
custom the customer belongs to and you
want to retrieve unique list of
countries for all your records. Now you
can use list as a data structure
and then remove duplicates later on. But
if you have if you have a knowledge of
set data structure then you can use that
in first go and it will
not only make your code compact but it
will reduce bugs too. Now you see how
data structure knowledge can help you
write better code. The third dimension of
this thinking process is design
principles
and scalability and performance
considerations. Even as a junior
programmer, you need to be thinking about
how how better
you can make the system design and there
are many resources that you can refer to.
For example, my friend Gaurav Sen has this
amazing youtube channel where he talks
about
system design and general you know
principles behind scalability and
performance. The other good resource is
Designing Data-Intensive Application.
That book is like a must. Once you read
that book
you get a lot of knowledge on designing
better system overall, and that can make
you a good programmer overall. Martin
Fowler's blog is another great resource.
Nowadays, if you appear for an interview
in any of these fang companies or any
man companies,
they will ask you system design
questions.
Fourth dimension is you should not be
afraid of refactoring the code. You're
working on this code base, which is
designed by some expert programmers in
your company who are your seniors but
doesn't mean that they are right all the
time. They can be writing a creepy crappy
messy code, whatever.
As a junior programmer you need to be
thinking that okay, I'm all powerful I
can write
better code, I can refactor things. So
don't be afraid of refactoring. This is
one common mistake that I've seen people
make, especially junior programmers.
[Music]
Hey, can you tell me something about
yourself?
I am Daval Patel. I am a react native
developer.
You what!?
I am
I'm a real native developer. I like to
build application in react native. It is
so cool.
And that's the second biggest mistake
that most of the junior programmers make.
Instead of saying I want to build
world-class scalable responsive mobile
applications,
they say
i am a react
native developer. They get too much
attached to a specific framework or
programming language. We all know
these frameworks and programming
languages, they evolve. They come and go,
and if you have too much unnecessary
emotional attachment, you're putting your
career in danger. You need to have this
attitude of a problem solver. "I'm a
problem solver, I can
take a business problem use technology
to solve this problem" and this theme is
very much conveyed in this famous clip
of the movie 300. You,
yeah
where's your profession?
I'm a potter.
And you,
Arcadian
what is your profession? Sculptor sir1
You?
Blacksmith.
spa tags
what is your profession?
If you don't have this flexible attitude
of a problem solver what will happen is,
let's say you are a java programmer. You
are given a task of machine learning. Now
you will try to do machine learning in
java, which is not a good idea. You know
python or R
are probably the languages you should be
using for machine learning. So
you have heard this code before, correct.
[Music]
The third one is they get so much
obsessed with tutorials and
certifications that
they get machine learning certificate,
then devops certificate, and then some
cloud certification.
What the hell you're going to do with
all these certificates? They're useless.
Focus more on the implementation.
Focus less on consuming the tutorials
and consuming
the the information related to various
programming concepts.
Because the internet is full with so
many courses so many youtube videos and
there is
you know, even let's say I want to learn
kubernetes. You will find hundreds of
tutorials and if you keep on watching
one tutorial after, other you're not
helping yourself. Just watch one tutorial
and try to implement that freaking thing.
You know that's how you learn the things.
You want to learn swimming? All right do.
This watch 10 swimming videos. What's
gonna happen?
Nothing.
You have to jump in the pool
and try it out yourself.
The fourth one is not giving enough
importance to debugging skills and
productivity tools.
I know many junior programmers who don't
know even what is conditional breakpoint.
Do you know what is conditional
breakpoint, by the way? Well, I have a nice
video, which you can watch.
But the point I want to make here is
as a programmer you're stuck in this
repetitive iterations, you know where you
write some code you get some error you
debug it you fix it write some other
code. So if you want to improve the
efficiency of these iterations, you need
to have a very good debugging skills
where you learn about things like
conditional breakpoint,
how to debug your code in ide in general,
the call stack, the
watch variables, you know stepping into
the code, stepping out of the code things
like that. You need to have a good
understanding of all those amazing
concepts.
Productivity tool is
another thing
I have seen programmers
who just try to do things with the with
the mouse, you know you need to
get yourself familiar with the shortcuts.
The keyboard shortcuts of ide and you
can work
really fast. Let's say there is a menu
you want to open in ide, and now every
time you're going and clicking the
button. Instead of that if you know the
con shortcut, let's say ctrl + j,
you're saving two second on each
iterations and this way you can improve
your efficiency
uh a whole lot and that's a common
mistake I have seen with the new
programmers that they don't spend enough
time in learning productivity tools, in
learning
debugging tools. You know many times you
can install
plugins. Let's say you're using visual
studio code.
Well install this plugin called github
co-pilot, which can just auto suggest the
code. You know people don't spend too
much time in the actual setup and then
they suffer eventually. And the last one
is over engineering, overthinking
and
you know just spending unnecessary extra
time in coming up with the designs, which
which might not be needed. You know don't
build for the future.
Just be very reasonable in your approach.
Do enough
design thinking,
but don't over engineer things. There are
for example, if you're using python there
are so many ready-made models out there.
So just use them you know don't try to
reinvent the wheel and that's again one
of the common mistakes I've seen
programmers they tend to over engineer
things and tend to
make things unnecessary complex. You know,
you are in your sprint cycle. You want to
get this feature out and
you need to have a reasonable approach.
Of course, think about system design,
think about code quality
but don't go extreme. You know the first
point we discussed was not doing enough
thinking but this is another extreme
where some junior programmers do too
much over thinking. Right so those are
the common mistakes that I have come
across in my professional career of 17
years of programming, mentoring so many
junior programmers, interacting with
people through my youtube channel
and that's a pattern I have seen. If you
know about any other common mistakes
that the new programmers make, please
post in a video comment below and I will
try to respond and we can have a
discussion. Thank you very much for
watching and I wish you all the best
[Music]