This is a highly subjective topic.

This are just traits I personally observe in good programmers and that I try to have as well.

In no particular order:

Owning mistakes

Credit

Mistakes happen, but how you react to them is important.

A good programmer owns their mistakes, fixes the problem, and tries to not let that mistake happen again.

I worked with a guy who made a mistake and accidentally sent 20,000 message to real people instead of the sandbox.

We were working late on a project that just had to be done, so there we were at 11pm in a mostly dark office testing code.

He made a small mistake and used the wrong settings file, which contained live credentials instead of the sandbox, and sent about 20,000 test messages before we realized what had happened.

After a brief moment of panic, we called the boss and explained what had happened, talk for a little about potential solutions, and all agreed on a course of action.

You don’t leave a teammate in trouble if you can avoid it, so I stayed in the office and worked on cleaning up the mess with him through most of the night, and by morning we had it done.

Later on when we talked to the manager he told us he’d talked to the legal department and in part because my co-worked had immediately owned the mistake and we’d cleaned up when it happened, everything was ok.

Don’t get me wrong, he wasn’t happy, but he knew that mistakes happen, and that we win as a team and lose as a team.

It’s how you react to the situation that determines what kind of a person you are.

Think it through

When I was a much newer programmer I’d get frustrated sitting with one of the Senior developers are Royall & Company, Kedric Griffin, he just seemed so slow to code!

My instinct was to smash keys, get code in the IDE, try to run it and see what happens. “Let’s gooooo!” I thought. “No need to follow that procedure! The name tells you what it does! Just get with the typing!”, I said in my head.

And then I’d watch as he solved the problem with little to no guessing, with an understanding of how the code works because he analyzed the problem, the error, the current code, the goal.

Today I’m a much slower programmer, and I thank Kedric for showing me that way of doing things!

Be obsessive

Most professional programmers I know are obsessive.

Just make sure to not let it consume you entirely.

When I pick up a problem I want to solve it. It’s absolutely painful to let it go. And even worse is implementing a less than good solution in the name of expediency, though sometimes that’s needed (Deadlines, production systems, bugs, etc.)

Even when I’ve come up with a solution I’ll keep working on it in the back of my head, if I feel that the implemented solution isn’t all that good.

That’s a trait I didn’t learn from anyone, but I’ve seen it in many programmers, the inability to let go of a problem without fixing it.

I worked with a great programmer, his skill absolutely outshined mine, but he had the habit of reinventing the wheel at every turn, and he’d do it regardless of deadline. Most of the time it just meant that if he’d touched a project, you knew it was going to work well, have at least fair documentation, be clearly laid out, be nicely tested, and he’d know about any question you might have.

But it also meant that the bosses had to ride him when it was deadline-time, because you’d hear at standup “I thought of a better way of doing it, so I’m rewriting the whole thing”, even if the deadline was about to be missed.

Learn all the things

All professional programmers I know keep learning things. They deepen their knowledge about their speciality, as well as learn new patterns, find alternative ways to solve problems, look at new tools.

The mediocre ones stagnate and refuse to leave their bubble of knowledge.

You should not just wonder how your language of choice was built, but go look at the source code! Most languages are open sourced and you can look at the core of it anytime you want.

You’d be surprised at how many developers never leave their preferred language or framework, or try to actually learn how they work.

The good ones never stop learning, they read books, try things out, and are always expanding their understanding.

Help others

Good programmers usually try to help others where they can, while mediocre ones don’t. I’m not saying you always have to accept someone’s request for help, but you should be writing articles, helping beginners, creating tools, writing guidelines, and so on, because as a professional you have knowledge many others don’t have but could use.

My mantra is “There’s always a way, it’s just a matter of figuring it out”, but there’s a second phrase I also try to go by, which is “Try to make the world better”. I’m not talking about world peace, I’m talking about doing something which helps others. I love creating things that make other peoples lives easier, that to me is a small way of making the world a better place.

Even beginners can share their knowledge, there are problems you’ve solved that someone else could benefit from, so answer questions, do pair programming, code review someones project, just look at the world and think “How can I make things just a little bit better?”.

Don’t buy the bullshit

There’s a ton of hype in the programming world. It’s mostly bullshit of some variety. Now don’t get me wrong, new tools, frameworks, and languages can be great, but the hype about stuff should be ignored.

I prefer tools and languages that have been around for a while, they’ve been battle-tested, been vetted, been over the hype period and people with clear heads have evaluated them. People much smarter than me.

On the same token, don’t get into the religious wars of “My language/tool/framework is better than yours!” because it’s dumb.

Yes, there are right and wrong problem domains for tools, but as long as you’re within that it doesn’t matter a whole lot what you pick.

I know professional programmers who use everything from Assembler to PHP, Java to Object Pascal, and they do just fine, they’re highly productive, produce good results, and get shit done.

I also know developers who always use the latest frameworks. They’re often frustrated about the speed at which new things come along, how often they have to learn the new shiny way of doing things, and how they never have time to really learn something before the next thing comes along.

Some them are seeing the light, and some of them scoff at me for using “old” tech while they struggle with trying to figure out how to get up and running with the latest toy.

But really, just keep learning, be productive, be helpful, don’t be an asshole, and you’ll do just fine :)

This is just stuff off the top of my head, not scientific in any way.

Best of luck!