It's fair to say that I have an interest in a broad range of topics. It's also fair to say that I don't like to dive down into the detail of any one of them. To find out about something I'm slightly interested in, I'll read the introduction, see some examples and follow a tutorial if it's available. If the tool, language or technology is well documented, I'll usually feel like I know enough about it to have a go at making something. Of course at that point everything falls apart.
I am quite a fast reader. My job involves reading a lot, and over the years I have developed my ability to scan a document when looking for something specific. Usually, because I understand the subject of what I am reading, I don't need to process every detail that is written to have a good idea of what's going on.
When I read something that is less well known to me (e.g. most of the world of software development), I still read with the confidence that I have with other material. But when it comes to actually trying to use that information, I quickly fail.
This experience was highlighted to me at the weekend when I committed to completing a working version of a Svelte app I had been messing around with. Despite reading a lot, watching a lot, following tutorials and so on, when it came to knowing what to do for myself, I struggled a lot.
I had a frustrating time. There were so many aspects I wanted to use and had already played with, but trying to put them together in a way that worked and that did something that I had only the vaguest idea of was a struggle. However, by stripping the project back to its most basic, I was able to focus on one problem at a time. By doing this, not only could I spend more time understanding what was going on, but I benefited from many small (tiny) achievements rather than waiting for one big success.
By the end of the weekend, I had a very simple application that I could run and, more importantly, that I understood. I followed this achievement by implementing some tooling to make my development process a bit easier, looking at good practice for git commits, linting etc.
I'm publishing this as part of 100 Days to Offload. You can join in yourself by visiting https://100daystooffload.com.