20 Habits of Successful Software Developers

20 Habits of Successful Software Developers (They’re Not What You Think.)

How to be the high-performing programmer who everyone wants on their project team.

If you're reading this, then you may be expecting a list of soft skills with advice on how to be patient, supportive, and collaborative.

And, yes, these traits are all important to hone to be a good developer.

Nucamp Blog: The non-coding skills you need to get a job in tech.

But let’s review 20 important habits every good programmer needs to embrace.

Because if they don’t develop these habits, they risk being a mediocre developer, or worse, a liability.

No one wants to be the developer who accidently writes the infinite loop that crashes the development server.

If you’re still reading, then mediocre or a liability are not what you’re striving for.

Good!

These habits will help you grow to be the developer that everyone wants on their project.

They will also help you grow to be the developer whose opinion the team trusts.

AND grow to be the developer that makes product managers yell, “Thank, Goodness!” when they hear you’ve been assigned to their project.

To embrace these 20 habits, every developer needs to be one of the following at any given time:

• student

• event planner

• construction worker

• detective

• psychic

STUDENT:

1. Never stop learning.

Technology evolves quickly and constantly.

If developers don’t stay current on what’s trending, they become relics faster than they can blink.

And playing technology catch-up is difficult and stressful.

So don’t blink.

2. Programmers don’t need to have an in-depth understanding of every piece of infrastructure and every integration point.

But they should at least know how the moving parts impact their code.

3. Sit in on every code review that you can.

Especially if it’s a programming language you don’t know.

You will learn something new.

Even if it’s just how to pronounce Kubernetes.

4. Google it before asking for help.

There are so many online resources that are just a search engine away.

If your code generates an error, Google it, or Bing it, or Yahoo it.

Pick your poison.

Chances are someone has already encountered the error and documented a solution.

 

EVENT PLANNER:

5. Reserve a conference room (virtual or in-person) and coordinate whiteboard sessions.

Walk through the scenarios that the project is trying to address.

Brainstorm as a team.

There are no bad ideas.

Have one team member draw it all out on the board, while another takes pictures of it (or screen shots.)

Side note: If you use a Sharpie on the whiteboard by accident, scribble over the Sharpie ink with the Dry Erase marker.*

Works like a charm!

*Only applicable for in-person sessions.

6. Understand the problem the user is trying to solve.

A product manager may come to you with a solution in hand, but you know the code better.

If you understand the details of the problem they’re trying to solve, perhaps there’s a more efficient solution.

The customer will be happy.

7. If you come across code that you think is poorly written, but is not part of your current project, please don’t take it upon yourself to rewrite it.

The project team did not plan to test for that change.

They won’t be happy.

You may be right—that code may be poorly written, but it was tested, and it works.

So, move along, or suggest that a different project get spun up to optimize that code.

8. Don’t make production changes on Friday.

The programmer on-call will not be happy with you on Monday.

 

CONSTRUCTION WORKER:

9. Organize your code with reusable functions, as if they were building blocks.

This doesn’t just help you, but it may save future projects from duplicating the feature if it already exists.

The reusable code can be as simple as calculating the square root of a number, or more complex, like reusing a UI component that displays a list of patient allergies.

10. Write readable code.

Develop software that is pleasing to the eye and the brain.

Indent, use line breaks, give your methods and variables intuitive names.

And don’t be afraid to comment.

The controversy over “to comment or not to comment” will have to wait for another blog post.

And please avoid the double negative logic.

‘Not isSlippery’ is easier to read than ‘Not notSlippery.’

11. Don’t underestimate the power and destruction one semicolon can cause.

Adding, changing, or removing one character to one line of code can change the logic significantly.

Test this change to the same extent you would test any other change.

12. Add user feedback options with caution.

Don’t ask their opinion if you’re not going to consider it.

But if you do decide to ask, don’t take the profanity personally.

 

DETECTIVE:

13. Test your code.

That’s a no-brainer.

But don’t be the only one who tests or reviews your code.

Syntax errors are one thing.

They’re frustrating and inconvenient, but at least it’s clear something is broken.

Logic errors are more sinister and elusive.

They can wreak havoc before anyone even notices there’s a problem.

Your code may be syntactically correct, but still not behave correctly.

14. Your code may not have done what you wanted it to do.

But it did exactly what you told it to do.

Own it.

With one caveat—if another programmer creates a regression error by not taking your code into account with their software change.

15. Understand and use every debugging tool at your disposal.

And create debugging tools and test harnesses if they’re needed, but don’t exist.

Share them with your colleagues.

You’ll be voted most popular programmer.

16. Check the error logs.

(You did include error handlers in your code, right?)

Or create a tool that sends an alert when an error is detected.

 

PSYCHIC:

17. Always consider the downstream effects of your code changes.

Remember the regression error that your colleague created above?

Well, don’t do that.

18. Write code with the future in mind.

Think Y2K.

And if you were born after 1999, trust me, it wasn’t fun to be a software engineer that New Year’s Eve.

But that was years in the making.

Operating system upgrades occur often.

Last minute security patches are applied.

New versions of programing languages get released.

Browsers are retired.

Hardware is replaced.

Any one of these events can create a project that sidetracks your whole department, since the software must adapt to accommodate it.

You’ll spend weeks or months reconciling and testing the code.

And if you do a quality job, then no one will notice anything.

All that work for your app to work exactly the same.

19. Keep documentation evergreen.

Don’t skip this step.

Just like falling behind on current technology trends, playing catch-up with documentation is not fun either.

Plus, outdated documentation creates risk.

20. Think of the developer who will inherit your code someday.

Write code that you want to hang on your refrigerator.

 

These 20 habits lead to happy developers, happy employers, and happy customers.

All you need is a library card, a whiteboard, a hard hat, a magnifying glass, and a crystal ball.

If you were born after 1999, don't worry, there’s probably an app for all of these.

And if there isn't...

Build one!

Ready to start your career in tech?

Join Nucamp, the #1 rated coding bootcamp in the US.

Nucamp offers the top-rated and most affordable coding bootcamps.

Learn web development on your schedule, without breaking the bank.

At Nucamp, we know we can help you upskill or make that career shift successfully.

We’re confident that our online web developer courses are the best the industry has to offer.

To learn more about how Nucamp can help you achieve your career goals, please schedule a call with a Nucamp advisor.