5 Signs of an Inexperienced Self-Taught Developer (and how to fix)

Summary

This video script addresses the challenges faced by self-taught developers in the tech industry, often perceived negatively by computer science graduates. The speaker outlines five signs of inexperience in non-traditional developers, such as focusing solely on making code work, making large changes to the codebase at once, constantly learning new languages without mastering concepts, working on too many tasks simultaneously, and avoiding code reviews. The script encourages embracing these criticisms as a learning opportunity to improve and grow in one's programming career.

Takeaways

• 😀 Self-taught developers are sometimes looked down upon by computer science graduates, who believe they give software engineering a bad reputation.
• 🔍 It's important for non-traditional developers to stand out by being good, reliable teammates and producing quality work.
• 📝 Sign 1: Inexperienced developers focus solely on making their code work without considering maintainability, readability, or scalability.
• 📚 Sign 2: They make large, sweeping changes to the codebase at once, leading to big pull requests that are hard to manage and review.
• 🔄 Sign 3: New developers often jump from one programming language or framework to another without mastering the underlying concepts of programming.
• 🔑 Sign 4: Working on too many tasks at once can lead to a lack of focus and reduced quality of work; it's better to complete one task at a time.
• 🚫 Sign 5: A reluctance to have others review and critique code can hinder growth and improvement as a developer.
• 📈 To improve, developers should plan their tasks, commit often with tested code, and break down large features into manageable parts.
• 🌐 Learning programming concepts is more beneficial than learning multiple languages, as the core ideas can be applied across different syntaxes.
• 🤝 Embrace code reviews and feedback as a way to learn and improve coding practices, rather than avoiding criticism.
• 💼 Focus on delivering quality work and becoming a reliable developer rather than juggling multiple tasks and spreading oneself too thin.

Q & A

What is the main concern expressed by the speaker about computer science graduates towards self-taught developers?

The speaker suggests that computer science graduates may view self-taught developers as imposters who are giving software engineering a bad reputation, and they believe the industry should be regulated to ensure only qualified individuals are involved.

What are the five signs of an inexperienced, non-traditional developer according to the speaker?

The five signs are: 1) Thinking only in terms of making code work, 2) Making huge changes to the code base at once, 3) Constantly learning new programming languages or frameworks without mastering the underlying concepts, 4) Working on too many different things at once, and 5) Avoiding having others see or critique their code.

Why is it important for developers to move beyond just making their code work?

It's important because, over time, developers need to consider the readability, maintainability, and scalability of their code, as well as how it fits into the existing codebase, to ensure long-term success and collaboration in a team environment.

What is the recommended approach to handling a new task or feature in software development?

The recommended approach is to first make observations, gather information, and understand the requirements before writing any code. Then, plan the feature, commit often with each completed task, and test each commit. Finally, push the code and create a pull request for review once the feature is fully working and tested.

Why should developers avoid making huge changes to the code base at once?

Making huge changes at once can make it difficult to diagnose problems, as it's hard to pinpoint what exactly caused an issue. It's better to make smaller, more manageable changes that can be reviewed and tested more easily.

What is the speaker's advice on learning new programming languages or frameworks?

The speaker advises focusing on mastering the underlying concepts of programming rather than learning many different languages for their syntax. If learning a new language is necessary, it should be done with a focus on understanding the deeper concepts, such as by learning a lower-level language.

Why is it beneficial to focus on one task at a time as a new developer?

Focusing on one task at a time allows a new developer to fully understand the requirements and deliver high-quality work. It helps in building a reputation as a reliable team member who consistently meets deadlines and produces maintainable code.

What is the speaker's view on code reviews and their importance in a developer's growth?

The speaker views code reviews as a crucial part of a developer's growth, as they provide an opportunity to receive constructive criticism and learn from more experienced developers, ultimately leading to better coding practices.

How can a developer ensure that their code is maintainable and scalable?

A developer can ensure maintainability and scalability by considering the design and structure of their code from the beginning, using best practices, and regularly refactoring to improve code quality.

What is the speaker's suggestion for handling criticism of one's code?

The speaker suggests embracing criticism as a learning opportunity, using it to understand areas for improvement, and applying the feedback to enhance one's coding skills.

Why is it important for developers to commit often and create pull requests for review?

Committing often and creating pull requests allows for continuous integration and feedback from the team, which helps in identifying and resolving issues early in the development process, ensuring code quality and collaboration.

Outlines

00:00

💻 The Struggles of Non-Traditional Developers

The speaker, a self-taught developer, addresses the prejudice they face from computer science graduates who believe that non-traditional developers are tarnishing the reputation of software engineering. They argue that the industry should focus on competence rather than formal education and propose five signs that may indicate inexperience or a non-traditional background in programming. These signs include a tendency to focus solely on getting code to work without considering broader implications, making large, sweeping changes to code bases, and a reluctance to have one's code reviewed or criticized.

05:02

📚 Embracing Growth as a Non-Traditional Developer

Continuing the discussion, the speaker offers advice for non-traditional developers to overcome the challenges they face. They emphasize the importance of learning programming concepts deeply rather than superficially across multiple languages. The speaker also advises against spreading oneself too thin by working on too many projects simultaneously, suggesting that developers should focus on one task at a time to ensure quality and mastery. Additionally, they stress the value of code reviews and the willingness to accept and learn from criticism, as this is a crucial part of growth in the field of software development.

Keywords

💡Self-taught developer

A self-taught developer is an individual who has acquired programming skills without formal education in computer science. This concept is central to the video's theme, as it addresses the challenges and stereotypes faced by such developers. The script mentions that computer science graduates may view self-taught developers with disdain, indicating a tension between traditional education and self-learning in the field of software development.

💡Engineer

In the context of the video, 'engineer' refers to a professional who applies scientific principles to design, build, and maintain structures or systems. The script discusses the desire for proper regulation of the term 'engineer' in software development, drawing a parallel between traditional engineering disciplines and web development, suggesting that the latter should be recognized with the same level of professionalism.

💡Imposters

The term 'imposters' in the script is used to describe individuals who are perceived to be undeserving of their roles in software engineering, often implying a lack of formal credentials or perceived competence. This concept ties into the broader narrative of the video, which is about overcoming the negative perceptions of non-traditional developers and establishing oneself in the industry.

💡Inexperienced

Inexperienced refers to a lack of prior knowledge or skill in a particular area. The video identifies signs of inexperience in non-traditional developers, such as focusing solely on making code work without considering broader implications like maintainability and scalability. This keyword is integral to the video's message, which is about recognizing and overcoming these signs to grow professionally.

💡Non-traditional developer

A non-traditional developer is someone who has entered the field of software development through a path that does not include a formal computer science education. The video script uses this term to describe the target audience and discusses the unique challenges they face, such as the need to prove their competence and navigate industry biases.

💡Code readability

Code readability pertains to the ease with which a programmer can understand the code written by another. The video emphasizes the importance of writing readable code as a sign of a more experienced developer, suggesting that new developers should focus on making their code clear and understandable to others, which is a practice that contributes to better collaboration and maintainability.

💡Pull requests

A pull request in software development is a proposal to merge changes from one branch to another, often used to incorporate new features or bug fixes. The script warns against making overly large or infrequent pull requests, advocating for smaller, more frequent commits that are easier to review and integrate, which is a practice that promotes better code management and collaboration.

💡Programming languages

Programming languages are formal languages used to write programs that instruct computers to perform tasks. The video script advises against constantly learning new languages for the sake of novelty, instead recommending a focus on mastering fundamental programming concepts that are applicable across different languages. This advice is part of the broader message to prioritize depth of understanding over breadth of knowledge.

💡Frameworks

A framework in software development is a collection of code that provides a structure to make the development of applications more efficient. The video script touches on the idea that new developers often chase the latest frameworks, but it suggests that a deeper understanding of programming principles is more valuable than familiarity with multiple frameworks.

💡Code reviews

Code reviews are a process where other developers examine and provide feedback on code written by a colleague. The video script highlights the importance of code reviews as a learning opportunity for junior developers, emphasizing that constructive criticism can help improve coding skills and contribute to better software development practices.

💡Critique

Critique in the context of the video refers to the evaluation and judgment of someone's work, specifically the code written by a developer. The script encourages new developers to embrace critique as a means of improvement, suggesting that feedback from more experienced developers is invaluable for personal and professional growth.

Highlights

Self-taught developers often face prejudice from computer science graduates.

The need for proper regulation of the term 'engineer' in software development to match traditional engineering disciplines.

Self-educated developers are perceived as giving software engineering a bad reputation, necessitating industry regulation.

Five signs of an inexperienced, non-traditional developer and how to overcome them.

The importance of planning before coding to ensure code readability, maintainability, and scalability.

Avoiding large, complex pull requests by committing often and testing each commit.

The strategy of committing after completing a unit of work and not pushing until the feature is fully complete.

Learning programming concepts is more beneficial than learning many different programming languages.

The recommendation to learn lower-level languages like C or Rust for a deeper understanding of programming concepts.

Focusing on one task at a time to ensure quality and completion rather than spreading attention too thin.

The importance of not being embarrassed to focus on one task and delivering it well.

The slower pace of software development when done correctly and the need for patience.

The reluctance of new developers to have their code critiqued and the importance of embracing feedback.

Accepting the role of a junior developer and using criticism to improve coding skills.

The value of code reviews and having senior developers approve or reject pull requests as a learning opportunity.

Encouraging viewers to share their thoughts in the comments to continue the discussion.

Invitation to subscribe to the channel for more content.

Transcripts

[Music]

so look I'm a self-taught developer I

was in experienced at one time too it's

okay but these computer science grads

they really hate us just look at this

comment Travis media I really hope that

the use of the word engineer will get

properly regulated like it is in many

countries in relation to the traditional

engineering because you know Building

Bridges and skyscrapers web development

it's all the same thing all those

self-educated are giving software

engineering a bad reputation and it's

high time the industry is getting

regulated and cleansed of the imposters

you me cleansed of the imposters that's

a big word so these computer science

graduates they're really hating on us

they hate us being in the industry for

reasons I don't want to get into and we

need to at least be sure that we're

growing into the programming roles we

aspire to being good reliable teammates

and producing good work so I was

thinking about this today about what

makes us stand out as inexperienced or

non-traditional maybe that's a better

word non-traditional developers and I

came up with five five things five signs

of an inexperienced non-traditional

developer and how you can stop

exhibiting these yourself let's get

started number one is your thinking only

in terms of making it work it's only

about making what you're coding work get

it working and move on and that's

actually okay at first obviously if you

can't get your code to work then you

really haven't made any progress with

your task but over time you have to

learn to move past that and in actuality

it all starts before you even write code

when you're assigned a task instead of

just firing up your text editor and

coding and making it happen you need to

make a number of observations first get

a notebook lay out what you're building

what it is you're building what your

requirements are which often leads you

to Gathering more information that you

didn't know that's important and

ultimately having a clear understanding

of what it is exactly you're doing and

once you have this mental process of

what you're doing think about how it

fits in the current code base like what

constants or existing code you can tie

your code into to keep from Reinventing

things and then consider the readability

of your code the maintainability of your

code and the scalability of your code

it's more than just making it work the

second sign of an inexperienced

non-traditional Dev is that they make

huge changes to the code base at once

meaning your pull requests are too big

to make sense of they're too big for any

meaningful comments or Remediation in

not checking your code in often you can

introduce problems that are harder to

diagnose because of all the changes to

the code base that you've introduced a

pull request should really just have one

cohesive feature that you're working on

not multiple and if that feature is Big

then perhaps it should be broken up into

multiple logical parts so commit often

and make sure to test each commit if

you've sketched or planned out your

feature first like I just mentioned you

probably have ended up with a checklist

of steps to get your feature working and

every time you check off a step or a

task test it and commit it and once the

feature as a whole is fully working and

tested then push your code up and create

the pr here's a good example that I came

across I commit every time I finish a

unit of work but don't push my code to

the server until the feature is fully

complete I'll try to elaborate with an

example say my job is to develop a login

system for some website I would write my

class for a user then commit then I'd

create the HTML form to accept the

username and password and then commit

then I would add the appropriate

validation making sure the password's

long enough making sure the email is

valid things like that and then commit

there three commits this could be three

commits in one day or spread over

multiple days it depends on how long

each unit of work takes once everything

is done I would then merge my

development branches into master and

push to origin you actually don't want

to do that you want to push up your

branch and create a pool request to be

reviewed and then merged into Master by

somebody who approves that I would never

ever ever push code that would cause a

crash or break the build for a project

obviously especially if you're

collaborating with others so if you're

in the middle of writing a class but

haven't finished typing out a function

don't commit until everything is done

and you can successfully build so if you

planned out your work and have some sort

of checklist you would commit at each

check mark the main thing here is don't

write a bunch of code and then push it

all up at one time that's a no no number

three is that you're always learning new

programming languages or Frameworks I

think all of us have fallen victim to

this whether it's the hype of a certain

technology or you just decide one day

that you want to master something

completely new just for the challenge of

it it's really a vain Pursuit why well

I'm all for you being a constant learner

that's a good thing you H actually have

to do that in this industry you have to

always be learning but the question is

what are you learning it's much more

beneficial to be learning and mastering

the concepts of programming and how

things are really working than learning

many different languages which to be

honest each one's just a new syntax it's

just a new language why do that if you

really understand the concepts that

underly programming a loop can be looked

up in any language a switch statement

can be looked up in any language it's

all just syntax so if you're asked to

build a feature in a new language or

framework something that you haven't

used before you should be able to one

read a quick overview of that technology

and how it works and two be able to

build that feature based on programming

Concepts or pseudo code even and then

transforming it into whatever centx that

language speaks also and I did a video

on this recently I'll put a link above

but if you're going to learn a new

language for the sake of doing so pick a

lower level language like C or rust or

even go or C if you're coming from

python or something high level like that

and once you put in the work of learning

the deeper Concepts that those languages

force you to understand you can really

jump in anywhere number four you're

working on too many different things at

once as a new developer you want to look

competent and you want people to think

you're very efficient that you just

happen to be this coding Prodigy that

came out of nowhere but take a look at

senior to mid-level devs they reject the

extraor because they're in the middle of

something they're in the middle of one

thing they have a really good grasp on

that one thing and the requirements for

that one thing and they get it done well

you on the other hand have three things

going on of which you still don't fully

understand and your brain is having to

jump back and forth between them as a

new Dev don't be embarrassed to say I'm

currently in the middle of something let

me get this done first and then I'll

jump on that stop volunteering for

everything get your one assignment

understand the requirements well and

then knock it out the park be a Dev that

always delivers over one who is always

in the middle of 10 different things and

always has to give updates and excuses

for all the things you're doing take one

task assignment at a time and complete

it and commit to a new task only when

the previous task is delivered as

requested in fact building software is a

slower process than you think especially

if you want to do it right and then

number five is you don't really want

others seeing or critiquing your code if

you did they'd probably be suggesting

that you do things differently or speak

on how inefficient or unreadable it is

and you don't want to touch it again

because you got it working and you

wrestle with it so long you're sick of

it and we just don't like the criticism

as new developers strangely we want them

to praise our super complex and

unmaintainable code but thankfully there

are code reviews and there's Gates set

up so that senior devs will have to

approve or reject your pool requests

this is a learning process the point

here is to accept that you're a junior

Dev and write junior level code and the

only way to really get better at it is

to have people critique your code in

learning what's wrong with it in making

adjustments in how you code along the

way so write your code take the

criticism and advice of others and let

it fuel you into becoming a better

programmer so these are five signs of an

inexperienced non-traditional developer

now you know make the adjustments and

you'll see growth in your career what do

you think leave me a comment below let's

get the discussion going if you found

this video helpful give it a thumbs up

if you haven't subscribed to the channel

consider doing so and I'll see you in

the next

video