I stopped coding for over 6 months, and I started missing it. That's good, but this clearly shows that there's a sustainability problem. Life can be distracting, but I need to find a way to somehow make coding truly intrinsic part of life, instead of projects and tasks on top of life. It's not easy, but I think it is necessary.
Project-based learning (PBL) works really well. It keeps you laser-focused on a real problem, and tackle it systematically. I once hypothesized that true internalization of skills (in the general sense of the word) comes only from staying in the creative mode for sufficiently long time. PBL puts people in such a creative state, no doubt, but once you're off from projects, then you're helpless.
During this recession, I did read several tutorials and various talks on coding, but such activities are essentially news browsing, no internalization is expected. They did serve as motivators for me to get back coding, though. But I left then because I was exhausted, I felt the need for a break. Coding is hard, it's no leisure activity. And taking breaks is OK. But maybe 1 or 2 months, not 6. Sure, the second half of 2022 was messy, but remember that coding only brought you inner peace, so even if you felt tired, maybe you could just try something lighter, instead of just stopping it altogether?
What are some of the lighter coding activities?
-
Utility scripts, yes, essentially to automate tasks you perform in life. I want to keep trying TCL (my 3rd language), although I also heard something good about scripting in Kotlin (now my 4th language, due to the ubiquity of Android-based mobile hardware). Python (with mypy) and JavaScript (and TypeScript) are still everywhere (and they're actually like my "zeroth" languages), but I felt that I used them just for the ready-to-use freebies from the ecosystem, instead of trying to get creative and take advantage of the dynamic power of the language. There're once in a while truly innovative and impactful projects coming out, like EdgeDB and CodeMirror, but I guess the majority of the use cases are motivated by "to do less work", and to me, that doesn't help with my trying to get better, possibly even does the opposite. OK, I'm way ahead of myself. Making truly novel software design takes a lot of genius and diligence, but here I'm talking only about lightweight mini-projects for those recovery periods. But still valid is the point that when intentionally working with a less popular language like TCL, you are forced to be less lazy, and you get less distracted, and perhaps that can bring more fun.
-
Presenting products, and that's been on my mind for long, but never got into the right head space for it. I always tell myself that I'm bad at it. And that's not the way to think about things that you believe matter. It's not corporate-grade special ops for promo marketing stunts, it can be very simple, basic, and harmless. The thing is, I want to get to do it for the first time, sometime this year.
-
Solving non-project problems, with my past experience, I've developed a strong aversion to artificial problems. But I know there's merit in deliberate practice. I guess the real issue isn't in practice problem-solving per se, but in the difficulty of finding the optimal load and intensity, the quality of the problems, and most importantly, the quality of the mental effort put into each practice - is it done by rote / regurgitation? Or by some dirty trick that is specific to the problem but has little generalizable value? I mean, with a good problem, it's even possible to simulate an artificial problem as a mini-project, as long as you can perceive it as something relatable to problems you find real. The point is, with this approach, you get to be surgical (or medicinal if you will) about issues you identify regarding your coding skills, and just like medicine, you can't doubt the merit in tackling problems "artificially". While doing real projects are very "organic" and natural, like eating and living healthy, we do get sick, and we need professional-grade help.
-
Revisiting previous projects, now that's a big one. No particular clue about how to work on that, but let's get to this in 2023.
One major problem I identified about my way of learning to do things is that I never kept at it continuously, and iteratively, instead, I got into an intense and effective session, from learning the basics to pulling stunts, to eventually producing a result that I deemed sufficiently decent, which was great, but then, I never came back. There are many such one-shot, one-off cases. The icon design, I got away with one piece of work. TCL, I got the GUI app, and never wrote another line of it.
This way I will never get far. There will never be true internalization. There will only be brief moments of excitement, like short-lived romance, but from such sparks one can never discover the magic world of mastery, innovation, and zen.
And it doesn't even have to be about excellence. Even maintaining a basic level of health and organization (including cleaning) necessary to support higher level life functions requires not just sporadic spikes of activities, but a regular habit, a true habit that is driven internally like a bio-rhythm.
You need to grow, and keep at it. That's what life is for. As a human.