On Thursday I was having a problem worrying that the work I'm doing on protagonist, while potentially useful, is programmatically boring. This feeling was intensified as I listened to and read about other Schoolers studying data structures and algorithms, implementing puzzles and machine learning.
I was feeling the strong urge to drop what I was doing and work on something conceptually cooler, and I wasn't sure what to do. I was having trouble separating feelings of curiosity and desire from feelings of shouldness.
So my solution was to take a reading day. Yes, I got even further "behind", but I needed to refresh my perspective.
Also, I told several people about the feelings I was having, and everyone was really supportive, and told me that this was not unusual. There are common experiences of fear of missing out, of comparing your own work to the collective achievements of others, and of not taking enough breaks. It felt great to get that validation.
- Apprenticeship Patterns Chapter 2. Emptying the Cup.
- Beginning Factor – Shufflers & Combinators, and possibly more on that blog.
- Algebraic data types.
The first pattern described in Emptying the Cup is called Your First Language. Although I am not learning my first language, I am learning a new language with a new paradigm, the stack-based paradigm. A lot of the advice in the pattern applies:
Have a problem to solve. ☑
Seek out opportunities for feedback, for example by taking very small steps using TDD. ☑
Read the specs. — I have been doing this!
Read the standard library as will be described in the Use the Source pattern. This is a great suggestion. I'm lucky that Factor is beautifully documented. Well, that is to say, you can easily find the code in the libraries, and it is indexed and searchable and browsable. It is not at all the case that every library function is explained. Still, reading the source sounds like an excellent way to get a feel for the idioms.
Find mentors, as will be elaborated on in the Find Mentors pattern. The main point of this in this context seems to be that it can be hard to be fluent. This might be particularly true when learning a second language, as it is natural to try to replicate the idioms of the first language, even when they are not appropriate.
This one is tough for me. The language I'm learning is obscure. I participate in the #concatenive irc channel, and that has already been helpful. When I get a little further along, I think I will try soliciting some refactoring help. I asked about asking about that, and was directed enthusiastically to the mailing list.
Even just getting this far in reading, and vocalising my feelings to others helped me a lot. At this point I starting to feel like returning to work, but I decided to wait until the feeling got more intense.
I randomly turned to this by opening a device I hadn't used for a while, and I read the introduction and first chapter. The first tool is called Making Mistakes and the following passages I particularly liked:
"The chief trick to making good mistakes is not to hide them—especially not from yourself. Instead of turning away in denial when you make a mistake, you should become a connoisseur of your own mistakes, turning them over in your mind as if they were works of art, which in a way they are."
"I am amazed at how many really smart people don't understand that you can make big mistakes in public and emerge none the worse for it. I know distinguished researchers who will go to preposterous lengths to avoid having to acknowledge that they were wrong about something. They have never noticed, apparently, that the earth does not swallow people up when they say "Oops, you're right, I guess I made a mistake." Actually people love it when somebody admits making a mistake. All kinds of people love pointing out mistakes. Generous-spirited people appreciate your giving them the opportunity to help, and acknowledging it when they succeed in helping you; mean-spirited people enjoy showing you up. Let them! Either way we all win."
I spent some time, maybe an hour, in a room with 4 or 5 others looking through the Python code of a fellow Schooler and refactoring it together. That was really fun! Watching an experienced person refactor into code that is less redundant or more idiomatic is a great way to learn, and this experience tied in well with the reading I did today. I enjoyed the process immensely and I would like to do a lot more of that!
Factor / protagonist
I finally got really excited about my own project again, and started working on it. I decided that the design had some unnecessary structure in it, and started refactoring it again. I also came up with a possibly better design idea for the unique identifiers of files:
I am thinking of using a content-based hash in every case, including for mutable files. If the content is changed and a new tag added, the system can detect this by noticing overlapping hard links, and rename the old links to match the current content. If the content is changed but no new tags are added, then either it could be left as it is, or there could be a verification process that updates it. This would also serve to integrity-check files. A user could possibly elect to be notified if a file changes. Or have a notify list of files expected to be immutable.