Knowledge Tree
A growing tree of ideas, books, and engineering principles. Each fruit is an insight — hover to peak, click to read.
20 insights · 4 branches · always growing
You do not rise to the level of your goals, you fall to the level of your systems. Goals are about the results you want to achieve; systems are about the processes that lead to those results. Focus on daily systems rather than end results — small habits, big changes.
habits, productivity, systems thinking
The ability to perform deep work is becoming increasingly rare at exactly the same time it is becoming increasingly valuable. The few who cultivate this skill will thrive. One fully focused coding session beats three hours of half-working, half-scrolling.
focus, deep work, deliberate practice
Don't leave "broken windows" (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. Neglect accelerates software rot faster than any other factor. A TODO comment that lives too long becomes permanent — fix it now or document it clearly.
clean code, engineering discipline, refactoring
Code is read far more often than it is written. A well-named variable, function, or class is worth a paragraph of comments. Clarity is kindness to your future self and your teammates. Renaming one vague variable to a clear name is the most valuable refactor I have ever done.
clean code, readability, naming
Curiosity is more durable than expertise. Experts stop asking "why"; beginners ask it constantly. The willingness to not know — and to keep exploring — is the real competitive edge. Every time I start learning something new, I remember the feeling of writing my first Hello World.
growth mindset, curiosity, learning
System 1 operates automatically, quickly, with little or no effort. System 2 allocates attention to deliberate mental activities. Most of our errors come from trusting System 1 where System 2 is needed. When debugging, System 2 is the one that actually solves the problem — System 1 just guesses.
cognition, decision making, mental models
The process of learning matters as much as the outcome. Writing down what you struggled with, what clicked, and what you would do differently transforms experience into compounding wisdom. This knowledge garden is the proof — I write things down so I never forget.
reflection, journaling, growth
A good architect maximizes the number of decisions not made. Keep details — frameworks, databases, the web — at the edges, behind boundaries, so the core business rules stay independent and testable. Separating business logic from the framework let me swap the DB from Oracle to Postgres without touching the core.
architecture, design, decoupling
Refactoring is a series of small behavior-preserving transformations. Each step is tiny, so if something breaks you know exactly where. The discipline is what makes large changes safe. Small commits + green tests after every step = never fearing a refactor that "breaks the whole week".
refactoring, testing, discipline
People lie to be nice when you ask about hypotheticals. Ask about specifics in their past instead: what they did, what it cost them, what they tried. Facts beat opinions when validating an idea. In user interviews, "when did you last run into this problem?" beats every hypothetical question.
product, user research, validation
Not everything on the screen is equally important. Use size, weight, and color to establish a hierarchy so the user knows what to look at first, second, and third — de-emphasize to emphasize. Dimming the secondary text usually works better than making the primary text bolder.
ui design, hierarchy, typography
Generous spacing makes interfaces feel calm, premium, and easy to scan. Crowding elements together to "fit more" usually makes everything harder to use, not easier. Whenever a layout feels cramped, I add padding before thinking about adding anything else.
ui design, spacing, clarity
You don't have to be a genius to share what you learn. Document the small steps publicly; the trail of breadcrumbs is what helps others — and your future self — and builds your reputation over time. Blogging about one tiny bug helped a stranger from Google — and helped me remember the fix.
sharing, creativity, building in public
When code is hard to test, that is a design smell, not a testing problem. Writing the test first forces small, decoupled units with clear inputs and outputs. If a function is hard to test, it is almost certainly doing too much.
testing, tdd, design
Sustainable output comes from rhythm, not constant grind. Sleep, walks, and stepping away are where the subconscious solves the problems the conscious mind got stuck on. The fix for the hardest bug usually arrives in the shower, not while staring at the screen.
rest, sustainability, wellbeing
Instead of a packed to-do list, pick a single highlight — the one thing you want to make time for today. It gives the day a focus and a sense of accomplishment that busyness never does. One clear highlight each morning keeps me from ending the day feeling busy yet empty.
focus, time management, intention
Every component should run with the minimum permissions it needs and nothing more. Most breaches escalate through over-granted access that nobody ever revisited. A service account made "admin for convenience" today is tomorrow's vulnerability.
security, access control, defense in depth
Reusing the same patterns, spacing, and components means users learn your interface once. Every inconsistency is a tiny new thing the brain has to decode. A small but consistent design system is worth more than many beautiful one-off screens.
design system, consistency, ux
A 1% improvement every day is barely noticeable in a week, but it is nearly 38x over a year. The same compounding applies to learning, relationships, and reputation — quietly, then suddenly. Studying 30 minutes a day for a year took me further than any end-of-term cramming sprint.
compounding, consistency, growth
DRY: every piece of knowledge must have a single, unambiguous, authoritative representation within a system. Duplication is not just typing twice — it is two things that must change together and won't. The most annoying bugs come from the same rule copied in two places that quietly drift apart.
dry, maintainability, clean code