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.