Up next in 10
10 Weird Signs of an Inexperienced Self-Taught Programmer
2K views
Feb 7, 2024
"10 Weird Signs of an Inexperienced Self-Taught Programmer" is a video that humorously identifies common behaviors or traits observed in self-taught programmers who are relatively new to the field. The video likely highlights quirks or mistakes that may indicate a lack of experience or formal training in programming. These signs could range from misconceptions about coding practices to inefficient problem-solving approaches. By humorously presenting these signs, the video aims to provide self-taught programmers with insights into areas they can improve upon and guide them towards a more polished and professional skillset. Viewers can expect an entertaining yet informative take on common pitfalls encountered by self-taught programmers.
View Video Transcript
0:00
One was titled five weird signs of an inexperienced self-taught programmer
0:03
And the other was five weird science of a mediocre self-taught programmer
0:08
We're going to see what he has to say. And I'm going to share my perspective. First point is that they choose the same tech stack
0:14
Self-taught people have a habit of choosing the same tech stack. They are not prepared to step out of their comfort zone
0:19
They don't want to learn anything new. If a manager asked them to learn a different language, they try to
0:24
convince their managers and team YX language they know will be better for that project
0:28
I really don't see how that ties specifically to a self-taught engineer. There are programmers who just want to focus on one programming language
0:36
That is their comfort zone. And then there's others who are more flexible and willing to
0:40
work across technology stacks. I think it's only natural that people are going to be inclined to work with the
0:47
languages and the tech stacks that they know when starting a new project, whenever possible, but generally speaking, good software engineers will be flexible and
0:54
willing to use the right tool for the right job. He goes on to say that they are not prepared to get comfortable with the
1:01
uncomfortable as a developer, you can never grow in the industry. If you can't get out of your comfort zone
1:08
I agree with the main point of it being important that you get out of your comfort zone, but that doesn't really have anything to do with whether you're
1:14
self-taught or whether you've got a computer science degree. Number two, they have the attitude of just making it work
1:20
Inexperienced self-taught programmers don't care about code quality. They don't focus on their own code style
1:25
They just want to build the desired feature in the app. Honestly, I think most people, when they're just starting out, really don't
1:33
Care. It's not that they don't care about code quality. They just don't know about code quality because that's something that comes with experience
1:39
And as you learn from your mistakes and how to improve things, I don't think
1:43
that's really a self-taught versus like a computer science thing. I do think that if you go through a computer science program, there's a lot
1:49
higher probability that during your coursework, that there are going to be
1:53
discussions on having good code. And you might learn about some of the things that make a good code, but until
1:59
you're actually in the trenches writing code, that's really where you're going to
2:03
be learning it. And I know people from both sides, self-taught and those who have computer
2:07
science degrees who don't care as much about like the code quality
2:12
And at the same time, there's those on both sides that are just amazing and really focused on it
2:16
So it's very much an individual thing, not necessarily tied to whether you're self-taught or not
2:20
They don't understand that sometimes when programmers try to write high quality code, deadlines can't be met
2:26
Deadlines have to be pushed in those situations. I know that seems kind of a stretch for the point that he was making here
2:33
Number three, they write duplicate code. No developer wants to maintain a project whose code is not well-written
2:40
If a code base contains code that has been posted thousands of times, it becomes difficult to manage
2:45
And this is really true. Like if you are writing code and you're just taking copies of something you did
2:49
and just stamping it all over the place through the code base, it does become difficult to manage because if you need to make a change to one of those like
2:58
components, you also have to go make that change everywhere else and hope that you
3:02
catch everything. So you don't end up with inconsistencies across the application
3:07
And experienced self-taught developers duplicate code a lot. They believe that if the software works properly, there is no need to remove
3:14
duplicate code. I think the key word here is inexperienced, not that it's self-taught
3:20
developers, because that is something that everyone tends to go through. A lot of people, when they're starting out, will take something they've done
3:28
and tend to stamp things out. And it's like this phase that you go through
3:32
You start off doing that. And then all of a sudden you start learning about the principles of having dry code and trying to prevent that
3:38
And then you actually can swing to the other extreme where you're so focused on
3:43
having reusable code that you start making these behemoth reusable components that can do everything
3:49
And then they can become really hard to manage. And you might even be adding features to those components that just aren't even
3:56
going to be used. And then eventually you kind of try to find this happy balance between writing
4:02
dry code and not doing something called over-optimization. They forget that by copying and pasting the same code, they're making the code
4:10
base bulky. They tell you that all these extra codes will only take a few seconds to execute
4:15
Honestly, I haven't heard many people actually say that in real life. I mean, yes, the more you stamp out code and the more lines of code, the larger
4:24
your code base. That's pretty obvious. Number four, they don't do any unit testing
4:28
Inexperienced, self-taught programmers have a false belief that no test case could break their code
4:35
They check their code just by making code calls along with some manual testing
4:39
This is just a very broad generalization. Again, nothing to do with whether you're self-taught or not, you know, whether you
4:45
end up liking unit testing or not. Now, if you're using like Odin project or Free Code Camp and stuff, they have
4:53
modules on actually testing so you can learn to test. This really does come down to the individual and how much time you want to
5:00
put into learning how to do the different kinds of testing. You also have to remember that there are a lot of opinions out there, strong
5:06
opinions on both sides from less testing to more testing. And there's valid reasons for that
5:13
Here he says that after talking to programmers, I can tell you wherever possible, take test-driven development approach
5:19
It is the only thing after which you can trust your code. Well, that's simply not true because there's like tons of applications out
5:25
there that are built that use testing, but don't use test-driven development
5:29
If you're not familiar with you doing the test-driven development, that's where you write your test first and then you write the rest of your code until
5:37
that tests, all those test cases actually pass, whether that's the end all be all
5:42
of how you should approach things is highly debatable. There are going to be lots of times where you're building things and you
5:47
might not even know exactly how everything is going to turn out, what
5:52
all of the possible edge cases are. And if you only have a narrow set of edge cases defined and you write tests
5:58
for those and you pass it, you think, Oh, I'm done. Well, that could be a problem because you haven't handled anything
6:03
Now you could also miss edge cases when you write their unit tests afterwards
6:08
but there are definitely times. And I've worked on projects where it simply just doesn't even make sense to
6:13
do test-driven development because things are so agile and so on the fly
6:17
And you don't even know what you're working with until you get it. That said, I do believe that doing unit tests are important and there is the
6:24
balance and I tend to be more in the middle on this where a hundred percent
6:29
code coverage can be very extreme. And oftentimes just adds a lot of boilerplate that you start seeing
6:35
people use tactics just to get that coverage when those tests aren't
6:40
actually providing any value. Number five, they run after the most hyped technology
6:46
This is the most fun. I find a self-taught man running after the most hype technology
6:50
I consider him inexperienced. So if you're interested in anything that is coming out new, then you must be an
6:58
inexperienced software engineer. And you can call me a little biased. Well, the dude is biased
7:02
I found that inexperienced programmers are the ones who talk about the next big
7:06
thing, each and every one of them wants to work with the latest technologies
7:11
What about those people who are passionate? I know tons of software engineers who like to stay up on the latest
7:16
technology so that they know the best tools to use in the future for future projects
7:22
Does that mean they're inexperienced just because they're passionate about learning about software technologies and frameworks and libraries that are coming out
7:30
Or what about those who are trying to stay up on what is highly in demand in
7:34
the industry and where things are changing so that they can position themselves to be in demand when it comes to new jobs so that they can grow how
7:42
much they make as a software engineer as quickly as possible. A little bit further down, I've noticed that these inexperienced self-taught
7:49
programmers have gone through a video tutorial on the latest technology. After watching the video, they start to consider themselves experts in that field
7:57
I don't know a lot of you who've been telling me that just because you just got
8:01
started and you're starting to learn a new framework and get your foot in the
8:04
door with programming, that you're an expert in the field. That doesn't seem to be the case
8:10
I know I didn't feel that way when I was starting out and I started feeling comfortable with AngularJS
8:14
I didn't feel like I was an expert. Shoot, in some areas I still don't feel like I'm an expert
8:19
All right, so five weird signs of a mediocre self-taught programmer. Number one, they write clever code
8:25
Clever code is good for showing off your skills, but clever code is highly unreadable
8:29
The tricks you've learned while learning the code don't work professionally. Mediocre self-taught developers think they could impress the reviewer with
8:35
their cool tricks. What he's talking about here with clever code is that you have kind of the
8:40
fundamentals of a programming language and how to do things, but you could get
8:45
into some kind of creative ways to do things. Maybe an unusual way of doing something with like bitwise operators that you just
8:51
don't see being used very often. And those kinds of things could be called clever code because it could really
8:58
shrink down the amount of code that you need to do something, but at the expense
9:04
of being readable and understandable. And if it's something that's unusual that works, but that just a lot of people
9:10
don't know what's happening, then it can cause more problems with someone's
9:14
trying to debug and figure out what is going on. And a lot of times we try to favor having something that is understandable
9:20
readable over being so over-optimized and clever, as he put it. And I agree that we should all avoid clever code, but I don't think that that
9:30
is something that is just specific to self-taught software engineers. I've seen plenty of people with computer science degrees do that
9:36
And I think this is also one of those situations where you go through phases as you get more comfortable, you start thinking, Oh, this is cool
9:42
I discovered something new. I'm going to try it out. And then you find out that the person doing the code review is like, what
9:49
what is even going on here? You go to explain it and they're like, yeah, maybe write it somewhere else
9:54
So I think this is something that we tend to fall into more as a new programmer
9:59
not so much just as a self-taught programmer. And I'm totally guilty of having made that mistake myself
10:04
Number two, they keep repeating themselves. After going through the code of many self-taught, I can say that they
10:09
have a habit of repeating the code. Okay. This is, it looks like one of the points on like the previous article and stuff
10:15
where he's talking about not stamping things out and, you know, having dry code
10:19
So we aren't going to like repeat that. Number three, they don't stick to fixed code style
10:25
I think he meant fixed mediocre developers don't care about code style
10:30
So it is interesting here. Something I am noticing is that compared to the last article, even though the title
10:35
has self-taught, you know, programmer, like scattered all over the place in this
10:40
one, he uses that in the title, but then there's more of like the mediocre
10:44
developers don't care about code style. He's targeting self-taught in the title, but not as heavily in the article itself
10:52
You're saying that they don't stick to a code style. And what he's talking about here is that for a lot of companies or projects, you
11:01
have kind of a predetermined way to do things to maintain consistency across the
11:07
code base. So if someone goes into work on like one file, they kind of know what's going on
11:12
and how things are structured. And there's some like basic patterns to follow, which can be good at making the
11:18
code base more readable and helps with like onboarding new software developers
11:24
It says a large code base that has multiple developers working on it should
11:28
appear to have been written by a single developer. So that's a very cool and ambitious goal
11:34
But the fact that we're all different, that simply is not going to actually ever happen
11:39
The code will look like it was written by one person, unless it's a super small
11:43
application with very little complexity to it. You can have a lot of consistency, but there are always going to be differences
11:49
just in how we kind of choose to, you know, pick our names and things like that
11:54
Believing that you can actually have a really large code base that was
11:58
contributed to by lots of people and that it will look like is all written by the same person just is not likely to happen
12:04
And frankly, this has nothing to do with whether you're self-taught or not. This comes down to you are presented with a style guide
12:11
And are you the type of person that likes to conform to a certain style guide or
12:16
are you not? I know plenty of like experienced people who disagree with some of the more
12:19
stringent style guides out there. And there's others who love it. Number four, they over-complicate simple things
12:26
A powerful principle in software and development is called KISS. And it's not just software development
12:31
It's in a lot of domains. KISS stands for keep it simple, stupid
12:35
A mediocre developer never tries to simplify things. The code written by them contain sections, contain complex
12:41
algorithms for simple problems. And this is one of those things that whether you're self-taught or whether
12:46
you come from a computer science program is that you aren't going to know how to
12:53
do simple solutions to complex problems until you actually encounter them. You work through them
12:58
You look back and learn and find new ways to do that. Now, someone who comes from like a computer science background, they will
13:03
have taken classes on algorithms. So they're going to know a lot more of like the common algorithm
13:08
So, you know, they definitely could in that situation be able to pick up that
13:12
kind of stuff a lot faster than someone who's self-taught, but by no means is
13:16
that only available to people who are self-taught, there's a lot of self-taught
13:21
programmers who spend a lot of time learning about data structures and algorithms and reading books on clean code
13:27
One of the things that a lot of people who are starting out who are self-taught, you know, may not be super familiar with is time complexity and understanding
13:35
how to have performant code. And that's something that they could use, definitely pick up over time
13:40
But this is not just, you know, limited to self-taught software engineers
13:46
I know plenty of people who have computer science degrees, who can overcomplicate it plenty with who are self-taught, who can overcomplicate
13:52
things, and there's been plenty of times where I've overcomplicated things. Number five, they hate to teach
13:59
Whoa, rockstar developers are great teachers. Not true. So rockstar developers, you know, may be amazing at writing like
14:07
the best code in the world. That is no guarantee that they are good at teaching
14:12
In fact, you know, a lot of people joke that, you know, those who can't do end up teaching
14:16
So here's saying a mediocre self-taught don't want to explain anything to other developers
14:23
They don't want to, or is that just like a personality type thing
14:28
This has nothing to do with whether you're self-taught or not. How good you are at teaching really does come down to the individual
14:33
Some people are more apt to be able to explain things well, or they enjoy
14:39
communicating with other people and teaching to other people, and then there are other people who tend to be more quiet and they can be super
14:46
brilliant at figuring things out that hardly anyone can, but, and they might
14:51
be the person who is just sitting in the corner quietly, listening to absorbing everything and coming up with solutions to the problems, but they
14:59
might really struggle with communicating. A lot of programmers struggle with communicating that has nothing to do
15:04
with whether you like to teach people or not, or whether you're a great teacher or
15:09
not, good developers, always ready to go back to the whiteboard. They're ready to explore their own thought process
15:15
They'd never run away from giving an explanation on a subject. Actually, I think it would be wrong to never run away from giving
15:25
an explanation on a subject. Sometimes you don't have a good explanation to give, and a smart
15:31
programmer isn't going to just step up and pretend to know things that they
15:35
don't and ramble on and mislead and just, you know, put themselves out there
15:40
They're going to hold back and defer to someone else that they know actually has experience in that topic
15:46
I would actually be more cautious if I didn't know someone and they had an answer to everything, I would want to double check that they actually knew
15:53
what they're talking about, because I have encountered people who have answers
15:58
to everything and can talk very convincingly, and they just don't know
16:03
what they're talking about in some cases. It seems that very little of what this guy has said is actually tied to whether
16:10
you're self-taught or not, and has more to do with where you are in your
16:15
progression, are you new with less experience and, you know, compared to
16:19
someone who is more experienced, you'll learn and you'll progress. And a lot of these things you'll pick up as you have more experience
16:26
I think there's a value in knowing these topics so that you can try to incorporate
16:31
that in the stuff you're learning and studying, and as you try to become a
16:35
better software engineer, but frankly, I've seen people on both sides of this
16:39
who are weak in these areas, take it as a grain of salt, the fact that the
16:43
articles target specifically self-taught programmers, because if you use this criteria to try to figure out if someone is self-taught or not, you're probably
16:52
going to be wrong more times than not. Thanks for watching, and I'll see you in the next one. Late
#Computer Education
#Computer Science
#Distance Learning
#Education
#Programming