4 Coding Habits to Form Now (and why it matters)

4 Coding Habits to Form Now (and why it matters)

It's week 6 of coding class - and we are live on production! And as I continue to code away, a comment from a visiting Iron Yard alum has stayed with me: he was griping about the lack of context left behind in legacy code. "Be thoughtful about how you code, if for no other reason than for future developers," he said. "You may not know them, but they will know you."

As new developers, it can be tempting to glaze over the best practices we're learning in an effort to get to the result faster. But this got me thinking: What are the good coding habits that we should be forming now, and why do they matter? 



When you're tinkering with programs on your own, it's easy to get away with hitting the keyboard before you plan. But when you become part of a team, this process becomes critical. You will likely encounter a Product Manager, and Product's requirements don't always make sense (trust me on that.) Sometimes PM's don't completely understand the technical details of their requests; other times, developers misunderstand requirements. Either way, it is critical that these two groups discuss until in agreement - otherwise; you could end up having to throw away your code halfway through its implementation. 

So before you start typing away, stop and think. Review or create a wireframe, make a chart of your database structure (if you are using a database), understand all of the requirements. Read through the code you are modifying and ensure that you get what it's doing, research early for existing gems or other tools to utilize. Planning beforehand has many benefits: it protects you from trying to reinvent the wheel - you'll likely come across some helpful resources during your research. It allows for better estimation, stronger communication with your non-technical teammates, and a greater chance of knocking everyone's socks off.



When you're working on a project to which only you will ever contribute, it can be super temping to code away without thinking about the context. But remembering that other developers will be reading your code is critical when coding as part of a team. Your priority is to make your code as interpretable as possible: proper indentation, obvious and descriptive variable naming, clear conditionals. While your code does of course need to be read by a machine, it is just as critical that it be readable for other humans. 

Too often there are changes that other developers must slog through without any documentation as to why certain changes were made. Documentation can be made externally to your code, in a ReadMe or in a GitHub Wiki. And while comments can be helpful, only add them when you cannot make your code easier to understand on its own. By writing your code for humans, you can save your team a major headache down the road. 



Write a test. Make sure it fails (otherwise, you may spend time writing code to pass a test that didn't fail in the first place.) Then write the code to make it pass. It can be difficult to discipline yourself to adopt this habit, but it's super useful to form when you're a beginner. The act of writing a test also forces you to identify a clear understanding of the feature's requirements. Otherwise, you may find yourself writing tests that allow your code to pass rather than crafting tests that ensure your code meets a requirement. 

TDD (Test Driven Development) is controversial, and many more experienced developers have moved on to more flexible conventions like BDD (Behavior Driven Development). But test coverage remains critical - when working on a team, thorough tests minimize the chance of regression errors causing other developers to spend time fixing your mistakes.  And it serves as yet another useful tool for developers to decipher what you were thinking when you wrote that code. 



As developers, we are taught to commit early and commit often. If you've made a mistake in your code and want to go back, you are much better off rolling back to your code one hour ago than one week ago. And when working on a team, the longer you wait to merge your code, the higher the chance that you'll have many conflicts with other developer's changes and will have to dig yourself out of them. 

There are other benefits as well: committing frequently forces you to dissect your project into shippable pieces, build each of them separately, and commit. Writing thoughtful and thorough commit messages helps your developer teammates review your history and understand certain changes and decisions. And there is no need to comment out chunks of code just in case you need them later - if you do, it's in your commit history. 


In his book The Power of Habit, Charles Duhigg identifies the habit loop: the cue or trigger, the routine or action you take, and the reward you seek by following the routine. He writes, "To change a habit, you must keep the old cue, and deliver the old reward, but insert a new routine." Good coding habits are powerful tools that guide good decision-making and effective workflows, while bad coding habits can forever condemn us to repeating the same mistakes. As new developers, let's put in the effort now to be great teammates later!

Open Source and A Warm Fuzzy Feeling

Open Source and A Warm Fuzzy Feeling

What Coding Errors Teach Us                           (About Life)

What Coding Errors Teach Us (About Life)