17

I'm an electrical engineer working for a small startup. The company has its own software department (which I'm not part of). Writing software is not part of my job description. However, I do write my own unit-level tests. My codebase is separate from that of the software team one and is relatively primitive.

A coworker in software who is a veteran developer wrote a very useful utility which we both use for debugging any issues. Without talking to him about it, I forked it to my repository (with full version control).

I have made significant changes to this code over time. I changed and added some functionality but also changed the code to make it suit my coding style. The majority of the changes I made were purely to allow me to better understand the functionality and extend it.

I would like to share this code with my coworker who wrote the initial version so he can use it, however I'm not sure how I should go about it. I don't intend to merge my code with his, just tell him that my fork exists. I wonder if I should have asked first. He is a veteran in the industry (and about 20 years older than me) and I don't want to come across as disrespectful because I changed his code so significantly without asking.

Should I have asked first?

|improve this question
  • 11
    @stacey Normally if you want your changes to be considered for inclusion, they should be made in a similar style to the existing code. You might consider making a new version which imitates his style which implements your changes/features. – Brandin May 10 '16 at 10:51
  • 2
    Side note; consider introducing a company coding standard to avoid the issue of "his style" entirely. (Bonus points if it's enforced by post-comit hooks or resharper rules). – RJFalconer May 10 '16 at 10:57
  • 2
    Yes at @Brandin. Not only because of religion wars about styles, but it will completely break your coworker version system (suddenly, all of the code will be "blamed" to you even if you did not change the related functionality). Can make things way too difficult to maintain to be worth the effort. – SJuan76 May 10 '16 at 11:05
  • 2
    Why not just shoot him a link to the fork and let him know you've made some changes, and if he wanted to review them to determine if a merge would be appropriate, you would rather the review happen before pushing the fork. Maybe he would rather you not sync the fork, or maybe he would like to review the diff in github. – Raystafarian May 10 '16 at 11:22
  • 5
    As an open source developer, I find it more disrespectful when people do not share forks of my code (even if they're not required to do so), than if the fork contains significant changes. Sharing code is part of how we make progress; don't stop the progress. – marcvangend May 10 '16 at 11:48

10 Answers 10

23

If there is a reason for sharing it, then I see no reason not to. Unless he is a very uptight sort of person he knows code evolves to meet needs and shouldn't be insulted.

|improve this answer
  • 2
    This. By all means, if you found a way to improve my work or fix some of the mistakes I did, Il'be grateful that you tell me. And perhaps some of those mistakes just happen to be there for a good and non-obvious reason. In any way, we all win by confronting our ides. How could anyone in his right mind behave otherwise ? – ereOn May 10 '16 at 12:07
  • 2
    If the majority of changes are changing coding style or other non-functional changes to "help you better understand," there's a significant chance the original author will not want to just merge. It's always good to share ideas though. – GrandOpener May 10 '16 at 12:23
  • 1
    @GrandOpener Sometimes I get deep into code and forget to leave comments or format correctly, so even if it is entirely superfluous changes, it might still be welcome 'housekeeping'. – Zibbobz May 10 '16 at 12:52
  • 2
    Yes, it's possible that would happen. But I wouldn't want to get the OP's hopes up without knowing more about the situation. – GrandOpener May 10 '16 at 12:55
  • In a small team, I'd have expected to have been told. It would have been courteous, and we could have worked together. Being told ages later that lots of improvements/changes have been made to your original work by someone you sit close to every day, without a single mention of it, is a bit of a slap in the face. There are no rights involved here, just common courtesy. IMO – Lightness Races with Monica Dec 30 '16 at 17:57
14

Just nicely ask him in the following way: "I added some features for myself, and I wonder if it makes sense to merge them with your version. I want to avoid keeping my own duplicate version of the code around forever, and I also have doubts about my code at some points; maybe we can discuss how difficult it would be to merge these features".

I am a senior developer, and usually I would decide if it makes sense to do a reintegration of the features, as a merge or as a rewrite. But if somebody shows me working code extending mine with a functionality he needs, I usually listen to him/her (as long as he does not insist on literally copying his code).

|improve this answer
  • 12
    In my career, I've written lots of tools that were intended to be a one shot at something, people got used to them, had feature requests, and after a while, they became messy and a burden as i had to, but didn't want to, support them further. I'd have been delighted had someone told me "I took your code, cleaned it, and added some features", and gladly handed the tool over to them, to allow me to move on to more interesting things. – Guntram Blohm supports Monica May 10 '16 at 10:28
  • There is always the issue of payment/hours to maintain some feature, but if that can be figured out, and personal offenses can be avoided, a constructive solution is usually found. – Sascha May 10 '16 at 10:32
  • I am not reading this as OP is suggesting a merge. – paparazzo May 10 '16 at 13:30
7

If he is a decent person, that veteran will look at it as what it is: An attempt by an amateur (and amateur is meant in the best possible way) to improve his understanding of an interesting and complex subject.

You are not changing his code. You copied his code and modified your own copy. That would be absolutely fine with me, and no reasonable person should have a problem with that. If you are lucky he will look at it, give you a critique, and help you improving your skills.

Modifying his code on the other hand would get someone very, very annoyed. And you wouldn't have to tell them, they would know.

|improve this answer
  • +1 because I like the second paragraph. OP (stacey), your version is simply some code (the other programmer's code) with customizations. And don't say you're not a software dev. You are. You're developing the software. (It might not be your official title, or considered to be the major part of your official position, but you are being a developer.) – TOOGAM May 10 '16 at 10:28
  • I haven't thought about it that way. I was concerned that modifying his code was out of place, but this makes more sense. I would be thrilled if he critiqued it. I'll see if I can find the courage to ask. @TOOGAM, it doesn't always feel like it! I'm definitely trying to get better so that I feel more confident calling myself that. :) – user5621 May 10 '16 at 15:01
6

If he is veteran in the industry as you said, he is probably use some more advance techniques or patterns that you probably find hard to follow.

We usually, tend to think that if we don't understand the code it means is not that good which in reality this complex code may use some advanced techniques to avoid some known problems or to meet some principles (e.g Open/Closed Principle) etc.

I think if you just tell him "Hi, I found your code really useful but I refactored it a bit to simplify and understand it, do you have some spare time to explain me your code?"

You could also ask to see your modifications and comment your code!

Once you have this meeting and discuss your code and his code you will then have a clue if you need to share your implementation or not, I think.

|improve this answer
  • Thanks, that's a good point! There are parts of it I don't understand, perhaps I should note a couple of questions about them and ask him. – user5621 May 10 '16 at 10:17
1

you can stress the fact that you've changed it so you can understand it more easily maybe, if you're worried he's insulted. Although you also say you have extended functionality, so that might be useful for him as well. If it were the other way around, and he added functionality or something, would you want to have an updated version?

It would be quite silly to be insulted at something like that, I think. I wouldn't worry too much about it and just have a chat about it with him

|improve this answer
1

It surely depends a lot on how you frame it. If you approach him with something along the lines of "Hey, I have changed/expanded the tool you wrote for me and it's soooo much better now...", then you might upset him. But from your description it doesn't look like you will do so.

So other ways to approach this in a constructive way would be "I have done a lot of modifications to your code, primarily to help myself understanding how it works, and I would like to share that back to you. Maybe some of the changes are useful for you as well or maybe you can point me to pieces where I could have done things more effectively, elegant or whatever." Unless he's a guy who is very easily upset from someone touching their code – I guess then he wouldn't have made it to senior developer – he will at least not be insulted and I'm rather sure that he will take the opportunity to share some of his knowledge to help you learn and proceed with your skills.

|improve this answer
1

Inform him that it exists, and give him access to look at it. Then it's up to him whether he does anything about it.

There's a small risk he'll be insulted, thinking that you "should" have come to the software team with feature requests rather than do your own skunk-works. But on the whole I'd say there's unlikely to be a problem provided that what you've done isn't considered wrong by your organisation (in which case the problem is you did it, and him finding out is merely when the problem bites you back!)

I'm a developer (probably not quite as veteran as he is), and personally I'd be slightly annoyed if someone forked the company's code to add features that we'd have added ourselves if asked. A fork to do something that would never be prioritized/resourced for us to do is just the way things go. From my point of view it's the same as not using the tool at all: I'd like to know why my thing isn't getting the job done for you, and whether the software department could work better so that you didn't need to do a fork, but I won't be insulted that you did it.

I would also be, not insulted, but greatly annoyed in the case where someone does a skunk-works fork, shares it with a bunch of other people who build their working processes to rely on it, and then leaves the company or otherwise dumps into the lap of the software team code that the team didn't write and never would have agreed to write in the form it's in, but now has to support and maintain because it's become business-critical. The software team writes code in a way that means they're happy to maintain it in future: you've done things differently. It doesn't sound like you have built a tower of critical process on top of your code, but don't try to highlight how useful your version of the code is to other people or you will terrify him.

Be aware that by re-styling it, and also because of the length of time it has been forked, you might have made it very difficult for him to take any changes back. Since it wasn't your goal to contribute code back, this isn't a fault on your part, but it is what it is. If you had set out to contribute to the original then you would have done things differently, and so you should be prepared for him to say, "nice ideas but unfortunately I can't use this" or even "Thanks, but I'm not interested in looking at what you've done". If you don't demand anything from him then you're much less likely to come across as disrespectful.

Don't say stuff like "I changed the style because my style is more readable than yours" (not that I think you were planning to), because that is basically trolling him.

Oh yes, and brace yourself for the fact that once he sees it he might have suggestions or find flaws, so you're going to have to be willing to listen to his opinion of it ;-)

|improve this answer
1

There shouldn't really be any concept of "his code" at all.

If you write code you should not become upset if someone improves it. At most, you could ask for a review as a courtesy or to ensure you are not introducing regressions.

Given you have forked the code rather than modify it, such changes do not affect him at all. Perhaps you can work with him to merge back so everyone benefits (rather than maintaining both copies).

|improve this answer
0

Yes, definitely, share it with him. But share it as information, not as code.

If you have made large-scale changes to this code, you would not expect him to take what you've done and use it directly: he will probably have a deep knowledge of the code he originally wrote, and be more productive when working on that version than he would be on yours.

I don't think that's what you really want, though.

In my experience as a programmer for many years, actually writing the lines of code is not the hard part of programming! Harder is to know what it should do, and how those features should work with the other things that the code already does.

With that in mind, I would suggest that there are two things that your hard work on this code can offer him, when you share with him the code you've written:

  • the actual changes in behaviour you've made, and how they work in practice alongside the rest of the tool. He may well want to take your ideas and reimplement them, but don't be disheartened or insulted by that: you've already done the hard work by working through the improvements and showing what they do and how they are useful.

  • some specific simplifications you've made to the implementation. Even if he doesn't take the whole of your code, perhaps there are key parts that you found confusing that might make it easier for you to work on it in future. When you share the code with him, do bring those specifically to his attention.

At the end of this exercise, expect that some of your features might make it into his version, and some may not. Hopefully for those that he doesn't pick up, he'll be able to explain why.

After that process concludes, I suggest you re-fork from his latest version and, knowing what you have learned about the structure of the tool and the way it's put together, re-create any of your remaining changes that you still want. It'll feel like unnecessary work, but you'll be surprised at how much easier it is, and how much better the result is, the second time around. Being willing to re-do a part of the system to improve its design and implementation is the mark of a good programmer (although be wary of those who want to start again from scratch on a whole system!)

One final remark: in my experience, there's only one thing nicer than somebody who takes something I've made and uses it, and that's somebody who likes it so much that they take the time to learn about and improve it. You have paid him a significant compliment by doing this!

|improve this answer
0

You should definitely share the changes with the veteran programmer - tactfully explaining how and why you've changed the code - if you feel it improves the functionality. Keep in mind that his coding style and practice is likely very different than yours, so write a simple-language explanation of the changes you've made. Share it with him, share the changes with him, and let him decide if it should or should not go in.

As for this...

I have made significant changes to this code over time. I changed and added some functionality but also changed the code to make it suit my coding style. The majority of the changes I made were purely to allow me to better understand the functionality and extend it.

This is pretty typical practice in coding - different coders use different styles when they write software, and re-format code that they see as 'cluttered' along the way. He might change it back as he works on the code, or even before committing it to source, which is also acceptable practice (since he maintains the code).

The worst thing that could happen is he'll reject the changes, and ask you to keep your unit-test coding to yourself. Which, if he does, isn't an unreasonable request. But it's unlikely he'll retaliate just because you've offered to share some of your own work with him - just keep it professional and non-confrontational, and hopefully he'll do the same.

|improve this answer