Characteristics of a Good Developer

Non-technical characteristics are valuable to being a good developer. A lot of developers seem to think that the job is only about technical skills, however not all problems we face are in the code.

Episode Breakdown

09:50 Lack of fear of using existing code.

“Even building a new house is more fun than fixing up an old one”

Developers like to build new things, rather than maintain old ones. Already built and tested code is an asset for a company. Development costs are an expense. If you aren’t willing to work on existing code, you’re cheap to replace with someone who will.

12:05 Willingness to say “I don’t know.”

“One of the goals of interviews is to see how you respond to not knowing something”

Developers like to show that they know things and be the smartest person in the room. When less qualified developers don’t have an answer for something, they often make things up. Green developers often haven’t yet realized that they aren’t supposed to know everything. “I don’t know” when you don’t know is a signal for actually knowing a lot of other things.

16:12 Willingness to rework code, even their own.

Greenfield code is typically more fun than brownfield code. Reworking code is difficult, as it requires attention to testing, understanding the existing code, etc. Reworking one’s own code requires humility, as it requires an admission that the code wasn’t perfect the first time.

18:50 Willingness to try out new concepts.

“If we do this can the entire team do this?”

Being stuck on a certain way of doing things means that not only is the developer’s career limited, but so is the team they are on. Being able to quickly pivot to better ways of doing things (notice I didn’t say different) can allow a developer to make the entire team more efficient.

23:15 Resistance to change for its own sake.

Along with the above, a good developer will not change something that is working, simply to be able to use the newest technology. New, bleeding edge, risky technology may or may not help the team. A good developer will carefully evaluate whether it will help or not before jumping into it. A good developer also recognizes that there is a cost to uncertainty.

25:56 Ability to communicate.

Most development shops have more than one person in them. Usually the developer is not the product owner. Therefore the developer has to be capable of communicating well. This includes written, face to face, and phone communication. This also includes not coming across as cocky and condescending.

29:36 Reasonable social skills and outside interests.

It’s important to point out that developers who do nothing but write code are just dull people. This doesn’t mean that you skimp on your technical skills and say that you are “making it up with personality”, because if you are saying that, you probably aren’t.

What it does mean is that you have a broad enough range of experience to actually be able to relate to people and to be pleasant to interact with when you do so. You shouldn’t have any coworkers that you interact with on a regular basis with whom you have nothing whatsoever in common. Either you are missing something (don’t know), you’re in the wrong place, or (more likely) you are ignoring commonalities that you should be paying attention to.

34:45 Ability to own up to mistakes.

You are going to screw up and take down a server at some point. It happens. If you can’t admit that you caused the problem, not only are incapable of avoiding it in the future, but anyone with sense is incapable of trusting you to avoid it in the future. Usually, people that are really good at making really bad mistakes are not only bad at recognizing them, but also really bad at recognizing that others think these things are mistakes.

40:20 Attention to detail.

Lots of developers are really good at getting work done for the basic use cases of a system, but fall down flat when it comes to edge cases, error conditions, etc. You cannot be good at this without paying attention to small details. Small details being taken care of automatically is a great way to add value to a system. Small details being ignored is a great way to add cost to a system.

42:18 Ability to blend in.

You should be able and willing to write code that matches the standards where you work. You should generally not stand out in a negative or disruptive manner in your work environment. It’s fine to stand out in ways that matter, but do so intentionally.

This also means avoiding touchy subjects that are inappropriate for work anyway. These include religion, politics, and things that are actually one or the other that people think aren’t, such as morality, social justice, etc. Being a source of division offers you no power that being a source of unity and a leader do not, and takes away options.

Human beings are tribal. Ignore this at your peril

IoTease: Project

IoT Coffee Pot

This project measures the weight of the coffee pot to determine when it is low and sends a notification to refill the pot. It uses a regular kitchen scale to publish the data to the internet then when it reaches a certain weight sends the notification that the pot is low and more coffee needs to be made. It also allows for people in the office to see if the pot is empty on the way to work.


  • Digital Kitchen Scale
  • LCD reader circuit
  • Wires, resistors, and capacitors
  • ESP8266

Tricks of the Trade

Signalling behavior as a proxy for unknown variable values especially when considering social signals. When you are in a group there are behaviors that define that group, almost a code talk. Signalling shows that youa re in the group. If you know the code you are in the group.

Editor’s Notes:

Tagged with: , , , , , , , , , , , , , ,

Enjoy the show? Let us know in the comments.