How Senior Programmers ACTUALLY Write Code
Summary
TLDRThe video script emphasizes the importance of writing high-quality code for professional growth and efficient teamwork. It outlines habits such as completing work fully, adhering to coding standards, documenting coding patterns, and avoiding micromanagement through proper estimation. It also stresses the value of incremental refactoring and the necessity of including time for documentation to ensure code longevity and maintain a professional standard.
Takeaways
- π Writing good code is crucial for being perceived as a senior programmer, as it allows other developers to easily understand and appreciate your work.
- π Good code writing practices reduce the time spent supporting and explaining code to others, thus increasing efficiency and productivity.
- π Writing high-quality code decreases the likelihood of your code being rewritten by others, which can be frustrating and a waste of time.
- π Completing work before moving on is essential to avoid building up technical debt and to maintain professionalism.
- π Enforcing coding standards through tools or plugins helps maintain consistency in code formatting, making it easier for team members to work together.
- π Documenting coding patterns and decisions is vital for team collaboration and for maintaining a high standard of code quality.
- π Reviewing and getting feedback on new coding patterns before fully implementing them can prevent potential issues and gain team support.
- π« Avoid creating separate tasks for refactoring, as this can lead to management pulling out these tasks, potentially harming the project.
- π Incremental refactoring, spread across multiple features, is a valuable skill that helps in maintaining code quality without large, disruptive changes.
- β° Estimating work should include extra time for unexpected design meetings and documentation, ensuring that commitments can be met without compromising code quality.
- π£οΈ Communication with the development team about refactoring needs and plans is key to spreading the effort and preventing management from making uninformed decisions.
Q & A
Why might a developer feel micromanaged when adding a new user story for a document?
-A developer might feel micromanaged because they have to report back to a project manager or scrum master for approval, which can be seen as an interruption to their workflow and an unnecessary oversight on tasks that should be within their autonomy.
What is the importance of writing good code according to the script?
-Writing good code is important for several reasons: it allows other developers to understand the codebase easily, reduces the time spent on supporting and explaining the code to others, and decreases the likelihood of someone rewriting your code due to misunderstanding or preference.
How does writing good code affect a developer's perception among their peers?
-Writing good code can elevate a developer's status from a junior to a senior programmer, as it demonstrates an understanding of best practices, consideration for others who will work with the code, and a professional approach to software development.
What is the first habit suggested for writing code like a senior programmer?
-The first habit suggested is to complete your work before moving on, avoiding the accumulation of technical debt and ensuring that the code is finished to a standard that can be presented to others.
Why is it beneficial to enforce coding standards?
-Enforcing coding standards ensures consistency across the codebase, making it easier for developers to understand each other's code and reducing the cognitive load when switching between different parts of the project.
What is the role of documentation in maintaining coding patterns?
-Documentation serves to communicate agreed-upon coding patterns to the team, providing a reference point for consistency and understanding, and ensuring that new team members can quickly get up to speed with the project's standards.
Why should a developer avoid creating a separate task for refactoring?
-Creating a separate task for refactoring can lead to management potentially removing it to meet deadlines or other priorities, undermining the quality of the code. Instead, developers should integrate refactoring efforts incrementally within new feature development.
What is the advantage of incremental refactoring over a complete overhaul?
-Incremental refactoring allows for a more manageable approach to improving the codebase, spreading the effort across the team and reducing the risk of introducing new bugs or issues that can come with a complete overhaul.
How should a developer handle unexpected design meetings or the need for additional documentation?
-A developer should account for such uncertainties by adding extra time to their estimates for work, ensuring that they can meet their commitments without compromising on the quality of the code or the thoroughness of the documentation.
What is the significance of self-discipline in the context of writing code like a senior programmer?
-Self-discipline is crucial for maintaining personal and professional integrity in code development. It involves taking pride in one's work, ensuring thoroughness, and completing tasks to a high standard before moving on to new tasks.
How can a developer demonstrate maturity and professionalism in their coding practices?
-A developer can demonstrate maturity and professionalism by rejecting the notion that code should be self-documenting, instead taking the time to document patterns and decisions made during the project, and actively seeking feedback and collaboration with the team.
Outlines
π The Importance of Writing Good Code
The speaker emphasizes the significance of writing clear, understandable code for several reasons. Firstly, it allows other developers to easily comprehend the codebase, which can prevent the urge to rewrite it entirely. Secondly, well-written code reduces the time spent on supporting and explaining it to others. Thirdly, it minimizes the chances of code being rewritten unnecessarily, which is often a waste of time in software projects. The speaker suggests that adopting good coding habits, such as completing work before moving on and taking pride in one's code, can elevate a developer's status from junior to senior.
π§ Enforcing Coding Standards and Documentation
The paragraph discusses the importance of adhering to coding standards and documenting coding patterns for a team. The use of auto-formatting tools is encouraged to maintain consistency in code formatting. Additionally, documenting agreed-upon coding patterns in a central location, such as a wiki or markdown file, is highlighted as a best practice. This helps in maintaining uniformity and understanding within the team. The speaker also stresses the value of reviewing new patterns with the team to gain feedback and ensure everyone is on board with the changes.
π Incremental Refactoring and Estimation Practices
The speaker advises against creating separate tasks for refactoring, as management might remove them, potentially harming the project's quality. Instead, they recommend discussing refactoring needs with the team and spreading the effort incrementally across features. This approach, known as incremental refactoring, helps in maintaining code quality without disrupting the development flow. Furthermore, the speaker suggests adding extra time for unexpected design meetings and documentation when estimating work, to ensure that the team can deliver high-quality, professional code without being micromanaged.
Mindmap
Keywords
π‘Micromanagement
π‘Senior Programmer
π‘Code Maintainability
π‘Technical Debt
π‘Coding Standards
π‘Documentation
π‘Refactoring
π‘Incremental Refactoring
π‘User Story
π‘Estimation
π‘Self-discipline
Highlights
The importance of avoiding micromanagement by ensuring tasks are fully completed before reporting them as done.
The value of writing good code for better team understanding and the transition from junior to senior developer status.
Writing good code reduces support time and the likelihood of being interrupted by questions from other developers.
The risk of code rewrites due to lack of understanding and the benefits of writing code with longevity in mind.
The habit of completing work before moving on to prevent technical debt and ensure professional integrity.
The significance of enforcing coding standards for consistency and reducing the frustration of reading varied code styles.
The use of auto-formatting tools and the establishment of team coding standards to streamline code reviews.
The necessity of documenting coding patterns and decisions for team alignment and future reference.
The practice of reviewing new coding patterns with the team to ensure collective understanding and support.
Avoiding the creation of separate refactoring tasks to prevent management from deprioritizing quality improvements.
The strategy of incremental refactoring to integrate new patterns without significant disruptions.
The importance of adding extra time for unexpected design meetings and documentation in work estimations.
The professional responsibility of developers to protect code quality and prevent management from making detrimental decisions.
The consultant's approach to thorough documentation, benefiting the team and enhancing the perception of professionalism.
The suggestion to reject the notion of self-documenting code and instead focus on mature and professional documentation practices.
The call for developers to share their opinions and suggestions for what makes someone a truly senior programmer.
Transcripts
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
5.0 / 5 (0 votes)