This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-09-27
Channels
- # announcements (2)
- # asami (25)
- # babashka (124)
- # beginners (46)
- # calva (55)
- # cljdoc (70)
- # clojure (68)
- # clojure-australia (2)
- # clojure-dev (63)
- # clojure-europe (38)
- # clojure-nl (1)
- # clojure-spec (1)
- # clojure-uk (8)
- # clojurescript (56)
- # community-development (4)
- # conjure (1)
- # copenhagen-clojurians (1)
- # core-async (1)
- # cursive (3)
- # datahike (5)
- # datomic (183)
- # depstar (2)
- # figwheel-main (10)
- # fulcro (20)
- # honeysql (2)
- # hyperfiddle (1)
- # integrant (68)
- # jobs (6)
- # jobs-discuss (5)
- # juxt (1)
- # malli (13)
- # off-topic (8)
- # pathom (2)
- # rdf (10)
- # reagent (11)
- # remote-jobs (1)
- # rum (1)
- # shadow-cljs (69)
- # spacemacs (1)
- # sql (5)
- # tools-build (51)
- # tools-deps (6)
- # xtdb (24)
Mornings!
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.
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?
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)
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.
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
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
maybe get him to suggest a few things that he thinks could be done to improve that aspect
only one? đ