Secrets of Techhood
Secrets of Techhood
A collection of hard-won wisdom from the trenches of technology work
After decades building software, leading teams, and watching organisations succeed and fail, certain patterns emerge. The same mistakes get repeated. The same insights get rediscovered. The same hard-learned lessons get forgotten and relearnt by the next generation.
This collection captures those recurring truthsâthe kind of wisdom that comes from doing the work, making the mistakes, and living with the consequences. These arenât theoretical principles from academic papers or management books. Theyâre the practical insights that emerge when life meets reality, when teams face real deadlines, and when software encounters actual users.
The insights come from diverse sources: legendary systems thinkers like W.E. Deming and Russell Ackoff, software pioneers, quality experts, organisational psychologists, and practising technologists whoâve shared their hard-earned wisdom. What unites them is practical relevanceâeach aphorism addresses real challenges that technology professionals face daily.
Use this collection as a reference, not a rulebook. Read through it occasionally. Return to specific aphorisms when facing related challenges. Share relevant insights with colleagues wrestling with similar problems. Most importantly, remember that wisdom without application is just interesting trivia.
The technology changes constantly, but the fundamental challenges of building systems, working with people, and delivering value remain remarkably consistent. These truths transcend programming languages, frameworks, and methodologies. Theyâre about the deeper patterns of how good technology work gets done.
Invitarion: Iâd love for readers to suggest their own aphorisms for inclusion in this collection. Please use the comments, below.
The Aphorisms
Itâs called software for a reason.
#SOFT
The âsoftâ in software reflects its fundamental nature as something malleable, changeable, and adaptive. Unlike hardware, which is fixed once manufactured, software exists to be modified, updated, and evolved. This flexibility is both its greatest strength and its greatest challenge. The ability to change software easily leads to constant tweaking, feature creep, and the temptation to fix everything immediately. Yet this same flexibility allows software to grow with changing needs, adapt to new requirements, and evolve beyond its original purpose.
Learning hasnât happened until behaviour has changed.
#BEHAVIOR_CHANGE
Consuming tutorials, reading documentation, and attending conferences is information absorption. True learning in tech occurs when concepts become internalised so deeply that they alter how problems are approached. Data analysis learning is complete when questioning data quality and looking for outliers becomes instinctive. Project management mastery emerges when breaking large problems into smaller, manageable pieces happens automatically.
Change hasnât happened unless we feel uncomfortable.
#UNCOMFORTABLE
Real change, whether learning a new technology, adopting different processes, or transforming how teams work, requires stepping outside comfort zones. If a supposed change feels easy and natural, youâre just doing familiar things with new labels. Genuine transformation creates tension between old habits and new ways of working.
The work you create today is a letter to your future selfâcreate with compassion.
#FUTURE_SELF
Six months later, returning to a project with fresh eyes and foggy memory is jarring. The folder structure that seems obvious today becomes a confusing maze tomorrow. The clever workflow that feels brilliant now frustrates that future self. Creating work as if explaining thought processes to a colleague makes senseâbecause thatâs whatâs happening across time.
Documentation is love made visible.
#VISIBLE_LOVE
Good documentation serves as an act of kindness towards everyone who will interact with the work, including oneâs future self. It bridges current understanding and future confusion. When processes are documented, decisions explained, or clear instructions written, thereâs an implicit message: âI care about your experience with this work.â Documentation transforms personal knowledge into shared resources.
Perfect is the enemy of shipped, and also the enemy of good enough.
#SHIP_IT
The pursuit of perfection creates endless cycles of refinement that prevent delivery of value. Hours spent polishing presentations that already communicate effectively could address new problems or serve unmet needs. Yet shipping imperfection carries risks tooâreputation damage, user frustration, or technical debt. Sometimes âdoneâ creates more value than âperfectâ, especially when perfect never arrives.
Every problem is a feature request from reality.
#REALITY_REQUEST
Issues reveal themselves as more than annoying interruptionsâtheyâre signals about unconsidered edge cases, incorrect assumptions, or untested scenarios. Each problem illuminates gaps between mental models of how things work and how they actually work in practice. When users struggle with an interface, theyâve submitted an unspoken feature request for better design.
The best problem-solving tool is a good nightâs sleep.
#SLEEP_SOLVE
The brain processes and consolidates information during sleep, revealing solutions that remained hidden during conscious effort. Challenges that consume hours of focused attention resolve themselves in minutes after proper rest. Sleep deprivation clouds judgement, reduces pattern recognition, and obscures obvious solutions.
Premature optimisation is the root of all evil, but so is premature pessimisation.
#BOTH_EVILS
Whilst rushing to optimise before understanding the real bottlenecks is wasteful, itâs equally dangerous to create obviously inefficient processes under the banner of âweâll fix it later.â Donât spend days perfecting workflows that run once, but also donât use manual processes when simple automation would work just as well.
Your first solution is rarely your best solution, but itâs always better than no solution.
#FIRST_BEATS_BEST
The pressure to find the perfect approach immediately creates analysis paralysis. First attempts prove naĂŻve, inefficient, or overly complex, yet they provide crucial starting points for understanding problem spaces. Working solutions enable iteration, refinement, and improvement.
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work.
#GALLS_LAW
John Gallâs Law captures a fundamental truth about how robust systems come into being. They arenât architected in their final formâthey grow organically from working foundations. The most successful large systems started as simple, functional prototypes that were gradually extended.
The hardest parts of tech work are naming things, managing dependencies, and timing coordination.
#THREE_HARDS
These three fundamental challenges plague every technology professional daily. Naming things well requires understanding not just what something does, but how it fits into the larger system and how others will think about it. Managing dependencies is difficult because it requires reasoning about relationships, priorities, and changes across multiple systems or teams.
Feedback is not personal criticismâitâs collaborative improvement.
#COLLABORATIVE_FEEDBACK
When colleagues suggest changes to work, theyâre investing their time and attention in making the outcome better. Theyâre sharing their knowledge, preventing future issues, and helping with professional growth. Good feedback is an act of collaboration, not criticism.
People will forgive not meeting their needs immediately, but not ignoring them.
#ATTEND_NEEDS
Users, stakeholders, and colleagues understand that resources are limited and solutions take time. They accept that their need might not be the highest priority or that the perfect solution requires careful consideration. What damages relationships is complete neglectânot making any effort, not showing any care, not demonstrating that their concern matters. People can wait for solutions when they see genuine attention being paid to their situation. The difference between delayed action and wilful neglect determines whether trust grows or erodes. Attending to needs doesnât require immediate solutions, but it does require genuine care and effort.
How you pay attention matters more than what you pay attention to.
#ATTENTIATIONAL_FEEDBACK
The quality of attention transforms both the observer and the observed. Distracted attention whilst multitasking sends a clear message about priorities and respect. Focused, present attentionâeven for brief momentsâcreates connection and understanding. When reviewing code, listening with genuine curiosity rather than hunting for faults leads to better discussions and learning. When meeting with stakeholders, being fully present rather than mentally composing responses changes the entire dynamic. The manner of attentionârushed or patient, judgmental or curious, distracted or focusedâshapes outcomes more than the subject receiving that attention.
Caring attention helps things grow.
#CARING_GROWTH
Systems, teams, and individuals flourish under thoughtful observation and nurturing focus. When attention comes with genuine careâwanting to understand, support, and improve rather than judge or controlâit creates conditions for development. Code improves faster when reviewed with constructive intent rather than fault-finding. Team members develop more rapidly when mistakes are examined with curiosity rather than blame. Projects evolve more successfully when monitored with supportive interest rather than suspicious oversight. The difference between surveillance and stewardship lies in the intent behind the attention.
The best work is work you donât have to do.
#NO_WORK
Every process created needs to be maintained, updated, and explained. Before building something from scratch, considering whether an existing tool, service, or approach already solves the problem pays off. The work not done canât break, doesnât need updates, and never becomes technical debt.
Every expert was once a beginner who refused to give up.
#REFUSE_QUIT
Experience and expertise arenât innate talentsâtheyâre the result of persistence through challenges, failures, and frustrations. The senior professionals admired today werenât born knowing best practices or troubleshooting techniques. They got there by continuing to learn, experiment, and problem-solve even when things felt impossibly difficult.
Your ego is not your work.
#EGO_WORK
When others critique work, they engage with output rather than character. Suggestions for improvement, identified issues, or questioned decisions focus on the work itself, not personal worth. Work can be improved, revised, or completely replaced without diminishing professional value.
Testing is not about proving a solution worksâitâs about showing where the work is at.
#STATUS_REPORT
Good testing reveals current status rather than validating perfection. Tests illuminate whatâs functioning, whatâs broken, whatâs missing, and whatâs uncertain. Rather than serving as a stamp of approval, testing provides visibility into the actual state of systems, processes, or solutions.
The most expensive work to maintain is work that almost functions.
#ALMOST_BROKEN
Work that fails obviously and consistently is easy to diagnose and fix. Work that functions most of the time but fails unpredictably is a maintenance nightmare. These intermittent issues are hard to reproduce, difficult to diagnose, and mask deeper systematic problems.
Changing things without understanding them is just rearranging the furniture.
#FURNITURE_MOVE
When modifying systems, processes, or designs without adequate understanding of how they currently work, thereâs no way to verify that essential functionality has been preserved. Understanding serves as a foundation for meaningful change, giving confidence that modifications improve things rather than just moving problems around.
Version control is time travel for the cautious.
#TIME_TRAVEL
Document management systems and change tracking tools let experimentation happen boldly because previous states can always be restored if things go wrong. They remove the fear of making changes because nothing is ever truly lost. Radical reorganisations, experimental approaches, or risky optimisations become possible knowing that reversion to the last known good state remains an option.
Any organisation that designs a system will produce a design whose structure is a copy of the organisationâs communication structure.
#CONWAYS_LAW
Conwayâs Law reveals why so many software architectures mirror the org charts of the companies that built them. If you have separate teams for frontend, backend, and database work, youâll end up with a system that reflects those boundariesâeven when a different architecture would serve users better.
Question your assumptions before you question your code.
#ASSUMPTIONS_FIRST
Most problems stem not from implementation errors but from incorrect assumptions about how systems work, what users will do, or how data will behave. Assumptions about network reliability, that users will provide valid input, that third-party services will always respond, or that files will always exist where expected become embedded in work as implicit requirements that arenât tested or documented.
The problem is always in the last place you look because you stop looking after you find it.
#LAST_PLACE
This humorous observation about troubleshooting reflects a deeper truth about problem-solving methodology. Issues are searched for in order of assumptions about likelihood, starting with the most obvious causes. When problems are found, searching naturally stops, making it definitionally the âlastâ place looked.
Your production environment is not your testing environment, no matter how much you pretend it is.
#PROD_NOT_TEST
Despite best intentions, many teams end up using live systems as their primary testing ground through âquick updates,â âminor changes,â and âsimple fixes.â Production environments have different data, different usage patterns, different dependencies, and different failure modes than development or testing environments.
Every âtemporary solutionâ becomes a permanent fixture.
#TEMP_PERMANENT
What starts as a quick workaround becomes enshrined as permanent process. The âtemporary fixâ implemented under deadline pressure becomes the foundation that other work builds upon. Before long, quick hacks become load-bearing infrastructure thatâs too risky to change.
The work that breaks at the worst moment is always the work you trusted most.
#TRUSTED_BREAKS
Murphyâs Law applies strongly to technology work. The elegant, well-tested system that generates pride will find a way to fail spectacularly at the worst possible moment. Meanwhile, the hacky workaround that needed fixing will run flawlessly for years. Confidence leads to complacency, which creates blind spots where unexpected failures hide.
Always double-check the obvious.
#DOUBLE_CHECK
Paranoia is a virtue in technology work. Even when certain about how a system works, validating assumptions, checking inputs, and considering edge cases remains worthwhile. Systems change, dependencies update, and assumptions that were true yesterday are not true today.
Notes are not apologies for messy workâtheyâre explanations for necessary complexity.
#EXPLAIN_COMPLEXITY
Good documentation doesnât explain what the work does but why it does it. It explains business logic, documents assumptions, clarifies non-obvious decisions, and provides context that canât be expressed in the work itself. Notes that say âprocess these filesâ are useless, but notes that say âAccount for timezone differences in date processingâ add valuable context.
The fastest process is the process that never runs.
#NEVER_RUN
Performance optimisation focuses on making existing processes run faster, but the biggest efficiency gains come from avoiding work entirely. Can expensive calculations be cached? Can results be precomputed? Can unnecessary steps be eliminated? The most elegant solution is recognising that certain processes donât need to execute at all under common conditions.
The systems that people work in account for 95 per cent of performance.
#DEMING_95
W.E. Demingâs insight: Most of what we attribute to individual talent or effort is determined by the environment, processes, and systems within which people operate. If the vast majority of performance comes from the system, then improving the system yields far greater returns than trying to improve individuals within a flawed system.
Individual talent is the 5 per cent that operates within the 95 per cent that is system.
#DEMING_5
Demingâs ratio explains why hiring ârock starsâ to fix broken systems fails, whilst putting competent people in well-designed systems consistently produces exceptional results. A brilliant programmer in a dysfunctional organisation will struggle, whilst an average programmer in a good system can accomplish remarkable things. The 5% individual contribution becomes meaningful only when the 95% system component enables and amplifies it.
Unless you change the way you think, your system will not change and therefore, its performance wonât change either.
#CHANGE_THINKING
John Seddonâs insight cuts to the heart of why so many improvement initiatives fail. Teams implement new processes, adopt new tools, or reorganise structures whilst maintaining the same underlying assumptions and beliefs that created the original problems. Real change requires examining and challenging the mental models, assumptions, and beliefs that shape how work gets designed and executed.
People are not our greatest assetâitâs the relationships between people that are our greatest asset.
#RELATIONSHIPS
Individual talent matters, but the connections, communication patterns, and collaborative dynamics between team members determine success more than any single personâs capabilities. The most effective teams arenât composed of the most talented individuals, but of people who work well together and amplify each otherâs strengths.
A bad system will beat a good person every time.
#BAD_SYSTEM
Individual competence and good intentions canât overcome fundamentally flawed processes or organisational structures. When systems create conflicting incentives, unclear expectations, or impossible constraints, even capable people struggle to succeed. Good people in bad systems become frustrated, whilst average people in good systems accomplish remarkable things.
You canât inspect quality inâit has to be built in.
#BUILD_IN
Quality comes from improvement of the production process, not from inspection. Good systems prevent defects rather than just catching them. The most effective quality assurance focuses on improving how work gets done, not on finding problems after they occur.
The righter we do the wrong thing, the wronger we become. Therefore, it is better to do the right thing wrong than the wrong thing right.
#ACKOFF_WRONG
Russell Ackoffâs insight highlights that effectiveness (doing the right things) must come before efficiency (doing things right). Becoming more efficient at the wrong activities compounds the problem. Focus first on whether you should be doing something before worrying about how well you do it.
Efficiency is doing things right; effectiveness is doing the right things.
#DRUCKER_DISTINCTION
Peter Druckerâs classic distinction reminds us that thereâs little value in optimising processes that shouldnât exist in the first place. The greatest risk for managers is the confusion between effectiveness and efficiency. There is nothing quite so useless as doing with great efficiency what should not be done at all.
The constraint determines the pace of the entire system.
#CONSTRAINT
In any process or organisation, one bottleneck limits overall performance regardless of how fast other parts operate. Optimising non-constraint areas looks productive but doesnât improve system output. Finding and focusing improvement efforts on the true constraints provides the greatest leverage for overall performance gains.
Innovation always demands we change the rules.
#CHANGE_RULES
When we adopt new approaches that diminish limitations, we must also change the rules that were created to work around those old limitations. Otherwise, we get no benefits from our innovations. As long as we obey the old rulesâthe rules we originally invented to bypass the limitations of the old systemâwe continue to behave as if the old limitations still exist.
In God we trust; all others bring data.
#TRUST_DATA
Decisions improve when based on evidence rather than assumptions, but data alone doesnât guarantee good choices. Numbers mislead as easily as they illuminate, especially when they reflect measurement artefacts rather than underlying realities. Data provides a foundation for discussion and decision-making, but wisdom comes from interpreting that data within context.
Every bug you ship becomes ten support tickets.
#FAILURE_DEMAND
John Seddonâs âfailure demandâ reveals how poor quality creates exponential work. When you donât get something right the first time, you generate cascading demand: customer complaints, support calls, bug reports, patches, and rework. Itâs always more expensive to fix things after customers find them than to prevent problems in the first place.
Technical debt is like financial debtâa little helps you move fast, but compound interest will kill you.
#TECH_DEBT
Strategic shortcuts can accelerate delivery when managed carefully. Taking on some technical debt to meet a critical deadline or test market assumptions is valuable. But unmanaged technical debt accumulates interest through increased maintenance costs, slower feature development, and system brittleness.
The best code is no code at all.
#NO_CODE
Every line of code written creates obligationsâdebugging, maintenance, documentation, and ongoing support. Before building something new, the most valuable question is whether the problem needs solving at all, or whether existing solutions already address the need adequately. Code that doesnât exist canât have bugs, doesnât require updates, and never becomes technical debt.
Start without IT. The first design has to be manual.
#START_MANUAL
Before considering software-enabled automation, first come up with manual solutions using simple physical means, like pin-boards, T-cards and spreadsheets. This helps clarify what actually needs to be automated and ensures you understand the process before attempting to digitise it.
Simple can be harder than complexâyou have to work hard to get your thinking clean.
#CLEAN_THINKING
Achieving simplicity requires understanding problems deeply enough to eliminate everything non-essential. Complexity masks incomplete understanding or unwillingness to make difficult choices about what matters most. Simple solutions demand rigorous thinking about core requirements, user needs, and essential functionality.
Design is how it works, not how it looks.
#FUNCTION_FORM
Visual aesthetics matter, but they serve the deeper purpose of supporting functionality and user experience. Good design makes complex systems feel intuitive, reduces cognitive load, and guides users towards successful outcomes. When appearance conflicts with usability, prioritising function over form creates better long-term value.
Saying no is more important than saying yes.
#SAY_NO
Focus emerges from deliberately choosing what not to do rather than just deciding what to pursue. Every opportunity accepted means other opportunities foregone, and attention is always limited. Organisations that try to do everything accomplish nothing well. Strategic success comes from identifying the few things that matter most and declining everything else.
Organisational effectiveness = f(collective mindset).
#COLLECTIVE_MINDSET
The effectiveness of any organisation is determined by the shared assumptions, beliefs, and mental models of the people within it. Technical solutions, processes, and structures matter, but theyâre all constrained by the underlying collective mindset that shapes how people think about and approach their work.
Technologists who dismiss psychology as âsoft scienceâ are ignoring the hardest variables in their systems.
#HARD_VARIABLES
Technical professionals gravitate toward problems with clear inputs, logical processes, and predictable outputs. Psychology feels messy and unquantifiable by comparison. But the human elementsâmotivation, communication patterns, cognitive biases, team dynamicsâdetermine whether technical solutions succeed or fail in practice.
Code review isnât about finding bugsâitâs about sharing knowledge.
#KNOWLEDGE_SHARE
Whilst catching defects has value, the real benefit of code reviews lies in knowledge transfer, spreading understanding of the codebase, sharing different approaches to solving problems, and maintaining consistency in coding standards. Good reviews help prevent knowledge silos and mentor junior developers.
All estimates are wrong. Some are useful.
#USEFUL_WRONG
Software estimates are educated guesses based on current understanding, not commitments or predictions. Theyâre useful for planning, prioritising, and making resource allocation decisions, but they shouldnât be treated as contracts or promises. Use them as tools for discussion and planning, and remember that their primary value is in helping make better decisions.
Security is not a feature you addâitâs a discipline you practise.
#SECURITY_DISCIPLINE
Security canât be bolted on after the fact through penetration testing or security audits alone. It must be considered throughout design, development, and deployment. Security is about creating systems that are resistant to attack by design, not just finding and fixing vulnerabilities after theyâre built.
Your users will break your software in ways you never imaginedâand theyâre doing you a favour.
#USERS_FAVOUR
Real users in real environments expose edge cases, assumptions, and failure modes that controlled testing misses. They use your software in contexts you never considered, with data you never anticipated, and in combinations you never tested. Each break reveals gaps in your mental model of how the system should work.
Refactor before you need to, not when you have to.
#REFACTOR_EARLY
Continuous small refactoring prevents code from becoming unmaintainable. When youâre forced to refactor, youâre already behind and under pressure, which leads to rushed decisions and compromised quality. Build refactoring into your regular development rhythm, not as crisis response.
If you canât measure it breaking, you canât fix it reliably.
#MEASURE_BREAK
Systems need observable failure modes through monitoring, logging, and alerting. Without visibility into system health and failure patterns, youâre debugging blindly and fixing symptoms rather than root causes. Good monitoring tells you not just that something broke, but why it broke and how to prevent it from happening again.
Knowledge sharing is not cheatingâitâs collaborative intelligence.
#COLLABORATIVE_INTEL
Technology work has always been collaborative, and online communities represent the democratisation of knowledge sharing. Looking up solutions to common problems isnât cheatingâitâs efficient use of collective wisdom. The key is understanding the solutions found rather than blindly copying them.
Error messages are breadcrumbs, not accusations.
#BREADCRUMBS
Error messages arenât personal attacks on competenceâtheyâre valuable clues about what went wrong and how to fix it. Good error messages tell a story about what the system expected versus what it encountered. Learning to read error messages carefully and use troubleshooting data effectively is a crucial skill.
Collaboration is not about sharing tasksâitâs about sharing knowledge.
#SHARE_KNOWLEDGE
The value of collaborative work isnât in the mechanical division of labourâitâs in the knowledge transfer, real-time feedback, and shared problem-solving that occurs. When professionals collaborate effectively, they share different perspectives, catch each otherâs mistakes, and learn from each otherâs approaches.
The most important skill in technology is knowing when to start over.
#START_OVER
Abandoning problematic systems or processes and starting fresh proves more efficient than continuing to patch existing work. When complexity accumulates beyond economical improvement, when foundational assumptions prove flawed, or when requirements shift dramatically, fresh starts offer better paths forward.
Remember: Every expert was once a disaster who kept learning.
Further Reading
Ackoff, R. L. (1999). Re-creating the corporation: A design of organizations for the 21st century. Oxford University Press.
Conway, M. E. (1968). How do committees invent? Datamation, 14(4), 28-31.
Deming, W. E. (2000). Out of the crisis. MIT Press. (Original work published 1986)
Drucker, P. F. (2006). The effective executive: The definitive guide to getting the right things done. HarperBusiness. (Original work published 1967)
Gall, J. (2002). The systems bible: The beginnerâs guide to systems large and small (3rd ed.). General Systemantics Press. (Original work published 1975)
Marshall, R. W. (2021). Quintessence: An acme for software development organisations. Falling Blossoms.
Seddon, J. (2019). Beyond command and control. Vanguard Consulting.
#ACKOFFWRONG #ALMOSTBROKEN #ASSUMPTIONSFIRST #ATTENDNEEDS #ATTENTIATIONALFEEDBACK #BADSYSTEM #BEHAVIORCHANGE #BOTHEVILS #BREADCRUMBS #BUILDIN #CARINGGROWTH #CHANGERULES #CHANGETHINKING #CLEANTHINKING #COLLABORATIVEFEEDBACK #COLLABORATIVEINTEL #COLLECTIVEMINDSET #CONSTRAINT #CONWAYSLAW #DEMING5 #DEMING95 #DOUBLECHECK #DRUCKERDISTINCTION #EGOWORK #EXPLAINCOMPLEXITY #FAILUREDEMAND #FIRSTBEATSBEST #FUNCTIONFORM #FURNITUREMOVE #FUTURESELF #GALLSLAW #HARDVARIABLES #KNOWLEDGESHARE #LASTPLACE #MEASUREBREAK #NEVERRUN #NOCODE #NOWORK #PRODNOTTEST #REALITYREQUEST #REFACTOREARLY #REFUSEQUIT #Relationships #SAYNO #SECURITYDISCIPLINE #SHAREKNOWLEDGE #SHIPIT #SLEEPSOLVE #SOFT #STARTMANUAL #STARTOVER #STATUSREPORT #TECHDEBT #TEMPPERMANENT #THREEHARDS #TIMETRAVEL #TRUSTEDBREAKS #TRUSTDATA #UNCOMFORTABLE #USEFULWRONG #USERSFAVOUR #VISIBLELOVE
