How to handle "bad quality code" by a team member

Question

Thing is, we are a start-up.

So far, I have been the only programmer taking care of our desktop app, api, mobile app...etc, but obviously we had to hire another programmer.

He is quite experienced "frontend developer", but when he started working on our project, it seemed to me that quality of his code is fairly poor, I mean, if you saw something like file.name.split(".").pop().toLowerCase()... - and in case . not being included within a string, it throws undefined error... etc.. you know this is bad, and such mistakes could be found on multiple places within the code.

Of course we discussed that, but what would you do if you were me? How to manage such people? Now I have to review every single line of the code he writes, I am not telling this is bad, quite the contrary, I would like to do it more often, but not from the point of view that on every single line lies a bottle-neck :/ .

It happened multiple times, that makes me sad.

Another thing is, this guy got another task, and it seems to me that I need to refactor a lot of lines from the code, sadly, that code is not usable in production.

Or did we just found bad people? Are there actually developers, who take their code seriously and see stuff like that? (I am very strict about code quality, since our product is used by pretty large amount of people and I want our app not to broke on undefined errors, I would rather it broken on "no space left on device" kind of errors :-) ).

Answer 1

David tackled the psychological side pretty well. I'd like to offer a couple of technical solutions.

Test Driven Development: If you have to write the test, before writing the code, then you're going to have better code. It's been proven out thousands of times in the last twenty years.

Pair Programming/ Mob Programming: Another, proven out too many times to count, concept. Two Devs with one keyboard are more effective and productive than one Dev with two keyboards. On this one you can even leverage some of the soft skil concepts by suggesting this along the lines of "No better way to learn than by doing, I'd love to pair with you so I can learn more."

Automation: At a previous company, one of the best things the VP of Development did was to lay down this law "Nothing can be checked in unless it has automation tests created or updated to support it." You need to get out of the business of checking code manually.

Cheers and good luck

Answer 2

Human performance is complex but one thing is certain: we are not very reliable. There is a lot of material out there to study regarding this topic. There are theories around motivation, theories around the performance curve, personalities, behavior, etc. Too much material to post here.

One area I will focus on in my answer is the performance curve. Some theorize it is not normally distributed but rather skewed positively, meaning majority are mediocre performers while few are high performers. Some theorize it resembles a Pareto curve. I personally think this is accurate. This means that, as you build your team, you need to expect that, in most likelihood, you will load your team with mediocre performers. Occasionally, you will find that stellar, hyper performer, but don't expect it and don't build your capability around him/her. In fact, when you find that person, you have secondary risks.

This means your build processes for whatever your product is needs to have quality enablers as part of that process, meaning you do not blindly rely on a human's output. You check it. You build checks into the process to find flaws and to eliminate them. On the proactive side, you train, you measure, you incentivize, you provide feedback, sometimes you replace, and on and on. This is nothing more than quality management, both leading and lagging controls that do nothing more than minimize defects.

Also, remember the concept of regression to the mean. Stellar performance is often followed by poor performance and vice versa. As I said above, we are not that reliable. Sometimes we perform well, other times no, but we hug our mean abilities.

Answer 3

Training. I have noticed that most programmers coming out-of-school or with only 2-3 years of experience are quickAndDirty Cowboy Coders. It is shame, but schools do not focus on good programming. They focus on getting things done and working alone to prove you can do it. Not working together in larger code-bases.

It starts with awareness that stuff like readability, maintainability and extensibility is more important than making it tick. What really works is good open discussions about topics like this.

• Everyone should read the CleanCode book and discuss each chapter in short sessions
• Watch a CleanCode video's together and do a group discussion afterwards. (First episode is free and is great to create awareness, but not how to tackle it, I suggest you watch it with the whole company if you can handle Bob's style ;-)
• Do Pair programming and refactor messy code to good code to learn
• Train TDD with Coding Dojo, these 4-5 sessions focus on readability and testability.

Each iteration our teams spend like 1,5 hours on stuff like this. So we keep growing and learn how to make better software. Sometimes we disagree with stuff we learn, but this way we can decide what works for us and keep our paradigms open.

Answer 4

I like Joel's suggestions @ https://pm.stackexchange.com/a/21735/20765.

I would start by doing a peer code review. You need to build a relationship with him to do so. Try to ask him to code review yours and you to code review his. Do not do this in a silo, start by sitting together. The more time you spent together, the better.

Then you can move on easier to the TDD or Pair Programming. Start from where you are and then move higher.