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