In any modern discussion of algorithms, there's mention of being cache-friendly, of organizing data in a way that's a good match for the memory architectures of CPUs. There's an inevitable attempt at making the concepts concrete with a benchmark manipulating huge--1000x1000--matrices. When rows are organized sequentially in memory, no worries, but switch to column-major order, and there's a very real slowdown. This is used to drive home the impressive gains to be had if you keep cache-friendliness in mind.

Now forget all about that and get on with your projects.

It's difficult to design code for non-trivial problems. Beautiful code quickly falls apart, and it takes effort to keep things both organized and correct. Now add in another constraint: that the solution needs to access memory in linear patterns and avoid chasing pointers to parts unknown.

You'll go mad trying to write code that way. It's like writing a short story without using the letter "t."

If you fixate on the inner workings of caches, fundamental and useful techniques suddenly turn horrible. Reading a single global byte loads an entire cache line. Think objects are better? Querying a byte-sized field is just as bad. Spreading the state of a program across objects scattered throughout memory is guaranteed to set off alarms when you run a hardware-level performance analyzer.

Linked lists are a worst case, potentially jumping to a new cache line for each element. That's damning evidence against languages like Haskell, Clojure, and Erlang. Yet some naive developers insist on using Haskell, Clojure, and Erlang, and they cavalierly disregard the warnings of the hardware engineers and use lists as their primary data structure....

...and they manage to write code where performance is not an issue.

(If you liked this, you might enjoy Impressed by Slow Code.)

Considering that every video game system ever made shipped with a physical joystick or joypad, the smooth, featureless glass of mobile touchscreens was unnerving. How to design a control scheme when there is no controller?

One option was to completely dodge the issue, and that led to an interesting crop of games. Tip the entire device left and right and read the accelerometer. Base the design around single-finger touches or drawing lines or dragging objects. But the fallback solution for games that need more traditional four or eight way input is to display a faux controller for the player to manipulate.

The virtual joystick option is obvious and easy, but it needs pixels, filling the bottom of the screen with a bitmap representation of an input device. Sometimes it isn't too obtrusive. Other times it's impressively ugly. Aesthetics aside, there's a fundamental flaw: you can't feel the image. There's no feedback indicating that your hand is in the right place or if it slides out of the control area.

There may have been earlier attempts, but Jeff Minter's Minotaur Rescue, released just over a year ago, was the first good alternative to a virtual joystick that I ran across. Minter's insight was that directional movement anywhere on the screen contains useful information. Touch, then slide to the right: that's the same as moving a virtual controller to the right. Without lifting your finger, slide up: that's upward motion. There's no need to restrict input to a particular part of the screen; anywhere is fine.

He even extended this to work for twin-stick shooter controls. The first touch is for movement, the second for shooting, then track each independently. Again, it's not where you touch the screen, it's when and how.

It's all clean and obvious in retrospect, but it took getting past the insistence that putting pictures of joysticks and buttons on the screen was the only approach.

I was originally going to call this "Undoing the Damage of a Computer Science Education," but that was too link-baity and too extreme. There's real value in a computer science degree. For starters, you can easily get a good paying job. More importantly, you've gained the ability to make amazing and useful things. But there's a downside, too, in that you can get so immersed in the technical and theoretical that you forget how wonderful it is to make amazing and useful things. At least that's what happened to me, and it took a long time to recover.

This is short list of things that helped me and might help you too.

Stay out of technical forums unless it's directly relevant to something you're working on. It's far too easy to get wrapped up in discussions of the validity of functional programming or whether or not Scheme can be used to make commercial applications or how awful PHP is. The deeper you get into this, the more you lose touch.

Keep working on real projects related to your area of interest. If you like designing games, write games. If you like photography, write a photo organizer or camera app. Don't approach things wrong-way-around, thinking that "a photo organizer in Haskell" is more important than "a photo organizer which solves a particular problem with photo organizers."

If you find yourself repeatedly putting down a technology, then take some time to actually learn and use it. All the jokes and snide remarks aside, Perl is tremendously useful. Ditto for PHP and Java and C++. Who wins, the person who has been slamming Java online for ten years or the author of Minecraft who just used the language and made tens of millions of dollars?

Don't become an advocate. This is the flipside of the previous item. If Linux or Android or Scala are helpful with what you're building, then great! That you're relying on it is a demonstration of its usefulness. No need to insist that everyone else use it, too.

Have a hobby where you focus the end results and not the "how." Woodworkers can become tool collectors. Photographers can become spec comparison addicts. Forget all of that and concern yourself with what you're making.

Do something artistic. Write songs or short stories, sketch, learn to do pixel art. Most of these also have the benefit of much shorter turnaround times than any kind of software project.

Be widely read. There are endless books about architecture, books by naturalists, both classic and popular modern novels, and most of them have absolutely nothing to do with computers or programming or science fiction.