Absolutely — great job finishing Problem Solving (2nd Edition) by S. Ian Robertson. It’s a dense book but one of the most practical introductions to how humans actually solve problems, why we sometimes fail, and how to deliberately improve.
Below is a structured refresher plus concrete, actionable takeaways tuned for your personal learning style (you tend to like systems, breakdowns, templates, right-brain/left-brain alternation, and deep skill-building).
Robertson’s core premise:
Problem solving is a skill built from understanding how minds work — not just logic, but perception, memory, heuristics, biases, creativity, and metacognition.
He blends cognitive psychology with practical strategies and research findings. The big themes:
How you frame or represent a problem influences how solvable it becomes. Two people with equal intelligence produce very different results depending on how they structure the problem.
Memory stores patterns, but the mind also “reconstructs” rather than retrieves — which leads to traps, assumptions, and biases.
We rely on shortcuts (hill climbing, working backward, means-end analysis). These are incredibly useful but also limit creativity.
Insight problems (“aha!” moments) often require stepping outside habitual frames. Thinking styles can be intentionally shifted.
Experts aren't faster thinkers — they have richer, more organized mental representations (schemas). This drastically improves accuracy and speed.
Monitoring your own strategies, failures, and progress teaches your brain to correct mistakes automatically.
The way you encode a problem determines whether a solution is possible.
- Good representation: clarifies constraints, goals, operators, and subgoals.
- Bad representation: traps you in unproductive assumptions (“functional fixedness”).
Examples from the book:
- The candle problem (functional fixedness).
- Nine-dot problem (assumption that the line must remain inside an imaginary square).
Relevance to you: You do lots of system design, programming, and homelab architecture — these are representation-heavy domains. Shifting interpretations leads to dramatically better solutions.
Three major heuristics Robertson emphasizes:
-
Hill climbing: Always take steps that appear to move closer to the goal. Good for optimization; bad for problems needing backward steps.
-
Means-end analysis: Identify gaps between current state and goal, then reduce each gap. Excellent in engineering and coding.
-
Working backwards: Start from the goal state and reverse-engineer. Useful for debugging and planning infrastructure or complex refactors.
Insight problems often require:
- Breaking assumptions
- Re-representing the problem
- Changing the “search space”
Robertson’s studies show that insight often appears when the brain stops fixating and starts associating.
Practical implication: You need alternating focus mode and diffuse mode — something you already do with your “creative right-brain breaks.” Keep doing that.
Your brain:
- reconstructs memory
- fills in gaps
- is vulnerable to priming
- requires chunking for complexity
This explains why expertise is largely organization of knowledge — not just adding more of it.
One of the book’s big research-backed findings:
You don't transfer skills unless the structure of the new problem resembles previous practice.
This means:
- generalized problem-solving “power” is rare
- domain-specific practice is essential (coding problems → better at coding; math problems → better at math; etc.)
The best solvers:
- track errors
- adjust strategies
- reflect on what worked and what didn’t
- consciously select heuristics
You already lean toward structured systems — metacognitive routines amplify that.
A refined and expanded guide you can use daily.
Below are actionable habits and strategies organized into clear sections. You can treat this as a personal “problem solving operating system.”
Your brain defaults to assumptions — Robertson shows this is the #1 cause of failure. So train yourself to deliberately build a problem model before doing anything else.
-
Goal state: What exactly must be achieved?
-
Current state: What do I know? What is observed?
-
Operators: What actions/techniques/tools are available?
-
Constraints: Which are real? Which are assumptions?
-
Unknowns: What variables or data do I not have yet?
-
Alternative forms: Can I restate this visually? Mathematically? Stepwise?
-
Test for hidden assumptions:
- “Am I assuming something is fixed when it isn’t?”
- “What if I remove this rule?”
Homelab problems, Kubernetes config, network issues, debugging code, and even math problems all benefit massively from tightening the representation before you start.
Different problems require different heuristics; using the same one repeatedly leads to fixation.
Keep this nearby when working:
- Means-end analysis: Identify gaps and systematically reduce them.
- Working backward: Start from the desired end state. Great for debugging.
- Generate-and-test: Brainstorm multiple paths; test small steps quickly.
- Constraint relaxation: What if X isn’t actually required?
- Analogy/transfer: What similar problem have I solved before?
- Diagram/visualization: Turn abstract problems into shapes or diagrams.
- Divide-and-conquer: Split into smaller subproblems.
- Counterfactual: “What would I do if I had to solve this in 10 minutes?”
- Deliberate brute force: Useful for small combinatorial problems.
Your brain is analytical, but tends to use means-end analysis and direct logic. Adding variation prevents rigid thinking and improves creativity.
Expertise = building reusable cognitive “units” called chunks or schemas.
- Identify recurring patterns in your work.
- Document the pattern, when it applies, pitfalls, and examples.
- Practice variations of the same pattern to strengthen it.
- Use small “drills” for the most important patterns.
- Network schemas: DHCP, DNS, mDNS, interfaces, Netplan patterns.
- Kubernetes schemas: bootstrap steps, PV/PVC patterns, CNI configs.
- Math schemas: factoring, substitution, limits, algebraic transformations.
- Programming schemas: OOP patterns, FP combinators, container setup patterns.
When chunks accumulate, you solve new problems faster because you recognize the structure instantly, rather than reasoning from scratch.
Insight emerges when the brain breaks fixation.
Trigger “Diffuse Mode”:
- take a short walk
- switch to a different mental task (coding → piano, math → drawing)
- sketch the problem abstractly
- restate the problem with different constraints
- revisit the problem after a short break
- Ask: “How would a complete beginner view this?”
- Imagine explaining the problem to a child.
- Reverse the problem (“What problem would have this as a solution?”).
- Change modality: text → diagram → equation → pseudocode.
Insight = jumping to a more productive representation.
Group items into meaningful clusters. Example: When studying math, group transformations (e.g., substitution, factoring, completing the square).
Link new knowledge to:
- your homelab
- a story
- an example
- a personal experience
- another concept you know
Elaboration increases retention dramatically.
Combine verbal + visual representations. Use diagrams, timelines, boxes-and-arrows, etc.
Use the optimal sequence:
Day 1 → Day 3 → Day 7 → Day 14 → Day 30
Works beautifully for:
- math skills
- programming concepts
- language syntax
- system architecture patterns
- troubleshooting steps
Transfer only happens when two problems share the same underlying structure. To grow your “mental library,” explicitly search for structural similarity.
- “What is this like in another domain?”
- “What underlying pattern does this resemble?”
- “Is this a search problem? Optimization? Constraint satisfaction?”
- “Which past solution matches this structure?”
- Kubernetes node join flow ↔ state machine patterns
- mDNS resolution failures ↔ DNS caching problems ↔ memory interference
- Math substitution ↔ refactoring code
- Terraform module design ↔ object-oriented encapsulation principles
- Network troubleshooting ↔ graph search
Making these connections builds general problem-solving power.
This is one of the highest ROI habits.
- The problem
- Your original representation
- Strategies you tried
- Where you got stuck
- What finally worked
- What chunk/schema it relates to
- What you learned about your thinking
- improves metacognition
- exposes recurring assumptions
- helps you identify your strongest heuristics
- trains your brain to adapt quicker next time
Over months, this becomes a personal “book of problem-solving patterns.”
Constraint surfacing is a simple exercise that uncovers hidden assumptions.
Make a list of all constraints you think the problem has. Label each:
- Real — imposed by physical or external reality
- Assumed — inferred but unverified
- Negotiable — can be changed with moderate effort
- Arbitrary — exists only because you're used to it
- Unnecessary — remove and test
Most breakthrough solutions come from realizing:
a constraint wasn’t actually real.
This is crucial in systems design, debugging, and mathematics.
To become a more flexible thinker, incorporate:
- math puzzles requiring creative transformations
- logic or lateral-thinking puzzles
- spatial puzzles
- short creative coding exercises (animations, fractals, simulations)
- drawing or visual tasks that reshape perception
Creativity is not separate from analytical skill — it helps you escape mental ruts.
Robertson emphasizes that abstract practice rarely transfers. Your strength: you always have real systems to improve.
Examples:
- learning OOP → apply to a real CLI or Ansible module
- learning math → apply to procedural graphics or physics simulation
- learning networking theory → test it in your homelab
- learning Linux internals → apply in Kubernetes troubleshooting
Real problems provide feedback loops that build deep expertise.
- Represent the problem (5 minutes)
- Pick a strategy (1–2 minutes)
- Try for 8–12 minutes
- If stuck → shift mode
- Solve or break it into smaller parts
- Reflect + log
- Add to your schemas/chunks
- Apply to a different domain
Doing this consistently creates exponential growth in your skill.