Must-Have Tips For Software Engineers From Santiago Valdarrama

hey thanks for checking out this video today I wanted to review another LinkedIn post that I thought had some really good information for software Engineers so this is not going to be my content but I saw it on my feed and I thought basically all of the points really resonated with me and I figured that I would share some of my perspective and we'll go through that together so let's check it out alright so this post is from Santiago Valderrama I hope I got his name right came up on my feed and basically like I said all of these points really resonated with me so let's go through these nine lessons that this individual learned from spending 10 years with someone that he considers a brilliant software engineer so the first one here says fast is better than good waiting too long overthinking and trying to get things right from the get-go is a mistake most of the time good enough is all you need and this one really resonates with me because it reminds me of the 80 20 Rule and I think a lot of people have probably heard about that and the idea is really that you don't need to go do everything a hundred percent get it all perfect and you know kind of spent so much effort and time on things because there are diminishing returns and if you kind of read through this the the waiting too long the overthinking trying to get things right and get them perfect right that's like he's calling out that's a mistake um you can kind of work through something you can get something going and a lot of the time that's kind of good enough to get to the next phase now with more time more experience and the more senior you become as a software engineer your ability to identify like what's important to be spending time on that becomes a lot easier so you know right in the beginning it's not like you're necessarily going to get this perfect because well and as it implies there isn't really a perfect solution here but just being able to move forward and make progress is really beneficial again a lot of folks now as software Engineers there's a lot of focus on agile you know I'm using air quotes here agile software development versus something like waterfall where you want to be able to iterate fast you want feedback and again the more experience you have being able to focus on what's important becomes easier so that one really sticks out to me I think that's great this next one is interesting because I think as software Engineers we're always kind of looking at technical debt so this says enough technical debt is a good thing right and a lot of us hear the exact opposite so hating technical debt is nonsense people just don't know how to take advantage of it technical debt means working on what truly matters and deferring anything that can wait so if you take this in line with the first point as well it's a it's an interesting point because I think that you know as people are working through code bases um you know think about if you've ever worked on a project where you joined and you weren't part of creating the code base from the beginning there's always going to be these situations where you're kind of going through code you're trying to learn it and people will you know you might be someone who's done this or you've heard other people do it where they're like like man why is the code this way like this is a bad way to write things like knowing what we know now like how did this ever exist and that's the technical debt kind of adding up so a lot of the time as software Engineers when we come across code that we just really don't want to like look at we think it's designed poorly we think there's optimizations that could be made it could be more readable the idea here is that you want to be able to prioritize it you truly can't do everything when we're thinking about software engineering with respect to actually you know delivering value to customers being part of a business there just isn't time for everything so having technical debt and having other priorities to focus on makes this really interesting so this person's kind of saying like it makes you think about what truly matters and deferring the other stuff so I think this becomes a really interesting conversation for software Engineers that are trying to factor in business value what to deliver on for customers because if you're like just going to give you an example right if you're working in a code base where you've come across some technical debt and that code hasn't changed in say a couple of years and for what it's worth the plan features the bug fixes nothing's really in that area like is it worth spending time to go clean up that code like probably not like maybe you should be focused on trying to deliver the next bit of value to the customer now in a situation where you're aware of the technical debt and it's aligned with where you're going to be iterating on in the code base perhaps it's a really good opportunity to say hey let's pause for a second let's get this Tech Deck cleaned up and that's going to make iterating and delivering more features more valuable and more easy so I think this is a cool one because it's a a bit of reframing for technical debt so I like that this third one there aren't stupid questions I love this especially for folks that are joining new teams new projects new companies so this says um he who asks a question is a fool for five minutes he who does not ask a question remains a fool forever and says Chinese proverb um I actually I don't know if that's true or not it kind of sounds like uh I don't know like it could be so I'm not one to claim that it is or is not but the the idea here I think is awesome um I have this conversation especially with more Junior Engineers or interns a lot but it's not restricted just to you know people that are early in career this this does come up a lot and I think I'm not an expert in this but I would think that as software Engineers we're generally people that are considered quite intelligent and we value intelligence so I think for a lot of people when you're asking questions it can kind of come across like or you might feel that if I need to ask then that implies that I'm not intelligent right if I don't possess some knowledge about something I am not intelligent therefore you know people look down on you you'll look stupid whatever it happens to be and I think a lot of the time this is self-inflicted but I can speak from experience especially um you know like I said it comes up a lot more with uh junior software Engineers but I think the ones that really Excel are the ones asking questions they're the ones trying to unblock themselves they're you know they're doing some problem solving on their own and then figuring out sort of that optimal time where they're like okay I've tried a couple of things now I need to ask questions about the best way forward or they're asking clarifying questions early so I think this one's great I really wish that more people would take this to heart because I just think it's so valuable and uh yeah I again I go back to I I suppose it's probably because of software Engineers um people kind of feel that if they have to ask questions maybe it comes across like they're not intelligent fourth one communication outweighs technical skills so I think there's a word missing here but it says spend twice as much time learning I think uh how to tell stories than building technical skills the ability to clearly communicate your ideas is a superpower so yeah like I mean spend twice as much time learning I'm not gonna say that like you know whatever the ratio is I think it's just for um you know making a point here but honestly being able to communicate is so important if you think about how much remote works going on as well how much time is software Engineers we spend on code reviews in written communication whether that's instant messaging email literally the code we write is written communication right so I think it's so important for us as software Engineers to figure out how to actually communicate information how to understand your audience right I've talked about this in different videos but if you're talking with a software engineer on your team that's familiar with the code base you're working in you can get into particular levels of detail that they're going to understand if you're talking with a software engineer you know they could be more senior than you and they're on a different team and they don't know your code base you probably have to figure out a different way to communicate things you know to navigate questions or challenges so that you can explain to them things that they're not going to know about your domain and you can kind of keep exploring this with like if you consider different roles so perhaps talking with your manager or talking with product or project managers you know in those types of roles I mean it depends on the company of course but it's it's less likely that they're going to know the code base as well so if you need to be talking about something like a bug fix for a customer um with the project manager does it really make sense to be getting into lines of code and particular syntax like probably not um in some cases sure like maybe maybe they are technical in that field and they are familiar enough with it so it's not a it's not a rule but it's a guideline right so you know having clear communication working on that skill I think is super important I really liked this one is called out here so um yes technical skills are important but in software engineering in the real world working on teams we are collaborating if you're just one person trying to you know do all of the work on a team or something you'll never be as productive as the whole team working together and that requires communication number five just because you can doesn't mean you should maximize the things you don't work on learn to say no prioritize and delegate you can only see what matters when you tune out the noise yeah this is I think a really cool one to to focus on um in some you know some companies some teams um how you're set up might mean that you have other roles like project managers product managers that kind of thing um I think one of the most important parts about those roles is that a lot of the time um they they focus on this type of thing for a lot of the stuff that you might you know be considering having to look at um but not it's not going to cover it all the time so even if you have those roles kind of working with you on your team you know they might be able to help on the coordination of stuff or they might be able to kind of tell you uh from being a user proxy like what's really important to uh to focus on but there's gonna be stuff that as a software engineer you are still responsible for and if you don't have those roles you're gonna have to try and figure that kind of stuff out as well when you're working on your team so the the important part here is that kind of like I said earlier you can't do everything there's so many things especially as a product is growing a code base is growing you start to have you know paying customers you have users you have a live service whatever it happens to be like the more progress you make the more stuff there is to do which I mean it sucks but that's the way it is so you can't just do everything so I think it's really important this I think this piece just really talks about learning how to prioritize stuff is is critical and the priorities that you have on your project the team has the business needs these are going to look different across different companies different products different projects so I think just understanding that and learning you know how to how to apply prioritization in your domain is going to be really important um this is one of those things that I think is especially you know again going back to Junior software Engineers or or people that want to you know they're they're trying to develop the skills to get into software engineering a lot of the time people are just focusing on code right they're gonna go try to do all the lead code problems they're going to watch all the YouTube videos on how to go make a you know a website or a web server but while these things are important like prioritization is is a really critical skill we talked about communication there's just these other things that you should be focusing on okay let's head to number six here share Like There's No Tomorrow People want to be around those who lift them so share your knowledge indiscriminately the quickest way to become a linchpin is making those around you successful so yeah this is um I think it's really important again like I think almost everything on this list is super important so when we talk about software engineers and one of the things in my opinion for kind of leveling up as a software engineer kind of working towards more senior roles as a software engineer I think like this part here making those around you successful this is It's a leadership thing right as you become more senior your expectations I think in most places your expectations around being a leader and that doesn't mean a formal leader like in a management position but being able to multiply those around you level them up making your whole team better by helping them by sharing knowledge is critical this is something I personally talk to individuals on my teams about as they're trying to trying to gain experience it's not just you know not just uh architecture and you know writing better code of course these are things we focus on but as they gain more experience uh the words I have highlighted on the screen make those around you successful this becomes more and more of a priority so I love this one okay number seven take full responsibility finding justifications is easy look inward instead learn your lesson and do better next time yeah so I'm not gonna necessarily speak to this exact wording here but what I wanted to call out for this is um something like a postmortem process and I mean you can use different phrases but the idea is is really like when things don't go the way you expect it's good to reflect and even when things do go the way you expect it's good to reflect so I think when I look at number seven here I think it's mostly focused on you know when things don't go right like what do you do with that information so sure if you're reviewing say a bug happens like a bug's detected by customers they're reporting it now the team's got to go through getting a fix out like communicating with customers about the fix all that kind of stuff and of course this looks different everywhere but just an example um you might go through a process of reflecting on this and it's you know okay you're on a team of five people and turns out bill on your team the you know the intern bill committed code introduce the bug so okay it was Bill's fault was it though is Bill the only person that had to get that code all the way out to production the customers who reviewed that code were you on that review was someone else on the team on that review who wrote the test for that what's the testing infrastructure look like right you can start to go through this process and really what it comes down to is like it's not ever going to be one person's fault you are working as a team so I think in this particular case it's really not about like you know trying to identify like who who done it it's really about like learning from the situation how to apply those lessons doesn't matter if it was you someone else that ultimately wrote the line of code or you know press the press the submit button whatever it happens to be I think it's really critical that holistically you look at the different things that happened and just try to understand and do better next time so um I I like this one a lot if you don't have a process where you're working um that kind of does this reflection process I think it's absolutely worth bringing up again you can apply it for positive or negative scenarios and regardless I think that the uh like you take a no blame approach and just try to learn and get better um it's it's honestly like a fascinating thing to go from not having that on a team to having it and just watching the whole team get better and grow if you do have something like this and there is a concept of of blame um I think it can really backfire so I think this part here that says look inward instead is critical for making this work effectively right so again no blame process review positive and negative things uh retrospective I think it's I think it's great number eight says the best code is the one nobody wrote I think this is interesting because code is a liability learn to solve problems by writing as little code as possible no code Solutions are an under appreciated superpower so I wanted to talk about this one from the perspective of prototyping and you know rapidly iterating on things I've spent a lot of my career especially early in my career working on teams that did rapid prototyping and I think one of the most important parts is um is really just getting to answers fast I think that's the way that I would phrase it get to answers fast and and what does that mean right so if you're thinking about prototyping something and why you do that the idea is that someone's considering that there may be a solution for a problem and there's an idea for how to solve that problem but I think as soon as you have to go start writing code code may be a solution to the problem right you can go code something up and and whatever it might run and you have a UI whatever people are trying it out but is that the quickest way to get your answers and I think that's a really important thing to consider when you're prototyping because I'm just going to give you an example if you're prototyping something to figure out if users would be interested in it do you need to go through the steps of creating a new application with a UI deploying it having users get onto a web page I mean you might in your particular situation in other situations maybe you have a product team that's able to interface with customers directly maybe you already have um you know an existing application where you can try to drop a small page and I mean that's gonna include some code but can you minimize the amount of code can you get that question answered with no like what if you made a PowerPoint and presented it to to customers or users right potential users um being able to do something like that that just has like such little effort compared to you know writing code getting your tests in place and getting the build going and then pushing it to production like those are great things but they might not be the best or quickest tool to go get your answers so I'm not sure if that's what this individual meant when he was talking about number eight here but when I think about the way this is written for number eight I always kind of reflect back to that rapid prototyping thing and um you know as software Engineers we love to write code we love writing code to solve problems we love writing code to answer questions but I think it's a really good opportunity to press pause and kind of go back and think about like do we really need code to get this answered okay number nine is probably one of my most favorite on this um it says if you don't test it it doesn't work any code that can break will eventually break if you don't have automated tests you are doing it wrong now that's a really strong statement um but I I like the phrasing in this because it is polarizing um I'm a I'm a really firm believer in having automated test coverage on on your code now I did talk about rapid prototyping right before this that's an example where um like testing it to me doesn't really make sense because hopefully you didn't even have to write code in your prototype right you're just trying to get questions answered um your prototype if you did write code that's probably going to get thrown away right so tests in that case I don't think help as much so it's not a it's not a rule but I like this a lot because I think a lot of the time um a lot of the time as software Engineers when we're you know coding up Solutions we might you know we'll go run it on our computer we'll go um we'll go flight out a change for a service and we're checking you know checking machines or we're you know we're doing something manual and going okay like that fixed the problem if it was a bug fix or you have a feature and you're testing it out by manually running things feel great like it worked and that's good like you should you should be testing your things to prove they work in some capacity right not just blindly pushing stuff to production and crossing your fingers but the part that's important here is it says any code that can break will eventually break and the automated test part that's where this comes in so just because just to give you an example right if you if you and I are working on a team and you go push up a code change and let's say it's something for a live service and it has to go through some a b testing or some flighting so it's rolling out the data's coming in it's all working and you're going yep awesome my change is perfect it's working we got green lights everywhere great cool now I come in and I go oh I'm going to deliver this other feature and I go do the same steps as you right so I'm gonna go uh commit something I'm gonna go flight it out and I'm getting green lights on all my stuff so great I did a perfect job too but what happens if what I was delivering and flighting out actually ended up breaking what you wrote you didn't have automated tests in place now we don't know if it broke now we have to wait for a customer to tell us hey this doesn't work or customers don't tell us and someone else comes across that someone internally goes oh crap this is broken either way it sucks right it's going to mean that you might have to revert stuff or you're going to have to depending on your scenario have to try and get a patch at whatever it happens to be but the idea here is that if you are getting stuff landed into production I do not think it's sufficient to just manually test something you know the one time even if you're flighting it out slowly like that's great but if there's no automated tests that help with regressions I think personally that that is a recipe for disaster to say you were doing it wrong like I said I think that's probably the polarizing part so um you know my opinion is yeah like that is not the right thing to do now as a rule um I don't really like saying I don't like having rules because I think there's always exceptions to every rule but um I I honestly do think that this is a practice that you want to have you do want to have automated regression tests um I just think it's super important and if you're in a position where you are delivering code and saying well there is no way to test this automatically it has to be flighted out no I think that's incorrect I think the correct thing to say is you might have to flight it to validate it but once it's been validated can you look at your Automation and figure out how to prove that that behavior still happens now your test infrastructure may not be able to support it currently and that's okay because that's an area that could be invested into but to say that you can't write tests on something to validate it I think that that's just missing the point you can validate things manually but you need to look at ways to have automated regression tests separately alright so that was a list of nine things from Santiago Valderrama again I hope I got his name right I really like that list um I think that personally everything on that list is something important that's come up when I'm talking with Junior software Engineers all the way through senior software Engineers I think a lot of those lessons are personally things that come up that aren't super technical right they're not like oh like using this programming language and following this design pattern like that's the the way to success like yes there are technical things you want to focus on as software Engineers but I think that was a really good list of nine things that are basically going to help you just level up as a software engineer in general so I'll put a link to this post in the description I want you to go check it out leave a comment I think this is great so thanks so much for watching and we'll see you next time