Becoming a software developer, whether it be through an online course like Treehouse or independently, can be one long, never-ending journey. The habits you form along the way can have a direct effect on your career and how well you work with others. 

As we talked about some of the essential software developer skills last week, we mentioned that the difference in skills is what separates a good developer from a great one. 

The same applies to your habits in your work as a developer.

If you want to make sure you’re following the best practices when working within a team of developers and your personal coding skills are suited for teamwork – be sure to read on.

Everyone has a different approach to coding, some less harmful than others. 

A lot of this comes down to experience. Bad habits can be hard to break, especially if you develop them early and they follow you throughout your career.

This is even more the case when you’re not even aware of your habits that could be taking up your precious time. 

“First we form our habits, then they form us” – Rob Gilbert

The same applies to your bad habits that could be killing your drive and ruining your development efficiency.

Research says that it takes anywhere from 21 days to 66 days to form a habit. In the long career span of a software developer, adopting small programming habits can have a huge impact on your overall work.

If you want to set your expectations appropriately, it might take some time to time to build new behavior, but it’s worth noting that building is not an all-or-nothing process. 

Building habits take time, but as long as you stick to them, the small investment is guaranteed to pay off.

You might look back on your previous web development projects, for example, and realise that your code could look better. But this shouldn’t discourage you. Everyone makes mistakes once or twice, this doesn’t necessarily impact your long-term habits.

Similarly, there is no reason to get discouraged if you start adopting a new practice in your development efforts for a few weeks and it doesn’t stick at first. As long as you’re aware of your habits and embrace the long-term, you can always change and improve your work quality.

With that said, If you’re a developer yourself, you might want to take note of some of the best-use practices to make sure your code performs optimally. 

The following is what we’ve found to work for us at Scale3C during our software and mobile development projects, and because of the nature of the programming habits, they can work for you as well.

1. Planning Before Coding

It’s essential you know the ins and outs of a project before beginning. 

In the development world, it can be relatively easier to plan ahead if you know the project requirements in advance (ideally, you should). Consider some of the features you might have to implement in the future.

Do you know how they work? Are there any parts you’re unfamiliar with? How will that interact with your initial code?

These are all questions you might want to ask yourself before writing the code.

If you are not sure, be sure to look it up beforehand, as opposed to when you’re halfway through a project.

Your planning and research phase may vary, depending on your time constraints. 

Consider the following scenarios and how you can form your habits for doing research.

1. It’s simple, and relevant to you. In this case, take the time to read through it carefully as it may contribute to your broader understanding of the subject and give you a stronger foundation when you begin. Consider how the 80/20 rule can affect your efficiency here.
2. It’s important, but may not be essential to your project at hand. In that case, see if you can familiarise yourself with the main idea and don’t get too invested in learning all the details.
3. It’s not relevant immediately or for the mid-term. In this case, you can simply return to the original task and come back to this if you ever need it later. It might not be worth spending your time reading about it for now.

With the above habit in mind, you’ll find that you can stay on top of any resources relevant to you and not venture far off from the original task. 

If it’s relevant for you to begin coding – save it as an important resource. If not, you can always come back to it later.

2. Writing Human-Friendly Code

Once you do your research and have a plan on how you’ll approach the project, you can then start writing code, as long as it’s human-friendly and readable.

Unclear code is a pet peeve for developers all over the world. 

You start working on a development project, the code makes sense so far, but somewhere along the way, it loses readability in favor of functionality. 

Does this sound familiar?

Just because the code works, doesn’t mean it’s optimal.

Remember, you’re not writing just for machines, but for your future self and your colleagues as well. It’s important to write readable code if you ever want to revisit it in the future and optimise it later.

Instead of saying “I’ll fix it later” or “I’ll come back to this in the future”, make sure to document your thinking process while coding and prioritise the architecture of the code first.

When writing human-friendly code, make sure that:

• You’re not disrupting the flow with unnecessary conditions. Are you leveraging flow state to write better code? Focus on what’s important.
• You’re following a consistent naming practice. For example, if your variables start with an underscore as the first letter, make sure you follow this habit for the rest of the project Similarly, if you’re working collectively with a team, be sure to discuss your naming practices before you begin coding.
• You’re commenting on the important parts of your code. This should be obvious, and it’s an easy habit to form. Also, this helps save time should you need to come back to the code later or pass it on to a colleague for revision.

Bonus tip:

At Scale3C, we sometimes jump into already existing projects where we have to go back and improve or add certain functions within the code. 

Having clear, human-friendly code with proper documentation is a huge relief as it allows us to save a lot of time going over pre-written code. Taking over development projects can be scary if you’re not sure what you’re getting yourself into.

Remember, you (and the machine) are not the only ones who have to understand the code. Make sure it’s readable to other developers as well.

3. Asking for Help

Asking for help can be hard at first, but it’s a great chance to practice collaborative problem-solving and improve your overall habits as a developer.

There are a number of things to consider here.

First, most people are afraid to ask for help due to impostor syndrome or that they feel they should know it or they’ll just figure it out. In reality, this just wastes your time and hinders growth.

As a developer, you have access to a lot of important resources.

Sometimes a quick Google search or a Stack Overflow answer is all you need. But in most cases, someone working close to you will be a better resource for the specific project at hand.

Daily scrum meetings are ideal to share your experience with colleagues and to ask for help.

No matter how long you’ve been a developer for, there’s always something new you can learn. 

Whether it be a new tech trend you can catch up on or a new app development framework, you never stop learning as a developer.

Then, as soon as you learn something new, be sure to note it down for future reference. This also contributes to being consistent in your development, as mentioned above, and you’ll have a place for resources you can always double check with. 

4. Consider Code Review

Speaking of communication, if you want to be on the same page as your team for future development sessions, consider adopting code review practices in your team.

Many developers dislike code review sessions because of how time-consuming they can be. But the aim of a successful peer review is to maintain code quality moving forward. 

For this, code reviews require a balance of consistent documenting practices that make for a highly efficient collaborative environment.

Effective code review is only worth doing if it’s done right. 

For this, consider adopting a checklist and proven best practices within your team.

Test-driven development and quality assurance practices have proven value in the long-term. 

More specifically, you should be keeping an eye out for the following.

What to review:

• Consistency.
• Structure.
• Style.
• Performance.
• And more. 

As for when you should do code reviews, consider the scope and the size of your project. This may vary across teams and may also depend on the methodology you use.

Overall, look for consistent communication and feedback in your code reviews if you want to increase your development efficiency.

5. Proper Use of Version Control

Version control (also known as source control) is the management of file changes throughout a specific period of time.

These systems automatically record changes for all files stored, allowing you to get back to a particular version or a point you made some changes in.

If you want to keep every version of your code, you can use a version control system like Git as a way to handle and track any kind of changes during your project. It allows you to revert to selected files to a previous state or version, see who modified it last, compare changes over time, and more.

Benefits of using version control include convenience when collaborating, understanding what happened better, and having a backup in case of an emergency.

Versioning is also a great way to keep track of application versions and to see which version is currently in development, in the QA phase or in production.

Essentially, it makes for better teamwork and communication. 

With a proper version control system, everyone on the team can work on any file, any time. 

The VCS will then allow you to merge all the changes into one common version. This way, there is no need to look for the latest version or the status of the project, as it will be in one place that everyone can access – your version control system. 

In order to use a VCS system optimally, be sure to:

• Commit often so that you’ll be dealing with small changes at a time, in case you need to revert back.
• Add a commit message to convey a message to other team members.
• Only push completed work to make it easier for everyone involved to know the status.

If you’re following all of the above habits, all while documenting everything and using a proper version control system – you’ll be well on your way of developing habits needed to become an efficient developer.

The above approach prioritises collaboration and communication within a development team. 

Not only will the habits help you in becoming a better developer, while maintaining teamwork and efficiency, they will also help your colleagues in working with you and focus on the same long-term common goal.