Discussing performance undermined by colleague's work

Question

As in my previous post about colleague wants to take control, I have had many frustrated weeks of fixing things that aren't and weren't there in my work and were introduced by my colleague or team lead. My deadlines have been really pushed to the boundaries, and my work isn't as impressive as it was or should be (as it has been worked on by another colleague), which led my team lead to ask me an embarrassing question about

Why is something not working?

and because we use version control, I can certainly say those changes are coming from another colleague, but when we talk about the issue, he simply says

They are not big issues (He would say same to the team lead as well).

which for someone who is good at his work is a setback and frustration and also for the team lead. My team lead is a non-predictable person, who might set off at anytime and without any reason, asking why? and what not. So I don't want to get on his wrong side.

How can I raise the issue with respect to him and tell him that instead of working on a new task/ticket, I am getting pulled in by issues which weren't there or which I submitted as working but aren't working now? Keep in mind, they both joined the company together a long time back, and I have a year with the company.

Answer 1

You can do a few things:

• With regards to SVN, generate a report using svn blame and present that privately

• With regards to culture, the most respectful way to talk about this publicly is by asking the team lead to institute pair programming, unit testing, or code reviews in order to improve developer productivity by reducing regression defects

• With regards to industry norms, the best way to comparatively improve the situation indirectly compared to other companies is to ask the SVN admin to create a pre-commit hook

References

• Ultimate Architecture Enforcement: Prevent Code Violations at Code-Commit Time

• A Subversion Pre-Commit Hook

• Stillnet Studios » Blog Archive » Require subversion comments – a perl pre-commit hook

• BizSutra: SVN pre-commit hook in VBScript

• Troy Hunt: Creating Subversion pre-commit hooks in .NET

• Making the Most of Commit Hooks with Subversion | Linux Magazine

• A Survey of Plan-Driven Development Methodologies (pdf)

• CMM Key Process Areas (KPAs) (pdf)

• A quality software process for rapid application development (pdf)

• Overcoming Management Resistance to Pair Programming | Motivations | InformIT

• SOFTWARE DEFECT ORIGINS AND REMOVAL METHODS (pdf)

• The Impact of the PSP on Software Quality: Eliminating the Learning Effect Threat through a Controlled Experiment

• MEASURING DEFECT POTENTIALS AND DEFECT REMOVAL EFFICIENCY (pdf)

• Optimizing Software Inspections with Statistical Quality Techniques - ASQ

Answer 2

While the answers in this, as well the linked previous post concentrate on giving you advice on the technical side of your work, it seems to me that you problems don´t root in technical difficulties at all but are mainly of a social matter.

As @TolMera suggests in his answer to that other question you should first think hard if you want to solve this conflict or if you are better off working elsewhere.

If you decide you want to improve you work environment, let´s look at what we have.

1. You want to keep up you good technical work and not be disturbed by the ability nor the attitude of you colleagues.
2. Your colleague wants to secure his position and probably feels quite threatened by you. He also probably feels that something is taken away from him since he works there longer than you and feels some kind of "ownership" of the code. He wants to keep his status.
3. Your team-lead want´s to meet his deadlines and at the same time does not want to go against you colleague as they probably formed some sort of bond (friendship?). Also he does not seem to be willing to get too much concerned with the root-cause of the issues.

Did I get anything wrong?

Now, you can concentrate on making yourself "invincible" by being technically superior and start going to War, but then it is inevitable that someone will loose this. OR, you could try to solve this and make everybody happy. First step is realizing there is three of you and you are all part of the problem.

• In joining a company you can´t automatically expect them to get all their coding-styles up to your standards, even if superior. It´s rather you who has to adopt their standards and improve from there. In fact, expect some things will never improve to where you want them.
• It is not only producing good code that makes you an asset for the company, but also getting along, sharing you knowledge etc.
• Getting from outright destructive team-environments to a pleasant and fruitful work environment requires a lot of skill in social engineering. I would argue this is the single most valuable skill for a professional programmer.

If you can accept that, start concentrating on the positives and try to go from there. You can basically choose between two routes.

A: Be Gentle:

Start complaining less and complimenting more. If you colleague makes a lot of errors, compliment him when he does none instead of complaining when he does. He never documents anything? Thank him when you do find a piece of documentation and state that it was helpful to you. Acknowledge his achievements providing functionality over the years. Stop blaming individuals entirely, if you are hindered by legacy code put it in general terms as "There are just a lot more lines of code which have to be considered and can brake than before. Try to always offer a solution: Weekly pair-programming sessions, refactoring, tests etc. Help you colleague to improve his programming skills. For example ask his opinion on a solution you just thought of. Be open, how would he solve it? What are the advantages and disadvantages of your vs his solutions? Treat him as equal and acknowledge that his solutions also get the job done, even if you think them inferior. Resist the urge to lecture him. See it as part of your job not only to create great programs but also to form a group of "friends and equals" who together create great programs.

B. Escalate:

Just tell them that you have a problem with work in general. You are not happy how thing run currently and you think to have a fruitful relationship some thing need to change. Still, do not blame. It´s not "he has to make fewer errors" - it´s "we need to improve quality of the code" etc. Don´t expect everything to be solved that way, but the should be a clear perspective of improvement. Actively be part of that improvement. Again, concentrate on solutions the strengthen collaboration.

B has the risk of escalating the wrong way and you may find yourself off worse than before (or even out of a job) while A requires a lot of patience and effort from you. Both are only viable if there is a minimal willingness of the other parties to improve. If not ... search for a new job.

Answer 3

If at all possible it might be worth putting together some documentation to highlight the efficiency and quality of your work before and after your colleague started getting ‘over involved’ in your work. This would be an interesting way to highlight the negative impact of his interferences, it’s worth noting that ‘data’ and or ‘statistics’ don’t come with any emotional bias. You could say something like:

"Looking over these results, I think it would be better if I handled X,Y,Z in the same way I used to before [my colleague] became involved, this way we could keep the work being completed efficiently without any inconsistencies in quality and/or time frame to complete."

This gives your manager (boss?) something to go over and consider, this way you’re not making the issue personal, you would come across logical and compliant. Not to mention it would show an active interest in pursuing what’s best for the company.