A curated collection of real-world system complexities that programmers should understand, distilled from common misconceptions and presented as positive knowledge.
This comprehensive guide is based on the excellent Awesome Falsehoods project, which catalogues false assumptions programmers make about the real world. Rather than focusing on what's wrong, this document presents positive facts about how systems actually work.
Original Source: The content is derived from analyzing and transforming the misconceptions documented in Kevin Deldycke's Awesome Falsehoods repository. All credit for identifying these important system complexities goes to the original falsehoods project and its contributors.
Document Structure: This README organizes 243 fundamental facts about system complexities into 6 major categories to help developers understand the intricate realities of building robust systems.
- People can have multiple legal names - Married names, professional names, nicknames, and cultural names create multiple valid identities.
- Daily-use names differ from legal names - People commonly use shortened, anglicized, or preferred names in daily life.
- Names change over time - Legal names can change due to marriage, divorce, adoption, religious conversion, or personal preference.
- Names use diverse writing systems - Arabic, Chinese, Sanskrit, Thai, and other scripts require Unicode support beyond ASCII.
- Name order varies globally - Family name first (East Asian), given name first (Western), no fixed order (Indonesian), or other cultural patterns.
- Names are not globally unique - Common names like "John Smith" or "ζε°ζ" are shared by millions of people worldwide.
- Names can match profanity filters - Common surnames like "Cox," "Dick," or "Hell" will trigger overzealous content filtering.
- Some people lack formal names - Refugees, stateless persons, indigenous peoples, or those from cultures without formal naming systems may not have traditional names.
- Many addresses lack building numbers - Rural addresses, named buildings, and areas with traditional addressing systems often use only names, descriptions, or landmark references.
- Building numbers can include letters and symbols - "123A", "45Β½", "12-14", and other alphanumeric combinations are common in many addressing systems.
- Building zero exists in many locations - Ground floor addressing, numbering systems that include zero, and specific cultural conventions create addresses with zero.
- Addresses use diverse character sets - Arabic, Chinese, Cyrillic, and other non-Latin scripts are essential for accurate addressing in many countries.
- People commonly have multiple addresses - Home, work, temporary, and mailing addresses create multiple valid address relationships for individuals and businesses.
- Many valid addresses aren't in postal databases - New constructions, rural areas, informal settlements, and database lag mean valid addresses may not be officially registered.
- Not everyone has a phone number - Some people do not own phones, cannot afford service, or choose not to provide their number for privacy reasons.
- People commonly have multiple phone numbers - Personal, work, mobile, landline, and temporary numbers create multiple contact points for most individuals.
- Phone numbers are regularly recycled - Telecommunications providers reassign disconnected numbers to new customers after waiting periods.
- Phone numbers can include letters and symbols - Vanity numbers use letters (1-800-FLOWERS), and some international formats include special characters.
- Phone numbers are identifiers, not mathematical numbers - Leading zeros, length variations, and formatting make them unsuitable for numeric data types.
- Days can vary in length - Earth's rotation is irregular, leap seconds exist, and relativistic effects mean days aren't exactly 24 hours.
- Hours can vary in duration during DST transitions - Spring forward creates 23-hour days, fall back creates 25-hour days.
- Minutes can have 59 or 61 seconds due to leap seconds - Leap seconds are occasionally added to UTC to keep atomic time synchronized with Earth's rotation.
- Time can appear to move backward - Time zone changes, leap seconds, system clock adjustments, and relativistic effects can cause apparent time reversals.
- System clocks drift and require synchronization - Crystal oscillators are imperfect, requiring regular network time synchronization to maintain accuracy.
- UTC offsets range from -12 to +14 - The Line Islands (UTC+14) and Baker Island (UTC-12) create a 26-hour spread, not the expected 24-hour range.
- There are more time zones than countries - With 244 time zones serving 195 countries, many nations use multiple zones while some share zones across borders.
- Time zones use 30-minute and 15-minute offsets - Countries like India (UTC+5:30), Nepal (UTC+5:45), and others use non-hour offsets for political or geographical reasons.
- Countries regularly modify their time zones - Political changes, economic factors, and energy considerations drive frequent time zone adjustments worldwide.
- Time zone abbreviations are highly ambiguous - CST represents Central Standard Time (US), China Standard Time, Cuba Standard Time, and Central Summer Time (Australia).
- DST changes can be non-standard amounts - Some regions have used 20-minute, 30-minute, or 2-hour DST shifts.
- DST transition dates vary globally - Northern and southern hemispheres have opposite seasons, and individual countries choose their own dates.
- Many countries don't observe DST - Most countries near the equator, China, India, and many others don't use daylight saving time.
- Unix time excludes leap seconds from its count - Unix time represents seconds since January 1, 1970 UTC, but doesn't count leap seconds, creating discrepancy with actual elapsed time.
- Unix timestamps can decrease - Leap seconds, system clock corrections, and time synchronization can cause timestamps to go backward.
- Timestamps are ambiguous during DST transitions - Times between 1-2 AM during fall DST transitions can occur twice in the same location.
- ASCII covers only basic English characters - The 128 ASCII characters exclude accented letters, mathematical symbols, and all non-Latin scripts used by billions of people worldwide.
- UTF-8 has practical implementation limitations - While theoretically comprehensive, font support, input methods, and rendering engines limit which Unicode characters can actually be used.
- Many characters require multiple code points - Accented characters, emoji combinations, and complex scripts often use combining character sequences rather than single code points.
- Character display widths vary dramatically - East Asian characters, combining marks, emoji, and mathematical symbols require different display space than Latin letters.
- Word separation varies across languages - Chinese, Japanese, Thai, and other languages don't use spaces between words, requiring different text processing approaches.
- Many languages use right-to-left or mixed text directions - Arabic, Hebrew, and mixed-script text require bidirectional text rendering and special handling.
- Text expansion and contraction vary dramatically - German text can be 30% longer than English, while Chinese can be 30% shorter, requiring flexible UI design.
- Alphabetical ordering rules vary by language and culture - Different languages sort accented characters, multi-character combinations, and special characters according to distinct cultural conventions.
- Case concepts don't exist in many writing systems - Chinese, Arabic, Hebrew, and many other scripts have no uppercase/lowercase distinction, making case-based operations meaningless.
- Multiple calendar systems are actively used - Islamic, Hebrew, Buddhist, and other calendar systems are official in various countries and required for proper localization.
- Date and number formats vary globally - DD/MM/YYYY vs MM/DD/YYYY, comma vs period decimal separators, and thousands separators vary by country and context.
- Address formats differ dramatically worldwide - Japanese addresses go from general to specific, Middle Eastern addresses may lack street names, and rural addressing systems vary globally.
- Floating point numbers are inadequate for monetary values - Floating point arithmetic introduces rounding errors that accumulate over time, causing cents to disappear or appear in financial calculations.
- Prices often require more precision than currency subdivisions - Gas prices, precious metals, bulk commodities, and financial instruments often use fractional cent pricing beyond standard currency subdivisions.
- Prices contain letters and special characters - Prices include currency symbols, words like "FREE" or "CALL," ranges with dashes, and promotional text mixed with numbers.
- Prices can have zero or negative prices - Free samples, rebate products, and trade-in scenarios can result in zero or negative final prices.
- Currency subdivisions vary widely - Some currencies use 1/1000 subdivisions (like the Bahraini dinar), others use 1/10, and some have no subdivisions at all.
- Some currencies have no subdivisions - Currencies like the Japanese Yen and Korean Won don't use fractional units in normal transactions.
- Many countries don't have their own currencies - Eurozone countries, dollarized economies, and small nations often use other countries' currencies or shared monetary systems.
- Multiple currencies share the same names - "Dollar," "Peso," "Franc," and other names are used by dozens of different currencies with different values.
- Currency symbol placement varies by currency and locale - Some currencies place symbols before, others after, and placement rules differ between countries using the same currency.
- Decimal separators vary globally - Some locales use commas as decimal separators while others use periods, and some use other characters entirely.
- Dollar sign represents many different currencies - The $ symbol is used for US, Canadian, Australian, Hong Kong, Singapore, and dozens of other currencies with different values.
- Multiple exchange rates exist simultaneously - Official rates, market rates, buying rates, selling rates, and black market rates can all differ significantly at the same time.
- Exchange rates don't exist between all currency pairs - Some currencies are not freely convertible, have no established market, or are prohibited from direct exchange.
- Places commonly have multiple official names - Bilingual regions, historical names, and administrative divisions often create multiple legally recognized names for the same location.
- Place names change frequently - Political changes, cultural shifts, decolonization, and local preferences regularly alter official place names.
- Many place names cannot be accurately transliterated to ASCII - Tonal languages, complex scripts, and culturally significant characters often lose essential meaning when converted to ASCII.
- Multiple coordinate systems exist beyond latitude/longitude - UTM, military grids, local projection systems, and proprietary coordinate systems are widely used for different applications.
- Shortest paths follow great circle routes on Earth's surface - The spherical nature of Earth means straight lines on maps don't represent the shortest travel distance between points.
- GPS accuracy varies significantly - Atmospheric conditions, signal obstructions, selective availability, and receiver quality create substantial variation in GPS precision.
- Maps necessarily distort reality - All map projections introduce distortions in area, shape, distance, or direction when representing Earth's spherical surface on flat media.
- Some locations have disputed or unclear sovereignty - Contested territories, unclaimed lands, and areas under multiple jurisdictions exist worldwide.
- Country boundaries change regularly - Wars, treaties, independence movements, and territorial disputes create ongoing boundary modifications.
- Many countries include non-contiguous territories - Islands, enclaves, overseas territories, and separated regions mean countries often consist of multiple separated areas.
- Time zones follow political rather than geographic logic - Economic considerations, political unity, and social factors make time zones deviate significantly from longitude-based geographic boundaries.
- Networks are inherently unreliable - Hardware failures, software bugs, congestion, and external interference create regular network failures and outages.
- Network latency is always present and variable - Physical distance, routing delays, processing time, and congestion create measurable and fluctuating latency.
- Bandwidth is always limited and shared - Network capacity is finite and must be shared among users, applications, and traffic types, creating bottlenecks and competition.
- Networks are fundamentally insecure - Unencrypted communications, man-in-the-middle attacks, and infrastructure vulnerabilities make networks inherently susceptible to security breaches.
- Network topology changes constantly - Equipment failures, routing updates, load balancing, and infrastructure changes create dynamic network topologies.
- IP addresses are not globally unique - Private address spaces, NAT, and address reuse mean the same IP address can exist in multiple network contexts.
- IP addresses change frequently - DHCP, load balancing, failover systems, and network reconfiguration cause regular IP address changes.
- DNS lookups can fail and have significant delays - Server failures, network issues, cache misses, and propagation delays cause DNS resolution problems.
- Domains can have multiple IP addresses - Load balancing, redundancy, and geographic distribution commonly use multiple A records for single domains.
- Most devices use dynamic IP addresses - DHCP, mobile networks, and residential connections typically assign temporary, changing IP addresses.
- HTTP requests fail regularly - Server errors, timeouts, connection failures, and network issues cause frequent HTTP request failures.
- HTTPS has implementation vulnerabilities - Certificate validation bugs, weak ciphers, protocol attacks, and configuration errors compromise HTTPS security.
- Packet loss occurs regularly - Congestion, hardware errors, routing issues, and quality problems cause routine packet loss in network communications.
- Message ordering is not preserved across networks - Routing differences, retransmissions, and parallel processing can cause messages to arrive out of order.
- Not everyone has an email address - Many people, especially elderly, children, or those in developing regions, may not have or need email addresses.
- People can have multiple email addresses - Personal, work, spam, and backup addresses are common, with individuals often managing several email accounts.
- Email addresses change frequently - Job changes, service provider switches, domain expiration, and personal preferences cause regular address changes.
- Email addresses can contain Unicode characters - International domain names and modern email standards support non-ASCII characters in addresses.
- Email addresses can include special characters - Quotes, spaces, and various punctuation marks are valid in email addresses according to RFC standards.
- Email is fundamentally unreliable - Server outages, network issues, spam filtering, and configuration errors cause regular delivery failures.
- Email delivery involves significant delays - Queuing, retry mechanisms, spam processing, and routing can cause hours or days of delay.
- Non-bounced emails can still fail delivery - Silent drops, spam folder placement, and filtering can prevent delivery without generating bounce messages.
- Email spoofing is technically possible - SMTP allows sender address manipulation, though modern authentication methods help prevent abuse.
- Email systems are highly distributed - Thousands of independent mail servers and providers create a decentralized email ecosystem.
- Email client HTML support varies - Security settings, text-only clients, and accessibility tools may not support HTML attachments.
- Email transmission is inherently insecure - Plain text protocols, server-to-server communication, and storage mechanisms expose email content.
- HTML has complex parsing rules and edge cases - Browser error recovery, legacy compatibility, and parsing ambiguities make HTML behavior complex and sometimes unpredictable.
- Browsers render HTML with significant differences - Layout engines, CSS implementation variations, and browser-specific behaviors create substantial rendering differences.
- Browsers tolerate and render invalid HTML - Error recovery mechanisms allow malformed HTML to display, though the results can be unpredictable across browsers.
- DOCTYPE declarations affect parsing mode - Missing or incorrect DOCTYPEs trigger quirks mode, fundamentally changing how browsers interpret HTML and CSS.
- URLs can contain Unicode characters through encoding - International domain names, Unicode characters, and various encoding schemes allow non-ASCII URLs.
- URL length limits vary dramatically by browser and server - Different browsers, servers, and proxies impose different URL length restrictions ranging from 2KB to 64KB.
- URL case sensitivity depends on the server and path component - Domain names are case-insensitive, but path components may be case-sensitive depending on server configuration.
- HTTPS doesn't guarantee complete page security - Mixed content, third-party resources, and client-side vulnerabilities can compromise HTTPS pages.
- CSS cascading involves complex specificity and inheritance rules - Selector specificity calculations, inheritance patterns, and cascade ordering create counterintuitive styling results.
- CSS feature support varies significantly across browsers - New features, vendor prefixes, and implementation differences require extensive cross-browser testing and fallbacks.
- Font availability depends on system and network resources - System fonts vary by OS, web fonts can fail to load, and font fallback behavior differs across browsers.
- Color reproduction varies by display technology and settings - Monitor calibration, color profiles, and display technology create significant color variation across devices.
- JavaScript can be disabled or blocked - Security settings, content blockers, and corporate policies frequently disable JavaScript, requiring graceful degradation.
- JavaScript feature support varies dramatically across browsers - ES6+ features, APIs, and implementation details differ significantly, especially in older browsers.
- Local storage has size limits and can be disabled - Storage quotas, user settings, and privacy modes can make local storage unavailable or unreliable.
- Pop-up blockers interfere with legitimate functionality - User-initiated actions, timing restrictions, and browser heuristics can block intended pop-up windows.
- POST requests can be cached by proxies and browsers - Caching policies, proxy settings, and browser behavior can cause POST request caching despite HTTP specifications.
- GET requests often have side effects - Analytics tracking, state changes, and server-side processing mean GET requests frequently modify system state.
- Content-Type headers can be incorrect or missing - Server misconfiguration, proxy interference, and dynamic content generation can produce inaccurate Content-Type headers.
- Same-origin policy has numerous exceptions and bypasses - CORS, postMessage, document.domain, and various browser features create same-origin policy exceptions.
- User agent strings can be spoofed and are unreliable - Browser identification, feature detection, and security decisions based on user agents are easily circumvented.
- Programming encompasses multiple distinct disciplines - Web development, systems programming, machine learning, and embedded systems require different skill sets and approaches.
- Every language has strengths and weaknesses - Tool selection depends on problem domain, team expertise, and ecosystem requirements.
- Language age doesn't determine quality - New languages may lack maturity while old languages may have accumulated cruft.
- Static typing catches some errors but not all - Type systems prevent certain classes of bugs but don't guarantee correctness or good design.
- Dynamic typing enables flexibility - Both typed and untyped languages can produce high-quality software when used appropriately.
- OOP is one useful paradigm - Object-oriented programming solves certain problems well but isn't optimal for all situations.
- Design patterns are tools, not solutions - Patterns help communicate solutions but can be overused or misapplied.
- Functional programming has specific strengths - FP excels in certain domains but isn't universally superior to other paradigms.
- Programming skill transcends paradigms - Good programmers adapt their approach to the problem rather than forcing one paradigm everywhere.
- Version numbers can decrease or use non-numeric schemes - Rollbacks, branching strategies, and alternative versioning schemes can create decreasing or non-sequential version numbers.
- Semantic versioning adoption is incomplete and inconsistent - Many projects use custom versioning schemes, don't follow SemVer rules, or apply them inconsistently.
- Git commits can be reordered and modified - Rebasing, interactive commits, and history rewriting can change commit order and timestamps.
- Merge conflicts occur regularly in collaborative development - Concurrent changes, large teams, and complex codebases make merge conflicts a frequent occurrence.
- Build processes have non-deterministic elements - Timestamps, system environment, dependency versions, and parallel processing can create build variations.
- Dependencies can become unavailable or modified - Repository outages, package removal, and version changes can break builds unexpectedly.
- Production environments differ from development - Hardware differences, operating system versions, network configurations, and security policies create environment mismatches.
- Dependencies frequently break backward compatibility - API changes, behavior modifications, and removal of deprecated features regularly break existing code.
- Configuration management is highly complex - Multiple configuration sources, environment-specific values, and dynamic configuration create intricate configuration challenges.
- Environment variables have limitations and security risks - Length limits, character restrictions, visibility issues, and process inheritance create configuration challenges.
- Testing reveals bugs but doesn't prove correctness - Good tests increase confidence but can't guarantee bug-free software.
- Tests can miss bugs and create false confidence - Incomplete test coverage, environmental differences, and test design flaws allow bugs to escape testing.
- Code coverage doesn't guarantee quality or correctness - High coverage can exist without testing edge cases, error conditions, or integration scenarios.
- Self-testing has inherent biases - Programmers often test their assumptions rather than challenging them, missing edge cases.
- Development performance tests don't reflect production reality - Different hardware, data volumes, network conditions, and user patterns make development testing unreliable.
- Static analysis has false positives and blind spots - Tool limitations, configuration issues, and complex code patterns cause static analysis to miss issues or report false problems.
- Compilers contain bugs - Even mature compilers have bugs that can affect program behavior in subtle ways.
- All dependencies contain bugs - Third-party libraries, frameworks, and tools have their own defects that can impact your software.
- Manual testing remains essential - User experience, exploratory testing, and real-world usage scenarios require human judgment and interaction.
- Self-documentation has perspective limitations - Authors know too much context and often omit information obvious to them but not to others.
- File path separators vary by operating system - Windows uses backslashes, Unix systems use forward slashes, and some systems support both, requiring cross-platform handling.
- File name restrictions vary by file system - Different systems prohibit various characters, have length limits, and handle Unicode differently.
- File system case sensitivity varies - NTFS can be case-sensitive or insensitive, HFS+ is case-preserving but insensitive, and ext4 is case-sensitive.
- Many files lack extensions - Unix executables, configuration files, and various file types don't use or require file extensions for identification.
- Symbolic links can create loops and broken references - Circular references, deleted targets, and permission changes can cause symbolic link failures.
- Databases can become inconsistent - Hardware failures, network partitions, software bugs, and concurrent access can create data inconsistencies.
- Database transactions can fail or behave unexpectedly - Deadlocks, timeout issues, isolation level problems, and system failures can cause transaction problems.
- Data corruption occurs regularly - Hardware failures, software bugs, power outages, and human error regularly cause data corruption.
- Backups frequently fail or are incomplete - Media failures, configuration errors, and incomplete backup strategies make backup recovery unreliable.
- Storage has costs and limitations - Financial costs, performance constraints, and physical limitations make unlimited storage impossible.
- HTTPS provides transport security but not complete protection - Endpoint security, certificate validation, implementation bugs, and application vulnerabilities remain despite HTTPS.
- Authentication and authorization are distinct security concerns - Identity verification doesn't guarantee appropriate access permissions, requiring separate authorization mechanisms.
- Security through obscurity provides minimal protection - Hidden systems remain vulnerable to discovery, and obscurity cannot replace proper security controls.
- Input validation cannot prevent all attack vectors - Logic flaws, authorization bypasses, and business logic attacks can occur despite proper input validation.
- Regular expressions can cause denial of service attacks - Catastrophic backtracking, ReDoS attacks, and resource exhaustion make regex dangerous for untrusted input.
- Company names can contain special characters - Many jurisdictions allow ampersands, apostrophes, hyphens, periods, and even HTML-like characters in legally registered company names.
- XSS attacks through company names are common - Web applications displaying company names without proper escaping are vulnerable to cross-site scripting attacks.
- CSRF tokens don't prevent all cross-site attacks - Token prediction, XSS exploitation, and implementation flaws can bypass CSRF protection mechanisms.
- Content Security Policy has implementation gaps - CSP bypasses, browser differences, and policy configuration errors can allow XSS attacks to succeed.
- Floating point numbers are inadequate for price storage - Floating point arithmetic introduces rounding errors that accumulate over time, making it unsuitable for financial calculations requiring exact precision.
- Integer cents representation has scale limitations - While storing monetary values as integer cents avoids decimal issues, it can overflow with large amounts and doesn't handle currencies with different subdivisions.
- Decimal point errors occur in production systems - Even well-tested financial systems regularly suffer from missing decimal points, turning $250 into $25,000 or vice versa.
- Missing decimal points often bypass validation - Many validation systems don't catch decimal point errors, allowing invalid amounts to propagate through financial workflows.
- Similar amounts can be confused by systems - User interface bugs, data entry errors, and parsing failures regularly confuse $250 and $25,000, especially when decimal points are missing.
- Type conversion of monetary values causes data loss - Converting between different numeric representations (float, int, decimal, string) frequently introduces rounding errors or truncation that corrupts monetary data.
- IBANs are primarily European with limited global adoption - IBAN is mainly used in Europe and some Middle Eastern countries, with major economies like the US, Canada, Australia, and most of Asia not implementing IBAN systems.
- IBAN reduces but doesn't eliminate input errors - While IBAN checksums catch many data entry mistakes, they don't prevent all types of errors, and incorrect but valid IBANs can still cause misdirected payments.
- IBANs are not confidential information - IBANs are designed to be shared publicly for receiving payments and don't contain sensitive information that requires secrecy, unlike account passwords or PINs.
- Optimization can harm performance or maintainability - Premature optimization, over-engineering, and complexity increases can reduce overall system performance.
- Caching creates new complexity and failure modes - Cache invalidation, consistency issues, and memory management make caching a source of additional problems.
- Adding servers can reduce performance - Coordination overhead, network latency, and synchronization costs can make distributed systems slower.
- Network calls are slow and unreliable - Latency, failures, timeouts, and bandwidth limitations make network operations inherently problematic.
- Memory is constrained and must be managed - Physical limitations, garbage collection pressure, and memory leaks require careful memory management.
- Performance has multiple dimensions - Algorithmic complexity, memory usage, network latency, and user experience all matter in different contexts.
- Clock synchronization is imperfect and temporary - Network delays, clock drift, and synchronization failures create persistent timing discrepancies across distributed systems.
- Partial failures are common in distributed systems - Component failures, network partitions, and degraded performance create complex partial failure scenarios.
- Network partitions can be permanent or long-lasting - Geographic isolation, infrastructure failures, and administrative decisions can create extended network separations.
- Nodes have inconsistent system views - Network delays, failures, and propagation time create situations where different nodes have conflicting information about system state.
- Economics is extraordinarily complex - Economic systems involve millions of interacting actors, psychological factors, cultural influences, and emergent behaviors that defy simple explanations.
- Classical economics has significant empirical gaps - Many classical economic theories were developed through theoretical reasoning rather than empirical validation and have been challenged by behavioral economics research.
- The efficient markets hypothesis has notable limitations - Markets regularly exhibit bubbles, crashes, and persistent inefficiencies due to information asymmetries, behavioral biases, and institutional constraints.
- People make systematically irrational economic decisions - Behavioral economics demonstrates that humans use mental shortcuts, exhibit cognitive biases, and make decisions that don't maximize utility.
- Advertising significantly influences and distorts markets - Marketing creates artificial demand, shapes preferences, and can lead to suboptimal consumer choices that wouldn't exist without advertising.
- Price often diverges significantly from cost - Market prices reflect supply, demand, market power, and speculation rather than production costs alone.
- Wealth often reflects luck and circumstances - Economic success depends heavily on timing, inheritance, geographic location, and systemic advantages rather than purely individual competence.
- Economics has inherent moral and political dimensions - Economic systems distribute resources and opportunities, making them inherently political and value-laden rather than neutral.
- Products can have no price or conditional pricing - Some products are "contact for pricing," auction-based, or require qualification before price disclosure.
- Products commonly have multiple prices - Different prices exist for wholesale, retail, member, student, bulk, promotional, and geographic variations.
- Stock keeping units represent complex product variations - SKUs often represent bundles, configurations, customizations, or virtual products that don't map directly to physical items.
- In stock status is dynamic and complex - "In stock" can mean reserved, allocated, in transit, at different warehouses, or available through drop-shipping arrangements rather than physical warehouse presence.
- Block height can decrease during chain reorganizations - When a longer valid chain is discovered, nodes will reorganize and accept the longer chain, potentially decreasing block height temporarily.
- Block timestamps can be inconsistent or decreasing - Miners can set timestamps within certain bounds, leading to blocks with earlier timestamps than their predecessors.
- Valid blocks can be orphaned - When miners find competing valid blocks simultaneously, only one becomes part of the longest chain while others are abandoned.
- Mempool transactions can be dropped or replaced - Transactions can be evicted due to full mempools, replaced by higher-fee versions, or become invalid due to conflicting transactions.
- Transactions can bypass the mempool - Miners can include transactions directly in blocks without broadcasting them to the mempool first.
- Bitcoin transactions are pseudonymous, not anonymous - All transactions are recorded on a public ledger that can be analyzed to reveal spending patterns and potentially identify users.
- Gas estimation can be inaccurate due to state changes - estimateGas provides estimates based on current state, but actual execution may encounter different conditions, especially during network congestion or state changes.
- Identical transactions can consume different gas amounts - Gas consumption varies based on network state, storage costs, contract interactions, and EVM optimization changes between blocks.
- Higher gas prices don't guarantee mining priority - Network congestion, miner policies, and transaction replacement mechanisms can cause high-fee transactions to remain unmined while lower-fee transactions are processed.
- Smart contracts can be modified through various mechanisms - Proxy patterns, upgradeable contracts, and admin functions can alter contract behavior even after deployment.
- ETH total supply can decrease through burning - EIP-1559 introduced base fee burning, and various other mechanisms can destroy ETH, reducing total supply over time.
- Anonymous and found art exists - Folk art, ancient artifacts, and found objects may have unknown or multiple creators.
- Collaborative art is common - Many artworks involve multiple artists, assistants, fabricators, or collective creation processes.
- Art has diverse price points - Original art ranges from affordable local pieces to museum-quality works at all price levels.
- Many artworks are untitled - Artists often prefer viewers to interpret works without title-based preconceptions.
- Artworks cross multiple categories - Mixed media, interdisciplinary, and hybrid works resist single categorical classification.
- Contemporary art requires skill and concept - Modern art involves complex ideas, technical innovation, and cultural commentary beyond traditional craftsmanship.
- Much music exists only in oral tradition - Many folk traditions, improvisational styles, and cultural practices never use written notation.
- Musical notation systems are culturally specific - Western staff notation can't adequately represent Indian ragas, Arabic maqams, or microtonal music.
- Many musical traditions ignore harmony - Monophonic chant, some folk music, and percussive traditions focus on rhythm, melody, or timbre instead.
- Scales vary dramatically across cultures - Pentatonic, chromatic, microtonal, and non-Western scales organize music differently than major/minor scales.
- Music and dance are often inseparable - Many cultural traditions combine music and movement as unified art forms.
- Amateur and community music is widespread - Most music-making happens outside professional contexts in homes, communities, and informal gatherings.
- Full-stack developers have limitations - No developer can be truly expert in all layers of modern software stacks due to their complexity and rapid evolution.
- Individual productivity varies by context - A 10Γ programmer in one domain may be average in another due to domain knowledge and tool familiarity.
- Programming combines engineering and craft - It involves systematic methodology like engineering but also creative problem-solving and intuitive design.
- Domain expertise doesn't transfer easily - Finance programming requires different knowledge than game development or scientific computing.
- Technical expertise doesn't equal general knowledge - Programming skills don't make someone more knowledgeable about politics, medicine, or other domains.
- Code authorship involves tradeoffs - Writing custom code gives control but requires maintenance; using others' code saves time but adds dependencies.
- Performance has multiple dimensions - Algorithmic complexity, memory usage, network latency, and user experience all matter in different contexts.
- Cross-cutting concerns need early consideration - Security, internationalization, and localization are expensive to add after initial development.
- UX requires dedicated expertise - Good user experience design is a specialized skill set separate from backend development.
- Falsehoods are infinite and evolving - New misconceptions emerge constantly as technology and domains evolve, making complete enumeration impossible.
- Most falsehood lists become outdated - Authors rarely maintain lists as domains evolve, leaving them incomplete or incorrect over time.
- Reading lists provides awareness, not skill - Recognizing problems is different from knowing how to solve them in practice.
- Lists don't create domain expertise - True expertise requires experience, practice, and deep understanding beyond memorizing pitfalls.
- Authors still make listed mistakes - Knowing about pitfalls doesn't prevent falling into them under pressure or in unfamiliar contexts.
- Everyone holds misconceptions - Cognitive biases and incomplete information mean all professionals, including experts, maintain false beliefs.
- All professionals face domain misconceptions - Engineers, doctors, lawyers, and other fields have their own "falsehood lists."
- Belief change is difficult - Cognitive biases, confirmation bias, and social pressures make changing established beliefs challenging.
- Programmers aren't universally better learners - Technical skills don't automatically translate to expertise in unrelated fields.
- Programming professionalism varies widely - The field includes everyone from disciplined engineers to independent contractors with varying professional standards.
- Industry experience differs from programming knowledge - Professional programming involves business requirements, team coordination, and maintenance beyond pure coding skills.
- Perfect name storage is impossible - Any system will make compromises in representing the full complexity of global naming systems.
- Date and time libraries frequently contain bugs - The complexity of time zones, DST rules, leap seconds, and calendar systems means most libraries have edge cases and errors in their implementations.
- Geographic databases lag behind real-world changes - Construction, natural disasters, political changes, and development constantly outpace database updates.
This comprehensive knowledge base contains 243 fundamental facts about system complexities organized into 6 major categories:
- ποΈ Fundamental Data Types (71 facts) - Human identity, time systems, text/i18n, financial data, geographic data
- π Communication and Integration (47 facts) - Networks, email, web development
- βοΈ Software Engineering Practices (40 facts) - Languages, development processes, testing, storage
- π Security and Reliability (28 facts) - Authentication, validation, performance
- π’ Domain-Specific Complexities (35 facts) - Economics, cryptocurrency, creative content
- π§ Meta-Knowledge and Professional Development (22 facts) - Programming philosophy, learning, industry realities
Each fact represents a real-world complexity that developers encounter, backed by concrete examples and documented in the original falsehoods literature. This comprehensive reference helps developers understand the intricate realities of building robust systems in our complex world.
All credit for identifying these important system complexities goes to Kevin Deldycke and the contributors to the Awesome Falsehoods project. This document simply reorganizes their excellent work from a deficit-focused ("things you shouldn't believe") to an asset-focused ("things you should know") perspective.
The original project identified these misconceptions through careful analysis of real-world systems, making it an invaluable resource for developers who need to build software that works reliably in the messy, complex real world.
This work is released under CC0 1.0 Universal (public domain), following the license of the original Awesome Falsehoods project.
See the LICENSE file for the full license text.
This comprehensive document was automatically generated using Claude Code by systematically analyzing and transforming the misconceptions documented in the Awesome Falsehoods project into positive, educational facts.
Process:
- Extraction: Analyzed 26 individual falsehoods articles from the original repository
- Transformation: Converted each misconception into a corresponding positive fact with explanatory context
- Organization: Creatively grouped 243 facts into 6 logical categories for maximum educational value
- Formatting: Applied consistent structure with proper Markdown hierarchy and emojis for navigation
Transformation Philosophy: Instead of focusing on what programmers shouldn't believe, this document presents what they should know about real-world system complexities.
The human insight and domain expertise came from the original Awesome Falsehoods contributors. Claude Code provided the systematic analysis, creative reorganization, and positive reframing that makes this knowledge more accessible and actionable for developers.
Because every developer deserves to understand how systems really work. π