The people that I work with must sometimes see me as selfish. And who can blame them? If an idea doesn’t excite me, I’m not on board with it. Don’t get me wrong. I understand that sometimes you have to do things you don’t want to do. And when one of those moments hits you, you just have to roll up your sleeves and do what needs to be done.

…but it’s surprising how rare those moments really are. I mean really, which do you find yourself saying more:

1. “Man. I really want X, but I just can’t do that. There simply isn’t any way to avoid doing Y instead.”
2. “I really need to get X done, but I keep procrastinating. I need to get my act together.”

Judging by my highly scientific approach of recalling blog postings I’ve seen in the recent past and comments I’ve seen on Hacker News, I’d say that problem #2 is the far more prevalent problem. Now sometimes you do run into a situation where you have to deal with something bad to get something that overrides that badness. But at the end of the day, I don’t run into many moments where I just have to do something I don’t want to do. It just doesn’t happen that often.

Some of you probably still see this attitude as selfish, but I don’t think it is. You do need to focus on others in addition to yourself. But happiness isn’t a zero-sum game. Happiness is more like an infectious disease. A person who is excited will also make others excited. They’ll be giving their team their all. Likewise, a person who just isn’t happy can drag others down.

But in either situation, how often do you run into a person who is successful at something they’re not happy doing?

In Joel’s now famous (some might say infamous) blog post about hiring, he asserts that you should look for an employee who is smart and gets things done. Let’s stop and think about a variation of that question now. What should a person, as an employee of a company, do to succeed?

I left a comment on Hacker News that basically boiled down to two things:

1. Get results.
2. Make sure people know you’re getting results.

…and that’s it. We can sit and philosphize about the ideal startup employee all day (and I’d probably join in!), but at the end of the day, results are all that matter. Let me expand a bit on these points.

I’m sure the vast majority of programmers winced a bit when I said that “results are all that matter”, while the vast majority of evil bosses patted themselves on the back. Let’s face it, everyone has had that boss who told us to “Just forget all that documentation, testing, version control, and process nonsense and just get things done for Christ’s sake. Results matter, not that bullshit!” Let me be clear: I’m not that guy. I’m pro-documentation, pro-testing, pro-version control, pro-process, and pro-other things I’m not thinking about. I support those things because I want to get results. Not that I necessarily do those things as often as I probably should, mind you.

After all, none of those things are an end in themselves. How often does anyone say “The best part of this commit is the documentation!”? But you should still write documentation because it will help you and your coworkers get results later on.

The second point is something I wouldn’t have included at one point in time. After all, results should speak for themselves, shouldn’t they? Sadly, reality doesn’t work that way, and point 2 oftentimes trumps point 1. Perception is reality. You might have built the feature or service that will make it big for your company. But that doesn’t matter if nobody realizes what you built and how great it is.

One issue that has been brought up is that I should add a third point: don’t be an asshole. I must admit that I’m a bit ambivalent on this subject. It’s not that I’m pro-assholes. I’ve dealt with assholes before, and I don’t want to create that kind of work environment. That said, I think that a person is allowed to be an asshole X% more if they’re getting results. We can debate the value of X, but I say that at a minimum it’s non-zero. Especially if it’s in the name of getting more results.

Thus, I don’t think a third point is necessary. You should be kind to your coworkers as long as you can do so while getting results.

So, to wrap this up, I think this makes a pretty good set of criteria to evaluate your actions as an employee of a startup (or any company!). Are you getting results? And do people know about those results?

Remember what it was like to be a kid? Adults always told me that I could be anything I want when I grow up. And having a strong imagination was considered a good thing. Of course, as an adult, imagination tends to be looked at as a distraction from real work at best.

I may groan about this from time to time, but there’s good reason for this. I can imagine the neatest castle, but it does me no good if I just have enough wood to build a trailerhome.

Here’s the thing though, being creative requires that you unlearn the things that make you a practical adult from time to time. I think this is why creative types can earn a reputation for being so impractical: they are. In fact, it’s part of the job description.

So how does one remain practical while being able to unlock their inner childish creativity? Personally, I’m more concerned with losing my ability to be childish as I age. No matter what you do, there’s always someone to remind you how to be an adult. When was the last time anyone told you that you need to be more immature? Or that you are too practical?

I think the key is to keep in touch with what excites your inner child as you become a wise adult. What can be more powerful than someone with the imagination of a child and the adult wisdom required to make it real?

Us programmers tend to be a logical, pragmatic bunch. We’re good at choosing the option that is strictly speaking the most practical. And yet, I have yet to hear a programmer ask the question “Will anyone want to work with this?”

And there’s the dirty word: want. Many times, we get so caught up in finding the way that will be the most efficient that we forget why we became programmers. I don’t know about you, the reader, but I became a programmer because it’s fun. The moment I stop enjoying what I do is the moment I stop being a programmer and start being a paid coding monkey.

And here’s the kicker: this rabid focus that we have on the practical isn’t practical. It’s quite idealistic in fact. Looking back, the best projects that I’ve completed aren’t the ones where I had an easy, efficient way out. In fact, they’re frequently projects where I get to try something new out or get my hands dirty discovering better ways to solve old problems. In short, as long as you don’t get too distracted from the task at hand, wants are practical.

Now, I already know what counterarguments I’m going to receive from this post, so let me take a moment to address them:

• You can’t always get what you want. And you would be absolutely right to make this point. No matter what you do, you’re always going to run into a situation where you have to do something you don’t want to do. However, you don’t completely abandon the idea of life just because you’re going to die at some point. Instead, you focus on living as long and enjoyable a life as you can.

• You’re putting your own desires ahead of your team’s. I’m certainly not arguing that any individual programmer needs to be able to sabotage the rest of the team just because they want something. It is extremely important that you take what others want into consideration in addition to what you want.

• Programmers need to focus on building a product, not the code. This sounds like something a Product Manager or startup founder would say. And I would agree with it to a certain point. It’s important to work on a product that’s important to you. However, I’m not a Product Manager or startup founder. I’m a programmer, and product design really makes up about 10% of my overall job (and that’s being generous). The rest of that time is spent coding. And programmers shouldn’t have to apologize for wanting to make that time as pleasant as possible.

• You’re not being pragmatic. You’re right, I’m not being completely pragmatic, and neither should you. The ideal solution is one that is pragmatic and enjoyable. Given a choice between a pragmatic solution and fun one, you should always choose the pragmatic one. After all, a fun but completely impractical idea will never see the light of day. However, things are rarely so black and white. You have to learn to balance tradeoffs. Such as the tradeoff between practicality and enjoyment.

I suppose the main thing that I’m trying to say here is that what you want is an important consideration in addition to what you need (despite what the Rolling Stones would have you believe).

A couple of things that bother me about Python’s interactive interpreter:

• Having to import commonly used modules like sys.
• Not having history stored across interpreter sessions.
• No tab-completion.

Of course, things like iPython and bpython help, but I generally prefer just a plain old python interactive interpreter session. Plus, the above three problems are easy to solve without installing any extra packages, but the way to solve them is documented in somewhat obscure locations. The solution?

First, create a file somewhere with the following text (I save mine to ~/.pystartup):

import atexit
import os
import readline
import rlcompleter
import sys
histfile = os.path.join(os.environ["HOME"], ".pyhist")
try:
    readline.read_history_file(histfile)
except IOError:
    pass
readline.parse_and_bind('tab: complete')

atexit.register(readline.write_history_file, histfile)
del os, histfile

Then, you just need to add a line to your .bashrc, .zshrc, or whatever else your shell uses:

export PYTHONSTARTUP=~/.pystartup

…and viola! Your interactive interpreter has just been pimped.

If you’re on Windows, I’m afraid I have bad news. This probably won’t work for you without using cygwin (as you will need readline).

I must admit to being pleasantly surprised by The Daily, News Corporation’s daily newspaper for the iPad. It’s not because of the content. There are plenty of other apps by better established and more reputable news organizations out there. That’s not to say that the content is terrible though. It’s not the right wing drivel (with emphasis on drivel, not right wing of course) that you would expect from the people who brought you Fox News. It’s just that the content is rather light and without very much in-depth analysis.

No, my surprise centers more around The Daily coming from the same people who run MySpace rather than it coming from the same people who bring you Fox News. Let’s face it, News Corp dropped the ball with MySpace. Under News Corporation’s watch, MySpace went from being the top social networking site to being the laughing stock of social networking sites.

That said, News Corp may well redeem themselves with The Daily. The Daily makes the iPad feel like a viable content platform. In short, it’s what the New York Times and all the other big names in news should be doing in terms of iPad content.

What makes The Daily so great? Well, the other players treat the iPad as a glorified newspaper or magazine. They take their content, put it on the iPad, and there you go. But the iPad is capable of doing so many other things than this.

For instance, why are images so… static on every other news app? Ok, you can blow them up. With The Daily, you can pan around on larger images. You can zoom in and zoom out. Some pictures even give you a panoramic view. Or, turn the page and you see a brief video.

What’s even more interesting is the possibilities this brings up. For instance, it might be possible to have a map of a war zone. Or perhaps you could have interactive widgets that help you to visualize the deficit.

Whatever the case, The Daily is a step in the right direction for iPad news apps. Now, if we could just combine its features with great news, I think the iPad would have its next killer app.

A topic that occasionally comes up in Python development is that of tail recursion. Many functional programmers want to see tail recursion elimination added to the Python language. According to Guido, that ain’t gonna happen. And to be fair, I agree. Tail recursion can be tricky not only for new programmers, but for old timers as well.

However, that doesn’t mean that we need to give up on the concept altogether. This is a problem that is hardly new. Functional languages have been implementing tail recursion in environments hostile to it for a while now using a trampoline approach. Let’s see how the newest version of pysistence implements that algorithm:

def trampoline(func, *args, **kwargs):
    """Calls func with the given arguments.  If func returns 
       another function, it will call that function and repeat
       this process until a non-callable is returned."""
    result = func(*args, **kwargs)
    while callable(result):
        result = result()
    return result

This makes it much easier to implement things functionally (using pysistence’s functional lists):

def iter_to_plist(seq):
    seq = iter(seq)
    def inner(accum):
        try:
            return partial(inner, accum.cons(seq.next()))
        except StopIteration:
            return accum
    return inner(pysistence.make_list())

>>> trampoline(iter_to_plist, xrange(1000))
PList([999, 998, 997, 996, 995, 994, 993, 992, 991, 990, 989, 988, 987, 986, 985

That was more work than writing this in a language that does tail recursion automagically. But it wasn’t too bad now was it? Ultimately, I think this approach works for a few reasons:

1. It’s explicit. The user is well aware of what’s happening because they’re returning a callable.
2. It makes functional programming more natural. Instead of using true recursion and risking blowing the stack or converting this into a loop and continually reassigning to a variable, you can make the algorithm work without side effects.
3. It lets Python stay imperative.

For me personally, this is a great set of arguments. I love Python and I love functional programming. The more functional programming I can do in Python, the better. But there are very few things in programming that are free, right? Here are some of the disadvantages:

1. It’s ugly. I don’t deny this. But this alone is not an argument against it. If you are the kind of person who wants nothing but beautiful code, I’d argue that you’ve chosen the wrong language. Python tends to be beautiful when possible, but ugly when it has to be. Besides that this is the best you’re going to get without modifying the language itself or adding macros.
2. It isn’t very performant. Insert your favorite quote about not needing to be blazing fast, just good enough here. Besides that, it can be optimized in C if need be.
3. Who needs more ways to do functional programming? I’m not going to join any flamewars on this one. But I will point you to the advantages of functional programming in Python’s own functional programming HOWTO.

I love writing. I think I have talent in writing. But that doesn’t necessarily mean what I’m writing is good. To become a good writer, you need to put in work and experience. Here are some things I’ve learned along the way:

Practice makes perfect – It’s indisputable that great athletes like Michael Jordan and Wayne Gretzky have a lot of talent. But that doesn’t mean that they were able to go into the major leagues on their first try. Similarly, you might have talent, but it takes practice to unlock that talent. If you don’t have talent, you can still become good at writing. It just takes more time and patience. Blogs are perfect for this. Rest assured of one thing: if your writing sucks, nobody will read your blog. That’s actually a good thing because that means you can write all the stupid things you want and no one will read them until you get good at writing.

I know you’ve heard it a thousand times before. But it’s true – hard work pays off. If you want to be good, you have to practice, practice, practice. If you don’t love something, then don’t do it. -Ray Bradbury

Write because you want to – How many people have you met that “really needed to start blogging”? Don’t write because you think it’s good for your career or because programmers “need” to have a blog. I write about programming because I love writing and programming. If you love programming but not writing, then chances are your time is better spent writing code.

Love is easy, and I love writing. You can’t resist love. You get an idea, someone says something, and you’re in love. -Ray Bradbury

Just write it down – When you write something the first time, it will suck. Therefore, if it doesn’t suck at first, it hasn’t been written down.

Writing is no trouble: you just jot down ideas as they occur to you. The jotting is simplicity itself—it is the occurring which is difficult. -Stephen Leacock

Edit – In this sense, writing isn’t a whole lot different than coding. When you start coding something, the most important thing is just to start coding and not worry about it being perfect. But no code worth writing is perfect the first time around. You have to test it, break it, and make others read it to see if it’s clear. Writing for humans is no different. You must be as merciless in your writing as you are with your code.

I’m not a very good writer, but I’m an excellent rewriter -James Michener