Archive for April, 2009

Code Monkies

Thursday, April 23rd, 2009

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.

Sequential versus random access

Sunday, April 5th, 2009

It’s inevitable that clothes get dirty with time. It’s inevitable that you have to change out of your dirty clothes and into clean clothes. It is inevitable that the dirty clothes will need to be washed. I can accept these three principles as laws of nature without needing all the math. Unfortunately, it’s also inevitable that, when all is said and done, the clothes will come back to me. Why is that so bad? It has to do with storage. At the foot of my bed, and about a foot away from my door, there’s a fancy wooden dresser that keeps my clothes and other items. It has six drawers. The two on the top row house an odd collection of bits and bobs, such as pictures, letters, lethal weapons, a hard drive or two, and a deck of cards. Below that is the underwear and sock drawer, which, coincidentally, also has a Shirasaya Wakizashi. Below that is a drawer full of books that I don’t read. Below that, my shirts. Below that, my pants.

Now, I really hate putting my clothes away. I hate getting them out too. Why? What’s so bad about my setup? Well, sequential access doesn’t facilitate my workflow. It’s very inefficient that I have to stack my clothes sequentially when I don’t have any fixed outfits. This would be easier if I could stack them in such a way that I would always be able to take the top item from my shirts and pants drawer, but I like to mix things up.

I have concluded that random access clothing storage (RACS for short, or “closet space” if you want to sound boring) is definitely the way to go. My RACS capacity is unfortunately very limited, so I will have to continue using sequential access clothing storage. I am currently looking for funding and sponsorship for large-scale usability tests to come up with new innovations in RACS. MIT has shown interest. If you want to sponsor me or send me money, please contact me via comments and I will surely get back to you.