5 techniques to becoming a better coder

On the Harness blog, we’ve discussed many software delivery concepts. Anything under the sun, including Continuous Delivery, emerging technology, and DevOps. And the purpose of that was to enable stakeholders to innovate. Breakaway from the status quo and the limitations enforced by traditional CI/CD. And ultimately let you make judgments on Harness. To decide if it’s the right platform to enable said innovation. 

With this said, our goal for 2020 enables a new age of developers that stand out amongst others, the Unleashed Developer. They accelerate software delivery excellence because they’ve solved it. And they’ve broken away from the limitations of CI/CD status quo.

To kick off this new milestone for the fiscal year, I'm sharing this blog post on becoming a better coder. In 2019 the United States Bureau of Labor Statistics released its report on software developers, stating well over 1 million jobs present-day. The projected average growth rate over the next ten years is 21%. In comparison, the average growth rate for all occupations is 5%. In an industry that’s growing and changing rapidly, the opportunities within technology are fantastic; we get to solve difficult problems, build great teams and communities, share knowledge, and experience personal growth. So here are my five tips on improving software code. Cheers to enabling software developers!

Understanding the source code. 

If you’re looking to extend and enhance your applications effectively, take care to understand the codebase. Think of the entry points of the application. What parts of the app are always called? What are the control flows for service requests? How did the application come to be, and what decisions were made to get to its current state? If you are a newer developer on the team, this is a great way to quickly become effective, as you’re able to navigate the application and resolve fixes. 

Here are a few more tips to understanding codebases:

Read existing documentation and commit messages to gain context to a source code’s history. What tools and approaches were considered in the decision-making process? What were the outcomes of the research? Encourage and seek out discussions with other members of your team.

Pair programming is a great way to build comrade across the team while sharing peer-feedback. Two pairs of eyes is better than one when it comes to reviewing code. And this is also a great way to build domain expertise across the team. There are dozens of resources that document the benefits of pair programming. Here is one resource. 

Having an in-depth understanding of the app helps you scale your team. Quickly create new modules to interface with the application. And feel comfortable working with existing modules of your application.

Creating Readability of Source Code. 

If your team does not already have one, I recommend defining a programming style guide. A guide helps maintain consistency through the codebase. Define rules around anything, such as indent styles, comments, and naming conventions. If you’d like some inspiration on style guides see Google's Style Guides. It's also possible to enforce these styles into your build or approval processes.

Aside from the readability of the code itself, pay attention to the code’s control flow. Nested bubbles of logic are hard to comprehend. Sometimes it manifests itself in what looks like pizza-shaped code: 

The best way to avoid this is to reiterate that conditionals serve as gates(as known as guard clauses). Instead of taking the happy path through the code, use conditions to check for failure and ensure that the code fails on said conditions. 

As an individual contributor, it if it’s code you’re working with leave code better than how you found it. Practice the DRY - Don’t Repeat Yourself methodology, by avoiding duplicate code when you can create helper functions/files. 

These basics make a huge difference in the readability of source code!

Consider symptoms of code complexity. 

Code complexity is “the degree to which a system or component has a design or implementation that is difficult to understand and verify.” Tools like SonarQube offer complexity grading and metrics. Poor performance in these areas can cause a variety of symptoms. One symptom of complexity is the time it takes to implement feature fixes or additions. Consider that code that is hard to evolve may be complex in nature. 

To minimize code complexity:

Break apart your code. Separate code that is likely to change or contains domain logic. It’ll be easier to spot needs for performance optimations, in consideration of memory space and execution time.

Note error handling and recovery. Consider best practices when handling exceptions (here is one on Java). Errors should also bubble up to the outer layers of your codebase. 

Code complexity keeps in mind three indicators: readability, understandability, and modifiability of code.

Navigate the Dependencies. 

Tightly coupled code is hard to fix. One change could result in a ripple effect of more changes. Testing also becomes harder because your unit tests will grow in complexity and size.

If you have trouble with this, consider using dependency injection and mocking out stable application components to enable the right amount of flexibility in your codebase. Dependency injection is the practice of creating a component that is dependent on another component. There are levels to the dependency injection that can occur at the function or constructor level. Code dependencies can also be managed with dependencies frameworks that will auto-generate code.

Poor code designs lead to changes that cause ripple effects that span different components. Manage your dependencies to avoid this and enable your testing suite. Remember that you can go too far with dependency injection, you shouldn’t end maintaining and writing unit tests that require the mocking of more than 2 or 3 services just to test a component.

Love your Craft.  

This sentiment is too underrated. Don’t forget to love your craft! Your work will naturally improve and set you apart with time and dedication. I enjoy this quote from Dave Xiang: “Code is meant to be shared and loved. It’s not just your code-it’s everyone’s code.” Code on.

Conclusion

This is the first blog post for the Unleashed Developer. I'm looking forward to the coming weeks of learning content where we get to support modern software development this year. If you'd like to see related content for the Unleashed Developer as it gets added, click here.

Software delivery is a top priority for organizations that own software, yet it remains one of the most challenging problems enterprises face today. Enterprises are keen on tighter execution models for delivery and using DevOps practices to get there. DevOps begins with people, process, and technology. These were five tips on maintaining and delivering better code with your team. I hope these tips help you gain the insight and experience you need to keep delivering better!