and the worst thing is having to go back to a project manager or a scrum master and say hey i need to add a new user story for this new document that i need to write i mean you're almost like guaranteeing that you're going to be micromanaged if you do things like that [Music] why does it even matter if we write good code like a senior programmer or not well first of all it lets other people understand our code you've probably found yourself in a code base before reading it and just being like i don't
understand what the hell is going on in here and the temptation is often to just jump in and rewrite everything but being able to write code where people can really easily read it is something that other developers on your team will really appreciate and that often is the difference between them looking at you as a junior developer and a senior programmer the second reason it even matters to write good code is it reduces the time it takes for you to support it and explain it to somebody else i often work with other developers who will
rush through and not follow some of the six things i'm about to tell you towards the end of the video and then they're frustrated when they're constantly interrupted by other developers asking them questions about the code and they're like i don't have time for it well if you do follow some of the things i'm about to share with you today that's actually going to reduce that time quite a bit and let you just work on what you actually want to do and the third reason it's really good to learn to write code as a truly
senior programmer is that it reduces the chance that somebody's going to rewrite your code i think one of the most frustrating things as a developer is when you work really hard to implement a feature and at a very short period after that somebody comes along and they don't like some aspect of it or they don't understand it and they rewrite all of it so if you follow some of the things i'm going to share with you today i think it's really going to increase the shelf life of your code and that's actually going to be
much more valuable to your company because i think one of the biggest wastes of time on many software projects is rewriting code that already works just to suit someone's preferences when there's not really a refactoring reason that's actually adding value to the project so what are some habits you can put in place to write code like a truly senior programmer well i think the first habit you can put in place is completing your work before moving on there's immense pressure on many projects especially if you're doing scrum or something like that to say that you're
done with work and know that okay i'm 85 done but there's a little bit of the code that's left and i'll just leave that to a future time i'll come back and fix it but at least in my experience after many projects i've been on when i do that i'm basically building up technical debt for myself now nobody else may see it i may be the only person on the team that's aware of it but it's ultimately there and somebody else will become aware of it and a lot of times when i'm reporting status to
project managers about what i'm working on i have to be really honest if i'm going to be truly professional and say no i'm not done with this task and if the rest of the team or the management is frustrated i'd much rather have them be frustrated and have them know the real state of the project then basically lie to them to just say i'm done with something so having the self-discipline to really look at your code like this is my personal brand scott nimrod talked about that in the first interview i did with him i
thought that was such a great point that every time we write code somebody else is going to look at it down the road and basically they're going to measure what they think of us based on that code so having some pride and making sure that you really finish it before you move on is honestly one of the first things you can do if you really want to be taken seriously as a senior programmer the second thing i see truly senior programmers do is they enforce coding standards luckily today and we didn't have this 15 plus
years ago you know if you're using vs code or something like that you know emacs and vim and some other tools will do this too most languages have auto formatting so you go in you write your code if you decide to put your line breaks and your curly braces in different spots once you save the file it'll format everything for you in a consistent way but if you don't have something like that finding a third-party tool if you're using visual studio or like a thicker ide that has a lot more features something like that there
are plug-ins for it that will let you do code formatting and establish code formatting for your team but some of the most frustrating code bases i've worked on have been where everybody has a completely different standard for formatting their code and it's so easy especially as a consultant sometimes when i come in on an existing project that i'm asked to audit to tell that very different developers wrote the code and it's really frustrating to have to read different styles of code when honestly we've got the technology today to do it now i still think it
makes sense to write a wiki topic or have a markdown file or something somewhere that's really easy for the team to get to that says these are our coding standards and if you just use an off-the-shelf standard like that's been established by an open source community or something like that that's even easier because you can just say we're using this standard and give them a link to that standard to read about it another thing you can do that will really help you write truly senior level code i think is to get much more disciplined about
documenting patterns i see many teams who will start a new software project they'll discuss amongst themselves pick a set of patterns some of them are just open source very well known patterns and some of them are not but especially like on a react project or something like that where you're using react just for the rendering part of the page and there's all these other libraries and different patterns you can pick from having at least one wiki topic or markdown file or something that says here's all the patterns that we've agreed we're going to use on
the project i think is really valuable because that way too if you're doing code reviews or something like that and you find the developer on your team is using some other pattern it's not just arbitrary where you're like well we picked this pattern we didn't tell you about it you can be like hey remember when you joined the project we showed you this page with all the patterns this is one we haven't agreed on now if you're using an off-the-shelf pattern something that's already part of a framework or a language that you're using i think
a really good idea can be just to include a link to the documentation somewhere online that at least has like a tutorial or explains how to use that pattern just to make it easier on your team so that they're not googling to try to find some example that might not be the example that you want them to look at for a pattern that already exists now if you have a pattern that's new you've created some pattern to be dry or basically to make the code easier to write i often see people that will introduce a
pattern they'll do a brown bag lunch or a demo or like a meeting over slack and they'll show it to the development team and then that's the last time they talk about it and i think every single new pattern that you introduce for which there is an existing documentation you gotta create a wiki topic or a markdown article or something that says okay here's the purpose of this pattern here's when you would use it here's when you would not use it and here's some example snippets of code that will show you how to actually apply
it in some common scenarios [Music] as a consultant i'll tell you one of the things my clients really like that i do for them is i often any code that i write in any project i'm on am really anal to be honest about my documentation but i just find the great thing about that is the the other developers on my team especially when i come in and remember i'm a consultant i'm not part of their company they love working with me because they have all these topics to go to i'm really disciplined about that so
if you really want to get looked at as a senior programmer unfortunately a lot of these things that we've convinced ourselves aren't really important like self-documenting code you really just need to reject some of that and actually have just the maturity and the professionalism to really just step back and take the time and actually document the patterns and the decisions that you've made on your project another thing that will really help you work with other developers like a truly senior programmer would write code is to review any new pattern you're introducing to the project as
soon as you've introduced it i've been on projects before where let's say there's one developer that's come up with a new way they want to access the database that's different than how everybody's been doing it it's a completely different library and they just introduce it to the code and over several sprints or just months of development they just start to slowly roll it out and introduce it to every feature across the code base and they never told anybody about it and then they find out later that somebody already evaluated that pattern and they had really
good reasons for why they didn't want to use it and now it makes the person look kind of like an idiot because they realize that it's not actually going to meet the requirements of something that maybe another person on the team already knows is coming later in the code base so i would just suggest if you're going to do something like that change a pattern or introduce a new pattern put just enough code into the project to demonstrate it and then get with your team show it to them ask for feedback they're probably going to
have some opinions on ways you could do it even better and then you can get buy-in from everyone and they'll actually be supportive of it and you can actually enlist all the other developers on your team to help you incrementally add that pattern to the code instead of putting it all on yourself [Music] another thing you can do that will really help you write code like truly senior programmers that i've worked with is never create a user story or a ticket or if you're using jira something like that a task that represents refactoring why would
i say this well anything that you put in as an individual item that your management can see is something they can take out and i just find that building quality into code is something that we as developers i think we have to take responsibility for it and as professionals we have to actually prevent our management from making bad decisions that are going to tank their project whether it's through technical debt or just not delivering stuff that actually can be extended as the project evolves so when i'm on a project and i realize refactoring needs to
be done i never create a ticket or a user story or estimate a refactoring effort what i do instead is i discuss it with the rest of the developers and we come up with a plan on how to spread that effort across the team so we can incrementally refactor now incremental refactoring is a really valuable skill and i meet a lot of developers who don't know how to do this they look at it like okay if we're going to change let's say the database pattern we're using or we're going to change some way that we
do state management react we're going to use redux or something like that we have to now take a two week period or a month and refactor all the code to do that it's a lot smarter to just decide on the development team okay every time we get a feature we're going to basically add some time to it so that we build that new feature using the new pattern and we also go back to one or two other features and update it to use this new pattern that we've agreed upon the key though is don't call
that out as a separate item because again management will be tempted to pull that out and i think as professionals we can't let that happen and the final thing that i think will really help you write code like truly senior programmers and i love when people do this on my teams is anytime you're asked to estimate work you gotta add extra time for unexpected design meetings and documentation that you might have to write it's so common when i'm on projects i'm going along writing code starting to implement a feature and i find out ooh there's
some uncertainty in here and to meet the requirements now i've got to add some new documentation and the worst thing is having to go back to a project manager or a scrum master and say hey i need to add a new user story for this new document that i need to write i mean you're almost like guaranteeing that you're going to be micromanaged if you do things like that so i always tell people give yourself extra time not just for meetings and uncertainty and all that but writing documentation if you really want to keep the
quality of the code high and you want to keep the team as productive as possible you have to protect your commitments with the extra time that you know it takes to write really excellent professional code i know a lot of these are my opinions today there's probably things that you agree with you don't agree with leave me some comments below i'd be really interested to know if you don't agree with me why and what would you suggest instead and if you've also got some other suggestions for what makes someone a truly senior programmer let me
know about it until next time thanks [Music] do [Music] [Music] you
