So have I observed:

• A good Code Monkey should know C++, Java, or both. (I have evaluated C# as well, but a lot of .NET and Mono programmers seem genuinely interested in getting things done, so they are therefore disqualified.) As a bonus, a good Code Monkey should take classes on either language. These classes are perfect because they don’t actually teach you anything.
• A good Code Monkey should disregard most other languages, except as toys, and should become familiar with the word “powerful” (but they should not give it any substantial definition in an argument). They should, however, avoid words like “expressive” (and any occurrence of the word should be remapped to “toy”).
• A good Code Monkey knows that if it can be done in 5 lines of code in a toy language, it deserves to be done in 50 in a real language.
• A good Code Monkey, further, knows that programming languages were not made for humans; they were made for computers.
• A good Code Monkey knows that programming languages only exist as a source of income. It is not, as toy programmers seem to spout, about solving interesting problems, culture, art, history, fun, or anything intellectual (unless followed by property). It is only about the enterprise.
• A good Code Monkey knows that if it does not exist in C++ or Java, it is probably not worth it, because all you need are pointers and long class names.
• A good Code Monkey should learn the object oriented paradigm, because it is the only one that matters in an enterprise environment. However, they should not be lured into toy languages that utilize the object oriented paradigm in non-standard ways (see Ruby, a toy language): It is only necessary that they can create deep class hierarchies.
• A good Code Monkey should also never be tempted to learn other programming paradigms, because if they want to make it in the world, there is only one way that they are required to think.
• A good Code Monkey knows that a strong language has two key features: static typing (because all errors happen at compile time) and native machine code compilation (Java has been forgiven). As an added bonus, the more code that must be produced to have a working solution means that it is a stronger solution.
• A good Code Monkey is able to judge a language based on the development environments that are available for it. As an added bonus, the harder it is to write code in a language without the full support of an enterprise-class IDE, the better the language is.

Here is another set of articles with which to feed your brain. This time around the main focus of my article-scrounging is history and conduct, although a few general programming articles are still there. History is especially important for programmers to understand because it gives us a basis for why things are the way they are today. Last time, I focused on dynamic programming languages (programmer brainfood, part 1).

How to Disagree

We all disagree on things. Sometimes we get carried away, or don’t exactly know how to disagree. This article by Paul Graham is a great overview of the argument pyramid, and a great set of guidelines for your next argument!

Let’s Talk About Python 3.0

Although this article is focused on Python 3.0, the introduction is very insightful and applicable to many areas of life, programming included. (And if you’re interested in Python, go ahead and read the rest as well.) I had always agreed with the lesson of the introduction in some way or another, but reading it there really put things into perspective for me: reasons are important.

Execution in the Kingdom of Nouns

Another long one by Steve Yegge. This time he’s focusing on “noun oriented programming” (which some also affectionately call “object obsessed programming”).

Things You Should Never Do, Part 1

Joel Spolsky talks about a big mistake that a lot of people have made, and I’m no exception: throwing away code. “It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time.”

How To Become A Hacker

“There is another group of people who loudly call themselves hackers, but aren’t. These are people (mainly adolescent males) who get a kick out of breaking into computers and phreaking the phone system. Real hackers call these people ‘crackers’ and want nothing to do with them.” Eric S. Raymond, long-time Unix hacker and author, presents an article and FAQ about (real) hacker culture.

The Art of Unix Programming: Chapter 1, Philosophy

Although it’s worthwhile to read the entire chapter, the focal point here is the list of rules that support the Unix philosophy. It’s filled with software design wisdom. Some of my favorites are “separate policy from mechanism” and (paraphrasing) “a programmer’s time is expensive; a machine’s time is not.”

The Art of Unix Programming: Chapter 2, History

Even if you have never used a Unix descendant, such as Linux or BSD, it has such a rich history that it is worth knowing. The birth of the Internet, the C programming language, and the Open Source Movement are all closely related to Unix. (The book is also available as a pdf.)

One of my favorite pastimes is scouring the internet for stuff to read. Much of the time I search for interesting articles about programming (in a broader sense than “just writing code”). These are the fruits of my labor. (This is taken from a post I made on a forum.)

Teach Yourself Programming in Ten Years

Many books claim to teach technical subjects in so-and-so days or hours. Peter Norvig disagrees with this approach and instead offers his own recipe for success, which includes teaching yourself over a span of ten years — not days.

Knowing Java is not knowing much

This article puts forth the idea that simply knowing a language doesn’t mean that you know a whole lot, whether it be Java, C, or something else. It’s a good, brief message.

Design Patterns of 1977

I’ve seen a lot of people try to throw design patterns around to make things less painful, and while well-implemented ones can help out a whole lot, it doesn’t address a core issue: Design patterns show a deficiency in the language.

Static Typing, Dynamic Language Performance, V8 and Tracing JITs

“For optimisation, more is known about a program written in a dynamically typed language at runtime than is known about programs in statically typed languages at compile time.” Dynamic languages are getting much faster. This article drives the point that performance needn’t be a trade-off, and that the more you know about a program’s characteristics at runtime, the more it can be optimized.

Dynamic Languages Strike Back

This is an entertaining and long (transcribed) talk that Steve Yegge gave earlier this year. It goes over a *lot* of stuff (when he’s not rambling ) and may take a while to read through, but it’s still enjoyable.

Beating the Averages

Paul Graham argues that all languages were not created equally, and shares what he believes “power” actually means. This is one of my favorite articles, and I highly recommend it to all programmers. (It is at least worth reading the “blub paradox” section.) He has other interesting essays posted on his website as well.

Write more to write better

From the comments: Someone once asked Somerset Maugham if he wrote on a schedule or only when struck by inspiration. “I write only when inspiration strikes,” he replied. “Fortunately it strikes every morning at nine o’clock sharp.” Not strictly for programmers, but just as effective!

Strong typing vs. Strong testing

Bruce Eckel of “Thinking in [Java, C++]” fame offers the argument that strong testing, even in dynamically typed languages, trumps the presumed safety of static type systems. (Note that “strong typing” here refers to static typing.)

Have some of your own? Feel free to share them!