10 Ways to Become a Better Developer

1. Find & Embrace "Team"

Teams are crucial to implementing almost every point made in this article. When we say “team,” we mean a group of knowledgeable programmers who work toward the common goal of making each other’s code the very best it can be for its given purpose.

If you’re a freelance programmer, find community that can serve as a stand-in team. It’s amazing that, at places like DEV, you can find people who will critique your ideas and code as though they had a stake in its success. Don’t take these people or their comments for granted; rather, find ways to thank them!

If you’re already on a team, dive into your role with zeal. On the Software Engineering Stack Exchange site, there are 14,827 questions related to working on teams. If teams weren’t crucial for innovation, quality, and progress, people wouldn’t put up with them!

Reflect frequently on your appreciation for your team and the mutual dependence you share. This will enable you to see past the interpersonal challenges that come with being linked to other programmers equally staked to the success of your projects.

2. Learn to Say “No” the Right Way

Nobody develops successful, purposeful code in a silo. For better or for worse, programming almost always comes with people, purpose and disagreement. As a craftsperson with expertise and an eye for quality, you may find yourself in situations where saying “no” to people is really needed. But pushing back without burning bridges doesn’t always come easy.

Perhaps your manager has unwittingly made a request that will set back the project. Or maybe your client is asking you to execute a terrible idea you know will never work. Whether it’s with your client or your boss, saying “no” can be risky. But if you handle the disagreement well and learn to stand strong on your expertise, it can help strengthen relationships and build confidence in your abilities.

Here are some practical tips for communicating in these touchy situations:

1. Provide recommendations and alternatives using positive language.
2. Once the other party concedes, follow up with clear, direct language, confirming your mutual decision. This way, you can move forward decisively and confidently without having to worry about: “Hey, I thought we were doing [XYZ]!” Leave no room for misinterpretation.
3. Identify and acknowledge together your common goals.
4. Talk through the “how” of reaching those common goals, and come to an agreement.
5. You’re on the same team. Show your investment in the success of the project by being rational at all times and supporting the other party, even if they don’t change their mind.

Here are some helpful phrases for disarming the person you’re talking with and opening the way for vulnerable, productive communication:

1. “It sounds like what you’re saying is…”
2. “I may be wrong…”
3. “I’m probably completely off the mark here…”
4. “Would you mind if I share my perspective?”
5. “Feel free to step on my toes here…”

(These tips are courtesy of Ryan Ostrom, software architect at Praxent. Read more of his thoughts on positive disagreement at work.)

3. Get Your Code Reviewed

Chances are, your code has a job to do beyond just being written. There are tasks and objectives it is expected to achieve. And if this is a paid project, your code must come through on its promises. So there’s no question--code reviews are essential, especially if the project involves languages or scenarios that are new to you.

Successful code reviews are positive and constructive. Don’t just go through the motions to say you did it. If you’re passionate about programming and take pride in your work, it will show in the way you receive and implement others’ feedback.

4. Review Code for Others

Great developers learn how to make the most of code reviews from both the receiving end and the giving end. There is certainly a lot to learn from having your code reviewed, but there’s also a lot to learn from reviewing someone else’s code, yourself. After all, you don’t really know something until you teach it.

Code reviews can go a long way in strengthening teams. They help cross-pollinate knowledge and insight around the team, allowing teams to lift each other up to the same level. They provide a platform and opportunity for aligning on standards and techniques.

When reviewing code for others on your team, start from a position of appreciation. Recognize that what’s good for the team is good for you. It’s in your best interest to lift up the developers around you through constructive feedback that not only makes their code better but instills them with confidence and equips them to confidently course correct. Never demoralize another developer.

5. Code Accessibly

The best developers think outside the box of their own computer. Your code might work here, now, on your screen. But you’ve got to think about where else your code may be headed, and will it still work when it gets there?

What if it changes hands? Your code must be readable. This means others can read and understand variable and function names within the general structure of the code. Any developer should be able to read and understand what the code is supposed to be doing.

This is easier said than done. Most developers naturally have a unique style. Some take pride in being different in the way they write their code. There’s nothing inherently wrong with creating new and different ways of writing code. But if you want this code to accomplish anything beyond the limits of what simply looks cool today on your screen alone, then save the creativity for better use. Write code that others can work with and understand, and that won’t leave you scratching your chin several months from now, trying to remember what you meant by:

for (int m = 0; m < 34; m++) {
    i += (s[m] * 4) / 5;
}

6. Code for the Future

For similar reasons that your code should be readable, it should also be maintainable. How easy will it be for you or someone else to alter the code in the future?

If there is a structural change you can make today that will save hours of labor in the future, do it.

7. Don’t Be Naive, Security Matters

The Identity Theft Resource Center reported 1,120 total security breaches and more than 171 million records exposed in the US in 2017.

Code as though the application will be processing your own social security number. If there’s even a chance that the project you’re working on could involve the exchange of any sort of confidential information, code must be written with security in mind at every stage. Being mindful about the potential impact your work could have on others is what sets apart responsible coders from the rest.

8. Use Coding Standards

If you or your team doesn’t have coding standards, create them (preferably together). Create them even if you’re a freelance programmer. Once you have standards, it’s even more crucial that you stick with them.

Why do coding standards matter? It all comes back to promoting longevity and multi-purposeness in your code. For example, if inconsistent formatting makes its way into the final product, it could result in unexpected breakage. Adhering to coding standards ensures consistency, saving time in the long run by revealing potential bugs before it’s too late.

You may not feel the need for coding standards until you’re working on a big project with lots of moving parts and multiple programmers. But it’s never too early to start instilling that DNA into your work, even if you’re a solo programmer. The code you’re working on now may be needed again further on down the road when coding standards really matter.

9. At the End of the Day, It Has to Work

Your code doesn’t just have to work, it has to work for the end user. And it has to work in every context for which it’s purposed. For this, testing is crucial.

What happens when the user inputs an unexpected digit that your code was not built to handle? Does the application recover gracefully? Or crash the whole network?

UX design and prototyping are increasingly essential for creating digital products that succeed today. Just because you're not a UX designer doesn't mean you aren't developing for the user. In fact, the best code is developed AFTER the user interface design has already been touched on.

If you're working on all stages of your project, from design through code, remember that you don't have to be a huge software company to conduct usability tests. Keep it simple, but make sure it's covered in your process.

10. Code for Fun

In business, there’s no such thing as technology for technology’s sake. But as a programmer, there is definitely a time and a place where coding should simply be about geeking out on tricks and experiments. Your gift of programming is not just for helping others get things done, it’s for your own enjoyment as well!

Participating in hackathons or developing side projects can be a really healthy outlet for developers to simply exercise their skills without pressure or constraint.