proomt

Search

Search posts, papers, and topics

Hall of Fame

Hall of FamePatrick McKenzie20103 min readintro

Falsehoods Programmers Believe About Names

Summary

Patrick McKenzie enumerates 40 common misconceptions programmers make about human names, showing that assumptions about uniqueness, format, immutability, and character set are all wrong. Systems should treat names as opaque, Unicode strings and avoid rigid schemas.

  • Never assume a person has a single, immutable, ASCII-only full name; names can have multiple forms, change over time, and use any Unicode characters.
  • Avoid rigid schemas like separate first_name/last_name columns; store names in a flexible way that can accommodate cultural variations.
  • Do not rely on case sensitivity, ordering, or uniqueness of names for identity; use separate identifiers instead.
  • Expect names to contain numbers, punctuation, all caps, or be in any language; design for variable length and full Unicode support.

Anyone building user profiles, identity systems, or databases needs to handle names robustly to avoid bugs and exclusion.

6/10

Related reading

  1. CodeSOD: The John Cage Variable

    This article showcases a C++ code snippet with an extremely unreadable variable name, `length4_3_3`, which is a hardcoded range expression. It serves as a cautionary tale against writing "disposable" code with poor naming conventions, as such code often ends up being reused.

    The Daily WTFthedailywtf.com1 min
  2. Lies, Damn Lies and Benchmarks

    Codename One engineers dissect why benchmark numbers can be misleading, then share concrete work on GC tuning, proper weak/soft references, and a new probing sequence for their open‑addressed HashMap that cuts miss‑probe counts from >16 k to ~1.5 per lookup.

    CodeName Onecodenameone.com20 min
  3. Reflections on Trusting Trust

    Ken Thompson’s Turing Award lecture shows how a compiler can be subverted to insert a hidden backdoor that survives source‑level inspection, and how self‑reproducing code can propagate such Trojan horses. The moral is that you can’t trust binaries you didn’t build yourself.

    Hall of Famecmu.edu9 mintalk
  4. Should you read the code, is RAG dead, and did Skills kill MCP?

    The article debunks five common AI‑tool hot takes, arguing you still must read AI‑generated code, AI fluency matters in hiring, MCP and Skills serve different purposes, RAG remains useful, and needing fine‑tuning signals a messy codebase. It offers concrete rules for reviewing generated code and integrating AI components responsibly.

    GitHub Oldgithub.blog5 minHN3