The GriGri Principle in Programming
In software development, the use of advanced IDEs with helpful features like auto-completion, type hinting and real-time linting has become commonplace. I use this sort of thing every day. But as useful as these features are, I’ve also noticed that they enable you to find your way around complicated codebases so much more easily than before that they tend to encourage a certain laziness about code simplicity, elegance and readability. I noticed this recently when doing a code review. It was basically impossible to get a clear picture of what the code was doing by looking at the changes in the pull request. To fully appreciate the flow of logic, you needed to load up the source code in your IDE to make use of its code-hinting, documentation and look-up features to trace through it all. I call this kind of dependency on tooling “The GriGri Principle”.
The GriGri is a belay device used by rock climbers to maintain a firm grip on a climbing rope and hold their climbing partner if they fall. Unlike most belay devices, the GriGri has a simple mechanical clutch that automatically engages, and is seen as a safer alternative. Even if the belayer lets go of the rope completely, the GriGri can lock on and hold a fall. Many climbing gyms install them as a somewhat fool-proof option for novice climbers.
I was surprised to hear from a climber I met in Zermatt that his friend had broken his back while being belayed with a GriGri. It turned out that instead of grabbing the trailing end of the rope and holding it in the braking position, his belayer grabbed onto the GriGri itself, squeezing it so hard that it cancelled the clutch action and allowed the rope to slip right through. The moral of the story was that using a GriGri is no substitute for learning proper belay technique, and that over-dependence on its safety features could let bad habits go unchecked, leading to potentially disastrous consequences.
Most technological advancements don’t substitute for basic competency. The GriGri isn’t a good substitute for knowing how to belay properly in the first place. The Boeing 737 Max MCAS system and numerous self-driving car crashes also come to mind. They show what can happen when technology is given priority over human competency.
Advanced IDE features can lead to bad habits, too, if you’re not careful. I often switch between using an advanced IDE and just using vi (a simple bare-bones text editor). I find that when using a simple editor like vi, it encourages me to keep things simple. Without a fancy IDE keeping track of dozens of related parts, I’m forced to organize things in a simple and intuitive way, write readable code, document things generously, choosing clear and descriptive names, and organizing the flow of logic better. It’s a good reminder not to let things get too out of hand — to keep the concepts of a software module encapsulated enough to reason clearly about without a lot of extra tooling.
