How Senior Programmers ACTUALLY Write Code
The syntax and patterns you use on software projects don't matter nearly as much as the standards you hold yourself to for professionalism.
Watch or listen to this episode
YOUTUBE
SPOTIFY
APPLE
The syntax and patterns you use on software projects don’t matter nearly as much as the standards you hold yourself to for professionalism.
In this episode, I share the essential habits I’ve developed while working on nearly software projects over my career. If you want to write code like senior programmers do, I hope these practices help you stand out from the pack.
Why Write “Senior” Level, High Quality Code?
Before getting into these habits, it’s important to know why it’s even important to write high quality code. It’s not just so other programmers think you’re cool. 🤣
Reason #1: Senior Coding Habits Increase Team Comprehension
First, you need other programmers to be able to read your code if they’re going to consider you senior. You’ve probably heard how programmers are often better at writing code than reading it. And if you want other members of your team to treat you like a professional, you have to reject myths like “self documenting code” and treat your code like a personal brand.
It may take things like adding extensive code comments, writing wiki topics, and authoring code samples to make the unique patterns in your code easy to comprehend. I talk about this more later in the article. I’ve been on far too many projects where people rewrite code with absolutely zero benefit to the business or customer – other than suiting their coding preferences!
Reason #2: Senior Coding Habits Reduce Interruptions
Second, writing high quality code will reduce the time you spend supporting it and explaining it to other members of the software development team. Many programmers are frustrated that they have to stop what they’re doing and explain code they wrote in the past to other members of the team. Then they get frustrated again when they barely understand what they wrote 6 months later. 😲
If your code really is self documenting – shouldn’t that not be the case?
Reason #3: Senior Coding Habits Extend Your Code’s Longevity
Finally, writing code like truly senior programmers do will reduce the chance somebody comes along to rewrite it just because they like some other coding pattern more. One of the most frustrating things is to pour your blood, sweat, and tears into a challenging software feature or task – only to have someone come along and do the whole thing over again.
6 HABITS FOR WRITING CODE LIKE A SENIOR PROGRAMMER
To increase the shelf life of your code, having the discipline to follow the 6 habits below for writing code like a senior programmer will make a huge impact on how others see you – and your quality of life on software projects.
Habit #1: Prevent Unfinished Work
The first habit is to finish the code you start! There’s immense pressure on some scrum or kanban projects to show progress, but if you aren’t done – don’t lie about it! This only leads to more personal technical debt that you will be under more stress to finish later. If you don’t want to let the code grow out of control – this is completely up to you.
Habit #2: Enforce Coding Standards
The second habit is to enforce coding standards. If other programmers on your team have different preferences for how they like to format curly braces, spacing, or any other aspect of your code – this makes it frustrating to share code across the project.
VSCode has extensive formatting support (especially using tools like prettier), but if you’re using a heavier IDE like Visual Studio, there are also third party plugins that will format according to rules when you save. There are also many tools for checking for things much more impactful than just formatting.
We’ve got the tools to do this automatically now – use them!
Habit #3: Document chosen patterns
The third habit is to be disciplined about documenting the patterns the team has agreed to use. You absolutely must have a wiki topic or markdown file in your project that has links to how to apply every major pattern on your project.
If you do this, it reduces wasted time in code reviews, and prevents people from introducing new patterns without a justifiable reason for having a discussion before it permeates throughout the codebase.
Habit #4: Review New Patterns EARLY
The fourth habit is to review new coding patterns with your team as soon as you introduce them. Rather than replace an existing pattern all over the code base (ask for forgiveness rather than permission), do your teammates a solid and be inclusive as soon as you have something to show.
They’ll probably have good advice for how to improve on your use of it, and you can get their buy-in and enlist them to help you with the full refactoring effort.
Habit #5: Never “Line Item” Refactoring
The fifth habit is to NEVER expose refactoring as tasks, user stories, or tickets in Jira, github issues, Trello, Asana, Visual Studio Online – or whatever tool your team may be using for work tracking. Whenever an essential engineering practice is called out as a separate item – it only tempts management to pull it out.
If you were building an airplane, would you let management cut corners on safety standards that could result in someone’s death? No, and you should never enable your management to control the quality of the code. To do this however, you need to learn incremental refactoring. This is the ability to slowly introduce changes over time as part of ongoing work.
I’ve been on teams where a developer explains this to management, and they try to create tickets so they can report progress on features and refactoring efforts as a separate line item. Don’t do it! It only ends in cutting corners and a mess of a codebase that’ll have you or your colleagues quitting soon when the project is a disaster to work on.
Habit #6: Assume Unexpected Change
And the sixth and final habit is to always assume there will be unexpected change in the project for every task you need to estimate. Whether it’s unplanned software design meetings, troubleshooting, or documentation – to write code like senior programmers actually do, you can’t be pressured to build a high volume of code and features without appropriate documentation and supportability.
While we can’t predict every possible uncertainty on a software project, if you estimate like nothing will go wrong – it’s your own fault.
Skip to Points in The Video
- 0:00 Introduction
- 0:25 Why senior code matters
- 0:30 1. Team comprehension
- 0:57 2. Reduce interruptions
- 1:28 3. Extend longevity of code
- 2:10 6 habits of senior programmers
- 2:18 1. Prevent unfinished work
- 3:46 2. Enforce coding standards
- 5:11 3. Document chosen patterns
- 8:01 4. Review new patterns early
- 9:28 5. Never expose refactoring
- 11:16 6. Assume unexpected change
- 12:40 Episode groove
Resources
About the THRIVING TECHNOLOGIST show
On YouTube and all major podcast networks, Jayme shares teamwork and leadership strategies, guidelines for healthy company culture, and stories about real projects so you can have a sustainable career in the software industry.
Jayme Edwards
A family man and veteran of nearly 40 software projects, Jayme experienced many wins and losses over his career as an architect and consultant.
Now he's coaching software developers, managers, and business owners to overcome challenges in the IT industry - so they keep growing.