30 Jul 2019
Responding to questions from Shrysr yesterday as to her history with TMSR and game development, Diana Coman links to her first blogpost interaction with Mircea Popescu, the Eulora logs and a blogpost summarising her first 2 years as CTO for Minigame.
Shrysr asks if it’s better to read article links before continuing; Diana confirms. She explains that this will lead to many rabbit holes – especially at first – but one will eventually reach the light at the end of the tunnel. Moreover, this is the only way to really understand – rather than merely skim over – something. To begin, one can make a list of “must read” items, and gradually work through.
Diana emphasises the simplicity; universality of the written plan-implement-review-amend pattern for getting things done, and notes that Shrysr hasn’t done this properly for next week’s agenda. Shrysr replies that he got distracted by reviewing the way he does things; Diana states that while the tools/methods one uses may differ, the core planning procedure is universal: explicit, written steps that are executed, then reviewed and fed into future plans. Parenthetically, she notes that an undue focus on planning tooling/methodology can be a way to avoid work.
Diana notes that Shrysr is buzzing about too much – perhaps owing to the excitement of all the new stuff – and is at risk of burnout. She points out his need to focus on, and commit to, specified tasks, and that there’s no need to rush: both she and TMSR have been around a while. Shrysr mentions that despite strict time management, he’s tended to yo-yo between productivity and forgetting what he’s learnt. Diana tells him to stick to the work she sets, because he’s unequipped to set his own work (he doesn’t know what he doesn’t know), and it’ll avoid burnout/bouncing around/FOMO. Diana notes that learning requires students’ submission.
Diana notes that strict time-scheduling works only if one is very disciplined, or has a live-in enforcer. It’s enough to be strict about doing the work; no need to micromanage every moment. She notes that if having trouble, he should publish what he’s got, and ask for help; this applies to problems generally.
Shrysr describes his habit of diverging from his plans, believing the disconnected streams will eventually converge. Diana points out the distinction between doing what one wants, versus getting what one needs, adding that some planning flexibility is fine.
Diana enquires as to Shrysr’s v.py study. He states he has a better idea of what it does, but hasn’t examined the code; seemingly distracted by intricacies of the Python language. Diana points out he hasn’t published what he’s learnt so far; that unless made public, no one can help with problems he may be having.
Shrysr is having trouble getting URL selection working in nginx; he’s reluctant to switch to Apache, despite not knowing much about either. Diana points out the superiority of investigating before picking something. Shrysr is convinced to switch to Apache, after Diana states it’s preferred by TMSR members. Diana notes the importance of publishing detailed posts when it comes to remote learning. Shrysr switches to Apache; has trouble getting it to work.
