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

[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

Channel: Travis Media

Views: 326,161

Keywords: software developer mistakes, self taught developers, non traditional devs, non cs degree developers, non traditional programmers, self taught software engineers, programming mistakes, growing as a software developer, how to be a better software developer, signs of a junior developer, computer science degree vs self taught

Id: B_HR2R3xsnQ

Length: 8min 40sec (520 seconds)

Published: Wed Jan 24 2024