Watch How Senior Programmers ACTUALLY Write Code Video Tutorial

Work with me → https://healthydeveloper.com/ 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 Scott Nimrod on Consulting and Software Craftsmanship https://www.youtube.com/watch?v=uh6o2UzoGo0 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