WhatCable
Or: Playing Nicely With Others
A couple of weeks ago, a new project on GitHub was mentioned on the Infrastructure Club Slack: WhatCable, with the word "YES" being followed by a bunch of discussion. It solves a problem that many of us have: knowing what a USB C cable can do.
USB C is the ubiquitous connector, which is great, but the actual cables can support anything from USB 2 speeds (480 megabits per second) up to Thunderbolt 5 (one direction can go up to 120 gigabits per second), and power from just 5 watts up to 240. In other words, one cable will charge the beefiest gaming laptop and copy data to your external SSD in seconds; another will not stop the battery from draining and take hours to back up.
WhatCable lives in the menu bar (or Dock, as a standard app), and tells you what cables and devices are plugged into your computer; how fast they are; and how much charge is passing through them. It's focused, and useful.
I had a quick look at the project, and realised that pressing โ, opened a blank window, rather than the settings pane (which could be accessed from an icon). A quick look at the list of issues showed a few more Mac native expectations were missing, so I thought I'd ask Gemini to look. (Why not Claude? I'm cheap, basically. Gemini isn't as good, but it's free, and the usage limit is generous enough.)
One huge help is that Swift apps have a command line only build process. This was news to me, but it's great - I've never got to grips with XCode (or, to be honest, any other IDE) - so it opens up the world of Swift (and hence macOS, iOS, and so on) development. Being able to kick off tests, and both debug and production builds, from Terminal - or coding agents - is great.
That meant I could, with help, prepare branches for the command key shortcut, and another for various menu and shortcut changes; build and test locally; and then push and create pull requests with some confidence, despite my lack of experience.
I also made changes to read the data for M1 and M2 Macs, since that's what I had. Returning a day later, there was an alternative implementation in another PR; a quick check and Gemini comparison of the code made it clear that the other change worked, and was better architected, so I made sure to close my PR and say the other would be a better candidate.
In the end, my preferences and "Macishness" changes did get merged, although from edited code rather than as simple merges. (In retrospect, I should have asked the coding assistant for reviews, to improve the PRs. Something to remember for next time.)
Nonetheless, I'm happy to have been able to contribute, and I'm grateful to the maintainer, Darryl Morley, for looking at my code and taking the time to accept it.