8 Years A Developer | What I’ve learned | Self-taught

what's up everybody it's Travis here from Travis dot media so as of 2023 I've now been in the software industry for eight years since learning to code at 34 up to the present it's been eight years and I want to announce in this video that I'm finally hanging it up just kidding in this video I want to give you eight things that I've learned as a self-taught developer that I think will help you on your journey and that's it I don't have anything else special to talk about so let's get started number one learn to push back be a developer that pushes back kindly when necessary the client often wants things done to their site or their app that just isn't wise to them it looks good or it keeps them in step with their competitors or it's some plug-in that they like that they just want to play around with it's your job not only to do the coding but it's your job to say no that's a bad idea or why would you want to do that that doesn't help you in such and such way it affects the app negatively it hinders performance it's overly complicated and is going to require a big redo of this section of the site it's up to you to step up and say that valuable developers push back replaceable developers they agree to everything the client wants something done sure I can do it whatever you need I can do it but coding is only half the job they hire you for your wisdom you know behind the scenes whether something is wise or unwise and you're being paid to speak up about it when I started out I was that kind of developer I was then agreed to everything developer because my thought was hey the client wants me to do something they're paying me to do it just do it and then the app got wrecked things started breaking and the client's like why are things messed up and I realized hey the client just wants to see results They Don't Know What It Takes they're actually hiring me not just to write the code and implement the things but to let them know whether it's a good idea or not they often don't know that they need you to push back when needed so when the request comes in and it's a very bad idea from a technical perspective you need to push back or at least bring it up don't just agree to it number two don't hide behind questions with software engineering you need to be precise when someone assigns you work you need to know the ins and outs of what's required before you can successfully execute that task when I first started out I wanted to look smart too I didn't want people to think that I didn't know what I was doing so I didn't ask questions everybody else else was getting it I should get it too I'll just figure it out later but that really hurt me in the long run because when a task was giving me and there were particular things about it that they thought I understood and I agreed saying yeah yeah I got it I really didn't get it I should have been like hold on what do you mean by this or what do you want to do about this thing I should have raised more questions to the point where when I sign off hey I'm good to do it I fully understand it and you if you're a new developer a junior maybe even a mid you might feel the same way you might feel like you want everybody to think you're also a good developer so you don't ask questions but it really hinders your growth and here's an example and I've told this before in one of my older videos but I think it's a really good example a couple of years back I got put on this project everybody on the project was from the same company as me except for one guy he was brought in from another company he was young he's pretty smart but he asked a lot of questions and it made many of us uncomfortable like why does this guy keep asking questions like during stand-up they would get to him and they'd be like hey so and so here's the task we need for you to be working on this week it involves such and such and they'd go over the steps and he would always say something like wait wait go back what was the last part again I don't I don't understand how you'd even do that and it would get the team talking and then they'd talk to him and he'd figure it out or he would say something like why are they going to use that technology that's not a good idea they should use python or something like that or he would say why are they even doing this this isn't a good idea we should push back and we should tell them that we shouldn't do this for such and such reason and many of us were just like come on man this meeting has gone too long and you're still talking I thought but I found out later that many of the questions he was asking are the questions that many of us wanted to ask but didn't at the risk of looking stupid we felt like we wanted to be smart developers we got it you can sign me something I'll figure it out I'll do a good job but this guy is asking too many questions but what he was doing was he was clarifying exactly what needed to be done and often his discussions led to further discussions with the team where someone could put him on the right track or he would expose some reason why we shouldn't do that and the rest of the team would be like hey that's a good idea and it actually worked out well and he wasn't asking too many questions I was just used to not asking any questions and by the end of that contract he was seen as a very reliable capable devops engineer and actually got an offer from a company that was on the project for like way more than he was making he didn't take it for some other reasons but anyway the point is that he didn't hide behind questions and you shouldn't either you should have a clear picture of what needs to be done if you don't know how to do something say it ask more questions ask the team so that they can help you do the exact job you need to do now don't be annoying about it you do have skill you can figure things out on your own you don't want to annoy people but just don't be shy don't be the guy in the stand-up that's quiet the whole time and then at the end he's like see you guys ask questions number three learn to read documentation well there's so many Technologies out there you can't learn them all you can't learn all the languages and all the Frameworks and all the other little things you need to use in your daily job instead you can become very good at reading documentation so if somebody says hey we need you to do such and such with Splunk and you've never used Splunk before you can go read the documentation what is Splunk how does it work like what's a diagram an overview of how it works and then dive into the individuals and find the specific need you have if it's a framework like react go to the react documentation how does react work maybe there's a getting started guide where you can do like a quick sample project to see how it works in the way to get better at reading documentation is just doing it you'll get better over time because you'll have to do it anyway but try to find some apps that have good documentation how is it laid out is there an example app is there a conceptual diagram of how it works overall well what are the parts that make up that technology spend some time with that and as you get better at reading documentation you'll realize it'll really help you level up as a developer and get things done faster number four be mentally and emotionally prepared to drink from the fire hose especially those getting into devops and site reliability engineering where you're in some new technology every day it seems like I said previously there's so many Technologies to learn it feels sometimes like you never actually learn anything you're just jumping from one thing to the next when you finally think you get something you're pushed to some other technology in fact I was just talking to a friend of mine the other day who just got into devops that feels the same way he told me there's so many things to learn in every couple of days I get pushed to some other technology to integrate that I feel like I never have time to settle down and learn anything how do you do this and here's my answer it's a two-part answer one get good at reading documentation we just talked about that that's critical to these kind of jobs but number two realize it just takes time and what happens is over time you start to connect Concepts so if you're on a project and you're using Linux a lot and you start to really understand the Linux CLI and the Linux file system when they move you over to integrating Splunk or datadog or something like that and you have to do it on a Linux machine you've already learned Linux over here so you get over here you're connecting that Linux experience with another task that you're tasked to do if you understand CI CD and AWS and you set that up then somebody wants you to come over to Google cloud and set up that same thing you have that concept understood already you just need to know how to do it on Google Cloud if you understand how oidc works or how saml works it doesn't matter what platform you're on or where you do that at it works the same regardless so what I'm getting at is it just takes time you're gonna have to drink from the fire hose you're going to have lots of Technologies coming at you and as you successfully figure each out you're going to start grasping all of these Concepts that are going to connect in the future as a year two years ago down the road to where when you're put on this new task you're able to nail it quicker and you don't feel like you're drinking from the fire hose I felt like that in the past but now I don't I feel more confident in my abilities to read documentation and to rely on my past skill sets that I've picked up along the way number five taking breaks can be the best thing for your success and I know this is so cliche and so many people say it just get up and walk away and come back and the answer is there I know so many people say that but it's so true if you're working on something and you're just like grinding the gears and you can't figure it out and you're hitting the button and you're just trying over and over to get this thing to work and you can't really just get up go take a walk around the building go take lunch go talk to a friend go do something else for a little while you'd be amazed how much coming back with a fresh mind helps and I was good often to kind of wipe out a little bit of what you were working on instead of getting up to that point where you can't get any further and then coming back and starting at that point just kind of go back a couple of steps take take a break come back redo those steps with a clear mind trust me this is a top-notch tip number six be a conceptual programmer realize that programming Concepts themselves can guide you through many different languages and Technologies and Frameworks even if you've never used them before if I understand functions how functions work parameters arguments things like that doesn't matter what language I'm in I know how a function works if I understand loops and I understand objects and all of that it doesn't matter what language I'm in I just need to look up the syntax and one thing that really helps with this is pseudocoding pseudocoding is like writing out in plain English or whatever language writing out in plain English how I'm going to do this so they've given me some tasks I'm going to grab a piece of paper and I'm going to write the steps out in plain English like I'm going to do this first then I'm going to do this then I need to Loop through these things and find this one I'm going to write it all out and because I'm a conceptual guy I can conceptualize how I'm going to do this and then figure out how I'm going to do it with that language this allows me to work in C sharp one day and then react the next day and then go laying the next day whatever it is if I can use pseudo code to figure out how to do it plainly I can then take those Concepts and figure out how to do it specifically in that language this also applies to Concepts like MVC model view controller or even like oauth 2 authorization the concepts are the same no matter what environment you're in so number six be a conceptual programmer it allows you to jump around number seven be humble the worst person in the whole world is a cocky developer who is always right and has no patience I've worked with these developers in the past one example is a number of years back I had to work on a project with this guy that was right out of college he just got his computer science degree he had his little clicky keyboard and his awesome Mouse and his little 3D printer and everything there I was like 35 with my wired Mouse trying to figure things out so we got put on a project and we had to like code together in one of these shared sessions and he just had no patience for me like I I would be like all right I'm going to set up a function and I'd be writing it out and then he'd say ah let me get the mouse let me take control of the mouse I can't take this anymore you're taking too long and he would get it and he'd start typing and just had no time for me it was always frustrated in all the meetings he was just telling everybody what to do and nobody liked him and he didn't like me I was very nice to the guy but he was just always frustrated and just thought he knew everything and he didn't stay long at the company I don't know what he's doing now but those kind of developers nobody likes you want to be a developer that's humble and good you don't have to prove yourself people see it in your work and you're enjoyable to be around be a humble developer not a cocky developer and number eight and this is a simple tip to those who are struggling with Landing that first job remember this keep this in the front of your mind do what it takes to get your foot in the door your first programming job doesn't have to be a good one it doesn't have to be with Google it doesn't have to be with some amazing company do what it takes to get your foot in the door take whatever job will hire you as a programmer once you're in there put in the work for a little amount of time at least to get that on your resume but once you're in it's easy to move somewhere better or somewhere else you'd rather be do what it takes to land that first job and that's all I got today guys if you found it helpful give me a thumbs up consider subscribing to the channel and I'll see you in the next video foreign [Music]

Channel: Travis Media

Views: 28,076

Keywords: coding tips, software tips and tricks, self taught programmer, self-taught software developer, software engineer life, tips for learning to code, succeeding as a software developer, first developer job, developer growth, become a better software engineer, what i've learned as a developer, tips for software engineers, tips for software developers, devops tips, site reliability engineering

Id: 3YqJU3WSixI

Length: 12min 40sec (760 seconds)

Published: Sun Mar 05 2023