Lingchi (simplified Chinese: 凌迟; traditional Chinese: 凌遲), translated variously as the slow process, the lingering death, or slow slicing, and also known as death by a thousand cuts. (https://en.wikipedia.org/w/index.php?title=Lingchi&oldid=1073688689)
凌迟
I keep encountering “Death by a Thousand Cuts” (DTC) in IT over and over again. What is it? Something which is hard to note and easy to put aside. Something “small”, which surely does not have an impact on your work. It may be a broken headset, which we do not need right now. It may be a Windows update we keep delaying. It may be not doing a tiny Proof Of Concept project before starting something big & important. It may be continuously refusing to learn up the “pair programming done right”. It may even be a coffee machine which is running out of Java beans anytime soon.
It is very easy and very tempting to keep ignoring small things. These almost do not have any impact on us, right?
WRONG.
Unsolved problems, however small, have a tendency to sum up. One day a combination of these will happen at the same time. Your headset is broken - so you cannot efficiently speak with other colleagues. Your Windows update starts while you are investigating a critical Live issue. You are lacking knowledge which you knew you might need, but you kept ignoring the need to read up on the topic and do a POC. Your team cannot really help you, because your knowledge is not shared with the team as you never started doing the pair programming in the right way. Oh, by the way, the coffee machine has just run out of coffee beans, so you will spend a long time solving this issue with NO COFFEE.
Well, that was a small exaggeration. However I keep noticing developers trying just to “wait and hope” that “minor problems” get resolved. Once I could spend 1-2 hours daily to do same manual tasks again and again, as the my “managed PC” has been accumulating more and more issues.
How to resolve the issue?
The practice of finding manual workarounds (aka “silent suffering” / “heroism”) around small issues has to stop. We work as a team. We share our problems. We raise them with parties concerned. We keep tracing the tickets we have raised for broken stuff, making sure it doesn’t get silently dismissed.
We work in teams. Treating “small issues” seriously is a part of our jobs.
Be The Team. Own it.
Top comments (4)
I think that this also comes close to the issue with technical debts of code or any other kind of software implementation. But you cannot solve always every small issue, after it has appeared. Sometimes it just has to wait.
Thank you for this!
Well, it depends on whether the small issue is likely to repeat or not. If there is a high chance of that issue taking 10s of my working day, I only need X more to consume my whole day :(
I agree that some problems are (or seem to be) impossible to resolve. Still, these need to be communicated to the team.
What's the best way to learn pair programming? From someone that's never gotten a collaborative experience out of it.
I would say - find a mentor who has more experience on the subject. Also, this book greatly helps: "Bolboacă, Adrian. Practical Remote Pair Programming: Best practices, tips, and techniques for collaborating productively with distributed development teams (p. 52). Packt Publishing. Kindle Edition.".
Free IT mentors can be found here: recworks.co.uk/home/meet-a-mentor-...