- How to take smart Notes
Introduction 4, The four underlying principles 4, the six steps to successful writing 6, afterword
write everything/ collect notes not related to any thing, organize notes, revirew, rewrite,
no reorganise no complex system, develop ideas by smart notes
1 slip-box; 2 repeatable tasks that can become automatic and fit together seamlessly change routinges
overarching workflow "Getting Things Done" GTD
constantly have to ump back and forth between different tasks
1- bibliographical slip-box: reference
2- collected and generated ideas slip-box
3- index: notes serve as entry point / thought/ topic
writing a paper step by step
1 fleeting notes: it will delete within a day
I always have a slip of paper at hand, on which I note down the ideas of certain pages. on the backside I write down the bibliographic details. after finishing the book I go throught my notes and think how ehse notes might be relevant for already written notes in the slip-box. it means that I always read with an eye towards possible connections in the slip-box
2 literature notes: contain the necessary information - in reference system or in the slip-box
I make a note with the bibliographic details. on the backside I would write "on page x is this, on page y is that" and then it goes into the bibliographic slib-box where I collect everything I read
read, think about its relevance
theoretical background, methodological approach or perspective of the text we read.
whether something adds to a discussion in the slip-box
we look at our slip-box for already existing lines of thought and think about the questions and problems already on our minds to which a new note might contribute. - assigning keywords is much more than just a bureaucratic act. it is a crucial part of the thinking process, which often leads to a deeper elaboration of the note itself and the connection to other notes.
3 permanent notes: develop ideas/new/ - only relevant to one particular project - in project specific folder - can be discarded or archived after project finished
add to slip-box behind the note you dirctyly refer to or behind the last note in the slip-box
add links to other notes or links on other notes to your new note
make sure it can be found from the index (MOC) add an entry in the index if necessary or refer to it from a note that is connected to the index
build a latticework of mental models
4 behind multiple notes (link backward) - link to related note - link to MOC
make sure it can be found again
keywords can easily be added to a note like tags and will then show up in the index
read and take notes
build connections within the slip-box - new idea
you write on your paper, notice a hole in the argument and have another look in the file system for the missing link. you follow up on a footnote, go back to research and might add a fitting quote to one of your papers in the making.
The four underlying principles
not from scratch
let the work carry you forward
the six steps to successful writing
separate and interlocking tasks
we use memo techniques is to bundle items together in a meaningful way and remember the bundles
the brain doesn't distinguish between an actual finished task and one that is postponed by taking a note
the fist step is to break down the amprphous task of "writing" into smaller pieces of different tasks that can be finished in one go. the second step is to make sure we always write down the outcome of our thinking, including possible connections to further inquiries.
read for understanding
take smart notes
develp ideas (MOC)
1 overview of a topic - referred to from the index and used as an entry point into a topic has already develped
2 keeping tarck of all topic - index -
share your insight
make it a habit
- Writing Solid Code
Enable all optional compiler warnings.
Use lint to catch bugs that your compiler may miss.
If you have unit tests, use them.
introduction assert page 16; assert.h
assert is nothing more than a repackaged form of the #ifdef code we saw before, but when you use
the macro, it takes one line instead of seven
That's why assert is a macro and not a function; if it were a function, calling
it could cause unexpected memory or code swapping.
Use assertions to validate function arguments .
Strip undefined behavior from your code, or use assertions to catch illegal uses of undefined behavior .
Don't waste people's time. Document unclear assertions .
Either remove implicit assumptions, or assert that they are valid .
Use assertions to detect impossible conditions.
Don't hide bugs when you program defensively.
Use a second algorithm to validate your results.
Don't wait for bugs to happen; use startup checks.
Maintain shipping and debugging versions of your program. Shrink-wrap the shipping version, but use the debugging version as much as possible to catch bugs quickly.
Assertions are a shorthand way to write debugging checks. Use them to catch illegal conditions that should never arise. Don't confuse such conditions with error conditions, which you must handle in the final product.
Use assertions to validate function arguments and to alert pro grammars when they do something undefined. The more rigidly you define your functions, the easier it will be to validate the arguments.
Once you've written a function, review it and ask yourself, 'What am I assuming?" If you find an assumption, either assert that your assumption is always valid, or rewrite the code to re move the assumption. Also ask, 'What is most likely to be wrong in this code, and how can I automatically detect the problem?" Strive to implement tests that catch bugs at the earliest possible moment. Textbooks encourage programmers to program defensively, but remember that this coding style hides bugs. When you write defensive code, use assertions to alert you if the "can't happen" cases do happen.
Eliminate random behavior. Force bugs to be reproducible .
Destroy your garbage so that it's not misused .
Not only did reallocate have to move the block of memory as it was expanding it, but the old memory had to be reallocated and filled with new data. In the assembler, both happened rarely.
This brings up another guideline for writing bug-free code: You don't want anything to happen rarely. You need to isolate those behaviors in your subsystems that may happen and make sure that they do happen. And of ten. If you find rare behavior in your subsystems, be sure to do something anything-to stir things up.
The assembler bug could have been found within hours, instead of years, if reallocate hadn't so rarely moved blocks when it expanded them.
If something happens rarely, force it to happen often.
Keep debug information to allow stronger error checking.
There is no question that the debug code will create differences be tween the ship and the debug versions of your code, but as long as you're careful not to change the underlying behavior of the code, those differences shouldn't matter.
Create thorough subsystem checks, and use them often.
Design your tests carefully. Nothing should be arbitrary.
Strive to implement transparent integrity checks.
Don't apply ship version constraints to the debug version. Trade size and speed for error detection.
Don't wait until you have a bug to step through your code.
Step through every code path.
What About Sweeping Changes? In the past, programmers have asked, "What if I add a feature that touches code in many places? Stepping through all that new code is going to be time consuming." Let me answer that question with another: Can you make such sweeping changes without introducing any bugs? The habit of stepping through your code creates an interesting negative feedback loop. Programmers who step through their code soon learn to write small, easily testable functions because stepping through large functions is so painful. Programmers also spend more time thinking about how they can localize the changes they need to make-again, so that they can more easily test their code. And isn't this exactly what you want? No project lead likes it when programmers touch a lot of code; it's too destabilizing. Nor do leads like large, unmanageable functions; they're often unmaintainable. Try hard to localize your changes. If you find that you must make pervasive changes, think twice before you decide not to step through all the new code.
Overflow and underflow bugs
Data conversion bugs
NULL pointer bugs
Bugs using garbage memory (0xA3 bugs)
Assignment bugs in which you've used = instead of ==
As you step through code, focus on data flow. Source level debuggers can hide execution details. Step through critical code at the instruction level .
Make it hard to ignore error conditions. Don't bury error codes in return values.
Always look for, and eliminate, flaws in your interfaces.
Don't write multipurpose functions. Write separate functions to allow stronger argument validation.
Don't be wishy-washy. Define explicit function arguments.
Write functions that, given valid inputs, cannot fail.
Make the code intelligible at the point of call. Avoid Boolean arguments.
Write comments that emphasize potential hazards.
Use well-defined data types.
Always ask ,"Can this variable or expression over- or underflow?"
Implement your designs as accurately as possible. Being kind a close is being kind a buggy.
these principles already: Don't accept special purpose arguments such as the NULL pointer, and Implement your design, not something that approximates it. The third principle is new: Strive to make every function perform its task exactly one time.
Implement "the task" just once.
Get rid of extraneous if statements.
Avoid using nested ?: operators .
Handle your special cases just once.
Avoid risky language idioms.
Don't needlessly mix operator types. If you must mix operators, use parentheses to isolate the operations.
Avoid calling functions that return errors.
Don't reference memory that you don't own.
Don't reference memory that you have freed.
Don't use output memory as workspace buffers.
Don't pass data in static (or global) memory.
Don't write parasitic functions.
Don't abuse your programming language.
Tight C does not guarantee efficient machine code.
Write code for the "average" programmer.
Bugs don't just "go away."
Don't fix bugs later; fix them now.
Fix the cause, not the symptom.
Don't clean up code unless the clean up is critical to the product's success.
Don't implement nonstrategic features.
There are no free features.
Don't allow unnecessary flexibility.
Don't keep "trying" solutions· until you find one that works. Take the time to find the correct solution.
Write and test code in small chunks.
Always test your code, even if that means your schedule will slip.
Don't rely on the testing group to find your bugs.
Don't blame testers for finding your bugs.
Establish your priorities and stick to them.
Never allow the same bug to bite you twice.
A: CODING CHECKLISTS
B: MEMORY LOGGING ROUTINES
To sum up
Charles Simonyi in the early 1970s. https://en.wikipedia.org/wiki/Hungarian_notation
flag f;/* flags that are always TRUE or FALSE*/
symbol sym;/* some sort of symbol structure*/
char byte flag symbol
*pch:/* character pointer*/
related link: https://www.morling.dev/images/code_review_pyramid.svg
- Shape Up: Stop Running in Circles and Ship Work that Matters
Six-week cycles: Our decisions are based on moving the product forward in the next six weeks, not micromanaging time. We don’t count hours or question how individual days are spent. We don’t have daily meetings. We don’t rethink our roadmap every two weeks. Our focus is at a higher level. We say to ourselves: “If this project ships after six weeks, we’ll be really happy. We’ll feel our time was well spent.” Then we commit the six weeks and leave the team alone to get it done
Shaping the work: key elements of a solution, appetite
part one shaping:
two separate tracks: one for shaping, one for building.
Steps to shaping
1. Set boundaries.
2. Rough out the elements: idea that solves the problem within the appetite but without all the fine details worked out
3. Address risks and rabbit holes.
4. Write the pitch.
fixed time, variable scope,
Where in the current system does the new thing fit? How do you get to it? What are the key components or interactions? Where does it take you?
five ingredients that we always want to include in a pitch: 1. Problem — The raw idea, a use case, or something we’ve seen that motivates us to work on this 2. Appetite — How much time we want to spend and how that constrains the solution 3. Solution — The core elements we came up with, presented in a form that’s easy for people to immediately understand 4. Rabbit holes — Details about the solution worth calling out to avoid problems 5. No-gos — Anything specifically excluded from the concept: functionality or use cases we intentionally aren’t covering to fit the appetite or make the problem tractable
part two : Betting
Some companies use two-week cycles (aka “sprints”). We learned that two weeks is too short to get anything meaningful done. Worse than that, two-week cycles are extremely costly due to the planning overhead. The amount of work you get out of two weeks isn’t worth the collective hours around the table to “sprint plan” or the opportunity cost of breaking everyone’s momentum to re-group.
after each six-week cycle, we schedule two weeks for cool-down.
bugs: Use cool-down. Bring it to the betting table. Schedule a bug smash.
We’ve noticed three phases of work when we build a new product from scratch. R&D mode (bet the time on spiking some key pieces of the new product idea. CEO and designer, we don’t expect to ship anything at the end of an R&D cycle) , Production mode (Shaping is deliberate again. bet multiple teams in parallel , Shipping is the goal) , Cleanup mode (There’s no shaping. There aren’t clear team boundaries. Work is “shipped”) [Cleanup shouldn’t last longer than two cycles]
Example: two years of development, R&D mode for the first year, a year of production mode cycles followed, two cycles of cleanup and significantly cut back the feature set, some overlap between R&D and production mode after that first year,
Part three: Building
We don’t start by assigning tasks to anyone.
we define and track the scopes as to-do lists. Each scope corresponds to a list name. Then any tasks for that scope go in that list.
image 1, 2, 3,
Mark nice-to-haves with ~
First there’s the uphill phase of figuring out what our approach is and what we’re going to do. Then, once we can see all the work involved, there’s the downhill phase of execution
image 4, 5,
- Disciplined entrepreneurship 24 steps to a successful startup by Bill Aulet
getting start: idea, technology, passion; What can I do well that I would love to do for an extended period of time? P: 19, 21
1 market segmentation: The single necessary and sufficient condition for a business is a paying customer. ; technological enthusiasts=early adopters=early majority ; P: 31,
2 select a beachhead market: P: 44,
3 build an end user profile: P: 52,
4 Calculate the Total Addressable Market (TAM) Size for the Beachhead Market; $200 <TAM < $100 million per year;
5 The process of developing a Persona provides specific details about the primary customer within your beachhead market.
6 Creating a visual representation of the full life cycle of your product enables you to see how the product will fit into the customer’s value chain and what barriers to adoption might arise. P: 86,
7 High-Level Product Specification;
8 Quantify the Value Proposition:
9 Identify Your Next 10 Customers: P: 115,
10 Define Your Core: First-mover advantage can help a company with a well-defined Core, but it cannot win the market by simply by being first; this must be translated into something else like locking in key customers, achieving positive networking effects for your company, recruiting the best talent in a certain area, and so on. ;
11 Chart Your Competitive Position: The goal is to show that your Competitive Position both leverages your Core and that your product satisfies your Persona’s priorities far better than existing or logical future products. ; P:134,
12 Determine the Customer’s Decision-Making Unit (DMU):
13 Map the Process to Acquire a Paying Customer: Okta; P:151, 152,
14 Calculate the Total Addressable Market Size for Follow-on Markets: If you want to attract venture capital and/or build a big business, the general rule is that the broader TAM (for 10 or less follow-on markets), plus your beachhead market TAM, should add up to over $1B. ;
*15 Design a Business Model: A business model is a framework by which you extract from your customers some portion of the value your product creates for them. ; GENERALIZED CATEGORIES OF BUSINESS MODELS= P: 167-171; two key entrepreneurship variables: the Lifetime Value of an Acquired Customer (LTV) and Cost of Customer Acquisition (COCA). Do not focus on pricing in this step, as your choice of business model has a far larger influence on profitability than your pricing decisions.
Licensing: your royalty rate will generally be equivalent to one-twentieth or less of the revenue per sale; and hence the TAM will as well, because a five percent royalty rate is about the best you can hope for.
*16 Set Your Pricing Framework:
*17 Calculate the Lifetime Value (LTV) of an Acquired Customer: P 184,
18 Map the Sales Process to Acquire a Customer: P 199,
19 Calculate the Cost of Customer Acquisition (COCA): P 209, 210, 211,
20 Identify Key Assumptions: “Minimum Viable Business Product” (MVBP)—a different concept than the MVP ;
21 Test Key Assumptions: P: 227,
22 Define the Minimum Viable Business Product (MVBP): P: 237,
23 Show That “The Dogs Will Eat the Dog Food”:
24 Develop a Product Plan:
you will also need to learn about many other things including the following:
• Building a Company Culture
• Selecting a Founding Team
• Growing and Building the Team (HR Processes)
• Developing the Product
• Selling and Sales Execution
• Servicing the Customer and Building Customer Service Processes
• Building Your Financials and Managing Cash Flow
• Raising Money to Scale the Business
• Entrepreneurial Leadership and Scaling the Business
• Building and Utilizing Good Company Governance
• And much more
- List of books I've read:
- Multiple view geometry in computer vision
- Learning OpenCV Book by Adrian Kaehler and Gary Bradski
- Digital Image Processing, Global Edition by Rafael C. Gonzalez
- Introduction to Algorithms, 3rd Edition (The MIT Press)
- The Mythical Man-Month: Essays on Software Engineering
- Cracking the coding interview 189 programming questions and solutions
- Cracking the Tech Career: Insider Advice on Landing a Job at Google, Microsoft, Apple, Or Any Top Tech Company
- The Art of Startup Fundraising
- Principles of Economics (6th edition)
- The E-Myth Revisited Why Most Small Businesses Don't Work and What to Do About It
- Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin)
- Reinventing Your Life: The Breakthough Program to End Negative Behavior
- Ways Of Thinking: The Limits Of Rational Thought And Artificial Intelligence
کتاب معما و چیستان
Websites and links
Dranbleiben Success Journal, a Companion for Your Goals, Concentration, Self-Reflection, Mindfulness and Mindset, A5 Format, High-quality Workmanship
Eono Diary 2021 A5 Weekly Planner from 1st January 2021 to 2nd January 2022 Diary 2021 Diary