Where I’m at
Mastermind - Development
Double Coincedence of Wants - Important in bartering trading theory. A buyer and seller must both be willing to sell their goods, and buy the others goods.
Pattern Designs - Important to solve common problems but not how it’s done
They’re blowing my mind - but they’re really useful. I understand that they’re not applicable in all cases, but are tried and tested solutions that work regardless of contex
Portal - Development
Sequence of events using the Stocktake and Stock Item models:
| Sequence | Action | Stocktake State | Stock Item State | UI Action |
|---|---|---|---|---|
| 1 | Start stocktake | Initialize with catalog items, zero counts | Fetch full catalog of items | Show full list of items with fields for counts, hint last known counts |
| 2 | Enter count for an item | Update count for item ID | Unchanged | Update count field for item |
| 3 | (Reserved for future) | - | - | - |
| 4 | (Reserved for future) | - | - | - |
| 5 | Submit counts | Set status to ‘inProgress’, store counts | Unchanged | Show confirmation dialog, then loading indicator |
| 6 | Validate counts | Unchanged | Unchanged | Perform validation checks, show any discrepancies |
| 7 | Confirm submission | Set status to ‘completed’ | Batch update quantities | Show loading, then success message, update list with new counts |
| 8 | Review stocktake | Load completed stocktake details | Load updated stock items | Display stocktake summary report |
| 9 | Close stocktake session | Clear/reset state | Unchanged | Return to main menu or dashboard |
What I learnt
Notes from “Pragmatic Thinking and Learning”
Introduction - Always Consider the Context!
Everything is connected to each other, nothing exists in isolation.
E.g. a tree is not an isolated object in the ground. It has two major systems:
- Processing of leaves and air, and
- Processing of roots and earth.
You are also very rarely a mere observer in the system but a part of it!
Novice vs Expert
The Dreyfus Model is how we can conceive skill level - not how a person learns. There are five levels on the model:
- Novice
- Advanced Beginner
- Competent
- Proficient
- Expert
The following are general characterisations of each level:
Novice
A novice is:
- Little to no experience - this does not simply mean time taken in practicising a skill. Skill means learning from failure.
- Very concerned about their ability to succeed, and not particularly concerned with learning
- Unable to respond to mistakes, or get easily confused when things go awry
- Can perform well when given context-free rules - “Whenever X happens, do Y” - like using a decision tree or following a recipe. But do not know which rules are relevant at any given time
Advanced Beginner
An advanced begineer is:
- Can break away a bit from the rules and try things on their own - still have difficulty troubleshooting
- Want information fast - don’t want to be bogged down in lengthy theory or spoon-fed basics again
- Can’t see the big picture yet - would probably dismiss it as irrelevant if given
Competent
A competent practitioner:
- Is developing abstract representations or conceptual models of the problem or systems they are working with – they are coming out of their small view and coming into the larger view
- Can be described as “resourceful” or “having initiative” - they can mentor novices and also not annoy experts
Proficient
A proficient practitioner:
- Needs the big picture - this is what they’ll seek out to understand the larger conceptual framework
- Is frustrated by oversimplification (Calling an IT helpline to just be asked “Is it plugged in?“)
- Can learn from the experience of others without participating in it firsthand. Being able to read / listen to accounts and gain knowledge
- Can apply maxims - situtiatonal proverbial truths distilled into shortform - “Test everything that can break”.
- A novice is overwhelmed thinking they have to test everything
- A proficient practitioner understands the context and knows what can break - or what is more likely to break
- Doesn’t have enough skill to predict what will come next, but knows how to respond - they can use reflection and feedback to full advantage.
Expert
An expert:
- Uses inuition over rules
- Knows the difference between relevant / irrelevant details
- Very good at targeted, focused pattern matching
Don’t cross the streams!
Experts do not work well with rules! Don’t herd a racehorse!
Novices don’t work well with intuition! Don’t race sheep!
Match the skill level with the work required!
Random thoughts to checkout
- Extreme Programming - systematic way of agile development. Focused on breaking things down by months, weeks, days, hours, minutes, seconds, etc
- Gang of Four - [Design Patterns: Elements of Reusable Object-Oriented Software (1994)] - Influential book in explaining what Design Patterns there are for object-orientated programming
- Software Design =/= Recipe Following, possibly Design Patterns? - Design patterns are standard solutions to common problems in software design. They are not snippets of code, but high level strategies to solve particular problems.
- Don’t Repeat Yourself - “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system”
- As an alternative: AHA - “Avoid Hasty Abstractions” - that being avoid pre-empting possible scenarios where change is required.
- Premature Abstractions / Optimisations - build infrastructure that is simple to change - premature abstractions are premature optimisations
- Sunk Cost Fallacy - software engineers want to avoid wasting time, and so try to over-engineer to avoid having to refactor later. However it’s better to refactor when you get clarity.
- Wait Until You Need It - As you develop the software, you’ll get a more clear picture of the requirements. Then you can create more appropriate abstractions when needed.
- No Broken Windows - basically you’ll neglect code much faster if you leave things unattended to such as commenting out bad code, or replacing with dummy data. Go and fix those and figure out why it went wrong.