9

TL;DR: Company co-founder wants to do some 'real work' but does more harm than good.

The company is a software house based in UK, has some ~20 employees, makes stable profits, pays well and offers excellent working conditions (friendly atmosphere, benefits, etc.).

They hired me 3 months ago to start a new, ambitious and long-term project. Currently there are total of 3 people involved in the project: one more specialist and one senior manager (co-founder of the company). There are no manager roles - we all do the 'real work' and we are all equal (e.g. decisions are made by voting).

The problem is that co-founder is not a proficient programmer. He might have been once, but probably lost traction over the years of not working as a software dev. He happily discusses things of low importance (e.g. coding style) but when it comes to coding he makes terrible mistakes. I'm tired double-checking every piece of his work.

I cannot complain about him as a person (e.g. he shows no signs of rudeness, jealousy, etc.), he just lacks skills. That's why I usually fix his bugs secretly during merges, but I suspect that this is not a right solution for longer term.

Given that I'm obviously NOT in position to advise him how should I proceed? Should I talk to him? Or better let it go and wait for disaster? If that matters, we are talking about a narrowly specialized area of software development and the guy in question is about 10 years older than me. He is also a CS graduate.

EDIT: answering the questions in comments: we work in a niche, rather difficult technology. Mentioned mistakes are simple bugs, like using uninitialized variables.

  • 1
    things of low importance (e.g. coding style) with multiple developers this is no longer of low importance if you want to understand each other's work :-| I saw projects where you could tell which part of code was written by who. This looked funny (but was pure chaos) - they apparently never talked about it. Nevertheless this is an interessting issue. I would just talk to him but I talk to everybody about anything :-] I'm curious what others will say... – red-shield Sep 20 '18 at 12:14
  • 3
    If you're all equal, why do you so you obviously cannot advise him? It sounds like either you aren't really equal, or you should be in a position to be honest with him. – Erik Sep 20 '18 at 12:43
  • 2
    " ... one senior manager (co-founder of the company). There are no manager roles - we all do the 'real work' and we are all equal" - whatever you might like to tell yourselves, you're not all equal. The sooner you realise that, the better. – AakashM Sep 20 '18 at 12:52
  • An unutilised variable is not always a "bug" it might be bad practice but dependant on the code its not always required – Neuromancer Sep 20 '18 at 20:58
  • Once company I worked in had a CTO that was probably one of the best engineers I've seen in my life but he had terrible habits like not indenting his code and not using meaningful variable names. Not once did I bag out his skill level because I could relate. I've forgotten where I parked many times when I was writing the most complicated code. You'll find the deeper the thinker the more of an airhead they become. Its hard to explain to someone who hasn't experienced this. – solarflare Sep 21 '18 at 1:29
10

Executive Summary

  • Use Code Quality software
  • Introduce Pull requests & Peer Reviews
  • Write Down all the other bugs you find

The Answer

The good thing is, things of low importance can usually be automated, especially the coding style. See how much of that can be handled by your build system. Introducing a code quality monitor (ie Sonarqube or similar) will pay huge dividends down the line especially in a young project like yours.

Demonstrate that the code is broken. By fixing the stuff in secret you

  • deprive him of the opportunity to know he's messed up
  • let him form wrong ideas regarding his own skill
  • let him form incorrect ideas about you as a professional, on your technical ability as well as and your soft skills in communicating problems.

You are not in a position to advise him, but you can point out the problem and steer the discussion where you want it.

For small things like uninitialized variables, a code quality monitor or static analyzer will be extremely helpful. Once in place it's just a matter of agreeing the level of code quality that you want for the project.

For larger issues I would create a unit test or a ticket for every bug I find. Once I have a bunch of these I would point out the growing pile, and ask how we're planning to address them. Now's a good time to introduce Scrum if you're a fan.

Depending on the relationship dynamic you might still do most of the fixes yourself, but he will be aware of the problem, and you'll be able to estimate the time cost if you ever need to.

Finally, to be honest, he sounds like a guy who can take criticism, so I would explore that as well. Introduce pull requests and peer review into your workflow and see how it goes.

How to Go About It

Not everyone thinks they need code quality monitors. If you can't sell it directly you might have to pull some overtime to get it set up, and then point out what a huge help it has been, and propose to adopt it. Again, your mileage will vary according to your boss; in my experience demonstrating is always better than selling (but I'm a terrible salesman).

  • 1
    So much work only to tell a guy that he sucks in programming ;-] Why do people always are scared to talk to someone if they know something is wrong? – red-shield Sep 20 '18 at 12:36
  • @red-shield Because we're developers and our interpersonal skills approximate zero :) This takes care of the soft-skills problem and will help the project in the future. But I agree, sometimes a plan dude, you suck at this, don't you does wonders – rath Sep 20 '18 at 12:38
  • 5
    @red-shield Rath's proposal does way more than just tell a particular person that their code sucks - it instills QA checks and balances that improves the entire software production process. That is a good thing™ and when correctly implemented it eliminates the need to have to tell a person that their code sucks. – Peter M Sep 20 '18 at 13:35

Not the answer you're looking for? Browse other questions tagged or ask your own question.