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.

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.

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 ;).

WHY WRITE HIGH QUALITY CODE?

First, you need other programmers to be able to read your code if they are 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.

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 explain their code to other members of the team. If your code really is self documenting - shouldn't that not be the case?

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. To increase the shelf life of your code, having the habits and discipline to follow the 6 tips I'm about to share 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.

6 TIPS FOR WRITING CODE LIKE A SENIOR PROGRAMMER

The first tip 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.

The second tip 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. We've got the tools to do this automatically now - use them!

The third tip 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.

The fourth tip 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.

The fifth tip 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.

And the sixth and final tip 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 cut corners. 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.

#programming #coding #technology

RELATED CONTENT

Scott Nimrod on Consulting and Software Craftsmanship

Need help with your career? Book a free career consultation:

CHAPTER MARKERS

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
Download a free software development career guide from my home page:

[travisSimon]

Also, if you're in a code base with irregular formatting and you want to make a clean up of formatting (whitespace and/or braces), be sure to make a commit that only does the reformatting and no code changes.

Formatting changes touch nearly every line of code, and if there are logic changes sprinkled in, it becomes very difficult to find them if 90% of the lines are changed.

[thegreatclarifying]

"If you don't have time to do it right the first time, what makes you think you'll have time to redo it." I had that quote on my whiteboard for years.

[tjmcode]

I've work inside a very large manufacturer, and when I present all of these principles--and try to enforce them on new projects from day one--I'm very surprised by the reactions from other team members. This video assured me that I'm not crazy and I've been doing it correctly for decades... Thank You.

[SpaceMonkey]

“Programs must be written for people to read, and only incidentally for machines to execute.” - Harold Abelson, Structure and Interpretation of Computer Programs

[justgame]

I like the quote “There’s nothing more permanent than a temporary solution” It applies well to the leaving code j finished scenario

[damnyutoobe]

I'm a senior dev and a scrum certified product owner and I can honestly say that many organizations abuse the whole velocity concept to prematurely force developers to "finish" their stories and tasks. They have taken something that developers love (development) and turned it into a sweat shop.
So please, respect your developers and stop pushing your team to its absolute breaking point just to meet some arbitrary velocity.

[dpuplava]

20+ years of development experience here - I agree with all these points. To reiterate an overarching theme, as a professional developer, do the professional thing and take ownership for your software. Notice the keyword being "software" and not "code" because software is more than just code - it's the documentation, communication, refactoring and timely delivery of that code.

[nl]

I've been a freelance graphic designer for almost a decade. SO much of this is exactly on point. Levels of communication, consistency, and clarity are what really separate the individuals who are a joy to work with to those who may be talented, but I would not want to work with again.

[stevejohnston]

Jamie,
This was great advice as usual. I started programming 50 years ago back in 1972 before Structured Programming had been invented in 1973. At the time, it was thought that writing computer code with the fewest lines of code was the mark of a truly gifted programmer. Remember, at the time, many programs were written to be only run one time by the person who wrote the code! This was very much like the Baroque period of music (1600 - 1750) in which Bach lived. So, at the time, programmers were like Baroque composers such as Bach who were commissioned by the King to write a piece of music that was only intended to be played one time at a particular regal function by a single orchestra and then discarded. So there was very little effort devoted to preserving Baroque musical compositions, and that is why we have very little Baroque musical code left for us to enjoy beyond the works of Bach and a few other composers. Only later in the 1970s did I run across "canned" programs that were meant to be run more than once using input data punched on a deck of cards. That's when I learned that "truly gifted" programmers did not write code in the fewest number of lines of code. Truly gifted programmers wrote code that others could understand and work with 10 years later!

Regards,
Steve Johnston

[hexchad]

You know you're a senor programmer when you are a Spanish man who writes code

[yar]

I really love that you wrote the summary text in the description. I've read the essential parts much quicker than it would take me to watch the video. You are a senior YouTuber for me, many thanks!

[simonekleinschmidt]

As a project manager I cringe about "don't make documentation and refactoring additional tickets because they might be axxed", not because it is wrong, but because I remember how often I fought for these tickets because I knew they would work for me in the long run. (and often got defeated anyway, so you are right)

[midoevil]

I think some of points that distinguish a senior programmers for me :
- They know WHY: when you ask a senior why this was done, they will usually have a logical answer, even if you don't agree with it, but their point will be consistent and reasonable, and usually will offer another point of view that wasn't obvious.
Juniors and "Pseudo seniors" will usually give excuses, can't provide a consistent answer, or pretty much rely on their authority to push their view.

- They have insight: Good seniors can make use of their experiences to predict the different outcomes of different decisions, in a way, they can make mental simulation, and so, they can save their team lots of time and effort by guiding them to avoid future problems, or at least set the project in a way flexible enough to keep going without hitting a deadend.

- They are good at handling and understanding business-side: wither it is based on trust or good arguments, good seniors usually know how to deliver their points to product-owners, product-managers, or business users. They may predict the business side concerns before feedbacks, or

- They are good at making trade-offs: this is based on the last points, with enough experience insight and negotiation skills, good seniors and tech-leads can make flexible trade-offs to offer the business as much value as possible.
- They are NOT perfectionists: Good seniors that "Good enough" is always better than "Expensive Perfection"

[JonLewis]

I’m a software development manager and former front-end web developer since 2003, great video and it’s interesting to see someone give their perspective on what it means to be a senior.

I’ve been a part of many projects, both brand new development and inherited code bases at several different companies in my career. What I look for when hiring senior developers is a sense that they have some wisdom and experience in what they do, regardless of the language they code in, you can see from interviewing them that they’ve encountered many different development scenarios in their career and they think deeply about what they do.

They aren’t too hard-headed, or proud, or set in their ways that they think they have learned everything they need to know, and everyone needs to do things their way because they know best. Humility is vitally important for cultural reasons in a company and also for the success of projects to be able to see obvious pitfalls and roadblocks during development.

Over-engineering can be the death of new projects and features. I want my developers thinking about solving the problem as simply as possible from the get-go and only introducing further complexity when it is required. I’ve even done it myself where I’ve tried to implement a new tech stack that I wanted to use, only to get into it and find out it’s adding way too much time and complexity. Usually because the documentation and best practices says that I require a whole lot of scaffolding for my application. This is bad for business. Take best practices into context but still try to solve simple problems with simple solutions.

Dependencies create complexity. The more dependency you introduce in a code base, the more chances you will create bugs and add fragility to the project. If you reduce dependencies you will likely reduce the bugs in your software.

Also, code so that others can easily understand it and debug it. Even if that means a few extra lines of code. You shouldn’t need to write novels about how your code works, it should be readable and easily understood even for a Junior developer. When code is over-abstracted it can be difficult to track down the root cause of bugs. Personally I’d rather read code than documentation about the code. Abstraction also adds complexity.

Anyways these are just some of the things I’ve learned so far in my career, and it seems this type of knowledge is a bit scarce these days (I’m trying to hire right now haha)

All the best to everyone out there and happy coding! May your days be bug-free with happy customers :)

[jtkilroy]

My second comment on this great video. I met a guy that was working at my old employer, but didn't know it. After being introduced he asked me if I used to work there. I said yes and he went on about seeing my name every day in all of my 20 year old code. Made me feel really good about my work.

[richardknouse]

I have been programming over 45 years. In too many projects if have seen a rush to produce visible surface results without first building and testing out the functional foundation. This is because management typically has its focus on visible features and doesn't appreciate the art of well structured code. Each sprint should include development of foundation function in anticipation of rolling out features in future sprints. This goes along with your recommendation to bury the refactoring effort so that management doesn't sabotage it.

[HealthyDev]

Don't be distracted by language syntax and coding patterns - habits are what makes a senior programmer! Here are some of the best one's I've learned. What are yours?

[gligorhoria]

I'm really glad you started making videos again. You teach things we can't really learn from anywhere else.

[kabeerchoudary]

I have started to follow your channel from few months back. Your videos does reflect day to day shenanigans in life of a software developer. It really helped me to see the bigger picture of corporates from a bird eye view. Thank you for your efforts and appreciate your content. 😊

[shivsticker]

As someone who does a bit of Dev and Ops, I sincerely believe your comments about refactoring are very true for the Ops world as well. When there is an opportunity to automate a manual process and it keeps getting pushed off by management in favor of the latest feature, the only way to get it done is to simply do it.

Getting that type of improvement work done makes me more excited to go to work, and makes my job and my team's jobs easier.