diff --git a/notebook/2021-05-20-20-17-36.org b/notebook/2021-05-20-20-17-36.org index 009cb74..95aac7a 100644 --- a/notebook/2021-05-20-20-17-36.org +++ b/notebook/2021-05-20-20-17-36.org @@ -3,22 +3,23 @@ :END: #+title: Professional narcissism #+date: "2021-05-20 20:17:36 +08:00" -#+date_modified: "2021-07-19 17:46:44 +08:00" +#+date_modified: "2022-07-08 14:35:30 +08:00" #+language: en -Per Pinker: +Per Pinker, coined from his book "The sense of style": #+begin_quote The confusion of the activities of your guild, profession, or field with the subject matter designed to deal with. #+end_quote -- coined by Steven Pinker from his book, "The sense of style" -- focuses on an unrelated thing of your study or activity -- some examples - + in film, instead of focusing what movie is about, they boast about the sales or views - + in media, "cover the coverage", a problem leading to echo chambers - + in learning, instead of focusing what and why of a note-taking method, they focus on the possible effects of your productivity -- this could also happen on yourself - + in note-taking, you may focus on the number of notes, neglecting certain aspects such as the purpose and the quality of the notes - + in programming, you may boast how the program is fast instead of making sure the program is usable +To quickly understand what this means, here's some examples: + +- In film, instead of focusing what movie is about, they boast about the sales or views. +- In media, "cover the coverage", a situation where multiple sources just focuses on other sources instead of the situation itself, a problem leading to echo chambers. +- In learning, instead of focusing what and why of a note-taking method, they focus on the possible effects of your productivity as much as possible. + +This could also happen on yourself already. + +- In [[id:0d2264a6-e487-4761-818a-d17d2833120f][Note-taking]], you may focus on the number of notes, neglecting certain aspects such as the purpose and the quality of the notes. +- In [[id:4b33103b-7f64-4b51-8f03-cac06d4001bb][Programming]], you may boast how the program is fast that is less readable instead of making sure the program is maintainable where maintaining that program for long-term use is more important. diff --git a/notebook/2021-05-20-20-25-47.org b/notebook/2021-05-20-20-25-47.org index 961346a..d03eeee 100644 --- a/notebook/2021-05-20-20-25-47.org +++ b/notebook/2021-05-20-20-25-47.org @@ -3,21 +3,30 @@ :END: #+title: Diving head-first with a difficult problem is a good indicator of progress #+date: "2021-05-20 20:25:47 +08:00" -#+date_modified: "2021-07-22 18:06:45 +08:00" +#+date_modified: "2022-07-21 16:40:47 +08:00" #+language: en -- a difficult problem is to [[id:01459b18-3f30-418e-bd8d-42661d5ea223][Start with wishful thinking]] -- when starting to learn, diving into problems are often seen as a bad thing -- it is essentially like trying to learn to swim on an ocean - + it could be effective if we have a lifeguard -- this sink-or-swim mentality can be great if we're to make a difficult problem as our model for progress -- for example, if you're trying to learn 3D modelling by recreating a massive landscape, you can start with it as an initial exercise -- at first try, it will fail but you can retry maybe next month to see how well you improve; - this goes well with consistency as [[id:adefcd38-46a8-4c9c-b609-9d3393b074d0][Consistency over time creates more progress]] -- a difficult problem can give us a clear indication of our progress -- contrast this to learning by starting with the simplest possible example -- in some capacity, we already have been doing this since we have an idea of what we want to do - + a lot of our inspirations tend to be people with advanced levels; - we tend to [[id:7f73f745-8ce0-4a02-b454-1b7c57b1e202][Follow the experts in the field]] -- beware, [[id:48cef2ac-a941-463d-a07f-6be8349456ad][Diving head-first into a difficult problem makes a bad start]] +Solving with a difficult problem often [[id:01459b18-3f30-418e-bd8d-42661d5ea223][Start with wishful thinking]]. +This allows us to think about the steps we need to deeply learn about a particular field. + +This practice also comes with additional benefits especially when we're beginners of a field. + +- We learn things that are going to be explored later down the line as if [[id:2667d942-48b6-4d1e-b92b-15c2dab645ed][Switching between different topics makes new perspective]]. + +- Most of the application comes from the understanding of the subject and creating custom solutions from that pool of knowledge. + What we're really doing is practicing under that situation and creating a drill exercise for ourselves. + We're getting used what it means to fail and how to deal with such difficulties. + This is what it really means to be familiar as we'll learn that [[id:7382c605-b481-4baa-997a-317f6cb1819c][Self-learning is about responsibility]]. + +In other words, practicing this prevents us from quitting at the first sign of difficulties. +We have a fallback excuse that we're beginners and shouldn't expect it learn it smoothly but rather smoothen the process of learning with [[id:adefcd38-46a8-4c9c-b609-9d3393b074d0][Consistency over time creates more progress]]. + +It is more important to know the importance of failure as an indicator of progress. +That successes show where you are and failure show where you lack. +Having a difficult problem where it can present "real" application of that subject can put yourself to the test how to gauge where you stand. + +However, this could go very badly with very real consequence of wasting real efforts. +[[id:48cef2ac-a941-463d-a07f-6be8349456ad][Diving head-first into a difficult problem makes a bad start]] if you don't have an intention to begin with. +It costs you time that you could have spent learning more on fundamentals. +This is best used as a measuring tool, not a real application of skill (regardless of the result). diff --git a/notebook/2021-08-07-14-14-23.org b/notebook/2021-08-07-14-14-23.org index 89e7b53..0c16ab1 100644 --- a/notebook/2021-08-07-14-14-23.org +++ b/notebook/2021-08-07-14-14-23.org @@ -3,16 +3,22 @@ :END: #+title: Restrictions bring out creativity #+date: 2021-08-07 14:14:23 +08:00 -#+date_modified: 2021-09-16 11:17:44 +08:00 +#+date_modified: 2022-06-21 20:05:36 +08:00 #+language: en -- with practically limitless resources at your side, you may get into choosing how to implement such things; - you can get into thinking too much as [[id:03cd9fad-e187-4939-9347-1a034c6efbe2][Overanalyzing slow you down]] if you think about the best solution possible -- the path of least resistance usually brings the least creative solutions -- furthermore, restrictions forces you to create systems that fit with the requirements; - that can also lead to accidental discoveries, finding paths that you haven't thought of before -- examples: - + this is especially evident with older software such as [[https://en.wikipedia.org/wiki/SCORE_(software)][SCORE]] and the [[https://github.com/chrislgarry/Apollo-11][earlier Apollo computer systems]] - + in [[roam:Game development]], this is especially challenged with fantasy computers such as roam:TIC-80 - + no budget movies +With practically limitless resources at your side, you'd think you have no problems into solving your solution. +However, reality sets in and gives you potential problems such as: + +- If you're prone into roam:Perfectionism, you can go into a situation where [[id:03cd9fad-e187-4939-9347-1a034c6efbe2][Overanalyzing slow you down]] finding the "right" solution. +- With great amount, comes the path of least resistance where all is nought and you can't resist finding the easiest way out. + +Restrictions forces you to create solutions that are within the requirements. +These solutions are often created out of pressure where quick solutions are preferred and [[id:5c603e2c-4dae-465e-abb5-12897ad7466d][Tunnel vision]] is less intrusive. +Furthermore, those solutions can lead into accidental discoveries, finding other solutions you haven't thought of before. + +Some examples: + +- Older software such as [[https://en.wikipedia.org/wiki/SCORE_(software)][SCORE]] and the [[https://github.com/chrislgarry/Apollo-11][Apollo-11]] where systems are often limited thus trying to squeeze every single drop of performance out of it. +- In [[roam:Game development]], a similar idea with fantasy computers such as roam:TIC-80. +- No budget movies with staff making the best out of what they are given. diff --git a/notebook/2021-09-16-11-45-21.org b/notebook/2021-09-16-11-45-21.org index 7206fff..f40b508 100644 --- a/notebook/2021-09-16-11-45-21.org +++ b/notebook/2021-09-16-11-45-21.org @@ -3,7 +3,7 @@ :END: #+title: Problems with simpler tools #+date: 2021-09-16 11:45:21 +08:00 -#+date_modified: 2021-09-16 13:11:29 +08:00 +#+date_modified: 2022-06-21 20:23:43 +08:00 #+language: en @@ -11,7 +11,7 @@ While [[id:69ec18ec-ae88-4cb8-bf03-299bc5d8a2a5][Simple tools make better workfl - The scope of simpler tools often results in doing the same task with multiple tools compared to less simpler tools. This is a sign of the process being too small or atomic. - In this case, [[roam:All-in-one tools make good explorations]] to look how other tools does it while adding the necessary parts preventing from being too simple. + In this case, [[id:65ee583a-bacd-480d-8d9b-90ecc1e22090][All-in-one tools make good explorations]] to look how other tools does it while adding the necessary parts preventing from being too simple. - Consequently, with the plethora of simple tools working together, incidental complexity will arise with the quirks of the tools starting to appear. Complexity is inevitable even in simpler tools. diff --git a/notebook/2022-05-22-22-31-28.org b/notebook/2022-05-22-22-31-28.org index 17aa223..075ef4d 100644 --- a/notebook/2022-05-22-22-31-28.org +++ b/notebook/2022-05-22-22-31-28.org @@ -3,7 +3,7 @@ :END: #+title: Time spent on learning a skill should equally spend time for applying said skill #+date: 2022-05-22 22:31:28 +08:00 -#+date_modified: 2022-05-22 22:31:43 +08:00 +#+date_modified: 2022-07-08 14:24:11 +08:00 #+language: en @@ -21,7 +21,7 @@ the fear of embarrassing ourselves to the wider audience if mistakes are shown; the worst case scenario is people will simply ignore it; simply put, no one truly cares; - while it is important to [[id:6f9c552f-055b-4238-874e-8608006ce0ca][Communicate with others to learn]], you should also put up to reduce that tendency of self-critical and let go of that judgement + while it is important to [[id:6f9c552f-055b-4238-874e-8608006ce0ca][Communicate with others to learn]], you should also tone down being self-critical - [[id:0bb464a1-94c4-4130-bc7d-413465aea8e8][Procrastination]] is also one but not of the typical variety; most people would see a thing for future projects and evaluate it as something that they cannot do in the current level until they can reach their desired skill level; there is one more problem to this approach: we cannot simply know; diff --git a/notebook/2022-06-21-20-15-36.org b/notebook/2022-06-21-20-15-36.org new file mode 100644 index 0000000..9f91df2 --- /dev/null +++ b/notebook/2022-06-21-20-15-36.org @@ -0,0 +1,18 @@ +:PROPERTIES: +:ID: 65ee583a-bacd-480d-8d9b-90ecc1e22090 +:END: +#+title: All-in-one tools make good explorations +#+date: 2022-06-21 20:15:36 +08:00 +#+date_modified: 2022-06-21 20:23:36 +08:00 +#+language: en + + +- the user can explore the components and features of a similar tool +- examples: + - Swiss army knife versus a toolbox of individual tools + - kitchen-sink IDEs versus a text editor with a shell + - roam:Zotero versus a simpler BibTex database manager +- oftentimes, all-in-one tools integrate multiple ideas together into one smooth workflow +- however, they also often hides complexity which can backfire if the user encountered an error; +- if the user takes the time to break apart the tool and study its components, they can replace those components piecewise resembling to what they're used to; + this is where [[id:69ec18ec-ae88-4cb8-bf03-299bc5d8a2a5][Simple tools make better workflows]] as they can reduce complexity diff --git a/notebook/2022-07-21-16-11-54.org b/notebook/2022-07-21-16-11-54.org new file mode 100644 index 0000000..8218b04 --- /dev/null +++ b/notebook/2022-07-21-16-11-54.org @@ -0,0 +1,26 @@ +:PROPERTIES: +:ID: 35581970-fd73-4a0e-89cd-cc496910b32e +:END: +#+title: Skills should be applied for the sake its own +#+date: 2022-07-21 16:11:54 +08:00 +#+date_modified: 2022-07-21 16:43:42 +08:00 +#+language: en + + +- this is especially true if you're a beginner +- it is a simple activity with one neat rule: any amount of things spent on learning should be spent on applying +- this means that you should apply your skill as is without the clutches of learning; + in most cases, you would do it for fun; + several examples includes [[id:4b33103b-7f64-4b51-8f03-cac06d4001bb][Programming]] side projects or sketching for [[id:cd7e8120-6953-44a6-9004-111f86ac52dc][Illustration]] +- this idea should be cherised for several reasons + - this lets you into experimenting with things and not be afraid of failure + - applying knowledge is a skill itself + - it allows you to make dive into concepts that you'll be exploring eventually; + [[id:12dc8b07-ed8b-46d8-bff0-a38d9f3cb83b][Diving head-first with a difficult problem is a good indicator of progress]] +- while it is nice to have additional benefits and intentions, applying this should be done on its own without any additional things in mind; +- however, keep in mind this is not about successes or failures; + +Imagine the same situation but with us being more familiar with the technical topics. +Being more technically-inclined bears with the additional expectation that we should apply the skill smoothly. +However, applying the skill is also a skill. +Being knowledgable is not the same as understanding how to apply.