Refactoring and Self Reviews - sgml/signature GitHub Wiki

I realized that while it is great to take pride in your work, you should not attach your sense of self into your work. This is often because once you attach a sense of self or personal attachment into your work, it can become harder to accept criticism of your work and strive to iterate or improve on it.

Reasons for Refactoring Encoded into IDEs

Encoded Reason How IDEs Implement It Example Refactor
Rename consistency IDEs ensure renaming updates all references safely Rename Method β†’ changes method name across the project
Encapsulation enforcement IDEs encourage hiding implementation details and exposing cleaner APIs Encapsulate Field β†’ generates getters/setters automatically
Code reuse & modularity IDEs help extract repeated logic into reusable methods or classes Extract Method/Class β†’ pulls out duplicated code
Simplify signatures IDEs streamline method parameters for clarity and maintainability Change Method Signature β†’ adds/removes/reorders parameters safely
Safe deletion IDEs prevent accidental removal of code still in use Safe Delete β†’ checks references before deleting
Improve readability IDEs restructure code to make intent clearer Inline Variable/Method β†’ replaces temporary variables with direct expressions
Package organization IDEs help reorganize classes into logical packages Move/Repackage β†’ shifts classes without breaking imports
Bug prevention IDEs automate fixes that reduce common coding errors Introduce Parameter Object β†’ prevents mismatched arguments
Fix null handling IDEs provide tools to reduce null pointer exceptions Replace Temp with Query β†’ avoids unsafe temporary variables
Eliminate logic errors IDEs highlight and refactor fragile conditional code Extract Conditional β†’ separates complex logic into safer methods

Remove dependencies on the variable which caused the bug (questionId === ???)

Replace the conditional logic with a hashed array tree of all states (https://en.wikipedia.org/wiki/File:HashedArrayTree16.svg)

Use that array to generate other arrays of actions (function calls) and metadata (HTML/CSS)

Reference those in templates rather than using conditional logic

Limit code to declarative and interrogative array methods:

  • declarative

  • from

  • keys

  • map

  • reduce

  • filter

  • imperative

  • some

  • indexOf

  • every

Self-Review in terms of Skills

Stage Athlete Lifecycle Programmer Lifecycle Athlete Age Range Programmer Age Range
Early Training Youth sports, learning fundamentals, building physical base Learning basics of coding, algorithms, and problem-solving 8–15 years 12–20 years
Skill Development Specialized coaching, refining techniques, building endurance Mastering languages, frameworks, and software design patterns 15–20 years 18–25 years
Competitive Entry Local/regional competitions, proving ability Entry-level jobs, internships, contributing to small projects 18–25 years 22–30 years
Peak Performance Professional leagues, championships, peak physical condition Leading projects, architecting systems, peak productivity and innovation 20–30 years 25–40 years
Maintenance Injury prevention, recovery routines, adapting training Continuous learning, adapting to new tech, avoiding burnout 28–35 years 35–50 years
Transition Phase Decline in physical ability, mentoring younger athletes Shift to management, mentoring juniors, consulting roles 30–40 years 40–55 years
Legacy/Retirement Coaching, commentary, sports administration Teaching, writing, open-source contributions, thought leadership 35+ years 55+ years

Self-Review in terms of Roles

Aspect Physical Fitness β€œNothing to Fear but Fear Itself” How to Ensure It Through Exercise Things to Fear Physically if Unprepared Equivalent Fear in the Software Industry
Core Idea Strength through training Courage through mindset Practice progressive overload to prove discomfort isn't danger Loss of muscle mass, reduced mobility Fear of adopting new frameworks or languages
Barrier Physical discomfort, fatigue Psychological fear, anxiety Use exposure training (gradually harder workouts) to normalize challenge Chronic fatigue, poor stamina Fear of breaking legacy systems or touching fragile code
Strategy Exercise, nutrition, recovery Facing fear directly, reframing it Incorporate mindfulness in workouts to reframe pain as growth Obesity, metabolic syndrome Fear of technical debt cleanup or refactoring
Outcome Improved health, resilience Collective confidence, progress Build confidence by tracking small wins and celebrating milestones Cardiovascular disease, diabetes Fear of scaling systems under load or adopting cloud infrastructure
Risk if Ignored Hypokinetic diseases, weakness Paralysis of action, stagnation Avoid avoidance: skipping workouts reinforces fear of effort Injury risk from weak joints, brittle bones Fear of innovation leading to stagnation, outdated tech stack
Historical Context Industrial Revolution shift to modern fitness Roosevelt’s 1933 inaugural address during Depression Adopt community fitness (group classes, team sports) to mirror collective courage Societal burden of inactivity, healthcare costs Fear of open-source adoption or collaborative development slowing progress

References

Games

⚠️ **GitHub.com Fallback** ⚠️