This commit is contained in:
141
Books/20241231172543-the_science_of_self_discipline.md
Executable file
141
Books/20241231172543-the_science_of_self_discipline.md
Executable file
@@ -0,0 +1,141 @@
|
||||
# Introduction
|
||||
|
||||
Upon completing the book titled "The Science of Self-Discipline" written by Peter Hollins, I wanted to write a
|
||||
little summary of the lessons the book has to offer.
|
||||
|
||||
# Purpose
|
||||
|
||||
The purpose of the book is to provide a framework for those wanting to build and maintain self-discipline in their
|
||||
daily routine, through science-based advice and strategies.
|
||||
|
||||
# Biological Basis of Self-Discipline
|
||||
|
||||
One of the first quotes given in the book is from Jim Rohn, who states that:
|
||||
|
||||
\> “We must all suffer one of two things: the pain of discipline or the pain of regret.”
|
||||
|
||||
The very first chapter talks about the biology behind self-discipline. The reason for discussing this is that
|
||||
without having an understanding of the things that cause, diminish or strengthen self-discipline, it would be
|
||||
difficult to benefit from it. The concept of [neuroplasticity](id:a087da71-bcfb-4ddf-9565-b82113d5d27f) is mentioned in the book, which
|
||||
enables change. Our brain's ability to form and reorganise neural connections alludes to the fact that
|
||||
self-discipline can be developed and improved over time. The example used is that of a road being taken to and from
|
||||
work every single day. The more often this road is taken, the more automatic the journey becomes, up to a point
|
||||
where you will be able to get through it without conscious thought.
|
||||
|
||||
Another important point raised is the concept of **willpower fatigue**. Self-discipline and willpower are not two
|
||||
static quantities that are fixed, they are like gas in a tank, it can be drained or replenished. Essentially this
|
||||
emphasises the point that no matter how great somebody's willpower is, it will eventually deplete. How does one
|
||||
combat this then? One should prioritise important tasks when the willpower is at its highest, larger tasks should be
|
||||
broken down into smaller ones, and self-care should be practiced to replenish willpower.
|
||||
|
||||
# Two Rules:
|
||||
|
||||
## The 40% Rule
|
||||
|
||||
This rule was developed by Navy SEALs, and states that when you feel like you've reached your mental or physical
|
||||
limit, the reality is that you've only reached about 40% of your true capacity. This rule allows you to create a
|
||||
shift in your mindset. Perceived limitations are no longer ones maximum capacity, but rather, this shift pushes you
|
||||
to tap into hidden reserves and maximises your potential.
|
||||
|
||||
## 10-Minute Rule
|
||||
|
||||
If you ever felt like you crave something, and the urge pushes you to it, the 10 minute rules states that you should
|
||||
wait for 10 minutes before getting it. If you want to eat a sugary snack, wait for 10 minutes before getting it.
|
||||
This exercise removes the 'immediate' from immediate gratification, and more-so shows that you **can** withstand your
|
||||
urges.
|
||||
|
||||
# Discipline Drainers
|
||||
|
||||
The author then goes on to mention common discipline drainers, and how to overcome them.
|
||||
|
||||
## False Hope Syndrome
|
||||
|
||||
Instead of setting unrealistic expectations, set smaller achievable goals, and celebrate the wins along the way. If
|
||||
you were to do the former, it can quickly lead to disappointment and a decrease in motivation. The latter approach
|
||||
will give you the sense of accomplishment, build self-confidence and increase momentum, which is more sustainable
|
||||
over time.
|
||||
|
||||
## Procrastination
|
||||
|
||||
To improve self-discipline, procrastination should be avoided, one should stop waiting to **be ready** or for
|
||||
everything to feel **just right**. Inaction goes hand in hand with making excuses, and ultimately sabotages the
|
||||
chances of you getting the thing you want done. The 75% rule was mentioned, where you take action when you are 75%
|
||||
certain of success. Embracing the imperfection allows you to act, and this action enables you to improve
|
||||
self-discipline.
|
||||
|
||||
# Flex your Uncomfortable muscle
|
||||
|
||||
By nature self-discipline is uncomfortable. If you were given the choice to play video games or run a mile, most
|
||||
would choose the former, simply because it is **easier**. Methods such as urge surfing, seeking out
|
||||
challenges and practicing discomfort are mentioned here that would allow you to develop self-discipline.
|
||||
|
||||
# Create a Disciplined Environment
|
||||
|
||||
The next chapter of the book states that having an environment that is conducive to self-discipline is one of the
|
||||
most effective and simplest ways to drastically improve ones life. How does one do this? The author lists and
|
||||
explains ways to create such an environment. From amongst them are:
|
||||
|
||||
- Minimising Distractions: essentially you create a clutter-free working environment, and focus on the 'out of sight,
|
||||
out of mind' principle
|
||||
- Regulate Dopamine: being mindful of the cues that trigger dopamine release, such as junk food, social media etc.
|
||||
and instead creating a reward system that enforces positive behaviour and habits
|
||||
- Optimise default choices: simply put, this is streamlining disciplined behaviour and choosing the path of least
|
||||
resistance
|
||||
|
||||
# Delayed Gratification
|
||||
|
||||
This chapter was titled 'Why You Should Always Eat Your Vegetables First', and, as one can tell, this is talking
|
||||
about the art of delaying gratification. The author goes on to explain how this works, and goes back to the
|
||||
[stanford-marshmallow-experiment](id:acba0d25-08db-4784-8cc2-fe5c437ba723). Two ways one can delay gratification are:
|
||||
|
||||
- Visualising your future self: research goes on to state that there is a strong correlation between visualising
|
||||
your future self and making better long-term decisions. This is simply putting yourself in the shoes of your
|
||||
future self and imagining what you will be doing in the future
|
||||
- The 10-10-10 Rule: a question to pose to oneself, asking 'how will I feel in 10 minutes, 10 hours and 10 days?'.
|
||||
This question forces a perspective shift and can allow you to prioritise long-term benefits over short-term
|
||||
satisfactions
|
||||
|
||||
# Using targeted questions
|
||||
|
||||
\> If you make the effort to ask yourself these four questions and to be
|
||||
honest in your answers, you’ll become more aware of your tendencies to
|
||||
rationalize and make excuses, and you’ll be prepared to create better
|
||||
habits for leading a disciplined life.
|
||||
|
||||
The four questions are as follows:
|
||||
|
||||
1. Do I want to be a disciplined person or not?
|
||||
2. Am I doing the right thing or simply what’s easy?
|
||||
3. These are the vegetables, so what am I getting for dessert?
|
||||
4. Am I being self-aware?
|
||||
|
||||
# Mindset and Approach
|
||||
|
||||
This chapter talks about how our mindset can affect weather we positively or negatively perceive our lives. Some of
|
||||
the ways one can take on a more positive and optimistic outlook on life are:
|
||||
|
||||
- The Endowed Progress Effect: perceiving advancements can make us feel more motivated and optimistic, one can do
|
||||
this by recognising and acknowledging progress in the past towards a goal
|
||||
- Goal Proximity: the idea that the closer we are to a goal, the more motivated we are to reach it.
|
||||
- Think of How Your Actions Can Benefit Others: when one considers how their actions can benefit others, this can
|
||||
quickly turn into a strong source of motivation and drive
|
||||
- Think Optimistically: by thinking optimistically, one can create a positive and optimistic outlook on life. The
|
||||
term used in the book is 'hoping for the best while preparing for the worst'
|
||||
- Think in Terms of Effort: focus on the effort, not the outcome. When one does this, they are able to enjoy the
|
||||
process regardless of the outcome
|
||||
|
||||
# Build Routines and Habits
|
||||
|
||||
Motivation is nice to have, but it is something that fluctuates based on emotion and circumstances. Habits on the
|
||||
other hand, are something concrete and can be built and maintained. Research has shown that it takes 66 days to
|
||||
build a habit, and requires self-discipline to get through that process. But once it is built, this habit will drive
|
||||
you instead. The final thing mentioned in the book is the six sources of influence model by Joseph Grenny. These
|
||||
factors are (1) personal motivation, (2) personal ability, (3) social motivation, (4) social ability, (5) structural
|
||||
motivation, and (6) structural ability.
|
||||
|
||||
# Summary
|
||||
|
||||
This book is a great read, and taught me a lot about self-discipline and the science behind it. I would definitely
|
||||
recommend it to anyone who wants to improve their self-discipline. It is, however, something that should be
|
||||
reflected upon, not all the approaches and strategies are a one-size-fits-all, thus, take it with a grain of salt and
|
||||
adapt it to your own circumstances.
|
||||
305
Books/20250715223949-the_clean_coder.md
Executable file
305
Books/20250715223949-the_clean_coder.md
Executable file
@@ -0,0 +1,305 @@
|
||||
# Links:
|
||||
|
||||
[Medium website](https://medium.com/@stephanie.manwaring/biggest-takeaways-from-each-chapter-of-the-clean-coder-by-robert-c-martin-5e9d1f5ae34)
|
||||
[Coding Journey Man](https://codingjourneyman.com/tag/uncle-bob/page/2/)
|
||||
|
||||
# CHAPTER 1: PROFESIONALISM
|
||||
|
||||
## Do no harm
|
||||
|
||||
No harm should be done to the function of our software. The harm comes about when there are bugs, the QA should find no bugs in the software. If the software is too complex to run without there being bugs, reduce the complexity of the software. Find ways to ensure that the code is designed so that it is easy to test. Aim for 100% test coverage, everything should be tested; automate the testing so you don't waste too much time.
|
||||
|
||||
## Do no harm to the structure
|
||||
|
||||
It is the structure of your code that allows it to be flexible. If you compromise the structure, you compromise the future. If you want the software to be flexible, you have to flex it. This is done by making easy changes to it all the time, which is known as **merciless refactoring**.
|
||||
|
||||
## Work ethic
|
||||
|
||||
Your career is your responsability and nobody else's. The 40 hours at work should be spent on the employers problems, and the extra 20 hours should be spent reading, practicing, learning, and otherwise enhancing your career.
|
||||
|
||||
## Know your field
|
||||
|
||||
Do you know what a Nassi-Schneiderman chart is? If not, why not? Do you know the difference between a Mealy and a Moore state machine? You should. Could you write a quicksort without looking it up? Do you know what the term “Transform Analysis” means? Could you perform a functional decomposition with Data Flow Diagrams? What does the term “Tramp Data” mean? Have you heard the term “Conascence”? What is a Parnas Table? If you want to be a professional, you should know a sizable chunk of ideas, disciplines, techniques, tools, and terminologies and constantly be increasing the size of that chunk.
|
||||
|
||||
Here is a minimal list of the things that every software professional should be conversant with:
|
||||
• Design patterns. You ought to be able to describe all 24 patterns in the GOF book and have a working knowledge of many of the patterns in the POSA books.
|
||||
• Design principles. You should know the SOLID principles and have a good understanding of the component principles.
|
||||
• Methods. You should understand XP, Scrum, Lean, Kanban, Waterfall, Structured Analysis, and Structured Design.
|
||||
• Disciplines. You should practice TDD, Object-Oriented design, Structured Programming, Continuous Integration, and Pair Programming.
|
||||
• Artifacts: You should know how to use: UML, DFDs, Structure Charts, Petri Nets, State Transition Diagrams and Tables, flow charts, and decision tables.
|
||||
|
||||
## Continuous learning
|
||||
|
||||
Read books, articles, blogs, tweets. Go to conferences. Go to user groups. Participate in reading and study groups. Learn things that are outside your comfort zone. If you are a .NET programmer, learn Java. If you are a Java programmer, learn Ruby. If you are a C programmer, learn Lisp. If you want to really bend your brain, learn Prolog and Forth\!
|
||||
|
||||
## Practice
|
||||
|
||||
Doing your daily job is performance, not practice. Practice is when you specifically exercise your skills outside of the performance of your job for the sole purpose of refining and enhancing those skills. More on this later.
|
||||
|
||||
## Collaboration
|
||||
|
||||
Make a speacial effort to practice, program, plan and design together (not for 100% of your time).
|
||||
|
||||
## Mentoring
|
||||
|
||||
The best way to learn is to teach.
|
||||
|
||||
## Know your domain
|
||||
|
||||
It is the responsibility of every software professional to understand the domain of the solutions they are programming. If you are writing an accounting system, you should know the accounting field. If you are writing a travel application, you should know the travel industry. When starting a project in a new domain, read a book or two on the topic. Interview your customer and users about the foundation and basics of the domain. Spend some time with the experts, and try to understand their principles and values.
|
||||
|
||||
## Identify with your Employer/Customer
|
||||
|
||||
Put yourself in your employer’s shoes and make sure that the features you are developing are really going to address your employer’s needs.
|
||||
|
||||
## Humility
|
||||
|
||||
Professionals know they are arrogant and are not falsely humble. A professional knows his job and takes pride in his work. A professional is confident in his abilities, and takes bold and calculated risks based on that confidence. A professional is not timid. However, a professional also knows that there will be times when he will fail, his risk calculations will be wrong, his abilities will fall short. Be your own critique and never ridicule others, accept ridicule when deserved and laugh it off when it's not.
|
||||
|
||||
# CHAPTER 2: SAYING NO
|
||||
|
||||
Professionals are expected to say no. Indeed, good managers crave someone who has the guts to say no. It’s the only way you can really get anything done. (tfb)
|
||||
|
||||
If you are a professional, you will pursue and defend your objectives as aggressively as you can, so will your managers/peers. The best possible outcome is the goal that you and your manager share. The trick is to find that goal, and that usually takes negotiation.
|
||||
|
||||
The most important time to say no is when the stakes are highest. The higher the stakes, the more valuable no becomes.
|
||||
|
||||
Make sure you have documentation (memos) for high stake deliverables/situations (CYA)
|
||||
|
||||
# CHAPTER 3: SAYING YES
|
||||
|
||||
Say. Mean. Do.
|
||||
There are three parts to making a commitment.
|
||||
|
||||
1. You say you’ll do it.
|
||||
2. You mean it.
|
||||
3. You actually do it.
|
||||
|
||||
There are certain phrases used by ourselves and our peers that show a lack of commitment. Here are some common phrases:
|
||||
|
||||
• Need. “We need to get this done.” “I need to lose weight.” “Someone should make that happen.”
|
||||
• Hope. “I hope to get this done by tomorrow.” “I hope we can meet again some day.” “I wish I had time for that.” “I wish this computer was faster.”
|
||||
• Let’s. (not followed by “I . . .”) “Let’s meet sometime.” “Let’s finish this thing.”
|
||||
|
||||
Real commitment will have you stating a fact about something you will do with a clear end time. If you rely on someone else to get your job done, do what you can to get what you need to move forward. Don’t let them be a blocker.
|
||||
|
||||
Professionals are not required to say yes to everything that is asked of them. However, they should work hard to find creative ways to make “yes” possible.
|
||||
|
||||
# CHAPTER 4: CODING
|
||||
|
||||
If you are tired or distracted, do not code. You’ll only wind up redoing what you did. Instead, find a way to eliminate the distractions and settle your mind.
|
||||
|
||||
Don’t write code when you are tired. Dedication and professionalism are more about discipline than hours. Make sure that your sleep, health, and lifestyle are tuned so that you can put in eight good hours per day.
|
||||
|
||||
Spend personal time before work trying to resolve or mitigate personal issues or demands so you can focus your mental energy on being a productive problem solver at work.
|
||||
|
||||
Avoid the \`flow zone\`, rational faculties are diminished in the name of speed. Yes, you may be able to write more code, but you are going to end up giving up the ability to have a holistic view of the problem. You are likely to make decisions that you are going to end up having to go back and reverse.
|
||||
|
||||
Be prepared to be interrupted and help someone — it’s the professional thing to do. When you hit writer’s block make sure you are sleeping, eating, and exercising enough. Additionally, read science fiction (or another form of creative consumption other than surfing the internet or watching TV). Lean on other creative consumption outlets to help keep you creative on the job
|
||||
|
||||
It is incumbent upon you as a professional to reduce your debugging time as close to zero as you can get. Clearly zero is an asymptotic goal, but it is the goal nonetheless.
|
||||
|
||||
Software development is a marathon — not a sprint. Conserve your mental energy during the day.
|
||||
|
||||
“Hope” will get you into trouble (“I hope to have it done by…”). Don’t hope. Be direct about your timelines and realistic expectations. If you must, use an estimate/range.
|
||||
|
||||
Ask for help and ask to give help (mentor).
|
||||
|
||||
Programming is so hard, in fact, that it is beyond the capability of one person to do it well. No matter how skilled you are, you will certainly benefit from another programmer’s thoughts and ideas.
|
||||
|
||||
# CHAPTER 5: TDD
|
||||
|
||||
1. You are not allowed to write any production code until you have first written a failing unit test.
|
||||
2. You are not allowed to write more of a unit test than is sufficient to fail—and not compiling is failing.
|
||||
3. You are not allowed to write more production code that is sufficient to pass the currently failing unit test.
|
||||
|
||||
Good tests function like good documentation.
|
||||
TDD is a discipline that enhances certainty, courage, defect reduction, documentation, and design.
|
||||
It’s professional to use TDD.
|
||||
|
||||
# CHAPTER 6: PRACTICING
|
||||
|
||||
It is not your employer’s job to keep your skills sharp for you. That responsability is on YOU.
|
||||
|
||||
<http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata>
|
||||
|
||||
<https://codingdojo.org/>
|
||||
|
||||
A programming kata is a precise set of choreographed keystrokes and mouse movements that simulates the solving of some programming problem. You aren’t actually solving the problem because you already know the solution. Rather, you are practicing the movements and decisions involved in solving the problem.
|
||||
|
||||
Many kata are recorded at <http://katas.softwarecraftsmanship.org>. Others can be found at <http://codekata.pragprog.com>. Some of my favorites are:
|
||||
|
||||
• The Bowling Game: <http://butunclebob.com/ArticleS.UncleBob.TheBowling-GameKata>
|
||||
• Prime Factors: <http://butunclebob.com/ArticleS.UncleBob.ThePrimeFactors-Kata>
|
||||
• Word Wrap: <http://thecleancoder.blogspot.com/2010/10/craftsman-62-dark-path.html>
|
||||
|
||||
For a real challenge, try learning a kata so well that you can set it to music. Doing this well is hard. See: <https://katas.softwarecraftsmanship.org/?p=71>
|
||||
|
||||
Programmers can practice in a similar fashion (wasa) using a game known as ping-pong. The two partners choose a kata, or a simple problem. One programmer writes a unit test, and then the other must make it pass. Then they reverse roles. See: <https://wiki.c2.com/?PairProgrammingPingPongPattern>
|
||||
|
||||
Other ways to practice: take on pro-bono work or a pet project, contribute to open source. Practice is something you do when you aren’t being paid.
|
||||
|
||||
# CHAPTER 7: ACCEPTANCE TESTING
|
||||
|
||||
## Intro
|
||||
|
||||
A company spends over ****\\$1 million every 6 weeks**** on manual testing.
|
||||
They consider cutting half the tests, risking half the product not working.
|
||||
****Manual test plans are unsustainable****. Automating tests is far cheaper and more reliable.
|
||||
****Acceptance tests**** should be ****automated**** using tools like:
|
||||
|
||||
FitNesse, Cucumber, Selenium, robot framework, cuke4duke, etc.
|
||||
These tools make tests ****readable and writable by non-programmers****.
|
||||
|
||||
Writing acceptance tests is ****not extra work**** — it's ****how you define what "done" means****.
|
||||
It ensures that stakeholders and developers are ****aligned on requirements****.
|
||||
|
||||
## Who Writes Them and When?
|
||||
|
||||
****Business Analysts (BAs)**** often write "happy path" tests.
|
||||
****QAs**** write edge cases and "unhappy paths".
|
||||
Developers may step in if others can't keep up.
|
||||
Tests are best written ****just before development****, typically during iteration planning.
|
||||
|
||||
## Developers are responsible for:
|
||||
|
||||
****Connecting**** acceptance tests to the system.
|
||||
****Implementing features**** to make tests pass.
|
||||
Negotiating unclear or flawed tests with authors.
|
||||
Avoid passive-aggressive compliance; collaborate to refine faulty tests.
|
||||
|
||||
## Realistic Expectations (e.g., Timing)
|
||||
|
||||
Not all requirements can be absolute (e.g., "must respond in 2 seconds").
|
||||
Use ****statistical assertions**** (e.g., 99.5% of requests under 2 seconds).
|
||||
Developers and stakeholders must ****agree on testable, realistic criteria****.
|
||||
|
||||
## Acceptance Tests vs Unit Tests
|
||||
|
||||
| | | |
|
||||
| ------------- | -------------------------------- | ---------------------------------------- |
|
||||
| Feature | Unit Tests | Acceptance Tests |
|
||||
| ————- | ——————————– | —————————————- |
|
||||
| Written by | Developers | Stakeholders / BAs / QA / Developers |
|
||||
| Purpose | Specify and verify internal code | Specify and verify business requirements |
|
||||
| Audience | Developers | Business + Developers |
|
||||
| Scope | Small units (functions, classes) | Full system (API, UI, etc.) |
|
||||
| Primary value | Design documentation | Requirements documentation |
|
||||
|
||||
Tests are ****not redundant**** even if they check similar things — their ****execution paths and intent differ****.
|
||||
|
||||
## Testing GUIs
|
||||
|
||||
GUIs are ****volatile**** (constantly changing), making them hard to test.
|
||||
Apply ****Single Responsibility Principle (SRP)****:
|
||||
|
||||
Separate GUI aesthetics from business logic.
|
||||
****Test through APIs**** beneath the GUI whenever possible.
|
||||
If GUI testing is necessary, use ****IDs or abstractions****, not layout-specific logic.
|
||||
Keep GUI tests ****minimal****, as they’re fragile
|
||||
|
||||
## Continuous Integration (CI)
|
||||
|
||||
Run ****all tests (unit + acceptance)**** multiple times per day via CI.
|
||||
Trigger builds/tests ****on every commit****.
|
||||
A failed build/test is a \*\*"stop everything" event\*\*.
|
||||
Never ignore broken tests; doing so can lead to ****customer-facing bugs****.
|
||||
|
||||
# CHAPTER 8: TESTING STRATEGIES
|
||||
|
||||
Having a full test automation policy is a feature of professional development teams which is not only composed by unit tests and acceptance tests. The test automation pyramid figure (<https://codingjourneyman.com/2014/09/24/the-clean-coder-testing-strategies/>) show every test types and their proportion.
|
||||
|
||||
Unit tests are written by the programmers for the programmers to ensure that the code is working at the deepest/lowest level. They should execute in milliseconds and target a 100% code coverage (at least 90%).
|
||||
|
||||
Component tests are a part of the acceptance tests and check the behavior of individual component. A component encapsulate a specific set of business rules. These kind of tests should be very quick as well because they are decoupled from the other components and should cover about half the system.
|
||||
|
||||
Integration tests are required to check the communication between components in order to verify that the “plumbing” has been done correctly. They ensure that the architectural structure of the system is correct. About 20% of the system is covered by integration tests.
|
||||
|
||||
System tests are executed at the highest level of the system, from the UI to check the whole application and its construction (load tests are in this category for instance). They check about 10% of the system.
|
||||
|
||||
Manual/exploratory tests are done by humans to explore the application for unexpected behaviors. They need the human creativity to hunt possible hidden bugs.
|
||||
|
||||
# CHAPTER 9: TIME MANAGEMENT
|
||||
|
||||
Attending meetings is important in order to follow the life cycle of your project but you are not required in every one of them. In this case you can politely decline the invitation if your presence is not mandatory. It’s no better to be present and play with your smart-phone because you’re bored or because you’re not involved.
|
||||
|
||||
There are also some cases where you can leave a meeting. I know it might look rude to do so but it can happen that a meeting goes not as planned and take much more time that you have anticipated. In a situation like this you can politely ask if your presence is still needed and negotiate your exit. There is nothing worst than a meeting without an agenda and/or without a goal, there is no better way to waste time and energy.
|
||||
|
||||
If you use an Agile methodology such as Scrum at work you certainly have to do stand-up meetings every day (mostly at the beginning of the day). Each member of the team should answer the 3 following questions :
|
||||
|
||||
1. What did I do yesterday ?
|
||||
2. What am I going to do today ?
|
||||
3. What’s in my way ?
|
||||
|
||||
And no more, each person should be able to answer these questions in less than one minute. With this short and simple meeting you can easily know if your project is on track or no.
|
||||
|
||||
During an iteration planning meeting a development team select and reject backlog items for the new sprint/iteration. The estimates (our next chapter) should be done for every candidate item and if possible some of the acceptance tests. The chosen tasks should be clear and ready for the development phase (coding) and this meeting aims to allow the team to briefly discuss over the items.
|
||||
|
||||
Iteration retrospective meeting are designed to share what went wrong and what went right during the last iteration and to present demos to the clients/business. It should not extend 45 minutes, 20 for the retrospective and 25 for the demos which are prepared in advance.
|
||||
|
||||
Uncle Bob defines two truths about meetings, finding the correct mix between them for your team can be challenging :
|
||||
|
||||
- Meetings are necessary.
|
||||
- Meetings are huge time wasters.
|
||||
|
||||
Writing code is an intellectual exercise that requires long periods of concentration and can be exhausting for your mind. But your focus is not infinite and can be depleted, if you are familiar with Role Playing Game (RPG) see this as an empty mana pool. Unfortunately unlike in RPGs you cannot drink a potion to recharge your concentration in a blink but you can refill it.
|
||||
|
||||
Sleeping is the best way to replenish your concentration, a good night of sleep (7\~8 hours) can give you enough concentration for an entire day. Coffee is the developer’s best friend and can definitely help you regain a small amount of concentration for a short amount of time but don’t let this beverage send your focus in the wrong direction.
|
||||
|
||||
It’s also possible to partially recharge your mana batteries by taking breaks during your day, it allows you to de-focus. If the weather permits it you can go out for a walk, have a conversation with a friends, even meditate if you want. You can also practice a physical discipline, it also demands concentration but not intellectual focus : muscle focus. This type of focus can help you increase your mental focus and give you mana. Programming is a creative discipline then exposing yourself to other people’s creativity (books, comics, movies, etc…) is also helpful to boost your own creativity.
|
||||
|
||||
When producing code you will sometimes encounter “blind alleys”. It means that the path you’ve taken leads nowhere, in other word your algorithm does not what you want, your solution does not answer your need. It’s impossible to avoid every “blind alleys” but it’s important to realize when you are in one of them to back out.
|
||||
|
||||
What you definitely want to avoid are software “marshes”, “bogs” or “swamps”. Unlike “blind alleys” they don’t stop you, there is always a way forward that looks shorter than the way back but that is not. Sticking to a bad software design is a typical example of a swamp, the more you advance the harder it is to advance and at the end you end up with a colossal “Technical Debt“ without noticing it. It kills a team’s productivity and can sometimes kills and entire project/company because maintenance has become overwhelming. If you discover that you are in a situation like this you should definitely turn back before it’s too late.
|
||||
|
||||
# CHAPTER 10: ESTIMATION
|
||||
|
||||
You are honor-bound to decline something you cannot commit to. Commitment is about certainty.
|
||||
Professionals know the difference between estimates and commitments.
|
||||
Estimates are just guesses. Estimates are ranges (not exact numbers).
|
||||
Avoid the word “try”. It’s a loaded term.
|
||||
Something to look into is a method like PERT to get a better estimate.
|
||||
Professional software developers are very careful to set reasonable expectations despite the pressure to try to go fast.
|
||||
Estimating methods: wide band delphi, flying fingers, planning poker.
|
||||
|
||||
When you estimate a task, you provide three numbers. This is called trivariate analysis:
|
||||
• O: Optimistic Estimate. This number is wildly optimistic. You could only get the task done this quickly if absolutely everything went right. Indeed, in order for the math to work this number should have much less than a 1% chance of occurrence.
|
||||
• N: Nominal Estimate. This is the estimate with the greatest chance of success. If you were to draw a bar chart, it would be the highest bar,
|
||||
• P: Pessimistic Estimate. Once again this is wildly pessimistic. It should include everything except hurricanes, nuclear war, stray black holes, and other catastrophes. Again, the math only works if this number has much less than a 1% chance of success.
|
||||
|
||||
# CHAPTER 11: PRESSURE
|
||||
|
||||
A professional developer is calm and decisive under pressure. As pressure grows, she adheres to disciplines knowing that they are the best way to meet the deadlines and commitments pressing on her.
|
||||
Under pressure? Be sure to manage your commitments, follow disciplines, and keep code clean, communicate, and ask for help.
|
||||
|
||||
The best way to stay calm under pressure is to avoid the situations that cause
|
||||
pressure. That avoidance may not eliminate the pressure completely, but it
|
||||
can go a long way towards minimizing and shortening the high-pressure
|
||||
periods.
|
||||
|
||||
# CHAPTER 12: COLLABORATION
|
||||
|
||||
Programmers have difficulty working closely with other programmers. That’s no excuse, though. Being a developer means working with people.
|
||||
The team owns the code, not the individual
|
||||
Professionals pair (and have good pairing habits).
|
||||
Pairing is a great way to share knowledge so that people don’t end up in knowledge silos.
|
||||
All team members should be able to play another team members’ position in a pinch and should know each other’s code.
|
||||
|
||||
# CHAPTER 13: TEAMS AND PROJECTS
|
||||
|
||||
Strive to have a “gelled” team. A gelled team is one that forms relationships, collaborates, and learn each other’s quirks and strengths.
|
||||
Gelled teams can work miracles. They plan together, solve together, and get things done.
|
||||
|
||||
# CHAPTER 14: MENTORING, APPRENTICESHIP, AND CRAFTSMANSHIP
|
||||
|
||||
Developers often start out by teaching themselves (books, trial & error, copying code).
|
||||
|
||||
Without mentorship, they risk missing crucial lessons—like setting expectations, meeting deadlines, and writing maintainable code.
|
||||
|
||||
Good mentors matter: they correct mistakes early, model professionalism, and guide juniors through real-world practices.
|
||||
|
||||
Software lacks true apprenticeships (unlike medicine, plumbing, or carpentry). New devs need hands-on oversight, not just “figure it out” work.
|
||||
|
||||
Professionals should seek mentors and become mentors—help others level up, share best practices, and prevent the cycle of isolated learning.
|
||||
|
||||
# APPENDIX A: TOOLING
|
||||
72
Books/20250723182408-so-good-they-cant-ignore-you.md
Executable file
72
Books/20250723182408-so-good-they-cant-ignore-you.md
Executable file
@@ -0,0 +1,72 @@
|
||||
# So good they cant ignore you
|
||||
|
||||
Some of these points have been inspired from this
|
||||
[website](https://jasonkwanhc.medium.com/book-summary-of-so-good-they-cant-ignore-you-58cb236fef0d)
|
||||
|
||||
# Summary
|
||||
|
||||
The book focuses on the reality of how people end up loving what they do. It demystifies the concept: "follow your
|
||||
passion", and details alternative strategies.
|
||||
|
||||
## Rule \*1: ****Don’t Follow Your Passion****
|
||||
|
||||
1. The Passion Hypothesis is the biggest myth in occupational happiness. It says that “The key to occupational happiness
|
||||
is to first figure out what you are passionate about and then find a job that matches this passion”, the author1
|
||||
argues against this.
|
||||
2. He mentions some incidents of people like Steve Jobs, proving that successful people like him (who is famous for the
|
||||
concept "follow your passions") didn’t start off because he had a passion for the thing they do.
|
||||
|
||||
## Rule \*2: Be So Good They Can’t Ignore You (Or, the importance of skills)
|
||||
|
||||
1. The traits that define great work are rare and valuable, if you want these traits, you need rare and valuable skills.
|
||||
These skills are called **[career-capital](id:f9838952-9753-471b-a2cc-d72e01a53ef6)**.
|
||||
|
||||
2. Adopt the ****Craftsman Mindset**** where instead you focus on what you can offer the world. This is in stark contrast to
|
||||
the ****Passion Mindset**** where you focus on what the world can offer you. The craftsman mindset focuses on becoming
|
||||
better and improving the quality of what you produce. It focuses on becoming so good they can’t ignore you,
|
||||
regardless of what you do for a living.
|
||||
|
||||
3. The concept of **[deliberate-practice](id:d4f96bfb-b83d-449b-9f74-f602a1a3c2d3)** is mentioned where you deliberately stretch your
|
||||
abilities beyond where you're comfortable and then receive ruthless feedback on your performance.
|
||||
|
||||
4. 5 Steps on applying the deliberate practice in your work:
|
||||
|
||||
1. ****Step 1: Decide What Type of Capital Market You’re Competing In.**** There are two kinds of markets, a
|
||||
**winner-take-all** market and an **auction** market. In a winner-take-all market, there's only one type of career
|
||||
capital available and only one that matters. In the auction market however, there are a variety of relevant
|
||||
skills that could **lead** you to getting the job, in other words, there are a variety of career capital available.
|
||||
2. ****Step 2: Identify Your Capital Type****. This step makes you figure out what are the relevant skills that are
|
||||
needed in order to be great at your job. In the winner-take-all market, it's pretty straightforward that it's
|
||||
that one career capital, however in the auction market there's more flexibility. A useful heuristic mentioned is
|
||||
the **open-gates** opportunities present. In other words, those opportunities to build capital that are already
|
||||
open to you, then you work your way up.
|
||||
3. ****Step 3: Define “Good”**** . Having a clear view of what **good** means is important. This step forces you to think
|
||||
about where you want to be and how you can achieve it using deliberate practice. This definition will be
|
||||
different for different people.
|
||||
4. ****Step 4: Stretch and Destroy****. Deliberate practice requires you to be uncomfortable, as it is something that is
|
||||
not enjoyable. The important thing is to push beyond your comfort zone and get immediate feedback to steer you in
|
||||
the right direction.
|
||||
5. ****Step 5: Patience****. The acquisition of career capital will take time, therefore, it is necessary to be patient
|
||||
and ensure that you pour all your effort into the capital you seek. The final sentence given in the book before
|
||||
the summary is: ****You stretch yourself, day after day, month after month, before finally looking up and
|
||||
realising, "Hey, I've become pretty good, and people are starting to notice".****
|
||||
|
||||
## Rule \*3: Turn Down a Promotion (Or, the importance of control)
|
||||
|
||||
1. The author here explains that once you've acquired a certain amount of career capital, your next step is to invest
|
||||
|
||||
in those traits that define great work. Discussion was made about control, and the common pitfalls that people fall
|
||||
into.
|
||||
|
||||
1. The law of financial viability: when pursuing a project or career path, it's crucial to seek evidence that people
|
||||
are willing to pay for it. If that evidence exists, it's a good sign to proceed; if not, it's better to reconsider or pivot.
|
||||
|
||||
## Rule \*4: Think Small, Act Big (Or, the importance of Mission)
|
||||
|
||||
1. This rule focuses on the importance of having a mission in your work. Having a unifying focus for your career, a
|
||||
sense of purpose, can make your work more meaningful and impactful.
|
||||
2. A good career mission is similar to a scientific breakthrough, discovered in the adjacent possible of your field.
|
||||
You will need to acquire enough career capital to be able to get into the **cutting edge** of your field. Once you
|
||||
get into this cutting edge, you can then start to see these missions.
|
||||
3. Think small, act big. Instead of focusing on a huge experiment with little feedback, focus on small experiments
|
||||
that yield concrete feedback, and use this to guide you into the direction surrounding your general mission.
|
||||
650
Books/20250727221512-clean_code.md
Executable file
650
Books/20250727221512-clean_code.md
Executable file
@@ -0,0 +1,650 @@
|
||||
# Chapter 1: Clean Code
|
||||
|
||||
Referenced Items:
|
||||
|
||||
- Implementation Patterns, Kent Beck, Addison-Wesley, 2007.
|
||||
- Literate Programming, Donald E. Knuth, Center for the Study of Language and Information, Leland Stanford Junior University, 1992.
|
||||
|
||||
Principles mentioned:
|
||||
Single Responsibility Principle (SRP), the Open Closed Principle (OCP), and the Dependency Inversion Principle (DIP)
|
||||
|
||||
# Chapter 2: Meaningful Names
|
||||
|
||||
## Use intention revealing names:
|
||||
|
||||
Names should reveal intent, there is no revelation in naming an integer `d`, intending it stands for days. Instead, you should use the following names:
|
||||
|
||||
``` java
|
||||
int elapsedTimeInDays;
|
||||
int daysSinceCreation;
|
||||
int daysSinceModification;
|
||||
int fileAgeInDays;
|
||||
```
|
||||
|
||||
## Avoid disinformation
|
||||
|
||||
Don't postfix the word 'list' to the name 'accounts' unless it's actually a list. This is because the reader will *assume* the data type of accountsList is indeed a list, instead choose a name like `accountsGroup`.
|
||||
|
||||
## Make Meaningful Distinctions
|
||||
|
||||
While it is possible to name by being disinformative, it is also possible to name being non informative. Consider:
|
||||
|
||||
``` java
|
||||
|
||||
public static void copyChars(char a1[], char a2[]) {
|
||||
for (int i = 0; i < a1.length; i++) {
|
||||
a2[i] = a1[i];
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
What on earth does `a[1]` and `a[2]` even stand for? We are better off using names like source and destination (due to the function's intent of copying the array).
|
||||
|
||||
Furthermore, noise words are redundant. We should never use the word `variable` when naming a variable, or `table` when naming a table.
|
||||
|
||||
## Use Pronouncable Names
|
||||
|
||||
This is quite straightforward. Do not use a name like `genymdhms` to refer to generation date, year, month, day, hour, minute,
|
||||
and second. Instead use `generationTimeStamp`.
|
||||
|
||||
## Use Searchable Names
|
||||
|
||||
In modern IDE's, it is still quite difficult to search for single-lettered variables. The writer states a personal preference of using single-letter names only as local variables and inside short methods. The following principle is given:
|
||||
|
||||
*The length of a name should correspond to the size of its scope*
|
||||
|
||||
## Avoid Encodings
|
||||
|
||||
Don't prefix variables with letters like m\_ as was done in the past. Do not type encode as well, an example of this is: `PhoneNumber phoneString;` we can see the reader being misled into thinking the phone number is a String.
|
||||
|
||||
## Avoid Mental Mappings
|
||||
|
||||
Clarity is king, don't use a name for a variable that only you know what it stands for. For example: using the letter r as the lower-cased version of the url with the host and scheme
|
||||
removed. That's being smart, not professional.
|
||||
|
||||
## Class Names
|
||||
|
||||
> Classes and objects should have noun or noun phrase names like Customer, WikiPage,
|
||||
> Account, and AddressParser. Avoid words like Manager, Processor, Data, or Info in the name
|
||||
> of a class. A class name should not be a verb.
|
||||
|
||||
{{{epigraph<sub>single</sub>(Classes and objects should have noun or noun phrase names like Customer\\, WikiPage\\,
|
||||
Account\\, and AddressParser. Avoid words like Manager\\, Processor\\, Data\\, or Info in the name
|
||||
of a class. A class name should not be a verb)}}}
|
||||
|
||||
## Method Names
|
||||
|
||||
Methods should have verb or verb phrase names.
|
||||
|
||||
## Don't be cute/Don't use puns
|
||||
|
||||
Do not use names that are only understandable to people whom you share jokes etc with. Furthermore, do not use colloquialism and slang in names.
|
||||
|
||||
- Example: `HandGrenade` instead of `DeleteItems`
|
||||
- Example: `whack()` instead of `kill()`
|
||||
|
||||
## Pick one word per concept
|
||||
|
||||
If you have multiple choices for naming a concept, use one and stick with it. For instance if your options are fetch, get and retrieve, use one and stick with it throughout.
|
||||
|
||||
## Solution Domain Names and Problem Domain Names
|
||||
|
||||
Where possible use solution domain names, as the people that are going to be reading the code are programmers. Therefore, do not shy away from using CS terms, algorithm names, math names and so forth.
|
||||
|
||||
However when it is not possible to use solution domain names (in other words, when there is no "programmer-eese" then use the name from the problem domain. The other programmers can ask the domain expert for clarification. If the code is more to do with the problem domain concepts, then the names should be drawn from them.
|
||||
|
||||
## Add Meaningful Context
|
||||
|
||||
Enclose names with well-named classes, functions, or namespaces. When all else fails, then prefix with something that provides more context.
|
||||
|
||||
## Don't add gratuitous context
|
||||
|
||||
Shorter names are better than longer ones, generally. This is so long as the context and intent is clear. Don't add redundant or irrelevant additions to the name in the for the sake of 'context'.
|
||||
|
||||
# Chapter 3: Functions
|
||||
|
||||
## Functions should be small
|
||||
|
||||
Functions should be extremely short—ideally just a few lines, so they remain easy to understand and maintain.
|
||||
|
||||
Avoid deeply nested blocks; keep indentation shallow (1–2 levels), often replacing blocks with descriptive function calls.
|
||||
|
||||
A small function tells a concise, self-contained story, making it easier for readers to follow the program’s intent.
|
||||
|
||||
The smaller the function, the more descriptive and accurate its name can be, improving self-documentation.
|
||||
|
||||
Large functions hide complexity and mix abstraction levels, making errors and duplication more likely.
|
||||
|
||||
## Do One Thing & One Level of Abstraction
|
||||
|
||||
A function should do exactly one conceptual task, and all its statements should exist at the same abstraction level.
|
||||
|
||||
Mixing details (like string concatenation) with high-level actions (like rendering a page) causes confusion.
|
||||
|
||||
The Stepdown Rule: organise functions so they read like a top down narrative, each calling the next abstraction level.
|
||||
|
||||
If you can extract a subfunction with a name that isn’t a restatement, the original function is doing too much.
|
||||
|
||||
Functions that “do one thing” cannot be logically split into sections such as “initialize,” “process,” “finalize.”
|
||||
|
||||
## Switch Statements
|
||||
|
||||
Switch statements naturally violate “do one thing” by handling multiple cases; they also grow in size over time.
|
||||
|
||||
They break the Single Responsibility Principle (multiple reasons to change) and Open-Closed Principle (must change for new cases).
|
||||
|
||||
Preferred approach: hide switch statements inside a factory and dispatch behavior polymorphically through an interface.
|
||||
|
||||
Allow only one visible switch in your system, used solely for object creation, then encapsulate it.
|
||||
|
||||
This removes duplication and keeps high-level code unaware of concrete type distinctions.
|
||||
|
||||
Example:
|
||||
|
||||
``` java
|
||||
public abstract class Employee {
|
||||
public abstract boolean isPayday();
|
||||
public abstract Money calculatePay();
|
||||
public abstract void deliverPay(Money pay);
|
||||
}
|
||||
-----------------
|
||||
public interface EmployeeFactory {
|
||||
public Employee makeEmployee(EmployeeRecord r) throws InvalidEmployeeType;
|
||||
}
|
||||
-----------------
|
||||
public class EmployeeFactoryImpl implements EmployeeFactory {
|
||||
public Employee makeEmployee(EmployeeRecord r) throws InvalidEmployeeType {
|
||||
switch (r.type) {
|
||||
case COMMISSIONED:
|
||||
return new CommissionedEmployee(r) ;
|
||||
case HOURLY:
|
||||
return new HourlyEmployee(r);
|
||||
case SALARIED:
|
||||
return new SalariedEmploye(r);
|
||||
default:
|
||||
throw new InvalidEmployeeType(r.type);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
## Use Descriptive Names
|
||||
|
||||
A function’s name should clearly state its purpose. Long, descriptive names beat short, cryptic ones.
|
||||
|
||||
Consistent naming patterns (shared verbs/nouns) help code read like a coherent story and aid predictability.
|
||||
|
||||
Descriptive names reduce the need for comments and improve comprehension without external documentation.
|
||||
|
||||
Renaming functions can reveal design improvements, so try multiple options until the best emerges.
|
||||
|
||||
IDE refactoring tools make renaming safe, encouraging experimentation.
|
||||
|
||||
## Function Arguments
|
||||
|
||||
{{{epigraph<sub>single</sub>(The ideal number of arguments for a function is zero (niladic). Next comes one (monadic)\\, followed closely by two (dyadic). Three arguments (triadic) should be avoided where possible. More than three (polyadic) requires very special justification—and then shouldn’t be used anyway.)}}}
|
||||
|
||||
Fewer arguments = better; aim for 0–2, avoid more than 3 unless absolutely necessary.
|
||||
|
||||
Flag arguments (booleans) are a red flag—they imply the function does multiple things.
|
||||
|
||||
Group related parameters into objects (e.g., `Point` for `x` and `y`) to reduce argument count and improve clarity.
|
||||
|
||||
Output arguments are confusing—prefer returning values or mutating the owning object’s state.
|
||||
|
||||
Match function/argument names in verb–noun or keyword style (e.g., `writeField(name)`, `assertExpectedEqualsActual`).
|
||||
|
||||
## Have No Side Effects
|
||||
|
||||
A function should do only what its name promises. Hidden state changes are misleading and dangerous.
|
||||
|
||||
Side effects create temporal coupling, meaning the function must be called in a certain sequence to be safe.
|
||||
|
||||
If unavoidable, make side effects explicit in the name (e.g., `checkPasswordAndInitializeSession`).
|
||||
|
||||
Clear separation of command and query functions avoids ambiguity in meaning and intent.
|
||||
|
||||
Functions that modify state and return information often cause confusion and should be split.
|
||||
|
||||
## Error Handling
|
||||
|
||||
Error handling is a single responsibility—separate it from normal logic to keep both paths clear.
|
||||
|
||||
Prefer exceptions over error codes to avoid cluttering the happy path and to reduce dependency magnets.
|
||||
|
||||
Extract try/catch bodies into their own functions for cleaner structure.
|
||||
|
||||
See below:
|
||||
|
||||
``` java
|
||||
|
||||
public void delete(Page page) {
|
||||
try {
|
||||
deletePageAndAllReferences(page);
|
||||
}
|
||||
catch (Exception e) {
|
||||
logError(e);
|
||||
}
|
||||
}
|
||||
|
||||
private void deletePageAndAllReferences(Page page) throws Exception {
|
||||
deletePage(page);
|
||||
registry.deleteReference(page.name);
|
||||
configKeys.deleteKey(page.name.makeKey());
|
||||
}
|
||||
private void logError(Exception e) {
|
||||
logger.log(e.getMessage());
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
Keep functions small enough that occasional multiple return or break statements are acceptable.
|
||||
|
||||
Avoid duplication in error handling, and follow the DRY principle to ensure changes occur in one place.
|
||||
|
||||
# Chapter 4: Comments
|
||||
|
||||
Comments are a necessary evil—they exist because code fails to express intent clearly.
|
||||
|
||||
Outdated comments are dangerous; they can mislead more than help.
|
||||
|
||||
Strive to write code that explains itself; comments should be minimized.
|
||||
|
||||
Truth is always in the code, not in the comments.
|
||||
|
||||
## Comments Do Not Make Up for Bad Code
|
||||
|
||||
Don’t use comments to excuse messy, unclear code—clean the code instead.
|
||||
|
||||
Clear, expressive code with few comments \> cluttered code with many comments.
|
||||
|
||||
``` java
|
||||
|
||||
// Check to see if the employee is eligible for full benefits
|
||||
if ((employee.flags & HOURLY_FLAG) && (employee.age > 65))
|
||||
|
||||
// Better:
|
||||
if (employee.isEligibleForFullBenefits())
|
||||
|
||||
```
|
||||
|
||||
## Good Comments
|
||||
|
||||
Only write them when unavoidable.
|
||||
|
||||
## Legal Comments
|
||||
|
||||
Sometimes required for copyright/licensing.
|
||||
|
||||
Keep them short; refer to standard licenses rather than embedding full legal text.
|
||||
|
||||
## Informative Comments
|
||||
|
||||
Explain return values, formats, or patterns.
|
||||
|
||||
Prefer naming/structuring code to make such comments unnecessary.
|
||||
|
||||
``` java
|
||||
|
||||
// format matched kk:mm:ss EEE, MMM dd, yyyy
|
||||
Pattern timeMatcher = Pattern.compile("\\d*:\\d*:\\d* \\w*, \\w* \\d*, \\d*");
|
||||
|
||||
```
|
||||
|
||||
## Explanation of Intent
|
||||
|
||||
Describe why a certain approach was chosen.
|
||||
|
||||
Helps future maintainers understand reasoning behind code.
|
||||
|
||||
return 1; // we are greater because we are the right type.
|
||||
|
||||
## Clarification
|
||||
|
||||
Translate obscure values into readable terms.
|
||||
|
||||
Useful when working with unchangeable APIs/libraries, but risky if incorrect.
|
||||
|
||||
## Warning of Consequences
|
||||
|
||||
Alert others about performance, thread-safety, or side effects.
|
||||
|
||||
// SimpleDateFormat is not thread safe, so create each instance independently.
|
||||
|
||||
## \\ Comments
|
||||
|
||||
Mark incomplete work or planned improvements.
|
||||
|
||||
Should be reviewed regularly; not an excuse for bad code.
|
||||
|
||||
## Amplification
|
||||
|
||||
Highlight the importance of seemingly small details.
|
||||
|
||||
// the trim is real important. It removes starting spaces…
|
||||
|
||||
## Javadocs in Public APIs
|
||||
|
||||
Public APIs should have clear documentation.
|
||||
|
||||
Javadocs can also mislead—keep them accurate and up-to-date.
|
||||
|
||||
## Don’t Use a Comment When You Can Use a Function or Variable
|
||||
|
||||
Replace explanatory comments with expressive variable or function names.
|
||||
|
||||
Refactor code to remove comment redundancy.
|
||||
|
||||
## Position Markers
|
||||
|
||||
Avoid decorative banners like // Actions ///////////////////////—they add clutter.
|
||||
|
||||
Use sparingly and only for meaningful grouping.
|
||||
|
||||
Overuse makes them blend into background noise.
|
||||
|
||||
## Closing Brace Comments
|
||||
|
||||
Comments on closing braces (} // while) are unnecessary for small, well-structured functions.
|
||||
|
||||
Prefer short, clear functions over brace markers.
|
||||
|
||||
## Attributions and Bylines
|
||||
|
||||
Don’t add personal tags like /\* Added by Rick \*/—use version control for authorship history.
|
||||
|
||||
Such comments become outdated and irrelevant over time.
|
||||
|
||||
## Commented-Out Code
|
||||
|
||||
Never keep old code commented out; delete it and rely on version control history.
|
||||
|
||||
Commented-out code adds clutter and confuses future maintainers.
|
||||
|
||||
``` java
|
||||
|
||||
// Old cruft that should be deleted:
|
||||
//hdrPos = bytePos;
|
||||
//dataPos = bytePos;
|
||||
|
||||
```
|
||||
|
||||
## HTML Comments
|
||||
|
||||
Avoid HTML markup inside code comments—it makes them harder to read in the editor.
|
||||
|
||||
Let documentation tools (like Javadoc) handle formatting.
|
||||
|
||||
## Nonlocal Information
|
||||
|
||||
Comments should describe nearby code only, not unrelated parts of the system.
|
||||
|
||||
Avoid embedding global/system details that the function can’t control.
|
||||
|
||||
## Too Much Information
|
||||
|
||||
Avoid long, unnecessary historical or technical explanations.
|
||||
|
||||
Keep only relevant context (e.g., “RFC 2045” reference is fine, not the full spec).
|
||||
|
||||
## Inobvious Connection
|
||||
|
||||
Ensure the relationship between comment and code is clear.
|
||||
|
||||
Don’t make readers guess what part of the code the comment refers to.
|
||||
|
||||
``` java
|
||||
|
||||
// plus filter bytes ... but which part is “filter”?
|
||||
this.pngBytes = new byte[((this.width + 1) * this.height * 3) + 200];
|
||||
|
||||
```
|
||||
|
||||
## Function Headers
|
||||
|
||||
Short, single-purpose functions with good names don’t need header comments.
|
||||
|
||||
Let the function name explain the purpose.
|
||||
|
||||
## Javadocs in Nonpublic Code
|
||||
|
||||
Javadocs are useful for public APIs, but excessive formality in internal code is just noise.
|
||||
|
||||
Internal methods should be self-explanatory without full doc comments.
|
||||
|
||||
## Example: Refactored Prime Generator
|
||||
|
||||
Original code: Over-commented, with redundant explanations and irrelevant history.
|
||||
|
||||
Refactored version: Only two comments remain—both explain why, not what.
|
||||
|
||||
One eases the reader into the algorithm.
|
||||
|
||||
One explains rationale for using the square root as a loop limit.
|
||||
|
||||
# Chapter 5: Formatting
|
||||
|
||||
## Vertical Formatting (Clean Code, Ch.5)
|
||||
|
||||
### Vertical Formatting
|
||||
|
||||
- Vertical openness (blank lines) separates concepts and improves readability.
|
||||
- Too much density makes code look like a muddle and harder to scan.
|
||||
|
||||
### Vertical Density
|
||||
|
||||
- Tightly related lines should appear vertically dense.
|
||||
- Avoid useless comments that interrupt association.
|
||||
- Example (bad):
|
||||
|
||||
<!-- end list -->
|
||||
|
||||
``` java
|
||||
public class ReporterConfig {
|
||||
/**
|
||||
* The class name of the reporter listener
|
||||
*/
|
||||
private String m_className;
|
||||
```
|
||||
|
||||
- Example (better):
|
||||
|
||||
<!-- end list -->
|
||||
|
||||
``` java
|
||||
public class ReporterConfig {
|
||||
private String m_className;
|
||||
private List<Property> m_properties = new ArrayList<>();
|
||||
```
|
||||
|
||||
### Vertical Distance
|
||||
|
||||
- Related concepts should be kept close together to reduce scrolling and searching.
|
||||
- Local variables → as close to use as possible, usually at top of function.
|
||||
- Control variables → declared inside loop headers.
|
||||
- Instance variables → declared at the top of class (common Java convention).
|
||||
|
||||
<!-- end list -->
|
||||
|
||||
``` java
|
||||
for (Test each : tests) {
|
||||
count += each.countTestCases();
|
||||
}
|
||||
```
|
||||
|
||||
- Dependent functions: caller above callee for natural top-down reading.
|
||||
|
||||
<!-- end list -->
|
||||
|
||||
``` java
|
||||
public Response makeResponse(...) {
|
||||
String pageName = getPageNameOrDefault(request, "FrontPage");
|
||||
loadPage(pageName, context);
|
||||
return makePageResponse(context);
|
||||
}
|
||||
|
||||
private String getPageNameOrDefault(Request request, String defaultPageName) { ... }
|
||||
```
|
||||
|
||||
### Conceptual Affinity
|
||||
|
||||
- Group functions with similar naming or shared purpose.
|
||||
- Example (JUnit assert methods):
|
||||
|
||||
<!-- end list -->
|
||||
|
||||
``` java
|
||||
static public void assertTrue(String message, boolean condition) { ... }
|
||||
static public void assertTrue(boolean condition) { ... }
|
||||
static public void assertFalse(String message, boolean condition) { ... }
|
||||
static public void assertFalse(boolean condition) { ... }
|
||||
```
|
||||
|
||||
### Vertical Ordering
|
||||
|
||||
- Organise code top down:
|
||||
- High-level concepts first (main logic).
|
||||
- Lower-level details later.
|
||||
- Readers can skim like a newspaper: important first, details last.
|
||||
- Contrast: C/C++ require declarations before use, Java does not.
|
||||
|
||||
### Summary - vertical
|
||||
|
||||
- Use vertical openness to separate concepts.
|
||||
- Use vertical density to group related ones.
|
||||
- Keep related variables, methods, and concepts close together.
|
||||
- Order code top down for natural readability.
|
||||
|
||||
## Horizontal Formatting
|
||||
|
||||
Keep lines short — most professional code naturally stays within \~45 characters, with \~80 as an upper bound. Lines beyond 100–120 characters are generally careless.
|
||||
|
||||
Avoid shrinking font or overly wide monitors to fit more code — readability \> fitting more characters.
|
||||
|
||||
Example limit guideline:
|
||||
|
||||
``` java
|
||||
// Good (short)
|
||||
int sum = a + b + c;
|
||||
|
||||
// Bad (too long)
|
||||
int sum = a + b + c + d + e + f + g + h + i + j + k + l + m + n + o + p + q;
|
||||
```
|
||||
|
||||
## Horizontal Openness and Density
|
||||
|
||||
Use spaces to separate low-precedence operators (e.g., +, -, =) and improve readability.
|
||||
|
||||
Do not put spaces between function names and parentheses — they are closely related.
|
||||
|
||||
Example (Quadratic formula formatting):
|
||||
|
||||
``` java
|
||||
return (-b + Math.sqrt(determinant)) / (2*a);
|
||||
```
|
||||
|
||||
Separate arguments with spaces after commas to show distinct parameters.
|
||||
|
||||
## Horizontal Alignment
|
||||
|
||||
Avoid aligning variable declarations or assignments in columns — it draws the eye to the wrong place.
|
||||
|
||||
Long aligned lists usually mean the class is too large and should be split.
|
||||
|
||||
Example (preferred unaligned):
|
||||
|
||||
``` java
|
||||
// Prefer this:
|
||||
private Socket socket;
|
||||
private InputStream input;
|
||||
private OutputStream output;
|
||||
|
||||
//instead of:
|
||||
private Socket socket;
|
||||
private InputStream input;
|
||||
private OutputStream output;
|
||||
|
||||
```
|
||||
|
||||
## Indentation
|
||||
|
||||
Indent according to scope hierarchy:
|
||||
|
||||
Classes → no indent
|
||||
|
||||
Methods → 1 level
|
||||
|
||||
Method bodies → 2 levels
|
||||
|
||||
Inner blocks → +1 for each nesting
|
||||
|
||||
Indentation makes scopes visually obvious; without it, code is hard to scan.
|
||||
|
||||
Avoid collapsing scopes onto one line — always use braces and proper indenting.
|
||||
|
||||
## Dummy Scopes
|
||||
|
||||
Avoid dummy bodies in loops (e.g., empty while or for loops).
|
||||
|
||||
If unavoidable, place semicolon on its own indented line to make it visible.
|
||||
|
||||
``` java
|
||||
while (dis.read(buf, 0, size) != -1)
|
||||
;
|
||||
```
|
||||
|
||||
## Team Rules
|
||||
|
||||
Teams must agree on a single formatting style for consistency.
|
||||
|
||||
Use IDE formatters to enforce these rules across all files.
|
||||
|
||||
Consistent formatting builds trust and reduces mental load for readers.
|
||||
|
||||
## Uncle Bob’s Formatting Rules (Example in CodeAnalyzer.java)
|
||||
|
||||
Short, clear methods with consistent spacing and indentation.
|
||||
|
||||
Use spaces around assignment and low-precedence operators, no space for high-precedence operators.
|
||||
|
||||
Avoid deeply nested structures — prefer clear, flat logic.
|
||||
|
||||
Example snippet:
|
||||
|
||||
``` java
|
||||
private void measureLine(String line) {
|
||||
lineCount++;
|
||||
int lineSize = line.length();
|
||||
totalChars += lineSize;
|
||||
lineWidthHistogram.addLine(lineSize, lineCount);
|
||||
recordWidestLine(lineSize);
|
||||
}
|
||||
```
|
||||
|
||||
# Chapter 6: Objects and Data Structures
|
||||
|
||||
# Chapter 7: Error Handling
|
||||
|
||||
# Chapter 8: Boundaries
|
||||
|
||||
# Chapter 9: Unit Tests
|
||||
|
||||
# Chapter 10: Classes
|
||||
|
||||
# Chapter 11: Systems
|
||||
|
||||
# Chapter 12: Emergence
|
||||
|
||||
# Chapter 13: Concurrency
|
||||
|
||||
# Chapter 14: Successive Refinement
|
||||
|
||||
# Chapter 15: JUnit Internals
|
||||
|
||||
# Chapter 16: Refactoring SerialDate
|
||||
|
||||
# Chapter 17: Smells and Heuristics
|
||||
|
||||
# Apendix A: Concurrency II
|
||||
340
Books/20260331113318-ikigai_notes.md
Executable file
340
Books/20260331113318-ikigai_notes.md
Executable file
@@ -0,0 +1,340 @@
|
||||
# Ikigai Notes
|
||||
|
||||
## Notes for page 19
|
||||
|
||||
Might be worth reading into the book `The Blue Zones`
|
||||
|
||||
## cellular oxidation.
|
||||
|
||||
Cellular oxidation is the process by which cells produce energy. It involves the breakdown of nutrients, such as glucose, in the presence of oxygen to generate adenosine triphosphate (ATP), which is the primary energy currency of the cell. This process occurs in the mitochondria, often referred to as the "powerhouses" of the cell. Cellular oxidation is essential for maintaining cellular functions and overall metabolism. However, it can also produce reactive oxygen species (ROS) as byproducts, which can cause oxidative stress if not properly managed by the body's antioxidant defenses.
|
||||
In simple terms, cellular oxidation is like a fire burning inside our cells to produce energy, but it can also create smoke (ROS) that can be harmful if not controlled.
|
||||
|
||||
## antioxidant-rich
|
||||
|
||||
Antioxidant rich foods are those that contain high levels of antioxidants, which are compounds that help protect the body from oxidative stress caused by free radicals. Free radicals are unstable molecules that can damage cells and contribute to aging and various diseases. Antioxidants neutralize free radicals by donating an electron, thus preventing them from causing harm. Examples of antioxidant-rich foods include fruits (such as berries, oranges, and grapes), vegetables (like spinach, kale, and broccoli), nuts, seeds, and certain beverages like green tea. Consuming a diet rich in antioxidants can help support overall health and reduce the risk of chronic diseases.
|
||||
|
||||
## Aging’s escape velocity
|
||||
|
||||
Interesting concept, but I don't think it's a real thing. It's more of a metaphor for the idea that if we can slow down the aging process enough, we might be able to extend our lifespan indefinitely (which will never happen, everyone is going to taste death at some point). However, there are many factors that contribute to aging, and it's unlikely that we will be able to completely stop it. That being said, there are things we can do to slow down the aging process and improve our healthspan, such as eating a healthy diet, exercising regularly, and managing stress.
|
||||
|
||||
## “mens sana in corpore sano”
|
||||
|
||||
Need to add this to the proverb list. It translates to: "a healthy mind in a healthy body." This Latin phrase emphasises the importance of maintaining both mental and physical health for overall well-being.
|
||||
|
||||
## Book mention
|
||||
|
||||
Maximum Brainpower: Challenging the Brain for Health and Wisdom
|
||||
|
||||
## Notes for page 30
|
||||
|
||||
> The American Institute of Stress
|
||||
> investigated this degenerative process and concluded that most health problems
|
||||
> are caused by stress.
|
||||
|
||||
|
||||
|
||||
## Notes for page 34
|
||||
|
||||
> Dr.Howard S. Friedman, a psychology professor at the University of California,
|
||||
> Riverside, discovered that people who maintained a low level of stress, who
|
||||
> faced challenges and put their heart and soul into their work in order to succeed,
|
||||
> lived longer than those who chose a more relaxed lifestyle and retired earlier.
|
||||
|
||||
## sedentary
|
||||
|
||||
Definition of sedentary: characterised by much sitting and little physical exercise. A sedentary lifestyle can lead to various health problems, including obesity, cardiovascular disease, and diabetes. It is important to incorporate regular physical activity into daily routines to counteract the negative effects of a sedentary lifestyle.
|
||||
|
||||
## Notes for page 35
|
||||
|
||||
|
||||
|
||||
## Notes for page 39
|
||||
|
||||
|
||||
|
||||
## Notes for page 43
|
||||
|
||||
> What, then, does logotherapy do?
|
||||
> The answer is pretty clear: It helps you find reasons to live.
|
||||
> Logotherapy pushes patients to consciously discover their life’s purpose in order to confront their neuroses. Their quest to fulfill their destiny then motivates them to press forward, breaking the mental chains of the past and overcoming whatever obstacles they encounter along the way.
|
||||
|
||||
## “He who has a why to live for can bear with almost any how.”
|
||||
|
||||
## Book mention
|
||||
|
||||
`Man’s Search for Meaning - Frankl`
|
||||
|
||||
`Morita Therapy and the True Nature of Anxiety-Based Disorders`
|
||||
|
||||
## “In feelings, it is best to be wealthy and generous.”
|
||||
|
||||
## Notes for page 54
|
||||
|
||||
> A donkey that is tied to a post by a rope will keep walking around the post
|
||||
> in an attempt to free itself, only to become more immobilized and attached to the
|
||||
> post. The same thing applies to people with obsessive thinking who become
|
||||
> more trapped in their own suffering when they try to escape from their fears and
|
||||
> discomfort.
|
||||
|
||||
“What do we need to be doing right now? What action should we be taking?”
|
||||
|
||||
## Book mention
|
||||
|
||||
> As Csikszentmihalyi asserts in his book Flow: The Psychology of Optimal
|
||||
> Experience,
|
||||
|
||||
Whiplash: How to Survive Our Faster Future
|
||||
|
||||
## “a happy man is too satisfied with the present to dwell on the future.”
|
||||
|
||||
## Notes for page 71
|
||||
|
||||
> Other studies indicate that working on several things at once lowers our
|
||||
> productivity by at least 60 percent and our IQ by more than ten points.
|
||||
|
||||
|
||||
|
||||
## Notes for page 74
|
||||
|
||||
> One of the first words one learns when
|
||||
> starting Japanese lessons is ganbaru, which means “to persevere” or “to stay
|
||||
> firm by doing one’s best.”
|
||||
|
||||
## Documentary
|
||||
|
||||
`Jiro Dreams of Sushi`
|
||||
|
||||
## Can someone really retire if he is passionate about what he does?
|
||||
|
||||
A very interesting statement. Having a purpose and passion in life is important, and for me personally, I would like to serve the deen as this is what I am passionate about. What would this entail? Teaching, reading, writing, and learning.
|
||||
|
||||
## misanthropic
|
||||
|
||||
Definition of misanthropic: having a general dislike or distrust of humankind. A misanthropic person may avoid social interactions and prefer solitude. This attitude can stem from negative experiences with others or a pessimistic view of human nature. However, it's important to note that not all individuals who are introverted or prefer solitude are necessarily misanthropic.
|
||||
|
||||
## Notes for page 86
|
||||
|
||||
> It is only a thought—one of the sixty
|
||||
> thousand we have every day, according to some experts.
|
||||
|
||||
## Notes for page 87
|
||||
|
||||
> Focus on enjoying your daily rituals, using them as tools to enter a state of
|
||||
> flow. Don’t worry about the outcome—it will come naturally. Happiness is in
|
||||
> the doing, not in the result. As a rule of thumb, remind yourself: “Rituals over
|
||||
> goals.”
|
||||
|
||||
## Notes for page 88
|
||||
|
||||
> Flow is mysterious. It is like a muscle: the more you train it, the more you
|
||||
> will flow, and the closer you will be to your ikigai.
|
||||
|
||||
## “Eat and sleep, and you’ll live a long time. You have to learn to relax.”
|
||||
|
||||
## Notes for page 97
|
||||
|
||||
> Of those still living, none have retired, and all still enjoy their passion, which
|
||||
> they plan to pursue until their final breath, demonstrating that when you have a
|
||||
> clear purpose, no one can stop you.
|
||||
|
||||
## Never Stop Learning
|
||||
|
||||
|
||||
|
||||
## Notes for page 99
|
||||
|
||||
> “You stay in your time. You don’t go backward. I think if you relate to
|
||||
> the time you’re in, you keep your eyes and ears open, read the paper, see what’s
|
||||
> going on, stay curious about everything, you will automatically be in your
|
||||
> time.”
|
||||
|
||||
## Notes for page 100
|
||||
|
||||
> The sense of community, and the fact that Japanese people make an
|
||||
> effort to stay active until the very end, are key elements of their secret to
|
||||
> long life.
|
||||
> If you want to stay busy even when there’s no need to work, there has
|
||||
> to be an ikigai on your horizon, a purpose that guides you throughout your
|
||||
> life and pushes you to make things of beauty and utility for the
|
||||
> community and yourself.
|
||||
|
||||
## Notes for page 112
|
||||
|
||||
> Washington Burnap stated two
|
||||
> hundred years ago: “The grand essentials to happiness in this life are something
|
||||
> to do, something to love, and something to hope for.”
|
||||
|
||||
## Notes for page 115
|
||||
|
||||
> “To live a long time you need to do three things: exercise to stay healthy, eat well,
|
||||
> and spend time with people.”
|
||||
|
||||
## Notes for page 116
|
||||
|
||||
> “Doing many different things every day. Always staying busy, but doing one thing
|
||||
> at a time, without getting overwhelmed.”
|
||||
|
||||
> “The secret to long life is going to bed early, waking up early, and going for a walk.
|
||||
> Living peacefully and enjoying the little things. Getting along with your friends.
|
||||
> Spring, summer, fall, winter . . . enjoying each season, happily.”
|
||||
|
||||
## Notes for page 117
|
||||
|
||||
“There’s no secret to it. The trick is just to live.”
|
||||
|
||||
## Book mention
|
||||
|
||||
`The Okinawa Program.`
|
||||
|
||||
## Notes for page 124
|
||||
|
||||
> A study of Okinawa’s centenarians showed that they ate 206
|
||||
> different foods, including spices, on a regular basis. They ate an average of
|
||||
> eighteen different foods each day, a striking contrast to the nutritional
|
||||
> poverty of our fast-food culture.
|
||||
|
||||
## Notes for page 125
|
||||
|
||||
Okinawans eat fish an average of three times per week;
|
||||
|
||||
## Notes for page 128
|
||||
|
||||
|
||||
|
||||
## Notes for page 131
|
||||
|
||||
> Shikuwasa is the citrus fruit par excellence of Okinawa, and Ogimi is its largest
|
||||
> producer in all of Japan.
|
||||
|
||||
Was having a look online on where to get Shikuwasa in the UK… seems to be out of stock everywhere and costs over £50 for just 500ml\!
|
||||
|
||||
## Notes for page 137
|
||||
|
||||
> As Easy as Getting out of Your Chair
|
||||
> “Metabolism slows down 90 percent after 30 minutes of sitting. The
|
||||
> enzymes that move the bad fat from your arteries to your muscles, where
|
||||
> it can get burned off, slow down. And after two hours, good cholesterol
|
||||
> drops 20 percent. Just getting up for five minutes is going to get things
|
||||
> going again. These things are so simple they’re almost stupid,” says Gavin
|
||||
> Bradley1 in a 2015 interview with Brigid Schulte for the Washington
|
||||
> Post.2
|
||||
|
||||
\`\`disciplines with clear rules are good for flow.''
|
||||
|
||||
## osteoporosis
|
||||
|
||||
Definition of osteoporosis: a medical condition in which the bones become brittle and fragile from loss of tissue, typically as a result of hormonal changes, or deficiency of calcium or vitamin D. This condition increases the risk of fractures, particularly in the hip, spine, and wrist.
|
||||
|
||||
## Radio taiso
|
||||
|
||||
|
||||
|
||||
|
||||
## Styles of yoga
|
||||
|
||||
- Jnana yoga: the yoga of wisdom; the search for discipline and mental growth
|
||||
- Karma yoga: focuses on action, on tasks and duties that benefit oneself and one’s community
|
||||
- Bhakti yoga: the yoga of devotion and surrender to the divine
|
||||
- Mantra yoga: focuses on the recitation of mantras to reach a state of relaxation
|
||||
- Kundalini yoga: combines diverse steps to reach the desired mental state
|
||||
- Raja yoga: also known as the royal path; encompasses a range of steps geared toward achieving communion with oneself and others
|
||||
- Hatha yoga: the most widespread form in the West and Japan; characterized by asanas or poses combined in a quest for balance
|
||||
|
||||
## How to do a Sun Salutation
|
||||
|
||||
<https://www.bodhisurfyoga.com/sun-salutation-sequence>
|
||||
|
||||
## Imitating clouds
|
||||
|
||||
## Methods for practicing qigong
|
||||
|
||||
1. Tyau Shenn: (regulating the body) by adopting the correct posture—it is
|
||||
|
||||
important to be firmly rooted to the ground
|
||||
|
||||
1. Tyau Shyi: (regulating the breath) until it is calm, steady, and peaceful
|
||||
2. Tyau Hsin: (regulating the mind); the most complicated part, as it implies
|
||||
|
||||
emptying the mind of thoughts
|
||||
|
||||
1. Tyau Chi: (regulating the life force) through the regulation of the three prior
|
||||
|
||||
elements, so that it flows naturally
|
||||
|
||||
1. Tyau Shen: (regulating the spirit); the spirit is both strength and root in
|
||||
|
||||
battle, as Yang Jwing-Ming explains in The Essence of Taiji Qigong.
|
||||
|
||||
## Book mention
|
||||
|
||||
Xiuzhen shishu
|
||||
|
||||
## Notes for page 157
|
||||
|
||||
> The book Xiuzhen shishu, known in the West as Ten Books on the Cultivation
|
||||
> of Perfection,
|
||||
|
||||
> In spring, breathe xu for clear eyes and so wood can aid your liver.
|
||||
> In summer, reach for he, so that heart and fire can be at peace.
|
||||
> In fall, breathe si to stabilize and gather metal, keeping the lungs moist.
|
||||
> For the kidneys, next, breathe chui and see your inner waters calm.
|
||||
> The Triple Heater needs your xi to expel all heat and troubles.
|
||||
> In all four seasons, take deep breaths so your spleen can process food.
|
||||
> And, of course, avoid exhaling noisily; don’t let even your own ears hear
|
||||
> you.
|
||||
> The practice is most excellent and will help preserve your divine elixir.
|
||||
|
||||
## Nana korobi ya oki 七転び⼋起き Fall seven times, rise eight. —Japanese proverb
|
||||
|
||||
## Notes for page 162
|
||||
|
||||
> God, give us grace to accept with serenity
|
||||
> the things that cannot be changed,
|
||||
> Courage to change the things
|
||||
> which should be changed,
|
||||
> and the Wisdom to distinguish
|
||||
> the one from the other.
|
||||
|
||||
## Notes for page 165
|
||||
|
||||
> The Stoics believed that these kinds of desires and ambitions are not worth
|
||||
> pursuing. The objective of the virtuous person is to reach a state of tranquility
|
||||
> (apatheia): the absence of negative feelings such as anxiety, fear, shame, vanity,
|
||||
> and anger, and the presence of positive feelings such as happiness, love, serenity,
|
||||
> and gratitude.
|
||||
|
||||
## Notes for page 168
|
||||
|
||||
> A complementary Japanese concept is that of ichi-go ichi-e, which could be
|
||||
> translated as “This moment exists only now and won’t come again.”
|
||||
|
||||
## Notes for page 169
|
||||
|
||||
> Ichi-go ichi-e teaches us to focus on the present and enjoy each moment that
|
||||
> life brings us. This is why it is so important to find and pursue our ikigai.
|
||||
> Wabi-sabi teaches us to appreciate the beauty of imperfection as an
|
||||
> opportunity for growth.
|
||||
|
||||
## Book mention
|
||||
|
||||
Antifragile: Things That Gain from Disorder
|
||||
|
||||
## Notes for page 170
|
||||
|
||||
> “Antifragility is beyond resilience or robustness. The resilient resists
|
||||
> shocks and stays the same; the antifragile gets better.”
|
||||
|
||||
## Notes for page 171
|
||||
|
||||
> The same idea goes for friendships and personal interests. It’s just a matter, as
|
||||
> the saying goes, of not putting all your eggs in one basket.
|
||||
|
||||
## Book mention
|
||||
|
||||
`Nassim Nicholas Taleb’s Antifragile.`
|
||||
|
||||
## Ikigai: The art of living
|
||||
|
||||
|
||||
|
||||
…achieve a happy state of flow in all you do, like the calligrapher at his canvas or the chef who, after half a century, still prepares sushi for his patrons with love.
|
||||
44
Books/20260402115029-dose_effect_notes.md
Executable file
44
Books/20260402115029-dose_effect_notes.md
Executable file
@@ -0,0 +1,44 @@
|
||||
# Notes
|
||||
|
||||
## p. 105
|
||||
|
||||
\[Quote\]: Happiness is equal to reality minus expectations
|
||||
|
||||
## p. 125
|
||||
|
||||
\[Insight\]: Hugging someone causes a huge release of oxytocin. Something to think about
|
||||
|
||||
## p. 131
|
||||
|
||||
\[Insight\]:
|
||||
Ideas to connect with one another:
|
||||
|
||||
- EXERCISING TOGETHER
|
||||
- WALKING AND RELAXING IN NATURE
|
||||
- CALLING INSTEAD OF MESSAGING
|
||||
- EATING AND DRINKING TOGETHER
|
||||
|
||||
## p. 137
|
||||
|
||||
\[Insight\]: Social connection checklist:
|
||||
|
||||
1. Remove phone
|
||||
2. Listen actively
|
||||
3. Compliment
|
||||
4. Make eye contact
|
||||
5. Connect physically
|
||||
6. Ask good questions
|
||||
|
||||
## p. 140
|
||||
|
||||
\[Insight\]: Social Confidence Steps Summary
|
||||
|
||||
1. STEP 1 Accept it
|
||||
2. STEP 2 Make eye contact and stand tall
|
||||
3. STEP 3 Pay attention and contribute
|
||||
|
||||
In these moments, our aim is to move our attention away from this internal voice in our minds and towards the people we are with.
|
||||
|
||||
## p. 165
|
||||
|
||||
\[Insight\]: The 2 serotonin principles: a) 90% is created within our guts. b) the happier your body, the happier your mind
|
||||
31
Books/20260417162601-effect_of_tiktok_on_teens_notes.md
Executable file
31
Books/20260417162601-effect_of_tiktok_on_teens_notes.md
Executable file
@@ -0,0 +1,31 @@
|
||||
# Effect of Tiktok on teens Notes
|
||||
|
||||
## Notes for page 1
|
||||
|
||||
> The latest TikTok statistics show that, as of July 2022, the platform has over one billion monthly active users worldwide
|
||||
>
|
||||
> In the US 62% of TikTok users are aged between 10 and 29
|
||||
|
||||
## Article Mention:
|
||||
|
||||
"TIKTOK - THE INFLUENCE ON SCHOOLPERFORMANCE AND SOCIAL LIFE OF ADOLESCENTS"
|
||||
|
||||
## Notes for page 2
|
||||
|
||||
> “Navigating the New Era of Influencer Marketing: How to be Successful on Instagram, TikTok, & Co”
|
||||
|
||||
> Just like there is no clock in a casino, Tiktok deliberately blurs the user's time judgment and hides the time in design.
|
||||
|
||||
## The negative impact of Tiktok on adolescent psychology
|
||||
|
||||
## Notes for page 3
|
||||
|
||||
> cyber-bullying generally involves using the Internet to threaten, harm, embarrass, or socially exclude others
|
||||
|
||||
> "The key period of personal socialization is the youth stage. In this stage, being bullied will weak adolescents' self-identity and increases the risk of anxiety and depression, which is not conducive to the development of adolescents' mental health and personality shaping"
|
||||
|
||||
> The Internet is a virtual world in which many netizens freely vent their anger and dissatisfaction, and abuse others at will to gain psychological catharsis.
|
||||
|
||||
## Notes for page 4
|
||||
|
||||
> “We are in an era of great change. This is the best time, and it is also a the worst times. Teenagers should constantly improve themselves, strengthen self-control and the ability to distinguish right from wrong, make use of the advantages brought by the Internet, and constantly explore the boundaries of the future, dare to try and create their own value”
|
||||
@@ -0,0 +1 @@
|
||||
# Effects of insufficient sleep on circadian rhythmicity Notes
|
||||
13
Books/20260418225944-art_of_computer_programming_notes.md
Executable file
13
Books/20260418225944-art_of_computer_programming_notes.md
Executable file
@@ -0,0 +1,13 @@
|
||||
# Art of Computer Programming Notes
|
||||
|
||||
## Notes for page 5
|
||||
|
||||
> Here is your book, the one your thousands of letters have asked us
|
||||
> to publish. It has taken us years to do, checking and rechecking countless
|
||||
> recipes to bring you only the best, only the interesting, only the perfect.
|
||||
> Now we can say, without a shadow of a doubt, that every single one of them,
|
||||
> if you follow the directions to the letter, will work for you exactly as well
|
||||
> as it did for us, even if you have never cooked before.
|
||||
>
|
||||
> -
|
||||
> McCall's Cookbook (1963)
|
||||
7
Books/Book Recs.md
Executable file
7
Books/Book Recs.md
Executable file
@@ -0,0 +1,7 @@
|
||||
# [Link](https://www.youtube.com/watch?v=qF6LQX-9p2I&list=LL&index=1&ab_channel=EmacsElements)
|
||||
|
||||
- The Unix Programming Environment by Brian W. Kernighan and Rob Pike
|
||||
- An Introduction to Programming in Emacs Lisp by Robert J. Chassell
|
||||
- GNU Emacs Manual by Richard M, Stallman
|
||||
|
||||
# [Co-Intelligence: Living and Working with AI](https://search.brave.com/search?q=co+intelligence&summary=1&conversation=091312e416c3bbb83c6c6ccc2d0cd4d40875)
|
||||
276
Books/Books Calibre.md
Executable file
276
Books/Books Calibre.md
Executable file
@@ -0,0 +1,276 @@
|
||||
---
|
||||
tags:
|
||||
- books
|
||||
- calibre
|
||||
- index
|
||||
generated_at: 2026-06-03T14:09:04.104390
|
||||
---
|
||||
|
||||
# Career
|
||||
|
||||
## Clean Code_ A Handbook of Agile Software Craftsmanship - Robert C. Martin #Read
|
||||
|
||||
- Author: Robert C. Martin
|
||||
- Status: Read
|
||||
- Calibre ID: 12
|
||||
- Completed at: 2026-01-11 13:03:47.285042
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Robert C. Martin/Clean Code_ A Handbook of Agile Software Craftsmanship - Robert C. Martin (12)
|
||||
|
||||
## Code Complete, Second Edition eBook #Unread
|
||||
|
||||
- Author: Steve McConnell
|
||||
- Status: Unread
|
||||
- Calibre ID: 18
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Steve McConnell/Code Complete, Second Edition eBook (18)
|
||||
|
||||
## Grokking Algorithms #Unread
|
||||
|
||||
- Author: Aditya Y Bhargava
|
||||
- Status: Unread
|
||||
- Calibre ID: 4
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Aditya Y Bhargava/Grokking Algorithms (4)
|
||||
|
||||
## Head First: Design Patterns #Unread
|
||||
|
||||
- Author: Eric Freeman, Elisabeth Robson, Bert Bates, Kathy Sierra
|
||||
- Status: Unread
|
||||
- Calibre ID: 22
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Eric Freeman/Head First_ Design Patterns (22)
|
||||
|
||||
## Quick Start Kubernetes #Unread
|
||||
|
||||
- Author: Nigel Poulton
|
||||
- Status: Unread
|
||||
- Calibre ID: 31
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Nigel Poulton/Quick Start Kubernetes (31)
|
||||
|
||||
## Structure and Interpretation of Computer Programs, 2nd ed. #Unread
|
||||
|
||||
- Author: Unknown
|
||||
- Status: Unread
|
||||
- Calibre ID: 11
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Unknown/Structure and Interpretation of Computer Programs, 2nd ed_ (11)
|
||||
|
||||
## The Clean Coder: A Code of Conduct For Professional Programmers #Read
|
||||
|
||||
- Author: Robert C. Martin
|
||||
- Status: Read
|
||||
- Calibre ID: 10
|
||||
- Completed at: 2025-09-23 14:47:41.693290
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Robert C. Martin/The Clean Coder_ A Code of Conduct For Professional Programmers (10)
|
||||
|
||||
## The Toyota Way - Jeffrey Liker #Read
|
||||
|
||||
- Author: Jeffrey Liker
|
||||
- Status: Read
|
||||
- Calibre ID: 16
|
||||
- Completed at: 2025-11-22 23:11:24.006065
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Jeffrey Liker/The Toyota Way - Jeffrey Liker (16)
|
||||
|
||||
# Current Reads
|
||||
|
||||
## Code Complete, Second Edition eBook #Unread
|
||||
|
||||
- Author: Steve McConnell
|
||||
- Status: Unread
|
||||
- Calibre ID: 18
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Steve McConnell/Code Complete, Second Edition eBook (18)
|
||||
|
||||
## Hujjatul Islam Hadhrat Moulana Muhammad Qasim Nanotwi Rahmatullai Alayh A Glimpse Into His Life #Unread
|
||||
|
||||
- Author: Jamiatul Ulama (KZN) Ta'limi Board
|
||||
- Status: Unread
|
||||
- Calibre ID: 36
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Jamiatul Ulama (KZN) Ta'limi Board/Hujjatul Islam Hadhrat Moulana Muhammad Qasim Nanotwi Rahmatullai Alayh A Glimpse Into His Life (36)
|
||||
|
||||
## Khulfa-e-Rashideen #Unread
|
||||
|
||||
- Author: Makbool Ahmed Suhaarwi | Afzal Hoosen Elias (translator)
|
||||
- Status: Unread
|
||||
- Calibre ID: 30
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Makbool Ahmed Suhaarwi , Afzal Hoosen Elias (translator)/Khulfa-e-Rashideen (30)
|
||||
|
||||
## Quick Start Kubernetes #Unread
|
||||
|
||||
- Author: Nigel Poulton
|
||||
- Status: Unread
|
||||
- Calibre ID: 31
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Nigel Poulton/Quick Start Kubernetes (31)
|
||||
|
||||
## Sahih Al Bukhari #Unread
|
||||
|
||||
- Author: Imam Bukhari RH
|
||||
- Status: Unread
|
||||
- Calibre ID: 35
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Imam Bukhari RH/Sahih Al Bukhari (35)
|
||||
|
||||
## The Dose Effect #Unread
|
||||
|
||||
- Author: Tj Power
|
||||
- Status: Unread
|
||||
- Calibre ID: 28
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Tj Power/The Dose Effect (28)
|
||||
|
||||
# Deen
|
||||
|
||||
## A Gift for Nikah #Read
|
||||
|
||||
- Author: Shaykh Abdul Raheem Limbada
|
||||
- Status: Read
|
||||
- Calibre ID: 23
|
||||
- Completed at: 2026-01-27 13:16:50.022878
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Shaykh Abdul Raheem Limbada/A Gift for Nikah (23)
|
||||
|
||||
## Hujjatul Islam Hadhrat Moulana Muhammad Qasim Nanotwi Rahmatullai Alayh A Glimpse Into His Life #Unread
|
||||
|
||||
- Author: Jamiatul Ulama (KZN) Ta'limi Board
|
||||
- Status: Unread
|
||||
- Calibre ID: 36
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Jamiatul Ulama (KZN) Ta'limi Board/Hujjatul Islam Hadhrat Moulana Muhammad Qasim Nanotwi Rahmatullai Alayh A Glimpse Into His Life (36)
|
||||
|
||||
## Imam Rabbani - Mujaddid Alf Thani #Unread
|
||||
|
||||
- Author: Unknown
|
||||
- Status: Unread
|
||||
- Calibre ID: 34
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Unknown/Imam Rabbani - Mujaddid Alf Thani (34)
|
||||
|
||||
## Khulfa-e-Rashideen #Unread
|
||||
|
||||
- Author: Makbool Ahmed Suhaarwi | Afzal Hoosen Elias (translator)
|
||||
- Status: Unread
|
||||
- Calibre ID: 30
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Makbool Ahmed Suhaarwi , Afzal Hoosen Elias (translator)/Khulfa-e-Rashideen (30)
|
||||
|
||||
## Lessons In Islamic History: Durus fi at-Tarikh al-Islami #Unread
|
||||
|
||||
- Author: Shaykh Muhammad Al-Khudari Bak Al-Bajuri
|
||||
- Status: Unread
|
||||
- Calibre ID: 33
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Shaykh Muhammad Al-Khudari Bak Al-Bajuri/Lessons In Islamic History_ Durus fi at-Tarikh al-Islami (33)
|
||||
|
||||
## Sahih Al Bukhari #Unread
|
||||
|
||||
- Author: Imam Bukhari RH
|
||||
- Status: Unread
|
||||
- Calibre ID: 35
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Imam Bukhari RH/Sahih Al Bukhari (35)
|
||||
|
||||
## The Tafseer of Surah Fatiha #Unread
|
||||
|
||||
- Author: Shaykh Abdul Raheem Limbada
|
||||
- Status: Unread
|
||||
- Calibre ID: 26
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Shaykh Abdul Raheem Limbada/The Tafseer of Surah Fatiha (26)
|
||||
|
||||
## The Tafseer of Surah Maryam #Unread
|
||||
|
||||
- Author: Shaykh Abdul Raheem Limbada
|
||||
- Status: Unread
|
||||
- Calibre ID: 25
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Shaykh Abdul Raheem Limbada/The Tafseer of Surah Maryam (25)
|
||||
|
||||
## The Tafseer of Surah Nuh #Unread
|
||||
|
||||
- Author: Shaykh Abdul Raheem Limbada
|
||||
- Status: Unread
|
||||
- Calibre ID: 24
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Shaykh Abdul Raheem Limbada/The Tafseer of Surah Nuh (24)
|
||||
|
||||
## The Tafseer of Surah Yusuf #Unread
|
||||
|
||||
- Author: Shaykh Abdul Raheem Limbada
|
||||
- Status: Unread
|
||||
- Calibre ID: 27
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Shaykh Abdul Raheem Limbada/The Tafseer of Surah Yusuf (27)
|
||||
|
||||
# Self Improvement
|
||||
|
||||
## Atomic Habits #Unread
|
||||
|
||||
- Author: James Clear
|
||||
- Status: Unread
|
||||
- Calibre ID: 32
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/James Clear/Atomic Habits (32)
|
||||
|
||||
## Ikigai #Read
|
||||
|
||||
- Author: Héctor García, Francesc Miralles
|
||||
- Status: Read
|
||||
- Calibre ID: 13
|
||||
- Completed at: 2026-04-01 16:09:57.170644
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Héctor García/Ikigai (13)
|
||||
|
||||
## Learn Like a Polymath #Unread
|
||||
|
||||
- Author: Peter Hollins
|
||||
- Status: Unread
|
||||
- Calibre ID: 9
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Peter Hollins/Learn Like a Polymath (9)
|
||||
|
||||
## Polymath #Unread
|
||||
|
||||
- Author: Peter Hollins
|
||||
- Status: Unread
|
||||
- Calibre ID: 8
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Peter Hollins/Polymath (8)
|
||||
|
||||
## So Good They Can't Ignore You: Why Skills Trump Passion in the Quest for Work You Love #Read
|
||||
|
||||
- Author: Cal Newport
|
||||
- Status: Read
|
||||
- Calibre ID: 5
|
||||
- Completed at: 2025-09-23 14:48:07.510340
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Cal Newport/So Good They Can't Ignore You_ Why Skills Trump Passion in the Quest for Work You Love (5)
|
||||
|
||||
## The Book of Ichigo Ichie: The Art of Making the Most of Every Moment, the Japanese Way #Unread
|
||||
|
||||
- Author: Héctor García, Francesc Miralles
|
||||
- Status: Unread
|
||||
- Calibre ID: 14
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Héctor García/The Book of Ichigo Ichie_ The Art of Making the Most of Every Moment, the Japanese Way (14)
|
||||
|
||||
## The Dose Effect #Unread
|
||||
|
||||
- Author: Tj Power
|
||||
- Status: Unread
|
||||
- Calibre ID: 28
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Tj Power/The Dose Effect (28)
|
||||
|
||||
## The Science of Daily Self-Discipline: Using Science and Daily Practices to Build Your Willpower, Self-Confidence, and Everyday Habits to Achieve Long-Term Goals (Science of Self-Help) #Unread
|
||||
|
||||
- Author: Oliver McAndrew
|
||||
- Status: Unread
|
||||
- Calibre ID: 3
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Oliver McAndrew/The Science of Daily Self-Discipline_ Using Science and Daily Practices to Build Your Willpower, (3)
|
||||
|
||||
## The Science of Powerful Focus: 23 Methods for More Productivity, More Discipline, Less Procrastination, and Less Stress #Unread
|
||||
|
||||
- Author: Peter Hollins
|
||||
- Status: Unread
|
||||
- Calibre ID: 6
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Peter Hollins/The Science of Powerful Focus_ 23 Methods for More Productivity, More Discipline, Less Procrasti (6)
|
||||
|
||||
## The Science of Self-Discipline #Read
|
||||
|
||||
- Author: Peter Hollins
|
||||
- Status: Read
|
||||
- Calibre ID: 7
|
||||
- Completed at: 2025-09-23 14:47:59.085450
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/Peter Hollins/The Science of Self-Discipline (7)
|
||||
|
||||
# Unsorted
|
||||
|
||||
## Fundamental Accessibility Tests: Basic Functionality #Unread
|
||||
|
||||
- Author: DAISY Consortium
|
||||
- Status: Unread
|
||||
- Calibre ID: 2
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/DAISY Consortium/Fundamental Accessibility Tests_ Basic Functionality (2)
|
||||
|
||||
## Quick Start Guide #Unread
|
||||
|
||||
- Author: John Schember
|
||||
- Status: Unread
|
||||
- Calibre ID: 1
|
||||
- Path: /home/zaine/master-folder/projects/calibre/library/John Schember/Quick Start Guide (1)
|
||||
35
Books/Books MOC.md
Executable file
35
Books/Books MOC.md
Executable file
@@ -0,0 +1,35 @@
|
||||
# Recommendations for books: [[Book Recs]]
|
||||
|
||||
# [[Books Calibre]]
|
||||
|
||||
# Book Notes:
|
||||
|
||||
## <span class="done DONE">DONE</span> [Ikigai Book Notes](id:fc07cbca-cf1a-4698-912b-de74001f0b5c)
|
||||
|
||||
## <span class="todo TODO">TODO</span> [The Dose Effect Book Notes](id:2c1d3647-a3be-4a4f-94c2-100f02de1f56)
|
||||
|
||||
## <span class="todo TODO">TODO</span> [The Book of Ichigo Ichie Notes](id:50dd4105-506e-424a-9cc2-4fd494dc4284)
|
||||
|
||||
# Article Notes:
|
||||
|
||||
## <span class="done DONE">DONE</span> [Effect of Tiktok on teens](id:db7b1fdb-28cd-43a8-8137-23399f38cd07)
|
||||
|
||||
## <span class="todo TODO">TODO</span> [Effects of insufficient sleep on circadian rhythmicity](id:5429d9c8-ace8-419b-a9dc-8403b9c20215)
|
||||
|
||||
## Software:
|
||||
|
||||
### <span class="done DONE">DONE</span> [I Thought I Knew System Design Until I Met a Google L7 Interviewer](id:9f220a90-635a-4744-9664-be89d8b2a64b)
|
||||
|
||||
### <span class="done DONE">DONE</span> [Every Senior Engineer I Respect Has Read These Books (Have You?)](id:c3b075bc-44c9-43eb-9c44-a58cb532fc35)
|
||||
|
||||
### <span class="done DONE">DONE</span> [Software Quality Article](id:453e252a-34f4-4d84-adab-35fe69ceed55)
|
||||
|
||||
# Long term:
|
||||
|
||||
## <span class="todo TODO">TODO</span> [Art of Computer Programming Notes](id:f1bc3f88-95c5-4013-b0dd-f72428200e72)
|
||||
|
||||
# Non PDF:
|
||||
|
||||
## <span class="done DONE">DONE</span> [Microsoft banned AI because it cost too much.](https://medium.com/data-science-collective/microsoft-banned-ai-because-it-cost-too-much-135bcbf15a18)
|
||||
|
||||
## <span class="done DONE">DONE</span> [The Best Engineers Write Less Code](https://shvetsm.github.io/posts/the-best-engineers-write-less-code/)
|
||||
5
Books/Notes/20250723183655-career_capital.md
Executable file
5
Books/Notes/20250723183655-career_capital.md
Executable file
@@ -0,0 +1,5 @@
|
||||
Career capital refers to the abilities and resources you accumulate—whether skills, credentials, connections, or
|
||||
savings—that allow you to do more with your career in the future. It’s an important consideration in long-term career
|
||||
planning, especially in the early stages of your career.
|
||||
|
||||
Taken from: <https://probablygood.org/core-concepts/career-capital/>
|
||||
5
Books/Notes/20250723183755-deliberate_practice.md
Executable file
5
Books/Notes/20250723183755-deliberate_practice.md
Executable file
@@ -0,0 +1,5 @@
|
||||
Deliberate practice refers to a special type of practice that is purposeful and systematic. While regular practice might
|
||||
include mindless repetitions, deliberate practice requires focused attention and is conducted with the specific goal of
|
||||
improving performance.
|
||||
|
||||
Taken from: <https://jamesclear.com/deliberate-practice-theory>
|
||||
8
Books/Notes/20250723184430-stanford_marshmallow_experiment.md
Executable file
8
Books/Notes/20250723184430-stanford_marshmallow_experiment.md
Executable file
@@ -0,0 +1,8 @@
|
||||
The Stanford marshmallow experiment, conducted in the 1960s and 1970s by psychologist Walter Mischel, explored the
|
||||
ability of children to delay gratification. In the experiment, preschoolers were offered a marshmallow with the promise
|
||||
of a second one if they waited a designated time (typically 15 minutes) without eating the first. The study's findings
|
||||
revealed that children who waited longer to eat the marshmallow showed positive correlations with future outcomes like
|
||||
higher SAT scores and better social functioning. However, later research has questioned the predictive power of the
|
||||
original study, particularly when controlling for socio-economic factors.
|
||||
|
||||
Source: <https://jamesclear.com/delayed-gratification>
|
||||
4
Books/Notes/20250723185056-neuroplasticity.md
Executable file
4
Books/Notes/20250723185056-neuroplasticity.md
Executable file
@@ -0,0 +1,4 @@
|
||||
The ability of the brain to form and reorganize synaptic connections, especially in response to learning or
|
||||
experience or following injury.
|
||||
|
||||
"Neuroplasticity offers real hope to everyone from stroke victims to dyslexics"
|
||||
7
Books/The Book of Ichigo Ichie.md
Executable file
7
Books/The Book of Ichigo Ichie.md
Executable file
@@ -0,0 +1,7 @@
|
||||
# The Book of Ichigo Ichie Notes
|
||||
|
||||
## Notes for page 5
|
||||
|
||||
> Before beginning to study the sacred texts and constantly singing the sutras, the
|
||||
> student should learn to read the love letters sent by the snow, the wind, and the
|
||||
> rain.
|
||||
Reference in New Issue
Block a user