How Senior Programmers ACTUALLY Write Code

Summary

The 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

00:00

📚 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.

05:01

🔧 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.

10:03

🛠 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.

Keywords

💡Micromanagement

Micromanagement refers to a managerial style where a manager closely observes or controls the work of their subordinates, often to the point of interfering with their freedom to make decisions. In the video, the speaker mentions the risk of micromanagement when developers have to report back to a project manager or scrum master for additional tasks like writing documentation, which can stifle creativity and autonomy.

💡Senior Programmer

A senior programmer is an experienced software developer who has a deep understanding of coding practices, can mentor junior developers, and is capable of making architectural decisions. The video emphasizes the importance of writing good code as a senior programmer to gain respect from peers and to ensure code maintainability, using the term to contrast with 'junior developer' and to highlight the maturity in coding practices.

💡Code Maintainability

Code maintainability is the ease with which a software system can be modified by its developers. The script discusses how writing good code is crucial for maintainability, as it reduces the time and effort required to support and explain the code to others, which is a key aspect of a senior programmer's role in ensuring the longevity of the codebase.

💡Technical Debt

Technical debt is a concept in software development that refers to the implied cost of additional rework caused by choosing an easy, short-term solution instead of a more robust, long-term one. The speaker warns against building up technical debt by not fully completing work before moving on, as it can lead to future complications and increased workload.

💡Coding Standards

Coding standards are a set of rules and guidelines for developers to follow when writing code. In the script, the importance of enforcing coding standards is highlighted as a habit of senior programmers to ensure consistency and readability across the codebase, which makes it easier for the team to collaborate and maintain the code.

💡Documentation

Documentation in software development refers to the written materials that describe the system, its components, and how they work together. The video script underscores the necessity of thorough documentation for patterns and decisions made during the project, as it helps in understanding the system and reduces the need for ad-hoc explanations, a practice advocated by senior programmers.

💡Refactoring

Refactoring is the process of restructuring existing computer code without changing its external behavior to improve nonfunctional attributes of the software. The speaker advises against creating separate tasks for refactoring, instead suggesting incremental refactoring integrated into feature development to avoid management's tendency to deprioritize such tasks.

💡Incremental Refactoring

Incremental refactoring is an approach where refactoring is done gradually over time, often as part of the regular development process, rather than in large, separate blocks of work. The script explains that this method helps in building quality into the code and spreading the effort across the team, which is a strategy used by senior programmers to maintain code quality.

💡User Story

A user story is a tool used in Agile software development to describe a feature from the perspective of the user or customer of the system. The video mentions the reluctance to create a user story for refactoring tasks, as it may lead to these tasks being deprioritized or removed by management, highlighting the need for developers to integrate refactoring into regular development cycles.

💡Estimation

Estimation in a software development context refers to the process of predicting the amount of effort, time, and resources needed to complete a task or project. The script advises developers to include extra time for unexpected design meetings and documentation when estimating work, which reflects the foresight and planning expected from senior programmers.

💡Self-discipline

Self-discipline is the ability to control one's emotions and actions, especially in the pursuit of long-term goals. In the video, self-discipline is portrayed as a key habit of senior programmers, who ensure their work is complete and of high quality before moving on to new tasks, thereby avoiding technical debt and maintaining a professional reputation.

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