How experienced programmers actually write code

Channel	Publish Date	Thumbnail & View Count	Download Video
	Publish Date not found	0 Views	View on YouTube Download Video

Professional habits make the difference between someone who actually writes code like an experienced programmer – and wishful thinking.

The syntax and patterns you use in software projects are not nearly as important as the standards you set for yourself in terms of professionalism.

In this episode, I share the essential habits I've picked up working on almost every software project throughout my career. If you want to write code like experienced programmers, I hope these practices will help you stand out from the crowd.

Before you start developing these habits, you should know why it's important to write high-quality code in the first place. It's not just about making other programmers think you're cool ;).

WHY WRITE HIGH QUALITY CODE?

First, other programmers need to be able to read your code if they want to consider you experienced. You've probably heard that programmers are often better at writing code than reading it. And if you want other members of your team to treat you like a pro, you need to reject myths like "self-documenting code" and treat your code like a personal brand.

Second, writing high-quality code reduces the time you spend supporting it and explaining it to other members of the software development team. Many programmers get frustrated when they have to explain their code to other team members. If your code is truly self-documenting, shouldn't it be?

Finally, writing code like a truly experienced programmer reduces the likelihood that someone will come along and rewrite it just because they like a different coding pattern better. To increase the durability of your code, you should have the habits and discipline to follow the 6 tips I'm about to give you on how to write code like an experienced programmer. This will have a huge impact on how others see you and your quality of life on software projects.

6 TIPS FOR WRITING CODE LIKE AN EXPERIENCED PROGRAMMER

The first tip is to finish the code you started! In some Scrum or Kanban projects there is a lot of pressure to show progress, but if you haven't finished, don't lie about it! This will only lead to more personal technical debt, so you'll be under even more pressure to finish later. If you don't want the code to get out of control, that's entirely up to you.

The second tip is to enforce coding standards. If other programmers on your team have different preferences regarding formatting of curly braces, spacing, or other aspects of your code, sharing code across the project can be frustrating. We now have the tools to do this automatically – use them!

The third tip is to be disciplined about documenting the patterns the team has agreed to use. It's essential that you have a wiki topic or markdown file in your project that contains links to how each important pattern is applied in your project. Doing this will reduce time wasted in code reviews and prevent people from introducing new patterns without a good reason to discuss them before they've become prevalent throughout the code.

The fourth tip is to discuss new coding patterns with your team as soon as you introduce them. Instead of replacing an existing pattern across the entire codebase (ask for forgiveness, not permission), do your teammates a favor and be inclusive as soon as you have something to show for it. They will likely have good advice on how to improve usage, and you can get their buy-in and engage them to help you with all the refactoring work.

The fifth tip is: NEVER expose refactoring as tasks, user stories, or tickets in Jira, GitHub Issues, Trello, Asana, Visual Studio Online, or whatever tool your team uses to track work. When an essential engineering practice is mentioned as a separate item, management will only be tempted to pull it out.

And the sixth and final tip is to always assume that there will be unexpected changes in the project for any task you have to estimate. Whether it's unplanned software design meetings, bug fixing, or documentation, if you want to write code like experienced programmers, you can't be pressured to cut corners. While we can't predict every possible uncertainty in a software project, if you estimate that nothing will go wrong, you only have yourself to blame.

#Programming #Coding #Technology