One cannot learn everything about a app/system, but whatever you do learn, store it such that it's reusable with the least amount of revision or deliberation. "Look up and paste" should be enough. Or look up and "hire" who could do it.
The buckets
Theory - w2h, usp, relevance examples, main principles. Theoretical gotchas. Advantages, disadvantages.
Product - app flow, LLD, HLD patterns, UI, UX. Example: very malleable callback structures in React app
Practical - requirements (packages), code to be copied later, gotchas (including minor)
Note:
When writing a note page - first write it mixes(it's fine). Second step, try to separate into 2 buckets (notes + code stuff). Finally, in step 3, try to separate into the said 2.
theory <-> product and product <-> practical may get blurry.
Why do this - distilling info like this makes delegation easy. Example: sessions (in auth) are the only way to minimize damage due to cookie stealing. Be it JWT or whatever, you need a ‘nullable’ field (i.e. DB) if you want to forcibly log out the attacker.
It is important to distill this insight.
Such theory is the generalizable and reusable part of engg, and can be used anywhere else.
Does this work for hardware
Maybe It does
theory - w2h
product - common gotchas
practical - parts, integration processes.
why
One cannot learn everything about a app/system, but whatever you do learn, store it such that it's reusable with the least amount of revision or deliberation. "Look up and paste" should be enough. Or look up and "hire" who could do it.
The buckets
Note:
sessions(in auth) are the only way to minimize damage due to cookie stealing. Be it JWT or whatever, you need a ‘nullable’ field (i.e. DB) if you want to forcibly log out the attacker.Does this work for hardware
Maybe It does
theory - w2h product - common gotchas practical - parts, integration processes.