106

My colleague and I both work for a small startup. We have been both allocated different sections of the product to work on, with different areas of expertise. We both have the same boss (the company owner).

Last week he was tasked with creating some code for me to use. While I was waiting for him to deliver me his part for integration into my code, I generated some stand-in code to use in the meantime so I could continue with my work. I didn't write the code. It was generated using a MATLAB tool, and I just inserted the parameters.

When he sent through his final code, I saw that my MATLAB-generated code was vastly superior. He also used MATLAB to generate his results, but he used a different tool with different parameters.

I was under the impression that he would generate these results 'by hand' instead of using the MATLAB generator. I just used the generator as a quick fix while I waited for him to be done.

I don't really know what to do. I didn't intend to do his work for him, and I didn't really (I wouldn't be able to do this by hand in any case!). I don't want him to feel like I'm stepping on his toes. Yet at the same time there is a vast improvement in results between mine and his (that is quantifiable). I also don't want to use inferior code when I know that a better performing one is available.

I want to clear this up and talk to someone about it, but I don't know how to approach the topic without coming across as a bad team player, or trying to sabotage my colleague's work, or anything like that. How do I talk to him about it? Or do I bring it up with our boss?

Improve this question
12
  • 2
    Do you have the impression that you need to thread carefully around this colleague? What's the team dynamic like? Are you at the same level? Is he senior? – Lilienthal♦ Aug 29 '18 at 8:30
  • 64
    Are you sure your code is better? Quality includes such diverse things as performance, readability, and correctness. There are times when bubblesort is the best sorting algorithm for the task, after all ... – o.m. Aug 29 '18 at 12:11
  • 96
    @Brandin so I spoke to my collegue and he actually mentioned something that I missed, so my idea wasn't as great as I thought! Heh, that's why he was hired for his job and me for mine. – user91714 Aug 29 '18 at 13:38
  • 5
    Why do you need to mention this to anyone? Does your boss think that the great performance is because of your co-worker's code? Or do you "just" want recognition (which is quite reasonable)? – RonJohn Aug 29 '18 at 15:26
  • 5
    @RonJohn neither? I want to understand (1) why my results were better and (2) get a consensus on which to use in the final product. I don't feel like #2 is a call I can or should make on my own. – user91714 Aug 29 '18 at 17:57
251

I recommend bringing this up with your colleague, not your boss. Even though you think your code is superior, it might be you're missing out on some specific details, or there are situations you didn't think about (bigger picture).

When you talk to your colleague explain the situation: you used code as a quick fix and it's giving different results than your colleagues code. Ask him about this difference. You would like to double check with him if you're missing something.

Assuming your colleague is a team player, he will observe the same results as you and he'll either tell you where this difference is coming from and why his code is better, or he'll tell you you are right and you get to use your code. In both situations your goal to get the best solution possible will be reached and you and/or him learned something new.

Improve this answer
3
  • 102
    +1 for that first paragraph. I once thought I wrote some amazing Html only be informed I basically destroyed the accessibility for screen reader. Always get the full picture. – John Pavek Aug 29 '18 at 12:55
  • 11
    Also, this way you both might learn from the experience - neither code is likely to be perfect, combining parts of either will improve things even further. The tool code could have issues in some cases, but could be a good base to start from in the future.. – Chieron Aug 30 '18 at 11:36
  • 8
    In the tech world we call this a "code review" :) You might even find a better third option. – Colin Young Aug 31 '18 at 15:40
56

Or do I bring it up with our boss?

No, I would not recommend that. It is a small issue, really.

How do I talk to him about it?

Just the facts. You did a comparison between your code and his code, and you are choosing the better solution between the two.

Assuming your colleague is understanding and does not make a big fuss out of it, then there is no problem. Unless your colleague is known to have bad temper, do not assume the problem until you have one.

Could you have done better? I'd say yes.

You could have shared your "temporary fix" with your colleague. That way, he knows the goal: his work has to be better than yours.

I didn't intend to do his work for him.

You didn't. You just accidentally discovered a better solution to a problem. That is common, especially in research-related areas. After all, we say Keep It Simple Stupid.

Lessons learned:

  1. You have discovered that in certain scenarios, the "quick & dirty" way (in this case, generating results in Matlab) is a better solution. Spending extra time and effort does not necessarily yield a better result.
  2. You can share temporarily fixes with others when they begin working on a better solution, which gives them a frame of reference about how their work quality.
Improve this answer
7
  • 2
    Regarding #1, I'd go as far as say that it hardly ever does. We're not working in assembly anymore, compilers generally do a much better job at optimizing than any single person can. Code generated with a sophisticated tool will almost always be superior than what you can think of on your own, simply because of the history it has. – kevin Aug 29 '18 at 12:37
  • 21
    @kevin - you've obviously never recorded a macro in any MS Office product. The VBA code that produces, while functional, is horrible in terms of efficiency, execution speed, and good coding habits. Oh, my bad... you said "sophisticated" tool! – FreeMan Aug 29 '18 at 13:43
  • 3
    @FreeMan I read the first few words and was gonna rant at you about my use of the word "sophisticated", but it seems you had me there :) I admit the comment could've been less matter of factly though, take it as a hyperbole if you will. – kevin Aug 29 '18 at 14:25
  • 2
    Or a WYSIWYG HTML generator. – WGroleau Aug 29 '18 at 20:29
  • 2
    Sometimes human optimization can be better though if it is something fundamental in the design rather than the actual steps to get there. I.E. a wildly different algorithm based on things that a computer wouldn't detect and wouldn't be obvious to someone unskilled. – user64742 Aug 30 '18 at 2:41
5

You've done nothing wrong.

I don't agree that you in any way at fault for not communicating about your stub implementation. Making stubs are standard practice.

"I've noticed that your implementation and the one I was using as a temporary measure has similarities. Could we take a half hour and check them both out?"

Assuming your co-worker agrees to that, you can have with you your quantification, but present it informally, not as a hammer. All too often, yours MAY be better, but the alternative may have some better pieces, and the best solution winds up combining the best of two solutions.

Talking it out not only helps approach better solutions, but it simultaneously helps form/define working relationships. If he will speak about it, you're on a good path. If he won't, then you have useful knowledge there too...

If there is no meeting in the middle, check in your code over his. Your burden for proof is no higher than his, and if your solution is superior, it's better for the company. Just before you do that, speak with management about your plan to do so, but that you aren't looking for them to step in, just to back your play. If management disagrees, then adopting the inferior implementation is on them, not you.

Good co-workers, be they implementors or managers, will always recognize and value better work through open communication. Poor ones, well, won't, and there's no changing them. Do your best, every time, and the best people will stick with you.

Improve this answer
4

I might show my colleague the situation and explain to him what you did. I would refrain from asserting beforehand that you think your work is better, because that might make him defensive. I would frame it as a learning experience: "This looks better to me, but I'd like to know why it isn't", and have him defend his code. If he can't, then you can have his blessing for not using his work without bad feelings, and he may have learned some new techniques for the future, and if he can, then you've learned that your initial gut reaction to which code is better might need to be recalibrated some.

Improve this answer
1

 How do I talk to him about it?

-- Hey Jim, I generated an implementation of X which seems to work faster (produce more precise results, etc, whatever you mean by "superior") than yours. Do you want to see it?

Then your colleague can improve their implementation based on your input, or decide to scratch their implementation and go on with yours. Or perhaps they will not want to see your version at all.

Whatever the outcome, I suggest you keep the implementation your colleague decides to go with in the final product. They were tasked to do it and are responsible for it. If a bug is later discovered in the implementation you provided on your own, you will be the only one to blame.

Improve this answer

You must log in to answer this question.