How Senior Programmers ACTUALLY Write Code
Professional habits are what makes the difference between someone who actually writes code like a senior programmer - and wishful thinking.
The syntax and patterns you use on software projects don't matter nearly as much as the standards you hold yourself to for professionalism.
If you want to write code like senior programmers do, and really delight your employer AND teammates - I hope these practices help you stand out from the pack.
This article is a summary of a video on my YouTube channel about the same topic. In this episode, I share the essential habits I've discovered that transform careers while working on nearly 40 software projects.
Why Writing Code With Senior Programmer Habits Matters
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.
Most of the recent videos on my channel end with an #episodegroove where I'm sharing little snippets of music I've written over the years. ??
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.
Need help with your career? Book a free career consultation.
CHAPTER MARKERS
You can jump to timelinks in the YouTube video that accompanies this episode below:
3 reasons why habits to write code like a senior programmer matters
6 habits of senior programmers
Download a free software development career guide from my home page:
Web Developer/Owner at Vibrant Web Design, LLC
2 年It seems quite a few of these come down to good communication skills.