What are the best programming articles?Part of being a good software developer is keeping current with what people are saying in the community. There are many good articles out there on the Internet about the wide subject of computer programming. What articles have you found worth your time?
Please provide the article's title, author and a link if possible.
ACCEPTED]
Teach Yourself Programming in Ten Years [1] by Peter Norvig.
A good article on what it takes to become a great programer and Peter Norvig's recipe for programming success.
[1] http://norvig.com/21-days.htmlThe Programmer Competency Matrix [1] is an excellent reference to gauge your development skills.
It's a reminder that everyone has areas they can improve.
[1] http://www.indiangeek.net/wp-content/uploads/Programmer%20competency%20matrix.htmPainless Functional Specifications, by Joel Spolsky. It's in four parts and all are good.
Fred Brooks's No Silver Bullet - Essence and Accidents of Software Engineering [1]
[1] http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.htmlThe Law of Leaky Abstractions [1] by Joel Spolsky.
[1] http://www.joelonsoftware.com/articles/LeakyAbstractions.htmlI really liked Coding Without Comments [1], from Jeff Atwood
[1] http://www.codinghorror.com/blog/archives/001150.htmlThe Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software [1] by Herb Sutter.
The biggest sea change in software development since the OO revolution is knocking at the door, and its name is Concurrency.
[1] http://www.gotw.ca/publications/concurrency-ddj.htmMaking Wrong Code Look Wrong [1] by Joel Spolsky on Hungarian Notation.
[1] http://www.joelonsoftware.com/articles/Wrong.htmlWhat Every Computer Scientist Should Know About Floating-Point Arithmetic [1] by Goldberg.
There is a PDF around
Personally, everyone should know about this one and What Every Programmer Should Know About Memory. They should make a yellow cover series with those!
[1] http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.htmlBeing the Averagest [1] by Steve Yegge on competition in programming
[1] http://steve.yegge.googlepages.com/being-the-averagestWhat Every Programmer Should Know About Memory [pdf] [1] by Ulrich Drepper
[1] http://people.redhat.com/drepper/cpumemory.pdfIts very surprising nobody posted this article from steve-yegge...
this inspired me to learn mathematics as a programmer...
http://steve-yegge.blogspot.com/2006/03/math-for-programmers.html
What to do when you're screwed [1] by Rands
[1] http://www.randsinrepose.com/archives/2004/07/10/what_to_do_when_youre_screwed.html"How to Write a Spelling Corrector" [1] in Python by Peter Norvig
[1] http://www.norvig.com/spell-correct.htmlGo To Statement Considered Harmful [1] by Edsger W. Dijkstra
[1] http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.htmlExecution in the Kingdom of Nouns [1] by Steve Yegge.
An essay that made me re-think my attitude towards OOP.
[1] http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.htmlThe Cathedral and the Bazaar [1] has several fun articles about the pioneering of Linux in the 90's.
[1] http://catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/Why numbering should start at zero [1] by E.W. Dijkstra
[1] http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.htmlSmashing Magazine's 10 Principles Of Effective Web Design [1]
[1] http://www.smashingmagazine.com/2008/01/31/10-principles-of-effective-web-design/Code Tells You How, Comments Tell You Why [1] by Jeff Atwood.
[1] http://www.codinghorror.com/blog/archives/000749.htmlJan Mikovsky on the fractal nature of UI design problems [1]. I spent a while writing code to deal with this :-)
[1] http://miksovsky.blogs.com/flowstate/2005/10/the_fractal_nat.htmlYou have a really a bunch of very good ones here [1]
Notably some of the already cited here ones, but also:
Looking back at them now, they're mostly oriented on functional programming, but I don't see Why functional programming matters [2]. If I remember other ones on another topic, I'll put them in another post.
[1] http://web.archive.org/web/20080109054858/http://www.prairienet.org/~dsb/artcls.htmI do found many of the Object Mentor articles immensely useful.
Object Mentor Articles
[1]
Raymond Chen on software development taxes [1].
[1] http://blogs.msdn.com/oldnewthing/archive/2005/08/22/454487.aspxA programmer's view of the Universe, part 1: The fish [1] by Steve Yegge
[1] http://steve-yegge.blogspot.com/2008/10/programmers-view-of-universe-part-1.htmlThey Write The Right Stuff [1], a timeless article by Charles Fishman published in FastCompany 1996.
[1] http://www.fastcompany.com/magazine/06/writestuff.htmlCoding: It's Just Writing [1] by Jeff Attwood.
A short article on writing style.
[1] http://www.codinghorror.com/blog/archives/001184.htmlPicture Hanging [1] by Colin MacDonald.
This wonderful essay on picture hanging as an analogy to software development made a huge impression on me when I first read it. The relentless accumulation of facts is just as important as talent or skill.
[1] http://www.bluegraybox.com/blog/2004/12/02/picture-hanging/Characterizing people as non-linear, first-order components in software development [1] by Alistair Cockburn
[1] http://alistair.cockburn.us/Characterizing+people+as+non-linear,+first-order+components+in+software+developmentHow to be a Programmer: A Short, Comprehensive, and Personal Summary [1] by Robert L. Read
«To be a good programmer is difficult and noble. The hardest part of making real a collective vision of a software project is dealing with one's coworkers and customers. Writing computer programs is important and takes great intelligence and skill. But it is really child's play compared to everything else that a good programmer must do to make a software system that succeeds for both the customer and myriad colleagues for whom she is partially responsible. In this essay I attempt to summarize as concisely as possible those things that I wish someone had explained to me when I was twenty-one.»
[1] http://samizdat.mines.edu/howto/HowToBeAProgrammer.html?p=1Awesome article on unicode and character sets.
[1] http://www.joelonsoftware.com/articles/Unicode.htmlAn insightful article about good software development practices - not strictly about programming as in writing code.
Continuous Integration [1] by Martin Fowler
I remember this was somewhat eye-opening when first reading it a few years ago, and have later come to consider this stuff quite essential.
[1] http://martinfowler.com/articles/continuousIntegration.htmlHow to become a hacker [1] by Eric Steven Raymond.
[1] http://www.catb.org/~esr/faqs/hacker-howto.htmlI will recommend Martin Fowler's The new Methodology [1], it is a great article about Agile.
[1] http://www.martinfowler.com/articles/newMethodology.htmlCert Secure Coding Standards [1] is a gem
Edit: fixed the link.
[1] http://www.securecoding.cert.org/confluence/display/seccode/CERT+Secure+Coding+Standards"What is Software Design" [1] by Jack W. Reeves
[1] http://www.developerdotstar.com/printable/mag/articles/reeves_design.htmlEric Sink's My life as a code economist [1].
[1] http://www.ericsink.com/articles/Four_Questions.htmlDoing Work Without Threads [1] by Ian Griffiths.
[1] http://www.interact-sw.co.uk/iangblog/2004/09/23/threadlessThe Pinocchio Problem [1] by Steve Yegge
[1] http://steve-yegge.blogspot.com/2007/01/pinocchio-problem.htmlThis is a good article on getting your first job offers.
Exploding Offer Season [1] by Joel Spolsky.
[1] http://www.joelonsoftware.com/items/2008/11/26.htmlThis is very specific to Java development, but an excellent overview of memory management issues by Attila Szegedi. Makes me want to buy him a beer :)
A day in the life of a memory leak hunter [1]
Yet another day in the life of a memory leak hunter [2]
[1] http://www.szegedi.org/articles/memleak2.htmlAnything in Hanselminutes [1], or Scott's Blog [2]. Saved my ass ongoing quite a few times.
[1] http://www.hanselminutes.com10 Useful Techniques To Improve Your User Interface Designs [1] by Dmitry Fadeyev.
[1] http://www.smashingmagazine.com/2008/12/15/10-useful-techniques-to-improve-your-user-interface-designs/Practice To Perfect: The Quality First Model [1] by Bertrand Meyer.
[1] http://se.ethz.ch/~meyer/publications/computer/quality_first.pdfThis blog post by a Google employee named Ben Sussman talks about how, due to the anonymous nature of the Internet, we programmers will accept nothing but perfection from ourselves and eachother. This is very different from other professions, where mistakes are expected to happen and people are expected to learn from them.
http://blog.red-bean.com/sussman/?p=96
XP Software Programming Paradigm [1] by Guy Lecky-Thompson.
[1] http://computerprogramming.suite101.com/article.cfm/xp_software_programming_paradigmSTEPS Toward The Reinvention of Programming [1]
"The STEPS project is setting out to create “Moore’s Law Software”: a high-risk high-reward exploratory research effort to create a large-scope-and-range software system in 3-4 orders of magnitude less code than current practice."
[1] http://www.vpri.org/pdf/tr2007008_steps.pdfHere's another article about good development practices, namely version control:
Version Control for Multiple Agile Teams [1] by Henrik Kniberg, posted at InfoQ [2]
From the introduction:
If we have several agile development teams working on the same codebase, how do we minimize the risk of stumbling over each other? How do we ensure that there always is a clean, releasable version at the end of each iteration? This paper describes an example of how to handle version control in an agile environment with multiple teams - it is the scheme that we migrated to at the company described in " Scrum and XP from the Trenches [3]".
The article talks about using short-lived devel branches to achieve stable trunk, into which goes only stuff that is done. At my work, we've generally had good experiences of applying these ideas, with two scrum teams working on one codebase. There's some overhead about the extra branching and merging (some of which can be automated away), but having stable trunk, from where a release could be made at any time, is a big plus.
[1] http://www.infoq.com/articles/agile-version-controlEvidence Based Scheduling [1] by Joel Spolsky.
[1] http://www.joelonsoftware.com/items/2007/10/26.htmlNotes on the Foundations of Programming I [1] and II [2]
By Alexander Stepanov [3]
[1] http://blazer.dreamhosters.com/papers/PAM.pdfWhat Stack Overflow Can Teach You [1] by Jeff Atwood.
This article describes eloquently the way that feedback helps you grow as a programmer, and shows how that is a key to success.
[1] http://blog.stackoverflow.com/2009/04/what-stack-overflow-can-teach-you/Any article published in Eric.Weblog [1] by Eric Sink.
For instance, one of the worthwhile articles is My Life as a Code Economist [2], which briefly describes when to fix a bug. Following picture summarizes his point of view on this topic:
Top 25 Most Dangerous Programming Errors [1]
additionally: Do stackoverflow users agree with the CWE/SANS Top 25 most dangerous programming mistakes? [2]
[1] http://www.sans.org/top25errors/The beginning of Google. This must be the research with the biggest ROI of all times:
The Anatomy of a Large-Scale Hypertextual Web Search Engine [1]
[1] http://infolab.stanford.edu/~backrub/google.htmlFire And Motion by Joel Spolsky [1]
It’s brief but true inspiration. Remember, long lines of code does not mean it’s a good program
[1] http://www.joelonsoftware.com/articles/fog0000000339.htmlYou’ll Never Have Enough Cheese [1], Atwood (2004). More about interface design and making software than programming, but I like the metaphors.
[1] http://www.codinghorror.com/blog/archives/000127.htmlChris Brumme's excellent essay on finalization in .NET [1].
[1] http://blogs.msdn.com/cbrumme/archive/2004/02/20/77460.aspxAnother excellent essay by Chris Brumme, this time on the gory inner details of the exception model in .NET [1].
[1] http://blogs.msdn.com/cbrumme/archive/2003/10/01/51524.aspxIan Griffiths again on deadlock complexities [1].
[1] http://www.interact-sw.co.uk/iangblog/2004/04/20/whatlocks"Being a Software Engineer in the Software Century" By: Barry Boehm Truly Inspirational
Effective Unit Testing [1] by Tim Burns.
Careful programmers test early and test often.
[1] http://www.acm.org/ubiquity/views/t%5Fburns%5F1.htmlArchitectural Styles and the Design of Network-based Software Architectures [1]
At least chapter 5 and 6 should be read by anyone in doing anything web related.
[1] http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htmSix Styles for Usability Requirements [1] by Soren Lauesen & Houman Younessi
I was looking into how to define usability as a requirement and came across this article. It is well written and was very helpful.
Abstract. A system can have adequate functionality, but inadequate usability because it is too difficult to use. The purpose of usability requirements is to guard against that. This paper shows six styles for usability requirements seen in practice or recommended by experts. For each style we discuss how we can verify the requirements, how we can use them during development, how we elicit the data for the specification, and to what extent the style covers the essence of usability.
[1] http://www.itu.dk/~slauesen/Papers/SixStyles.pdfThe ones that appeared in PC Techniques... Jeff Duntemann's magazine.
Pounding a Nail: Old Shoe or Glass Bottle [1] by Alex Papadimoulis. Summary: programmers have a nasty habit of helping newbies write bad code instead of encouraging better programming practices.
The Complicators Gloves [2] by Alex Papadimoulis. Summary: for any given problem, programmers have a nasty habit of overlooking simple solutions in favor of complicated, over-engineered, enterprisey solutions.
[1] http://weblogs.asp.net/alex_papadimoulis/archive/2005/05/25/408925.aspxAn article? But a book I recommend this: Code Complete 2nd Edition
