Yesterday, Joe introduced me to Keypirinha, basically a Windows alternative to macOS' Spotlight. Microsoft have released a similar utility as part of their PowerToys, and I've used it along with Listary, but Keypirinha blew both of those out of the water. Now, I typically wouldn't talk about software like this, but bear with me here.
The nice thing about Keypirinha is it provides an extendable API with which you can write plugins in Python. Keypirinha comes built in with a number of plugins, and you can choose to enable and disable those which you like, and they also officially support certain third-party plugins as seen on their website. Joe pointed out that there wasn't a dictionary package for Keypirinha, so naturally I thought, well, why not make one?
It couldn't possibly take that long, just make a Python class that extends from the Plugin class that's part of Keypirinha's package API, and let it perform certain actions on certain events, querying a dictionary library for whatever is being typed in by the user at any given time, collecting definitions and word classes and then displaying them, allowing them to be copied on click. Simple, right? I installed PyDictionary, which makes API requests to the Princeton dictionary rest API and returns translations, meanings and synonyms in simple Python dictionaries. Perfect for this purpose. I ran pip install pydictionary, quickly wrote a rough mockup plugin based off the events from other plugins, zipped it up and changed the file extension and put it in the packages folder.
Import error.
Keypirinha doesn't have site-packages (pip's install directory) in its PATH. Fine, I'll just put the library in as part of the package and perform a relative import in the package itself. I'm pretty sure this is legally fine - I didn't plan on releasing the package as public as of yet. Well, turns out PyDictionary, like many other Python libraries, has more than a couple imports of its own, making things more complicated. I kept nesting libraries into the package, before eventually realising, upon more than 20 failed attempts to get the imports working, that this was absolutely not the way to go.
I looked through various dictionary APIs before landing on an unofficial one built off of Google's dictionary. Multiple language support, easy to parse JSON responses, it was perfect as far as I was concerned. I rewrote the package such that whenever the user would type anything in the search bar, it would make an API request, parse the response and display them as actionable items. I zipped it up, moved it into Keypirinha's package folder, and tested it out. Didn't work. A hot hour of debugging later, I found that I was fetching the results from the API perfectly, it was all parsed beautifully, but for some reason they just weren't displaying on Keypirinha.
Only at this point, 4 hours into making the plugin, did I actually think to properly read through the documentation provided by Keypirinha.
I'd mixed up a couple of the functions I was overloading from the plugin superclass, failed to add should_terminate checks and didn't read into what types of item categories are required. But in short, the 30 minutes I'd spent reading the documentation expedited my writing of the plugin exponentially - and it's ridiculous that it happened that way. I think everyone who's done any sort of programming has made this mistake, thought they would learn from it and continued to do it.
I personally don't even dislike learning documentation, I just have somewhat of a head-first attitude when it comes to writing programs. If I don't just start, I think, I won't ever start. But there's a distinct difference between jumping into writing a program within a framework with some knowledge of the framework (or similar frameworks) and doing so without any clue what the hell is going on.
During my internship, I had a week-long break between the project they had given us to learn Spring and writing Rest APIs and getting started in the actual software development side of things. At this point, knowing that I would have to transition from Java (in which I'd been writing programs for a year) to Kotlin (similar in certain aspects as it does use the JVM, but has many distinct differences), I decided to hunker down and read Kotlin in Action. And this decision was genuinely a massive reason why the transition was so smooth - just documentation. It can be dry, and a bit of a pain to read at times when poorly written, but a proper understanding of a framework, platform or language can make your life so much smoother that it's worth every second.