Super Volatile

I would ask for proof of talent. Although a degree from an ivy league university might do the trick for some, quality experience does set the good developer apart. My developer friends have loads to show to testify for their talent. For some, from past work done, for others, from apprenticeship projects, but for all, from hands on development.

How to find a programming “friend”. Tips that, when applied in real life, would almost guarantee you would die lonely.

Don’t be too critical too early. Sometimes when you arrive on a new project, there may be things that do not make a lot of sense: a choice of tool, technology or practice that no-one appears to question but to you as an outsider seems substandard. It’s worth just hanging back on that criticism just for a couple of weeks. Ask your team mates for back story and try and get their opinions too. It’s alway worth digging around for the reasons first. Then you might be in the position to change things and make a positive contribution to the team.

Tips for programmers joining new teams.

If you take the McDonald's approach and ship shit then you satisfy that need in the short-term. But you'll feel the effects in the long-term. Your code will be harder to maintain and need more attention later. It won't have a long and healthy life.

Fortunately, this elaborate food metaphor can be summarized in one paragraph.

I settled on combining all forms of input into a single system event queue, similar to the windows message queue. My original intention was to just rigorously define where certain functions were called and cut down the number of required system entry points, but it turned out to have much stronger benefits.

With all events coming through one point (The return values from system calls, including the filesystem contents, are "hidden" inputs that I make no attempt at capturing, ), it was easy to set up a journalling system that recorded everything the game received. This is very different than demo recording, which just simulates a network level connection and lets time move at its own rate. Realtime applications have a number of unique development difficulties because of the interaction of time with inputs and outputs.

Transient flaw debugging. If a bug can be reproduced, it can be fixed. The nasty bugs are the ones that only happen every once in a while after playing randomly, like occasionally getting stuck on a corner. Often when you break in and investigate it, you find that something important happened the frame before the event, and you have no way of backing up. Even worse are realtime smoothness issues - was that jerk of his arm a bad animation frame, a network interpolation error, or my imagination?

Reading the archive of John Carmack's aaaa.plan files files a bit like archeology of programming and game design. I still remember playing the games he was writing at the time.

Frequent insights about programming are intertwined with boring parts concerning tuning and racing with his Ferrari cars.

What I try to do nowadays is to implement new ideas in parallel with the old ones, rather than mutating the existing code.  This allows easy and honest comparison between them, and makes it trivial to go back to the old reliable path when the spiffy new one starts showing flaws.  The difference between changing a console variable to get a different behavior versus running an old exe, let alone reverting code changes and rebuilding, is significant.

John Carmack shares his approach to exploratory programming.

Now is the time to do the same thing for classes. From a language extension point of view, classes have much less impact on the language than modules. Yet, they have a huge impact on code compatibility and language adoption, by lowering the barrier to entry for “non-native” JavaScript programmers.

Classes in JavaScript, the subject of most heated debates in the community, is back. People behind Cloud9 are considering adding support for it in the their IDE.

The whole point of an abstraction is that it is supposed to simplify. An abstraction of SQL that requires you to understand SQL anyway is doubling the amount you need to learn: first you need to learn what the SQL you're trying to run is, then you have to learn the API to get your ORM to write it for you. In Hibernate, to perform complicated SQL you actually have to learn a third language, HQL, which is maddeningly almost-but-not-quite SQL, which then gets translated to SQL for you.

On fundamental flaws of ORM. When one reads this article it sounds obvious, but for some reason I've seen ORM used with many projects without any reflection if it's actually saving work or adding it.

There’s nothing wrong with this, by the way.  You’re in the business of unemploying people.  If you think that is unfair, go back to school and study something that doesn’t matter.

Harsh but true career advice for programmers. A lot of it may seem obvious if you have been in the industry for a while, but it's not something one can get from academia. However, the article made me appreciate the fact that I took courses in economy instead of studying computer science alone.

I mentioned that many Shapes are in property trees. These are N-ary trees, but most Shapes in them have zero or one child; only a small fraction have more than that, but the maximum N can be hundreds or even thousands. So there’s a long-standing space optimization where each shape contains (via a union) a single Shape pointer which is used if it has zero or one child. But if the number of children increases to 2 or more, this is changed into a pointer to a hash table, which contains pointers to the N children. Until recently, if a Shape had a child deleted and that reduced the number of children from 2 to 1, it wouldn’t be converted from the hash form back to the single-pointer. I changed this last Friday. I also reduced the minimum size of these hash tables from 16 to 4, which saves a lot of space because most of them only have 2 or 3 entries. These two changes together reduced the size of the “shapes-extra/tree-shape-kids” entry in about:memory by roughly 30–50%.

What Mozilla is doing to reduce Firefox's memory footprint.

Jack is a Rockstar. Jack talks about all the latest trends at all the coolest conferences around the world. Jack makes a point of starting each project with at least three new technologies. When asked to produce an internet-based backend for letting kitchen devices synchronize their list of recipes, Jack went to town. The result was a combination of Google Protocol Buffers, node.js, and Cassandra. Elegant, scalable, and totally unmaintainable.

Joel Spolsky nailed down the essence of good technical hiring in the title of his book: Smart and Get Things Done. Developers themselves tend to admire “smart” over “getting things done”. This article offers a counter perspective to that.