You can’t learn everything from scratch practically; you need to stand on the shoulder of giants. These articles were very insightful; either it’s a clear writing that shares my already-held belief or something that reshaped my thinking. I’ve collected them over the years. I’ve given short descriptions to most links.

It’s a bookmark page updated once in a while.

By Authors

Eric S Raymond

Renowned hacker¹. He’s written a lot about Unix philosophy including The Art of Unix Programming and The Unix Koans of Master Foo.

• How to Become a Hacker: detailed treatise on traits of great hackers
  • FAQs on Hackers: follow-ups on doubts you might have on above
• How to Ask Questions The Smart Way: please read this if you haven’t the experience of asking (good) questions; not just via digital mediums
  • Short, Self Contained, Correct (Compilable), Example: come up with this before asking programming questions
  • Help Vampires
• Compactness and Orthogonality: two very important concepts for programmers and architects

Joel Spolsky

Co-founder of StackOverflow.com, Product Manager of Trello, Program Manager of Microsoft Excel, founder of Fog Creek.

• The Perils of JavaSchools: diluting programming curriculum with easier languages replacing powerful languages, abstracting away the underlying machine, is a bane
• Things You Should Never Do, Part I: explains why against scrapping a working system and rewriting it from scratch (instead of incremental fixes) is almost always a blunder
• The Law of Leaky Abstractions: all designs draw the line somewhere and are bound to leak, letting the abstracted show through the abstraction
• Making Wrong Code Look Wrong: bring all relevant information about a line of code physically as close as possible to improve readability, avoid bugs and increase productivity; talks about Hungarian notation, macros and exceptions too
• Can your programming language do this?: in praise of functional languages and the meta-programming features they sport
• The Gorilla Guide to Interviewing: explains good interviewing process with clear examples and checkpoints
• Don’t Let Architecture Astronauts Scare You: avoid analysis paralysis and get down to real work as the latter (giving tangible output/product) almost always trumps former (giving confusions, ideas but just vapourware)
  • The Duct Tape Programmer: similar to above, advocates on getting job done with boring tech that’s easy to maintain instead of overthinking and using niche stuff most wouldn’t want to maintain
• The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!): minimum concepts you’ve to know about Unicode when working with text

Jeff Atwood

Co-founder of StackOverflow.com.

• Inherits Nothing: advocates composition over inheritance
• Shall I Call it… SomethingManager: avoid vague names; employing proper conventions help clarifying your code and improve its health
• The Broken Window Theory: ignoring one issue, and letting it slip by leads to poor software health as it becomes a habit and in no time we’ve lots of issues unattended
• The Best Code is No Code At All: more code = more bugs; minimalism for programmers
• The Delusion of Reuse: avoid over-engineering in the name of code reuse as it’s seldom done; this is similar to Write Games, Not Engines
  • Stop Future-Proofing Software
• Code Smells: list of code smells – questionable idioms or patterns – for easy reference
• Don’t be Afraid to Break Stuff: encourages programmers to poke around, make mistakes and learn instead of treading softly around code worrying about existing design/architecture breakage; problems of magical thinking
• Are You a Doer or a Talker?: against analysis paralysis and getting the job done, even if it’s not great
  • Good Programmers Get Off Their Butts: against over planning and how software development is an iterative, not theoretical, process
• How to Hire a Programmer: programmer interviews should be about real programming; give the design and implementation of a small piece in your current project, discuss result and hire
• Nobody’s Going to Help You, and That’s Awesome: why self-help books can only give tips but not drastically change anything; self-motivation and elbow grease does; real change comes from within
• Regex: Now You’ve Two Problems: why regular expressions are a good tool but apply it at the wrong place leads to more problems than solutions
• What’s Your Backup Strategy: talks about backup stratgies for a home

Paul Graham

Co-founder of Y Combinator (the startup seeder) and Hacker News. His work/writings on Lisp are popular too.

• The Bus Ticket Theory of Genius: having obsessive interest in something just for its sake, without any gains, distinguishes geniuses from normals
  • The Value of Learning “Useless” Things by Scott H Young: explains how having interest in random things actually come together when you don’t expect
• Beating the Averages: how using Lisp when most weren’t gave Viaweb an edge over competitors – this is a departure from using boring tech which I believe is better, but it’s a nice read

Randall Munroe (XKCD)

Super popular web comics on programming. explainXKCD.com details each comic.

• Standards: how standards proliferate and doesn’t fully solve the compatibility problem
• Duty Calls: arguing on the internet (or elsewhere) is pointless and never-ending; we don’t learn from a disagreeing perspective but impose our ideas without listening; programmers strongly believe in what they believe; alternatively, being a keyboard warrior ruins one’s happiness in the real world
• Real Programmers: parody on how programmers are weighed by their editors than their code and the versatility of Emacs :)
• Wisdom of the Ancients: parody about landing on a page with the exact question you’re seeking an answer for, with no answers

James Hague

• Organizational Skills Beat Algorithmic Wizardry: how asking mind-bending, hardly used in day-to-day clever algorithm/data-structure/puzzle question is pointless and how organizational skills are more important for programmers; very relatable
• Do You Really Want to be Doing This When You’re 50?: how programming for a profession is neither desirable nor rosy
• Constantly Create: do what’s natural to you and keep creating; don’t try to a perfectionist, volume not perfection; don’t cave in to audience/review pressure, do it for yourself
  • Why Trying to Be Perfect Won’t Help You Achieve Your Goals (And What Will) by James Clear
  • The Perils of Future-Coding: most insidious form of tech debt; over-engineering, second-system syndrome, over-generalized code
• How Did Things Ever Get This Good?: just pick the tool of least resistance and get to work instead of wasting time

Noel Llopis

• Start Pre-allocating and Stop Worrying: when game making, stop worrying about memory allocation strategies and start pre-allocating
• What’s Your Pain Threshold: build/test times breaking programmer flow
• Data-Oriented Design (Or Why You Might Be Shooting Yourself in The Foot With OOP): benefits of DOD
  • Explaining Data-Oriented Design: further explanations on DOD

Misc

• OMG Ponies!!! (a.k.a Humanity: Epic Fail): funny but meaningful exposition on bad decisions that make life of programmers hard
• Choose Boring Technology: choose simple, boring and time-tested tools that’re easy to reason about and maintain than some niche tech only elites know
  • Orthodox C++: the subset of C++ that’s better understood and helps with maintainability
  • Why I Write Games in C (yes, C) gives a clear exposition on why C still has many advantages over other contending languages for a game programmer
  • One Year of C talks about a key advantages of C over C++: less anxiety
  • Follow Boring Advice is the meta-concept
• The Rise of “Worse is Better” argues how “worse-is-better” philosophy (followed by C and Unix) is better than “the-right-thing” (followed by Common Lisp); how former has better survival characteristics, etc.
• What Color is Your Function: explains how async programming has introduced two classes of functions which can’t be mixed
  • Red & blue functions are actually a good thing: counter point to above idea
• Write Games, Not Engines: writing games, and many of them, gives you enough insights eventually it distil reusable parts into an engine; don’t hurt yourself doing it the other way around
  • Make Games Not Engines… to learn Engines
• Teach Yourself Programming in Ten Years - Peter Norvig’s excellent piece on practise
  • The Forty-Year Programmer - Great insights (and useful tips) from an experienced developer
• Your Brain on the Internet — Multi-Tasking Research: on the horrors of continuous partial attention due to multi-tasking, smartphones and internet.
• Essays on programming I think about a lot: a page similar to this one
• The Rise of User-Hostile Software: explains the rampant problem with proprietary, tracking software crippling the industry