For me, whenever I'm working on a meta-issue (laerning a new language, learning a new software pipeline, learning a new documentation/testing style), I like to

For me, whenever I'm working on a meta-issue (laerning a new language, learning a new software pipeline, learning a new documentation/testing style), I like to pick a simple library in a problem domain I'm familiar with. So, for example, I like doing a simple 2D vector math library--I am pretty familiar with the topic matter so I don't think about it much and can focus on how the language or whatever feels. I also can easily tell if the implementation is borked and can benchmark it as I try different things. A simple entity system with messaging is another example of something that is simple and bounded but lets you try out different parts of the language. A game of breakout is a really good one as well--combines both of the above, and lets you play with graphics and input and whatnot. Then again, picking a problem domain that is deliberately outside what the language's sweet spot is not usually helpful--doing the math library in, say, awk or SQL might not show me anything those languages are good at. Doing Web content scraping in C would get me distracted with implementation details of the language instead of what it's good at.