Within the troubleshooting of Plymouth issue in Raspberry Pi 5 system, I had referenced EL (Experiential Learning). This was developed by Kolb in the 80’s and I’m learning and integrating the system/method.
The following are some top-of-mind thoughts, in no particular order, as I troubleshooted the issue:
-Documenting the blogpost, as I was troubleshooting, kept me on task and more focused
-Was able to do other searches for various commands, and then add to the post, after trying out the command
-Created a sense of cause and effect (versions; updating things; change control)
-Able to have a form of relief when commenting that another poster on an electronic board had the same experience as me, and then I integrated his fix
-Thinking that I would be able to come back to this post in the future, if I needed to repeat the steps
-A somewhat altruistic thought of maybe helping someone else, just as the original poster had made same comment
-Awareness that the actual learning and understanding of the issue is all relative. I’ve now dabbled across several systems within RP 5, but I can’t really say that I fully academically understand what all the systems are that I was specifically changing and fixing. What I was really after was system stability.
-Over time, I’ll troubleshoot other areas, and there maybe a cross-reference back to the troubleshooting focus. The idea of EL is to continually learn and grow.
-I found it effective to write as if I was asking myself questions. That created a return of some logic blended with creativity.
-I know I have a pattern of wanting to fast-track and get to the answer. In this case, I was able to get to the answer, and was OK with it taking a while, as I had to divert and learn some other things (eg how to edit a file in CLI), before I could actually effect the final system changes.