automatic termination – thanks apple

Mac OSx Mountain Lion (10.8) has a new “feature” called auto-termination. Even the sound of it is ominous. Auto termination. This means you.

Here’s the thing Apple. I’ve been programming a lot lately. I also do photography. And build robots. And program using two or three different apps at a time. And I actually read about politics instead of listening to talk radio. And I check email. Sometimes go find weird music. I do these things on this here little Mac. Typically I have six desktops open which then become 12 desktops when I get to work and hook it up to that monitor I paid y’all a bunch to purchase.

Then I upgrade to Mac OSx Lion. Released the day before DefCon guaranteeing I could not use the laptop I had with me (not this one) because you couldn’t download the upgrade and security fixes. And the updates to all of the apps. And XCode 4.3 and now 4.4 with the Command Line Tools. Because you can’t download the command line tools alone anymore.

I leave Lightroom open if I am working on a project. It can stay open for days as that isn’t my real job. It’s just something I chew on like a bone to keep my sanity. But I want to know when I leave the bone one desktop 6 that it will be there when I get back.

Or, I used to do all of that. I did buy extra RAM after all. Now, I am auto terminated. I close the lid on my laptop and it’s like a mystery game when I get back. Hey, guess which one (1) app we decided to leave running for you!? Usually none.

So this is me venting. Stop with the auto terminating if there are any open windows anywhere on any desktop. No open windows I get (like Preview) but if Sublime is open with three files THERE IS A REASON. Leave me be.

no time for a salesman, i have a war to fight

“I have no time for a salesman right now. I have a war to fight!”

This was on the desk of an associate of mine, or one that looked very similar about 20 years ago. Still true today. We all resist change, even if that change is a Gatlin Gun that sure would come in handy in the immediate future.

why are programmers arrogant? perception or warranted?

Running a company of 30+ employees with account executives, designers, sales people, support, operations, programmers, execs, etc, it is very apparent that every role is different. Even if the same person moves from one role to another, their attitude quickly can be morphed by their new role.

Every group has it’s stereotypical achilles heal, but today I’d like to talk about the perception of the “arrogant programmer.”  To wit; how about a readme file that starts:

  • edit your bash file to alias /your/project/file/path to the download
  • add the package to your path.

Baroo? Bash file? Path? Which friggin’ path? I’ll get back to that. (But don’t worry, the answer is definitely “no” that doesn’t make sense to an experienced programmer either, except at a high level.  More on that at the end.)

Given I started the company as a programmer who learned to sell, as opposed to a salesman who learned to code or a designer who learned to code, I suspect I have a few swords to fall on myself in the process. Yet first let us consider what others say about the perception of programmers being arrogant, earned or unearned, as a whole.

One poster on Yahoo Answers asks

Why are so many programmers arrogant?

I seriously don’t get it. I am a programmer myself, but whenever I’m having an issue with my code and need help and enter an IRC help channel, everyone is so rude and just acts like if I don’t know the answer to my question already, I’m stupid… the people are always so mean and aren’t there to help but rather to show off their alleged knowledge.

And a few excerpts from the answers:

It seems that many programmers have a hard time with interpersonal skills… Because their lives lack a significant amount of human social interaction [something that makes our lives pleasurable], they derive their pleasure by feeling superior over others


There is a certain elitism amongst programmers, it’s probably knowing that they understand something a lot of other people don’t.

OK, Yahoo answers isn’t a great source for anything. So let’s consider this more reasoned post by Jay Fields:

At SpeakerConf 2009, one of the speaker’s wives asked me: Why is it that most speakers are confident, and some are simply arrogant. The question was also in the context of “software is nerdy, how can you speakers be so cocky”. I pondered for a minute and replied: When no one knows what’s “correct”, people with confidence generally win the discussion….

As I’ve said before, we’re still figuring this stuff out. I constantly try to improve my processes for delivering software. I share those processes via speaking and blogging. However, I’m definitely aware that I could be doing it entirely wrong.

Emphasis added. And to take it a step further, consider the three modes a programmer goes through by John Byrd.

All programmers of any competence go through three modes of professional development: an Arrogant mode, a Sponge mode, and a Mentor mode.

All good game programmers are born into Arrogant mode. An Arrogant programmer believes that he is personally capable of writing the smallest, the fastest, the “best” code possible, and that other programmers don’t have the depth of understanding that an Arrogant programmer does. This extreme self-confidence is the fundamental motivator for the Arrogant programmer to produce high-quality results.

Arrogant programmers maintain and defend control over all aspects of their code.


Given enough time and experience, an Arrogant mode programmer will grow out of this phase of professional development and turn into a Sponge programmer.

Sponge programmers believe that other programmers exist who have a deeper understanding of the code than they do, and Sponge programmers are committed to learning from these more experienced programmers.

Wow, that’s depressing. So any good programmer has to start out being arrogant before they can approach self actualization and… oh, I don’t know…. humility? Major bummer.

And I am *sure* that I was that arrogant programmer. I can think back on specific interchanges and realize that “yup, you were an ass that day lording your almighty knowledge over everyone to win the argument.” And how many UI suggestions did I miss? How many actual client requests that might have made the company many more millions were not mentioned because of the perception of arrogance? I don’t and will not ever know my losses from arrogance. Hindsight is so 20/20. And humility is so profitable.

Back to our not-so-victimless-crime-of-arrogance.  The readme file that starts:

  • edit your bash file to alias /your/project/file/path to the download
  • add the package to your path.

Why are those two lines useless? Because they do not compile. They completely lacks exactness. They waste time. It is pseudo code at best and assumes you have time to waste that the writer does not to give you the details. They want you to fail or prove yourself like it’s Lord of the Flies or something.

Any programmer will tell you we are too lazy to remember the syntax to do those edits.  I know I am.  They say Einstein didn’t know the value of pi  because he had it written down and could look it up. As programmers look stuff up when faced with poor documentation. Logic is what programming is about. Languages and operating systems, on the other hand, are about syntax. Humans add value with higher level logic that machines are incapable of.

Thus glazing over the details of syntax, taking time away from someone else’s higher level thinking, is motivated, in my opinion primarily (thankfully) by laziness.  Not arrogance. The truth is we can’t remember the syntax to edit your bash file and don’t want to document the variables so we glaze over it. We skip over it bluffing, pretending “you should know” when in fact we aren’t linking it because we can’t remember ourselves!

That my friends, if it is intended as arrogant or not, clearly comes across as arrogant. No two ways about it.

But to suggest that a real programmer has the method of doing so memorized would suggest that only a stupid programmer would create a short-cut in their bash file called “editbash” that opens the file in their editor of choice. My point? A real programmer doesn’t memorize that crap. Therefore, if we don’t have it memorized, the documentation isn’t really anything more than a fishing assignment that wastes someone’s time  unnecessarily. #lame

Oblique assumed knowledge to have someone “prove themselves” is nothing more than a hurdle. A mental “pay your dues or you can’t use my code” type of statement. Or possibly just lazy documentation – which when I see it internally is my hope. Arrogant people are terrible security risks because they are so easy to manipulate. Thus I prefer to think of it as lazy as opposed to defensive when I observe it within my team. Yet the external perception, regardless of motive, is still unfortunate. Working on that.

The bottom line is arrogance, be it real or perceived, sucks. If you  really  want people to use your code, then you don’t let your documentation’s excuse for brevity hide behind arrogance or  laziness.

a user is a user is a user – database design fundamentals for marketers and programmers

Even in the mainframe days we had the golden rule that every user, person, student, teacher, whatever, on the system had a record in one (1) location.

Sure there might be descriptive data in another location. It might be a central table as simple as userid-username-password-role with a one to one relationship to a “role” table that then linked to the appropriate table for that role. Kung Fu Master versus Adjunct Professor. You get the idea. In Django this is the auth_users table with a relationship to the profiles table. But it is sooooo tempting to ignore the intention of the designers of Django, to break away from their DRY principles, and come up with a different system to reduce the number of records in auth_users. Despite lessons learned from Discus, the world’s largest Django application.

I followed that law, that a user is a user is a user, and wish I could credit it to the correct professor from my mainframe days on VAX using FORTRAN 4 and then FORTRAN 77.  I was taught as early as the 80s that there was always one (1) place for humans (in a database at least). When Microsoft Access came out and everyone became an amateur DBA they suddenly created tables for “students” and “teachers” and “staff” which required duplication of data all over the place. It became so brittle that if another programmer worked on your file they had to know every field in every table. In other words – it was pathetic. I swore I would never do that again.

But I did forget. My fault. You can’t blame the young guns with two or three years of experience as they haven’t suffered the “mile in shoes over broken glass” of permissions for humans in disparate tables. Which might work, until you hire the next programmer and they go “what the F were you people thinking….?” This one is all on me.

One user. One record….. – so simple and yet so profound. It is the singularity in database design. No exceptions

That rule, “one user, one record” served and our clients well recurring revenue and a nice margin with true database integrity for over 10 years. We all made a profit. And the software? “It just worked.”

As a public post so I don’t do something this stupid again in the future, I am posting these two pages from the book  Direct and Database Marketing by Graeme McCorkell. I used it with Tendenci 1,2,3,4.x+ and it served us well for 10 years. And then I forgot. Uuuuuugh. Double+plus+dumb points for me. And unfortunately this is hurting our clients through delays which is what really kills me.

One user. One record.

A user is a user is a user.

Here is to Tendenci 5.1 being pushed out in a few weeks. Major strides in the right direction. Back towards DRY and simplicity. Simplicity is best.

pycrypto install fails on mac osx mountain lion in virtualenv

Receiving the following errors trying to install pycrypto in a virtualenv on mac osx mountain lion. Assuming the name of the virtualenv is “PROJECTVIRTUALENV” and that your project is PROJECT my first try was:

……… change into the project folder
$ pip install -r requirements.txt
……… everything installs except pycrypto
$ sudo pip install pycrypto

that also fails resulting in:

File "/Users/eschipul/.virtualenv/PROJECTVIRTUALENV/build/pycrypto/", line 278, in run
raise RuntimeError("autoconf error")
RuntimeError: autoconf error


This was a new one on me so what changed? A few things. First virtualenv and virtualenv wrapper now default the –no-site-packages, but you were using that already.

Second the upgrade from OSx Lion to OSx Mountain Lion required an update of the command line tools with xCode. I’ve tried the stand alone xCode tools and they don’t keep up with Macs updates so I have the whole bloody xCode installed on my machine. To resolve the install problem with pycrypto it needed the new compiler. Simply updating to xCode 4.4 does not solve the problem by itself.

Per a note half way down this blog post on similar installation troubles  by jiaaro you need to re-download the command line tools. From the post:

You need to install Xcode 4.4 (from the app store) and then, within xcode open  Xcode > Preferences  (or press  Cmd  +,) then open the  downloads  tab and install the  Command Line Tools.

which looks like this:

and results in this:

sudo pip install pycrypto
…. yada yada yada …. a warning or two …. then
Successfully installed pycrypto
Cleaning up…

Note that I *did* already have the command line tools installed on xCode 4.3. The upgrade didn’t match my previous config and I had to explicitly download them again. Hope this saves some other poor soul some time as it makes no sense to me. But there it is.