2

The context

I'm a software developer in my company and I have to write a report about a task I've done this past year. I'm doing this for the sake of maintenance and transparency in the work. In a nutshell, the task was about improving a functionality created by a coworker.

The problem

I have to explain in the report why I did certain things and one of them was an improvement of the code written by my predecessor. The real reason is that the code wasn't perfect and I knew I could improve it so it could be easier to understand and to maintain. The thing is we have different professional background and specialities so I can't and won't reasonably blame it about this.

Therefore my question is : How can I explain him what I did without suggesting that he did a bad work ?

I can't write "the quality of the code was bad", or anything that suggest that I'm better than him, that's not what I think, who I am but I still have to explain my decisions.

6

How to talk about a coworker work in a report

You don't. The report shouldn't be about the coworker. The report should be about the code.

How can I explain him what I did without suggesting that he did a bad work ?

I can't write "the quality of the code was bad", or anything that suggest that I'm better than him, that's not what I think, who I am but I still have to explain my decisions.

All reports like this should be solely about the code, and not about the person (or people) who wrote the code. This is no different than a bug report or code review.

You report what kinds of problems you found in the code, and what you did to fix them, or to make the code better. You might need to mention what would happen if that portion of the code were not fixed.

No need to mention the name of the developer, nor even to use the word "Developer", just talk about the code itself. "The variable userName was uninitialized. The XYX method was missing an explanatory comment. The input method getLoginName didn't use the required Whitelisting library." etc, etc.

You don't need to say "the quality of the code was bad", you just need to indicate where it needed to be fixed. "Bad" is a judgement you aren't being asked to draw.

You aren't saying you are better than anyone. Just refactoring this code doesn't make one person better and another worse - it's just something that needs to be done.

  • 1
    I've never met a programmer who wrote perfect code - not even me! We often have to compromise, and I know there are things out in the wild I'm not crazy about, but was never able to go back and improve. Typically because they were "good enough" and there was no return on investment to have me spend more time on them. As a result, I doubt many programmers would take offence at someone else improving things, as long as (like Joe says) qualitative assessments aren't bandied about. After all, that's why we try and write maintainable code - so it's easier for the next person to modify. – Laconic Droid Aug 15 '15 at 19:10
  • I never thought about it this way. To me, saying that the code needed a refactoring (in a way that there is a return on investment) meant that the code was somehow "bad" and one could take offense about it. – Carvallegro Aug 15 '15 at 21:20
  • I get what you are saying. I'm still young and I'm just starting to understand that working in a team is also about thinking about the greater good (the project), instead of myself. It's great though, very motivating – Carvallegro Aug 16 '15 at 13:21
  • 2
    @Carvallegro As a side note, this is an important distinction to make. You are not your code. If you learn this, code reviews will be a glorious learning oppurtunity, if you dont, it will feel like schoolyard bullying. – Fredrik Aug 17 '15 at 7:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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