Fork me on GitHub

Good Morning!




Good morning


My favourite cookbook at the moment is Fuchsia Dunlop’s “The food of Sichuan”. I make Chinese food around once a week. I use pretty much the full set of measuring spoons for every recipe.


Any tips for dealing with a mildly hostile developer in his late 60s who has never really collaborated on any of his projects before? He gets very defensive about his code, but doesn’t really want to review the fairly innocuous PR I’ve made. Doesn’t attempt to run the code either. We are colleagues and I will probably be taking over responsibility for his projects once he’s retired.


So he wants to be left alone and work for himself, also does not care for your work?


Basically, yeah. These are old C++ projects that are tailored to his specific workflow. He agrees (at least in public) about rewriting them somewhat to make it work on all platforms and eventually wrapping it with Python, but in practice he’s stalling and increasingly hostile.


Which I get, because this has been his baby for 12-13 years.


Ah damn, that would be the next question, how his style and code was. If it was okay-ish, I’d ask myself if it is worth the hassle. If he is not cooperative, I’d maybe start looking for allies. If him not rewriting causes issues in the long term, who will suffer from this issues the most? Who else has an interest in solving this?


We are the only two developers, so me and his (eventual) successor. I wouldn’t want to force his hand by appealing to our boss because it would really make any kind of cooperation impossible.


I wouldn’t apply force either, I was more aiming at “Some other department cannot do a migration project because this code does not run on the new platform”. But if the issue only affects you, and he doesn’t do it simple because he doesn’t want to, it’s a tough situation.


Perhaps team up with him for a bit? Work with him on his code, but passively, just try to understand him and the way he does thing the way he does, then perhaps he'll open up eventually to some small suggestions, then bigger suggestions later. So, rather than go in trying to change what he does and the code he's wrote, go in more on a personal, get-to-know-you, work with him a bit then he may open up more. If that approach doesn't work, then ultimately, an appeal to authority might be the only way to go?

❤️ 1

In the end, the code we write isn't our code (I have a hard time with this too), but our employer's code and if you're trying to make the situation better for your employer, then their demands trump any personal feelings.


I like to think that everybody tries to do their best and nobody shuts something like this down from ill will. Maybe he is afraid that his last years on the workforce will become more restricted than they used to be, maybe he feels like his contributions from the last 12 years with this software were never valued enough. I agree that empathy might be a good start (not implying, that you are not already empathic towards him)


Thanks for all of the suggestions.


I recommend a mix of overt friendliness mixed with subtle hints that he might want to question his attitude, e.g you could approve each one of his PRs with "ok boomer". Seriously: I guess empathy is the way to go. If it doesn't change his behaviour, it will at least make it more bearable to you. Might also want to read about NVC if you hadn't already. I know that it gave me precious guidelines and tools that helped me feel less awkward in dealing with conflictual situations.

❤️ 1
Ben Hammond12:09:06

what is the testability of the system like? One eason to dislike other peoples changes is because you are worred it will break something subtle, and then ruin your life later

Ben Hammond12:09:54

working on a test framework might be a less confrontational way to get things going?


The testability of the system is non-existent. He thinks modern dependency management (i.e. having a “deps.edn” or a “requirements.txt”) is basically rubbish and prefers to copy the various dependency source files into his project instead. He doesn’t write tests at all. And actually his software is frequently buggy precisely because he doesn’t test and he only ever commits code to the master branch. I’ve had to explain to him how git branching works after making my PR.


finding common technical ground like testing is good .... maybe find out what he values most


once you know what he values most, you can steer your changes towards improving those aspects


I'm assuming for example that he wants to produce working software that meets requirements


maybe his ability to quickly make changes is something that he values and can demonstrate cos he knows the code and the domain


Yeah, I think he definitely values that


maybe get him to suggest a few things that he thinks could be done to improve that aspect


if he is contributing ideas / suggestions you're in a good place


This is a psychology thing more than a code thing. We are a generation apart.


only one? 😛