• It’s difficult to remember/know the current state of a project
  • Keep notes of the work that has been done, what is left to do
    • Create a to do list first, then proceed from that to do list
    • Update the to do list as you notice things that should be/not be done

Process

#

• Determine what was worked on last time
• Determine what needs to be worked on now (priorities)
• Establish the current state of the project
  • Look at the state of tasks in the issues tracker
  • Ask others about the status of the project

Principle: a fundamental truth or proposition that serves as the foundation for a system of belief or behavior or for a chain of reasoning.

Mindset and life

#

• Always improve.
• Always adapt.
• Accept that nothing is perfect.
• Know what you want and don’t want.
• Always remain positive.
• Surround yourself with positive people.
• Avoid spending your time on negative thoughts.
• Spend no time complaining.
• Spend time working on interesting things.
• Spend your time with happiness generators, stay away from happiness drainers.
• Always limit how much time you spend dwelling on problems and mistakes.
• Do not spend too much time thinking about hypothetical situations.
• Do not invent problems that do not need solving.
• Be proactive rather than reactive.
• Minimize your regret.
• Overcome fear by doing the thing you fear.
• Constraints force creativity.
• Stay humble; any edge you have is small and temporary.
• You define the meaning of your own life.
• Tolerating bad behavior harms the good.
• When the assumptions behind a trusted practice change, reevaluate the practice itself, not just how you execute it.
• Effort cannot close a gap between two different capacity categories.
• Feeling informed is not being informed.
• Work you did not choose takes longer because nothing pulls you through it.
• Do not set your standards by the behavior of the people around you.

Focus and attention

#

• Effectiveness over efficiency.
• Work on things that matter.
• Work on fewer things to get them to completion.
• Focus on input, not output.
• Stop starting, start finishing.
• Focus on the critical path and let minor tasks wait.
• Put your time where you get rewarded for the effort.
• Periodically measure and review how you spend your time.
• For each recurring activity, explicitly decide whether to cut, reduce, keep, increase, or add it.
• Curating the right input is not enough; ensure the consumer actually attends to it.
• When a recipient ignores information it was already given, the fix is subtraction, restructuring, or repositioning, never more volume.
• Context-switching carries a save/restore cost proportional to task complexity; chunk long-horizon work to shrink the cost of re-entering it.
• Optimize for signal, not coverage; filtering is designable where reading speed is fixed.
• Focus defends itself on work you want to do; distractions win only on work you resent.
• Treat attention, not generation, as the scarce resource.
• Parallelize generation, serialize judgment.
• The number to watch is not how much you delegate but where the freed time lands.

Decisions and prioritization

#

• Priority, priority, priority.
• Say no early and often.
• If everything is top priority, nothing is.
• When working on projects with unclear objectives, always define your KPIs.
• Order your backlog; do not merely prioritize it.
• Priority describes what a task is, not when you will get to it; separate classification from scheduling.
• Allocate capacity across priority levels rather than only ever working the single top item.
• Apply the 80/20 rule: identify the few inputs that produce most of the results and plan around them.
• Build funnels, not lists: discard most candidates at the cheap stages, confidently and without guilt.
• Prioritization frameworks are a forcing function for conversation, not an oracle; the value is in the disagreement they surface, not the score they produce.
• Every item you keep carries a cognitive tax; a small, well-ordered list beats a large one, so archive aggressively.
• Treat urgency as a hypothesis from someone with an incentive to inflate it, not as a fact.
• Filters decay; periodically re-audit what you discarded and what you kept.
• When overwhelmed, discard your list and rebuild it fresh from your own judgment of what matters most.
• Do not delay difficult decisions indefinitely.
• Prefer action over a perfect decision.
• Know when to abandon goals.
• Spend your best energy on your most important decisions.
• Batch similar decisions to stay in one cognitive mode and reduce switching cost.
• How you decide matters more than what you decide; the meta-process compounds while the specific answer does not.
• Do not relitigate settled decisions under pressure; defer to a written process.
• Convert “impossible” into a priced menu of options; never present a refusal without the cost of overcoming it.
• Invert, always invert.
  • Spend less time trying to be brilliant and more time trying to avoid obvious stupidity.
  • https://fs.blog/2013/10/inversion/
• Use analogies when reasoning about complex ideas.
  • Sometimes equivalents make it easier to reason about a problem when translated into a different domain.
• Understand the root cause; do not brute-force solutions.
• Judge changes by their consequences and reversibility, not by their category.
• Prefer feedback from reality over prediction.
• Prefer the right information over more information.
• Be adaptive to relevant change and robust against irrelevant change.
• The cost of gathering information is always less than the cost of building the wrong thing.
• Consistently wrong is worse than inconsistently right.
• Activity is not progress; do not confuse motion with movement.
• The skill is in choosing the right work, not in doing the work.
• Observed behavior reveals process better than stated process; read the artifact over the doc.
• Between two failure modes, choose the cheaper to recover from.
• Define success criteria before the experiment starts, not after.
• Truthful labeling forces truthful conversations about what you are explicitly not doing.
• A backlog is a commitment queue, not a wish list.
• Every item must trace to a parent goal; orphaned work is bloat.
• Never inflate priority labels; inflation destroys the meaning of every label.
• Distribute reversible decisions; give irreversible ones a single owner.
• When acting becomes cheap, deciding must become more careful; being wrong has not gotten cheaper.
• Start cheap and escalate on failure signals; pay premium prices only on the hard tail.
• When attempts are cheap, race them and keep the winner.
• Prefer risks you can audit over risks you must take on faith.
• Some work is faster done than delegated.

Planning and estimation

#

• Always plan, even if you don’t end up using the plan.
• Begin with the end in mind, then plan backwards.
• Define what “done” looks like before you start.
• Plan with the most realistic scenario in mind.
• Plan by preventing the worst scenarios from happening.
• Reduce risks and unknowns early in your projects.
• Separate discovery (figuring out what to do) from delivery (doing it); unrefined items do not get scheduled.
• Set a fixed time budget (appetite) that defines scope, rather than estimating an unbounded duration.
• Eliminate work by specifying better, not by running more of it.
• Separate the vision (direction) from the commitment (contract); never conflate them.
• Quantify everything you can, then measure it.
• Calibrate your estimates against your past performance.
• Keep buffers for when estimates are wrong.
• Use relative comparisons when absolute estimates are too hard.
• Prefer coarse discrete scales over false precision.
• Schedule the longest task first to minimize total completion time.
• Use robust statistics (median over mean) when measurements may be contaminated by outliers.
• Predictability is worth more than heroism.
• Track throughput and stability as independent axes; speed without stability is a house of cards.
• Fast feedback beats comprehensive feedback.
• Divergent estimates signal unspecified scope, not bad estimators.
• The serial fraction of your process caps all parallel speedup.
• Shrink long-term problems into chunks you can start and finish quickly.
• Technical debt has no natural advocate; fund it by fixed allocation.
• Manage the outcome, not the activity; effort signals die when execution is cheap.
• A delegable outcome names what becomes true, how it will be checked, and what it may cost.
• When exploration is nearly free, the failure mode is premature documentation.

Leverage and compounding

#

• Separate activities into compounding and depreciating; protect compounding work and delegate or automate depreciating work.
  • Use the two-year test: ask whether continuing an activity leaves future you more or less valuable.
  • Overweight durable activities; underweight ephemeral ones.
• Invest effort where the blast radius is largest, not where the noise is loudest.
• The constraint never disappears; it just moves.
• Move with the bottleneck as it shifts.
• The binding constraint is usually the layer you are not looking at.
• Continuously optimize.
• Periodically simplify; do not only add.
• Have people depend on you less and less.
• Avoid repeating yourself constantly.
• Prefer standard solutions for solved problems; spend your energy where it differentiates.
• Anything that scales with size must be optimized to grow slower than size.
• Make yourself unnecessary at the layer you occupy.
• Improving anything other than the binding constraint is theater.
• Automation relocates work to a different layer; it does not remove it.
• Per-unit effort cannot match entropy that is produced faster than you can process it; operate on the system that produces the units, not the units.
• Specification compounds; review is a non-compounding backstop.
• Delegation is not free even when the delegate is free; delegating a compounding activity forgoes the practice that built the judgment to evaluate it.
• Produce work that is cheap to accept, not merely plentiful.
• Unaccepted work is inventory; it rots the longer it waits.
• Discipline buys a constant factor; only replication buys a curve.
• Point surplus capacity at lightening the constraint, not at feeding it.
• When you cannot add capacity at the bottleneck, choke the demand arriving at it.
• The durable asset is the system that produces the work, not the work it produces.
• Every check you write is attention you never have to spend again.
• Audit the rules rather than each output; a bad rule produces bad outputs forever.
• Promote experts from reviewing outputs to owning the rules.
• The line between compounding and depreciating moves; re-sort it regularly.
• Delete scaffolding when the capability it propped up arrives.

Learning and knowledge

#

• Learn new things everyday.
• There are no shortcuts to mastery; learn the fundamentals.
• Specialize first, then generalize.
• Deliberately practice the things you are weak at.
• Study failures, not just successes.
• Answering your own questions exposes what you do not yet understand.
• Learn from prediction errors (surprise), not just from outcomes.
• Build the mental model before you need it under pressure; you cannot grow one on demand.
• Reading is cheaper than writing; it transfers everywhere and builds the model without demanding fluency.
• Survey many sources in parallel, not sequentially, to surface cross-cutting patterns.
• Consume on demand, not on schedule; knowing where to find something when you need it beats knowing it now.
• Every new source or commitment should displace an existing one, not stack on top.
• Copy, transform, combine.
• Model those who have already achieved what you want and identify the gap between your state and theirs.
• You cannot prompt a mental model into existence under time pressure; foundation knowledge cannot be acquired just-in-time.
• Honest failures teach; soft failures train nothing and accumulate until they become outages.
• Transfer reasoning, not conclusions; your map expires, the navigation does not.
• Parallel consumption surfaces patterns that sequential decay hides.
• The last non-delegable job is articulating taste, what the automation is for.
• Only people can tell you that you are wrong; every other system replays decisions you already made.
• Judgment is grown by contact with consequences, not transferred by explanation.
• Judgment does not persist without exercise.
• Automating junior work cuts the input to the pipeline that produces senior engineers.
• When automation removes the struggle, the learning must become deliberate.
• When automation removes a learning channel, rebuild it deliberately off the critical path.
• Generation is free; understanding is not, and it is the part that appreciates.
• Maintain living knowledge, not snapshots; put recurring questions on a loop.
• A strong practice preference is scar tissue from a real failure somewhere else.
• Study how others reason about problems, not just their solutions.
• Much of what we call judgment is undocumented procedure, discoverable by attempting to automate it.

Memory and notes

#

• Always write down why.
• Externalize your memory: write down what is in your head.
• Capture first, organize later; keep a low-friction buffer separate from structured notes.
• Notes you never review are wasted; build a review loop into your information system.
• Memory of past interactions is signal to be retained, not bias to be eliminated.
• An unwritten decision’s half-life is one new person; write decisions down to make them travel.
• A meeting that ends without a written decision will have to be held again.
• Record rationale at decision time; a decision record written after the fact is fiction.
• A wrong claim in a durable document grows authority every day it survives.

Communication and writing

#

• Do not engage in fruitless debates or one-sided confrontations.
• It is more important to have support for your ideas than for them to be perfect or right.
• Use progressive disclosure: lead with a summary, offer detail only on request.
• Writing does not degrade as it passes through people; speech does, so write decisions down.
• Make stakeholders co-authors of decisions so they defend them rather than overturn them.
• Distribution is half the work of production; effort spent producing is wasted without matching effort on distribution.
• Be a source, not an echo.
• Proof of work is the signal that survives: show costly effort, not assertion.
• Narrow beats broad; specificity is what cannot be synthesized.
• Stories transfer; advice without context does not.
• Candor earns authority; admitting error builds trust faster than defending perfection.
• A fast, clear no is a kindness; silence is the answer that swells the queue.
• When instructions fail, the fix is usually subtraction; over-specification is the common decay.
• Writing exposes the gaps that live conversation silently repairs.
• Arrive with proposals others can amend, not verdicts they can only review.
• Answer the argument, not the volume.
• Demonstrate the hardest case, not the happy path; edge examples carry the most information.
• The judgment behind the words is the product; the prose is the cheap part.
• Fluency without experience produces echo.
• Factor ideas like code; extract and reuse instead of rewriting duplicates.
• Write ideas self-contained so they survive outside their original context.
• Volume makes you more of the flood, not more visible within it.

Systems and automation

#

• Have a structured process for everything you do that is written down and updated as it changes.
• Use checklists for routine critical tasks.
• Establish a manual process before automating it.
• When you repeatedly catch the same issue, automate the check.
• If you can describe a problem precisely, you can automate it.
• Engineer workflows around your own cognitive limits instead of trying to power through them.
• Use tools to amplify your judgment, not replace it.
• Distinguish between friction that wastes time and friction that prevents mistakes.
• The metric you optimize determines the system you get.
• Encode your judgment into the layer everything passes through; your leverage scales with encoded surface area, not hours.
• Encode standards as gates and defaults, not as opinions; a standard runs whether or not anyone agrees with it.
• Make the right behavior the path of least resistance: tax what you want less of, subsidize what you want more of.
• Convert preferences into machine-checkable invariants where possible.
• Grant autonomy gradually, based on accumulated evidence of reliability, not optimism.
• Make systems slow learners, not judges; require accumulated evidence before changing state.
• Bound autonomous systems on two independent axes: cost (budget) and capability (least privilege).
• Make operations idempotent so they are safe to re-trigger.
• Make failures visible; silent failures are worse than no automation at all.
• Design systems so that gaming them produces the behavior you wanted anyway.
• A system people do not trust is a system that does not run, regardless of how well it verifies.
• Make every automated decision legible: which rule fired, what it checked, who owns it.
• Keep a kill switch; the cost of not having one is an unconstrained runaway.
• When a measure becomes the target, it ceases to be a good measure.
• Drift rate must stay below the cleanup rate for a system to stay net-positive over time.
• Triage before review: decide whether something deserves your attention before you evaluate it.
• Use AI to triage AI.
• Variability is the enemy of scale.
• A system is a decision made once.
• A process that only works when nothing ever goes wrong is not a process, it is a countdown.
• An overloaded gate fails silently: rubber-stamped work feels reviewed without being reviewed.
• A queue grows without bound whenever intake outpaces processing.
• Every fixed cost at a gate incentivizes batching, and batching makes changes riskier.
• A human gate is also a human attack surface.
• Never let a system approve changes to itself; someone must audit the auditors.
• Either read a change deliberately or merge it on signals; do not fake the reading.
• Measure the gap between what a process claims to do and what its participants actually do.
• Every approval gate that adds no information is pure delay.
• A process earns its keep only if it forces thinking people would otherwise skip.
• One tool doing many jobs does each poorly; give each property its own dedicated check.
• Make critics adversarial and single-purpose: reward finding a failure, never approving.
• Defend a process with production outcomes, never with “a human looked at it”.
• Separate deciding from executing, with different privileges, so neither runs away.
• Autonomy over an enumerated, closed list is auditable; autonomy over open-ended judgment is not.
• Apply the cheapest filters first; sort with cheap signals before spending deep attention.
• Feed every manual correction back into the artifact that produced it.
• Keep an exit from every dependency; switching should be a configuration change, not a rewrite.
• Scaling a flawed system repeats the flaw in every instance at once.

Software and code quality

#

• Every line of code is a liability.
• Invest in quality early because it compounds.
• The quality of the output is bounded by the quality of the input, context, or foundation that produced it.
• Front-load human effort where mistakes are cheapest to fix; the later you catch a defect, the more expensive it is.
• When a class of problem recurs, fix the source once so the correction compounds across every future occurrence.
  • Fix at the source once, or fix at the symptom forever.
• Make quality a property of your constraints and system, not of individual reviewers.
• Separate the valuable act from the gating ritual; satisfy the function rigorously and let the form follow.
• Separate execution from review to avoid bias.
• When a reviewer shares the generator’s blind spots, agreement proves almost nothing; verify with independent signals.
• Use structurally diverse verification methods so failures do not correlate.
• Do not trust the output; trust the verification system behind it.
• Most production failures occur at integration points, not within components.
• Isolate components with different scaling characteristics so each can scale independently.
• Make coordination optional, not mandatory; components should function independently.
• Distinguish high-interest debt from low-interest debt; treat them differently.
• Defects flow downstream and multiply; fixes must flow upstream to compound.
• Fix the process, not the product.
• When the builder is a machine, code quality is bounded by specification quality.
• Move verification upstream to the specification; review is the latest, most expensive stage to catch an issue.
• Accountability lives upstream in the decisions that guided the work, not in whoever scans the diff at the end.
• Write the verification and acceptance criteria before the code exists.
• Right context, curated and ordered, beats more context; attention dilutes.
• Implicit assumptions are the most dangerous context gaps because you do not notice them.
• The value lives in the tails, not the mean; average-case metrics hide tail erosion.
• Keep the oracle separate from generation, and broader than the happy path.
• Subjective requirements are discovered by contact with the artifact, not enumerated in advance.
• For generated artifacts, the prompt is the source code.
• Maintain code as if no author can be asked.
• Optimize code for readability; it is read far more often than it is written.
• Concentrate what changes often; let what rarely changes be broad.
• Verification speed sets the ceiling on safe generation speed.
• Treat every passing test suite as a claim about coverage, not proof of correctness.
• Split verification (built right) from validation (right thing); they need different stages and owners.
• Review what a change does, not what it looks like.
• As generation gets cheaper, spend review on intent and substance, not style.
• Make reversibility a structural property of how changes are made, not a review-time judgment.
• Gate changes by blast radius and reversibility, not by artifact type.
• Write the contracts before fanning out workers; fixed interfaces make integration mechanical.
• Trust comes from attack, not inspection.
• Understand opaque artifacts by what they do, not what they are.
• You can own only as much code as you can understand.
• Keep the spec, delete the code.
• If you cannot answer why-questions without the tool, you generated the artifact rather than built it.
• Bad output is the truest signal about where the input is incoherent.

Teams and collaboration

#

• Structure (tooling, architecture, repository layout) should follow the coordination and trust structure, never lead it.
• The right size for any unit is the smallest that can own a coherent domain end-to-end.
• When something belongs to everyone, it belongs to no one; diffuse ownership causes decay.
• Every healthy system needs both entropy generators (visionaries) and entropy controllers (stewards).
• There is an optimal team size; beyond it, adding people decreases output.
• Push decisions down: let workers resolve their own ambiguities and escalate only above a defined threshold.
• Consistency beats optimality for conventions and practices.
• Treat practices and opinions as hypotheses to test, not identities to defend.
• Never discourage anyone who continually makes progress no matter how slow.
• Fix the system, not the person; structure determines behavior.
• Culture must be actively transmitted during growth; it dilutes by default.
• During a crisis, one person owns the response; everyone else supports.
• During incidents, diagnose first and assign blame never; save blame for the post-mortem.
• Hiding a boundary is not the same as removing it.
• Onboarding must scale sublinearly; keep the ratio of onboarded to onboarders above 1:1.
• Create new teams when the current team is at capacity, not when the project is already late.
• A team moves at the pace of its least coordinated member.
• Trust is the strongest predictor of team performance; a trusting team of mediocre engineers outperforms brilliant engineers who do not trust each other.
• Treat resistance as information; skeptics map where your system is weakest.
• The real architecture is the role structure of the contributors, not the dependency graph of the packages.
• Every harsh rule is a scar on reviewer time; trace each rule to the wound it prevents, and delete the ones that have none.
• The first disagreement a group resolves sets the template for every disagreement that follows.
• A team’s standard is set by whatever ships first, not by what it agrees is best.
• Absence of objection measures busyness, not consent.
• Name the cost of what you absorb, or the team learns absorption is free.
• People choose deferred shared costs over immediate personal ones, even when the deferred cost is larger.
• Tolerating post-decision overrides turns the process into veto by the most stubborn.
• A team directed by one person has one person’s judgment, no matter how many people it employs.
• Hoarding decisions manufactures the incompetence that justifies hoarding them.
• Name norm-violating behavior early, before it calcifies.
• Judge people by their total cost, not their visible output.
• Never reciprocate aggression; matching tone turns a disagreement into a status fight.
• Measure knowledge risk by re-acquisition time, not by how many heads hold the system.
• Treat planned absences as load tests of whether the system survives without its owner.
• Add a human when the context no longer fits in one head.
• Hire for where a person will disagree with you, not for how much they produce.
• The appearance of specialists marks the point where generalists can no longer cover the surface.
• Delegate execution without delegating ownership.
• A handoff is complete when the receiver can explain the work, not when the artifact runs.
• No owner, no merge.
• Before removing a role, name its function; the function survives the role.
• When producing is nearly free and owning is not, people produce more than they will maintain.

Strategy and business

#

• When you outsource an outcome, you also outsource the decisions that produce it.
• Invest during good times so you can survive the bad; maintain a consistent strategy through both.
• Compete on what cannot be cloned.
• When everyone can build anything, deciding what to build becomes the differentiator.
• Low barriers to entry drive margins toward zero.
• When the cost to produce falls below the cost to consume, the consumer becomes the bottleneck.
• For an automated workforce, the evaluation pipeline is the critical asset, more than the agents it tests.
• Coherence is a job that must be owned, not a byproduct of good local decisions.
• A feature is a probe, not a deliverable.
• Trust is the slowest thing in a product to reproduce.
• Trust is the only distribution channel that does not saturate.
• Sell the outcome, not the tool.
• When everyone is fast, advantage shifts to the quality of the feedback signal.
• Make whoever creates the volume carry the cost of making it reviewable.
• When the cost to create falls below the cost to review, review becomes the resource to defend.
• Put the cost back where the benefit was captured.
• Build alternatives; dependence is what gives aggression its leverage.
• When the layer you mastered commoditizes, move your value up a layer.

The onboarding process described here is specific to a software engineer joining a tech company. While some/most of the items may still apply to any job where you mainly work from a computer, the assumption will be that you develop software as an individual contributor.

Week 1

#

• Setup laptop
• Access to slack
• Access to zoom
• Setup calendar reminders
• Initial meeting with buddy
• Access to git central repository
• Installation of development tools/languages
• Request software licenses
• Access to CI/CD
• Find where task management is done
• Find the documentation to build projects
• Connect 1 on 1 with each member of the team
• Meet with manager 1 on 1
• Define a 30-60-90 days plan with manager
• Verify access to various systems (SSO, code repository, insurance company, payroll company, etc.)
• End of week meeting with buddy

Week 2

#

• Setup and run the one step build process
• Determine how are features/tasks prioritized, who prioritizes features/tasks
• Review the team documentation
• Review team practices/processes documentation (code style, code review, standups, planning, retrospective, demos)
• Review common vocabulary, terminology, glossary documents
• First PR + code review
• Review the career ladder of the position

Week 3

#

• Review user definition, use cases, requirements
• Read prior team meetings notes

Week 4

#

• Identify how deployments are done
• Review the team roadmap
• Determine where I can have the biggest impact
• Determine a timeline where I’ll have reached my 80/20 at the company
• Determine the maturity of existing projects
• Determine how fast can we iterate on certain aspects given the team/company composition
• Identify the core/principal/staff contributors and their contributions
• Review the architecture of the system
• Review the database architecture
• Learn about “how we got to this point”
• Determine whether the product is a monolith or micro-services
• Identify which (3rd party) tools are used by the team/company
• Determine the portfolio of STARS situations of the team/company
• Determine a rough estimate of the number of people in the different organizations
• Connect 1 on 1 with important collaborator in other teams
• End of first month meeting with buddy
• First month performance review with manager
• Informal 360-degree review with manager and peers on adaptation
• Month 1 job satisfaction review

Week 8

#

• Team interaction diagram
• Month 2 job satisfaction review

Week 12

#

• Month 3 job satisfaction review

Notice/Advisory: I am not an accountant nor a day trader. The following is not advice, only notes I’ve taken for myself. Content may be wrong or inaccurate. Use at your own risk.

The following is a list of items and things to think about if you would like to be a day trader. I wrote it with the intent of identifying what were the requirements to be a day trader and what would be the impacts of being considered as one vs being an investor.

• Basics
  • Computer or phone
  • Internet
  • Broker
  • Money
• Do not do day trading in your TFSA/RRSP/RESP accounts
• Your gains/losses will either be categorized as capital gains (50% taxable) or business income (100% taxable) based on how you trade. In any case, since this is a day trading article, you can assume this will be business income. Here are some properties taken into account
  • Volume and frequency of trading
  • Length of ownership of securities
  • Type of securities owned
  • Your profession and level of stock market knowledge
  • If trading is your main source of income or substantially supplements it
    • Here it is not clear what substantially represents. I would estimate that anything below 25% of your non-trading income isn’t substantial.
• If you want to day trade, you will want to have access to level 2 data, which costs money depending on your broker
  • Some brokers will reimburse your data package fees if you spend a certain amount of money on commissions each month. For example, Questrade data package will cost you 90$/month, but if you spend over 400$ on commissions this fee will be rebated.
• You do not need to register with the government or any agency
• You do not need a minimal amount of money, although it is suggested to have a few thousands dollars otherwise you will not make a lot of profit daily and your commissions fees are likely to eat any profit you will make
  • Some brokers have minimum account balance
• You have a trading strategy
• Track your transactions
  • Time of entry/exit
  • Cost at entry/exit
  • Symbol/Ticker

References

#

• https://investingbasics.ca/guides/day-trading/#2--how-to-start-day-trading-
• https://www.wealthsimple.com/en-ca/learn/how-to-start-day-trading

• Decide what habit you want to have and record why you want this habit
• Start with the smallest amount of effort possible
• Increase the amount of effort regularly until you reach the desired amount of regular effort
• Track your habit in a habit recording system such as Loop Habit Tracker
• Review on a regular basis (monthly) whether you want to keep this habit or not
  • If you decide not to keep the habit, record why you decided to drop the habit such that if you decide to pick it up again, you can determine whether you might end up dropping it again.
• It’s not a problem if you miss doing your habit, just make sure to do it when you’re supposed to

My habits

#

Daily

#

• Daily planning
• Daily review
• Eat/Drink
• Shower
• Wash dishes
• Cook
• Exercise
• Read
• Watch TV shows
• Floss
• Brush teeth

Weekly

#

• Weekly planning
• Weekly review
• Wash clothes
• Clean apartment
• Buy groceries

Monthly

#

• Monthly planning
• Monthly review
• Pay bills

Yearly

#

• Yearly planning
• Yearly review

My prompts

#

• Daily planning at 10 am
• Weekly planning on Mondays
• Monthly planning on the first of the month
• Pay credit card on the first of the month

My prompt sources

#

• Google Keep
• Google Calendar
• Google Mail
• Slack
• Daylio
• Notion

• List all the features you would like to develop
• Define an appetite for the task (day, week, month, quarter)
• Identify the features where the appetite differs between individuals and discuss them to reach consensus
• Define the roles necessary to complete the task
• Identify dependencies between features
• Categorize the dependencies
  • Soft: somewhat depends on this other feature but isn’t blocked by its absence from the codebase
  • Hard: depends on this other feature and is blocked by its absence from the codebase
• Prioritize the features
  • Use the RICE framework
  • Priority can also be skipped if using ROI as prioritization metric
• Estimate the value of a features in dollars
• Calculate a ROI (return on investment) as the estimated value of the feature divided by the defined appetite
• Order tasks according to dependencies and ROI

• Start the longest tests first. If you have for example 2 tests, a short one and a long one, the long one will be the sequential bottleneck. If you have many additional short tests, they will run in parallel to the longer one. If you have 2 workers, 1 will be dedicated to the long task while the other will process many of the short tests. If the total execution time of the short tasks is greater than the longer task then the total execution time will be at least the duration of the long task.
  • If we were not to schedule the longest tests first, we run the risk of running many short tests on a worker and then running the longest test, which may be suboptimal.
  • As you accumulate many short tests this issue is mitigated. However you have to be careful of distributing your longest tasks on separate workers as much as possible.
• If you know the exact duration of a test (or an approximation of it, given a desired quantum), determine if you can solve the scheduling problem in a reasonable amount of time such that solving the scheduling and running the scheduled tests takes less time than running the tests.
• From the standpoint of execution, we will prefer to have the best response time possible (i.e., run the shortest tasks first to get most of the tests executed as soon as possible).
• As you have many short and long tests, it may make sense to run all the short tests first and keep all the long tests for the end, ignoring the heuristics that suggests running the longest tests first.
• Other important consideration when running tests are shared environments/resources between tests. If those take a non-neglectable amount of time to setup/teardown and could be reused, it may be beneficial to group such tests on the same worker in order to avoid paying the cost of setup/teardown.
  • Setup/teardown duration should be recorded and be associated to each test.
  • Some system have different types of setup/teardown: global, per class/module/scope. Being able to be aware of whether the test system will need to re-run a set of setup/teardown functions may help with scheduling the tests.
• While we may be collecting test duration data, it is important to be aware that this data may end up being tainted if used in a continuous integration system. What this means is that we may sometimes record durations that are out of the ordinary due to a bug in the code, or because the tests execute on different hardware.
  • To mitigate this issue we may use different approaches such as using the median of the recorded values (which is more robust to outliers than the mean), use a percentile (such as 95%) to determine the expected duration, record the duration of successful tests separately from failed ones, record tests in separate buckets defined by the user (e.g., defined on the CPU spec used to run the test), etc.
• If the number/list of tests hasn’t changed since the last run, it would also be beneficial to store the computed schedule so that it is only computed once and reused many times, which is a common use case. The only time you may not want to do this is if computing the schedule is very cheap and represent a neglectable amount of time in the overall testing process.

Example use case - pytest-xdist

#

• By default pytest does not store any prior test duration so we would have to estimate that all tests are of equal duration.
  • As we run tests, we may start to collect information about the duration of parameterized tests. This may serve us to determine whether the parameterized test has the same duration over different set of parameters and serve as a base to start providing estimates for the remaining parameters combination of this test.
  • A system similar to the cache provided by pytest may be used to record the duration of tests

Concepts

#

• Scheduler: responsible for taking a set of tests with meta data and scheduling them (i.e., determine in which order they will be executed).
• test: the unit of code to execute.
• test duration: the duration of a test. Test duration may be represented as a distribution since tests generally do not complete in an exact and fixed amount of time.
• test unit: a collection of tests that we can assume as being the same test (e.g., parameterized tests).

References

#

• https://en.wikipedia.org/wiki/Scheduling_(computing)
• https://en.wikipedia.org/wiki/Queueing_theory
• https://en.wikipedia.org/wiki/Queuing_Rule_of_Thumb
• https://docs.pytest.org/en/latest/cache.html

• Do you understand what is at stake?

• Do you know what already exists?

• Can you take an informed decision?

• What did you consider during your decision?

• What are your unknowns (things you’d need to know before your can make a decision)?

• Do you have experience with the problem which needs a decision?

• Indicate who has the most expertise to make the decision.

• You should be allowed to cast a vote if the decision will impact you. If it doesn’t (i.e., you’re not a stakeholder), your vote will not be counted towards any option.

Let’s start by saying I’m not suggesting you read a full book per day. What I’m suggesting is to read at least a few pages of a book per day, reading a variety of books over the course of a week.

For a while I used to start book and finish them before starting another one. I’d allow myself to read a fiction book and a technical book at the same time, but not more than that. The idea was that by reading more than one of each my brain would have trouble with context and information retention.

I’ve recently decided to switch this approach. The main reason was that I found myself spending too much time reading articles online that I thought didn’t bring me much value over time. I always thought books were more valuable, but their biggest problem was that it required a good amount of time involvement for the value to kick in.

Just like there are two strategies in learning systems, exploration and exploitation, I decided that leaning more on the exploration side might be more useful. In learning theory, “exploration” refers to trying new things or information, while “exploitation” involves deepening knowledge in known areas. Instead of spending hours on the same book over a short period of time (1-3 months), I would instead read bits of many books at once.

Here are the benefits I’ve observed through this approach:

It’s easier to identify similar sources. I would read a few books on a similar topic, and of course they would all cite the same sources. The difference between processing all those books in parallel instead of sequentially is that you notice the pattern of reuse more clearly. When reading the books sequentially, what happens is that this type of information decays over time. We start to forget what the last book was referring to, so that the next book appears to have new references.

Similar ideas can be identified and speed up reading. As you identify the same ideas in different books, instead of reading the arguments careful in each book, the best argument is read thoroughly and the others quickly scanned for additional information.

You are exposed to more variety. Some people get topic fatigue, which is that you get bored of reading on the same topic. Reading on different topics avoids this issue while also stimulating you to think about many topics. This is a great way to sometimes make connections between unrelated topics.

Overall I’ve been very satisfied with this experiment and I’ve been doing it for over 4 months now. I highly recommend it if you have a large list of books you haven’t started yet. See my article How to prioritize which book to read to help you organize your reading.

Tesseract (an open source OCR engine) supports a TSV format as output. I looked online for some documentation about the columns but couldn’t find anything, so I looked at the source code.

Here is a summary description of each column, what they represent, and the range of valid values they can have.

• level: hierarchical layout (a word is in a line, which is in a paragraph, which is in a block, which is in a page), a value from 1 to 5
  • 1: page
  • 2: block
  • 3: paragraph
  • 4: line
  • 5: word
• page_num: when provided with a list of images, indicates the number of the file, when provided with a multi-pages document, indicates the page number, starting from 1
• block_num: block number within the page, starting from 0
• par_num: paragraph number within the block, starting from 0
• line_num: line number within the paragraph, starting from 0
• word_num: word number within the line, starting from 0
• left: x coordinate in pixels of the text bounding box top left corner, starting from the left of the image
• top: y coordinate in pixels of the text bounding box top left corner, starting from the top of the image
• width: width of the text bounding box in pixels
• height: height of the text bounding box in pixels
• conf: confidence value, from 0 (no confidence) to 100 (maximum confidence), -1 for all level except 5
• text: detected text, empty for all levels except 5

Here is an example of the TSV format output, for reference.

References

#

• https://tesseract-ocr.github.io/tessdoc/Command-Line-Usage.html