Don’t Call Yourself A Programmer

I’ve always hated the term “Programmer.” Like a craftsman, I’m a Developer.

Patrick McKenzie has a great writeup on this:

Engineers are hired to create business value, not to program things: Businesses do things for irrational and political reasons all the time (see below), but in the main they converge on doing things which increase revenue or reduce costs.

Producing beautiful software is not a goal. Solving complex technical problems is not a goal. Writing bug-free code is not a goal. Using sexy programming languages is not a goal. Add revenue. Reduce costs. Those are your only goals.

I’ll add that adding perceived business value is also a goal (playing off McKenzie’s “Businesses do things for irrational…reasons”). If your boss feels happy, then you’re doing the right thing. Most of the time.

Where we run into trouble is when the boss is a micro-manager, is inexperienced and/or plain-ol-wrong. What do you do? As a professional, speak up and say what’s on your mind, diplomatically. Then do whatever the boss says, cheerfully.

Is this always the best solution? Sometimes it is and sometimes it is not. The boss that thinks for his employees is doing exactly the wrong thing, though:

by Kathy Sierra
“The more you use the reins, the less they’ll use their brains.”

What are your top commands?

Sometimes it is interesting to navel-graze. What commands do you type the most?

history | awk '{a[$2]++}END{for(i in a){print a[i] " " i}}' | sort -rn | head

Here’s mine:

95 ll
93 git
67 cd
37 vi
29 identify
15 find
12 agvtool
11 history
11 exit
10 cat

“ll” is an alias for ls -l
Interesting that I’ve been using imagemagick (identify) a lot. I’ve been formatting/sizing a bunch of images for inclusion in an iOS app, so that’s probably what that is from.

App Development in the Real World

When developing applications for mobile phones, it is easy to get tricked into thinking the emulator will accurately represent how a user will interact with the application.

This is dangerous for a few reasons.

I ran into one reason today: real devices move around. They rotate, yaw, pitch and jiggle. The emulator does not. Sure, you can rotate it and simulate a “shake,” but no way are you going to move it around like you would a real device. One app in development has two screens: a main screen and a settings screen. As long as the user keeps the device orientation the same when switching too/from the settings screen, everything is great. The problem occurs when the user is looking at the main screen, switches to the settings screen, rotates the device, and switches back. The main screen still thinks it is not rotated, so the display is messed up.

Another problem is there is no way to use the emulator as you would a real device. You wrap your fingers around your phone and type with your thumbs. You select options a certain way, you scroll, pinch, expand, and press buttons in a way that is natural for you to do so. None of that is obvious on the emulator, since it is all keyboard, with the mouse acting like a “finger.” What looks great and works great on the emulator can suddenly become clunky and hard to use on a real device.

Lots of device testing (with different size screens) is time consuming, but getting it right is important.