The other side of being a free electron

So my last blog post on the subject of free electon programmers seems to have been successful.  I’ve gotten responses in two forms:

  1.  This is so self-serving.  What about the other people on your team?  They have a special personality as well!
  2.  This really hit home with me.  But I still don’t really feel like it’s really helped me much.
My response to these points:  I couldn’t agree more!  Here’s the thing though:  it’s much more difficult to say what other people want.  On the other hand, what better expert is there on what you want than yourself?  That was kind of the idea behind my last post:  “if you’re struggling with somebody who has a personality like this, here’s what you need to understand”.
That said, I’ve learned a thing or two in my time that I think I can share.  Although this is mostly related to free electrons, a lot of this is useful for any programmer.

Other people have emotions

If I had to choose one area where INTPs and INTJs have the most difficulty, it’s here.  This goes beyond your typical geek social idiocy.  Heck, it hasn’t been more than a decade since it actually hit me that other people expect me to acknowledge their feelings.  Now I know this feels dumb.  And yes, you’ll still forget.  But you’d be surprised at how much this helps you get along with people.
You see, people expect you to react in certain ways when they say something.  When they tell you a story about something that’s exciting to them, show some interest no matter how inane it sounds.  When people are angry about something, empathize with them and try to find some common ground even if it’s difficult.  If it’s you they’re angry at, resist the temptation to respond in kind.  If you’re calm and rational about it, people will usually be willing to have a calm and civil discussion about things.
And this is the most important part:  if you did something wrong, apologize.  I know this can be hard, but if there’s one thing that’s never ceased to amaze me, it’s humankind’s capacity to forgive and forget.

It’s a good thing that other people don’t understand you

We’ve all been there before.  You have to spend an hour’s worth of your time explaining the simplest and most benign thing in the world to someone else who just doesn’t get it.  If the person is truly an incompetent idiot, you should be discussing things with your manager.  Otherwise, you should take the person’s bewilderment as a complement:  you understand something they don’t and they want to learn from you.  After all, if they really didn’t want to learn from you, they’d probably just ignore you.
In fact, you’d do well to take a page from their book.  Next time you find yourself feeling that someone else’s opinion is the stupidest thing ever, don’t criticize them.  At least not immediately.  Instead, ask questions to get at why it is they feel the way they do.  You never know, they could have seen something you haven’t.  You see, not only is it a good thing that people don’t understand you, but it’s also good that you don’t understand other people.

Fight the urge to always go it alone

Most of the time, it’s easiest for me to just go off on my own for a week or two, code something, and come back when it’s done.  The thing is that I almost always end up with something that nobody else really gets.  You don’t have to be joined at the hip with the entire team all the time.  But it’s helpful to just spend some time at least explaining your code to someone else.  This is good even if for no other reason than it helps you learn what trouble other people are going to have with it.
Code reviews are really awesome for this.

People like you

Yes, even when you’re being a jerk.  There have been several occasions where I’ve gotten into some rather heated arguments over mundane issues with people that were admittedly my fault.  And not once has anyone died because of it.  You see, if I had a choice between working with people who disagreed with everything I say or working with people who love all of my ideas, I’d go with the argumentative asshole every day.  People who think critically about other peoples’ ideas are a rare asset for a software company.  And your coworkers will appreciate this if they truly want to do their jobs.

Choose your battles

Free electrons have a very ordered way of looking at the universe.  We tend to get frustrated if something disturbs that way of thinking.  And that’s led me to some long arguments.
Next time you get into an argument with someone, ask yourself this:  “If I just let this person win, how big of a deal will it really be?”  If your answer is “not a big deal”, then just let them have their way.  If you can’t answer the question, then you probably are arguing over nothing and should let them have their way.
However, if your first instinct is “this is a huge deal” and you can explain why, then stick to your guns as much as possible.  Generally, people will be willing to cede the important fights to you if you stick to this strategy.


Admittedly, I’m borderlining on making free electron programmers the new “duct tape programmers”.  If that’s the case, then so be it.  If there’s one thing that nobody can say about Joel Spolsky’s piece on JWZ, it’s that people didn’t consider his way of thought.
However, I’d like to hear feedback.  What other piece of advice do you have for programmers like me?  Is there anything else that I’m missing or getting wrong?

How programming language webpages should be designed

A while back, I asked a question on Stackoverflow that taught me something (other than what programming languages are fun to work with). A lot of programming language authors just aren’t very good at marketing their languages.

There are a lot of programming languages out there that I wanted to try out, but couldn’t figure out an excuse to spend my time on them. And that’s pretty sad considering how much I like trying new languages out.

Therefore, I’d like to present to the world my ideal website for programming languages: the Ruby webpage. In fact, I have to admit that if I were trying to decide between Python (my favorite programming language) and Ruby today, I’d easily choose Ruby just based on their website. And that would be sad considering how much I love Python.

Let’s take a look at why this is.

Show me the code!

I still don’t understand why this is such a difficult concept for some programming languages. The first thing I want to know is how my code
will look if I write it in your language. With Ruby, it’s right there on the first page.  Now try doing the same thing on the Python webpage.  Not as easy is it?

Even if you don’t want to put it on the first page, it should at least be reachable using one click on the first page.  See the Scala webpage for an example of this.

Feature lists are useless, documentation is priceless

Hey, your language is cross-platform, has object-oriented and/or functional and/or concatenative and/or [insert language buzzword here] features. Good for you! Since you’ve taken a whole lot of time to provide me with great features, show them to me.

Again, I hold up Ruby as a prime example of how to do this. Right on the front page is Ruby in Twenty Minutes. This shows me all of the great features in brief code examples. And if that doesn’t work for me, I can even try Ruby out in my browser.

As an example of how not to do this, I present the Unicon webpage. From the front page, I can gather that Unicon is a “very high level, goal-directed, object-oriented, general purpose applications language”, but that’s about it.

But we just met!

And one other thing, don’t try to sell me a book. Yes, you should make it easy to find books on your programming language. No, you shouldn’t remind me of it every chance you get. I view suggestions to buy a book as being somewhat like asking me to move in with you on the first date. Yeah, I find you interesting. I’m just not ready for the commitment.

Python metaclasses in depth

Metaclasses have a reputation for being among the blackest of Python’s black magic. As it turns out, they’re actually pretty simple, but they require you to understand some concepts. There are two ways to learn metaclasses in Python:

  1. Skip the details and get straight to a useful implementation of a metaclass.
  2. Understand the core concepts behind metaclasses.

Number 1 is useful, but will only get you so far. If you really want to understand metaclasses, you need to take approach number 2.

With that in mind, I’m going to start with the basics of how classes are constructed in Python. Let’s consider the following class:

class SomeClass(object):
     x = 1
     y = 2

If you’re ready to learn about metaclasses, the above statement shouldn’t require much thought to understand. But let’s stop to think about it a bit anyway. In Python, everything is an object. Therefore, classes are also objects. But if SomeClass is an object, it must be an instance of some class. Let’s find out what that class is:

>>> type(SomeClass)
<type 'type'>

So apparently, it’s an instance of type. We just saw the most common usage of type: to query an object’s type. But have you ever read the help on that function?

>>> help(type)

Help on class type in module __builtin__:

class type(object)
 |  type(object) -> the object's type
 |  type(name, bases, dict) -> a new type

So it turns out that type is not only a builtin function, it’s also a class! How do we instantiate an instance of type? You’ve already seen the most obvious way: using a class statement. But did you know that you can create a class using type?

SomeClass = type('SomeClass', (object,), {'x' : 1, 'y' : 2})

For all intents and purposes, the above statement is equivalent to the prior definition of SomeClass. But this way is ugly and isn’t used very commonly. That said, we’ve demonstrated something: type isn’t just any class. It’s the class of classes. It’s a metaclass.

Let’s go a step further though. How does the compiler generate the dictionary that’s the third argument to type? As it turns out, classes have something in common with functions: they have local namespaces. You might have seen the locals function used like this:

def some_func():
    x = 1
    y = 2
    print locals()

If you execute this, the output is this:

>>> some_func()
{'y': 2, 'x': 1}

If classes have their own namespaces, then they must also be able to use the locals function as well:

>>> class SomeClass(object):
...     x = 1
...     y = 2
...     print locals()
{'y': 2, 'x': 1, '__module__': '__main__'}

The only difference here is that the namespace is generated at import time and passed into the type function.

So this is all interesting, but we haven’t really seen anything terribly useful yet. Let’s go further. We’ve seen that type is the class of classes. But if type is a class, then we must be able to subclass it. There are a number of reasons you might want to do this. For instance, you may sometimes want to attach a property to a class rather than to an instance. Let’s do just that:

class SomeMetaClass(type):
    def z(self):
        print 'In class property z'
        return self.x + self.y

>>> SomeClass = SomeMetaClass('SomeClass', (object,), {'x' : 1, 'y' : 2})
>>> SomeClass.z
In class property z

But we don’t want to use this same ugly notation for creating SomeClass. Python provides syntactic sugar for this. We can instead define SomeClass like this:

class SomeClass(object):
    __metaclass__ = SomeMetaClass
    x = 1
    y = 2

A more common use of metaclasses is to create a class constructor. Let’s attach z to the class directly rather than defining a property:

>>> class SomeMetaClass(type):
...         def __init__(self, name, bases, dict):
...             self.z = self.x + self.y
>>> class SomeClass(object):
...         __metaclass__ = SomeMetaClass
...         x = 1
...         y = 2
>>> SomeClass.z

As we can see, we’ve defined a constructor for SomeClass. Now let’s go a bit further. What if we want to change the base class of SomeClass? That can be done, but we have to use a __new__ method. I’m going to presume that you know a bit about __new__ methods. If you don’t, you might want to read up on them.

>>> class SomeMetaClass(type):
...     def __new__(cls, name, bases, cls_dict):
...         new_cls = type.__new__(cls, name, (dict,), cls_dict)
...         return new_cls
>>> class SomeClass(object):
...     __metaclass__ = SomeMetaClass
...     x = 1
...     y = 2
>>> x = SomeClass()
>>> x['foo'] = 'bar'
>>> x
{'foo': 'bar'}

That should hopefully give you an idea of what metaclasses are and how to use them. If you’re even more lost than you were before, don’t worry. This is just one of those things that requires an “aha!” moment. You might also want to check out Michael Foord’s great Meta-classes Made Easy for a different perspective.

The “free electron” programmer

I have to say that I really liked reading Rands in Repose’s excellent blog post about “free electron” programmers.  Unrelated side note:  Did you know that Simply Hired has a graph showing the median salary of these kinds of programmers?  Apparently the median salary is around $78,000.

At any rate, I feel that this is a subject I can add to.  I say this because I consider myself a free electron.  And I’m not saying that to be cocky either.  It’s just that Rands’s description of the free electron is almost a word-for-word description of the Architect (INTP) or maybe the Mastermind (INTJ) personality type.  I just so happen to be an Architect. I think that people with both of these personalities were almost born to be programmers.  They’re naturally inquisitive and love nothing more than to understand complex systems.  But they can really be destructive if not dealt with properly.  And they’re so rare (about 1-5% of the population) that many people may simply be unaware of how to deal with them.
At any rate, here is a list of general pieces of advice to get along well with your free electron (in no particular order):
Listen to them
Alright, so I lied when I said this was in no particular order (at least for this point).  This is the single most important thing to do to get the most use of your free electron and to keep your free electron happy.  Yes, we come up with some rather zany ideas that seem to not be grounded in reality.  And a lot of the time, that may be true.
But you also need to understand that free electrons have an unmatched ability to understand complexity.  This means that oftentimes, they may understand something you don’t.  And sometimes, it is difficult to put complexity into words.  Thus, what seems like a zany idea to you might actually be a perfectly rational way of looking at things when you understand all of the details.
But you shouldn’t just listen to them when they’re right.  You also need to give them thoughtful consideration when they’re quite obviously wrong too.  Nobody likes not being listened to, but free electrons hate it worse than anyone else.  And more to the point, they’re driven to make people listen to them by whatever means are available.  If this leads to an overly long and drawn-out discussion of whether to use camel-casing or underscores, then so be it.
Be logical
A lot of people will come to the conclusion that free electrons are hard to get along with and inflexible.  However, this is a person who hasn’t learned to frame their arguments properly.  A lot of people tend to put things in emotional terms.  Emotional arguments have little impact on free electrons.
Remember how I said that free electrons hate not being listened to?  Responding to a free electron’s arguments with emotion is equivalent to not listening to them.  However, you will find that a free electron is willing to listen to arguments about how their idea is the stupidest thing you’ve ever heard as long as you can present logical reasons why.
Conversely, they’re likely to not take others’ feelings into consideration in discussing things.  Therefore, you need to understand that if they say something that comes off as insulting, they probably didn’t mean it as such.  If this bothers you, it is helpful for you to point out when they’re being rude as long as you do so calmly.
They may not realize how talented they are
Remember how I said that there are two personality types that can be free electrons?  Here is the area that differentiates them.  Masterminds tend to be very much aware of their talents, so this section doesn’t really apply to them.  Architects usually aren’t.  They assume that every programmer can understand what a monad is just by reading the wikipedia page on them.  Sometimes, you just need to get them to slow down for the programmers who don’t spend their weekends writing compilers for fun.
They need direction sometimes
Free electrons tend to be focused on the big picture.  However, they’re not very detail-oriented.  This means that they tend to be great at getting an overall framework for a solution set up.  They tend to not be very good at putting the finishing touches on things.  Thus, free electrons tend to be good at starting projects.
This is all well and good, but sometimes you need them to stick with something.  Typically, a free electron will want to move on to something else when they feel they’ve learned everything they can from the current project.  You can help to counteract this effect if you can point out other interesting things that are still left to do in the current project.
You have to be careful with this approach though.  If a free electron is forced to work on a project they find uninteresting, they will find a way to make it interesting.  You don’t want to assign them to a little modification of one method just to find out that they’ve changed your piece of software’s entire architecture.
…but most of the time you should just leave them alone
Free electrons are very autonomous individuals.  They’ll probably dislike pair programming and hate micromanagers.  But that’s fine because free electrons can do amazing things with little to no direction.  When teamwork is required, you should keep interactions with the free electron mostly at the high level.  If there’s too much tedium involved, they’ll probably turn very toxic very quickly.
Also bear in mind that free electrons tend to keep their thoughts to themselves.  In other words, if it seems like there are 10 levels of intricacy behind everything they say, it’s because there is.  There are two things that can cause this:
 1. If your free electron is an Architect, they could very well assume that those 10 layers of complexity are obvious to you.
 2. They may just not feel like explaining it to you.
While number 2 makes free electrons sound like snobs, take a moment to think of the world from their perspective.  As stated, free electrons are ridiculously rare.  That means that they’ve spent their entire life trying to explain their way of thinking to people who will probably never be able to understand it because they just don’t think the same way.
This leads them to unconsciously come to the conclusion that explaining things to people is hard and avoid it at all costs.  This makes getting the full story out of a free electron a bit like pulling teeth.  The best approach is to show some initiative.  Get them to talk about those subjects in normal conversation.  Chances are, they’ll be more than happy to share if they feel you’re genuinely interested in the subject and not just asking about it because it’s your job.
They can’t do it alone, no matter how much they claim otherwise
Free electrons can do amazing things that no other engineer can do.  But they have weaknesses that need to be balanced out.  This means they need good managers to help direct them and good engineers who can make up in the areas they lack.  The best free electrons are the ones who realize this.  Don’t expect them to ever admit it to you though.

Heroes and Villians, or electrons and duct tape don’t mix

One of Carl Jung’s great contributions to the field of psychology is the idea of the archetype.  There is a boatload of psychology books on this subject out there if you have a lot of free time to spend deciphering psychological jargon or just happen to also have a PhD in psychology (in which case this blog post wouldn’t be useful to you anyway).  Here’s the thing though:  you already know what an archetype is.  You just haven’t put a name to it.

Think of the characters that are in every story.  There’s always a hero and a villain.  They also have a supporting cast of other characters.  You have the parent (metaphorically speaking – they don’t have to be someone’s actual parent), a good natured mentor who protects people (think Obi-Wan from Star Wars).  Then there’s the senex:  the wise man who treats his proteges like crap because that’s the only way to learn (think of the sensei in any martial arts movie).  You’ve also got the Puer, the good natured, innocent child-like character (just about every role Adam Sandler plays).  And there’s also the trickster:  the child-like character who causes trouble (Kevin from Home Alone). These are all archetypes.

Not only do we see these characters in fiction, but we also see them in real life too.  Here’s where things get interesting though.  We all share these archetypes, but we put different people in each role. Your hero might be my senex.   Your puer might be my villain.

The reason?  We place people in the role of these archetypes based on ourselves, not other people.  You might feel that a part of your personality is particularly child-like and associate it with the puer when you see it in other people.  Seeing through this illusion can be difficult.  However, it’s usually very liberating to see through this.  While others are always looking for heroes and villains and such, you get a chance to see people as they actually are.

It’s no coincidence that each of these archetypes has a “good” and “bad” version, either.  The “good” version is usually more conscious. The “bad” version usually comes from the unconscious.

It might be easiest to see this with an example. Compare Joel Spolsky’s blog post about Duct Tape programmers to Michael Lopp’s essay on Free Electron programmers.

Ostensibly, these programmers are both really productive. But the similarity ends there. Spolsky’s Duct Tape programmer is someone who doesn’t go with the latest fad. They’d rather just get things done than spend their time worrying about what’s fashionable. They also don’t spend too much time worrying about making their code perfect because they want to ship. Lopp’s Free Electron programmer on the other hand “defines the bleeding edge”. They can get things done, but you have to be careful. They’ll rewrite your database layer from scratch for that .1 release.

What’s most interesting is that they both refer to the same person (unless Lopp means someone else when he mentions Netscape’s Free Electron — UPDATE: apparently he did, jwz claims to not be able to ride a unicycle). Now Lopp actually worked with Zawinski so his version might be more accurate, but I suspect that both are projecting themselves onto him at some level.

In other words, these kinds of writings tell us more about the author than they tell us about what makes a programmer good. This is what we do when we talk about our Hero: emphasize its strengths while we gloss over its weaknesses. This makes sense if you realize that the Hero essentially represents our ego. Any attack to the Hero is an attack on the ego.

The Cult of Not Done Manifesto

It seems to me that hacker culture seems to be focused too much on doing lately. There’s nothing wrong with doing things. In fact, I like doing things quite a bit. However, not a week goes by when I don’t see another blog post about how to be more productive and get more done.

I sometimes wonder if hackers are the new teenage girls in a certain sense. Teenage girls are constantly bombarded with images of women who are so beautiful in ways they’ll never be. Of course, we’ve all heard of the negative effects this has. Girls become anorexic and go on unhealthy diets just so they can be beautiful. They’re too caught up in being like supermodels that they have difficulty accepting that they really don’t have to be supermodels to be beautiful.

Us hackers are a lot like that. Hacker news is constantly bombarded with stories about hackers getting amazing things done. Everytime I’ve been to a hacker meetup of some kind, the first and only question is always some variant of “So what are you working on?” Of course the answer is supposed to be either you’re putting in hours and hours on your startup or you have a day job and another “job” that is your real passion.

I’m not saying that there’s anything wrong with some constructive encouragement. However, I think we’re collectively going down the wrong path. The path of having spent our youths solving a ton of problems that people probably won’t even care about 10 years from now anyway.

So in the vein of the “Cult of Done Manifesto”, I present the “Cult of Not Done Manifesto”. This something I’ve been unconsciously writing my entire life because that’s all I’ve had:

  1. There are two stages of being: not done and less not done.
  2. Accept that no programmer has ever died from having their project be in the not done status for too long.
  3. Sometimes good things take time.
  4. Slack off. Spend time you should be spending being productive reading a blog or conversing with a friend.
  5. Your project will be there for you tomorrow. And the next day. If it isn’t, are you sure it was such a big deal anyway?
  6. Ask yourself a question: is it really that important? Will peoples’ lives be better 10 years from now because of what you’re doing? Chances are good that the answers to these two questions are the same.
  7. Just make sure to at least get something done. The Cult of Not Done isn’t an excuse to be a worthless bum.