Text

· · to read

From time to time I’ve been recording voice memos. I find them to be valuable both when I record them, because I explore thoughts in a different way, and later, when I listen to them. It’s a convenient sort of diary for me. Here’s a snippet from a voice memo I recorded while I was driving from the Raleigh-Durham International Airport to the coast in a rental car, thinking about what I had just resolved to do, which was to learn things in depth, rather than just read web development news:

So, who shall I learn from? I guess, it doesn’t matter that much. What matters is that I learn, that I stick to learning, that I spend my time on real learning and that I don’t get lured into the kind of learning that isn’t that important. Now, it doesn’t help me to read Hacker News, and to poke around into every little thing that comes out…because, it’s rare that I learn about what comes out enough to use it on something, so what value am I getting out of it? Not much. And…it’s real easy to do that, because I’ve been lured into the idea that being a successful programmer is mostly about keeping up on learning everything new—not missing anything.

One poignant memory I have of not really learning something is when I read about rip on twitter. I went nuts about it, and I thought it was really cool that I had twitter and Hacker News so I could hear about it right away. Then, a couple of weeks later, I realized that I had done absolutely nothing besides read the article. I hadn’t even installed it. Meanwhile, in those same couple of weeks, I had spent maybe an hour a day reading articles I found on HN and twitter. I was really busy when I realized this, so I didn’t immediately go out and try it. Chances are, if I had any problems that could have been solved by rip, my knowledge of it would have got me nowhere. Because I hadn’t used it, I forgot almost everything in the article about it, except that rip is like virtualenv for ruby.

Now, a new one has surfaced: Node.js. I read some early articles about Node.js. I’ve downloaded it. I’ve even ran a couple of demos. But what I haven’t done is build anything with it. Now, everyone knows about Node.js, and many of the people who don’t pay attention to new developments like I did, know Node.js, while I don’t. What’s more, people who have been more proactive about learning and participating in open source projects, have people from other communities begging them to try Node.js. I’ve seen it happen. It seems that the information networks of those who genuinely participate in open source are fine without HN or twitter (though they may be enhanced by them).

Text

· · to read

I just found myself wishing that I hadn’t deleted some dead code, because I wanted to use the same technique I’d used earlier. Now, if someone else had been in my position, and refused to delete it, because they wanted to be able to look at it later, I would have suggested that they learn to use their version control system better. So what did I need to learn to do? That’s right: learn git better.

After googling, I found that with the -p flag, git log can be made to show patches. I ran git log -p admin.py, since I knew which file used to contain the code I wanted to look at. It brought up all the changes made to that file, including when I created it, in my pager. I searched for get_urls, because I wanted to find where I had set up a custom admin view in django. It came right up! I copied it and pasted it back into the file. Problem solved.

Text

· · to read

I’ve always had the type of job where I’m given a set of responsibilities and some tasks. Many of these tasks are things that have a quick-and-dirty way of doing it, and could be expanded to just about anything.

Clients haven’t always been the best at communicating which tasks are most important. Often, I don’t think they know which are most important.

Sometimes, I have a hard time focusing. That’s why I’m trying a new strategy.

I’m going to try doing many of the tasks in a quick-and-dirty way and see what my clients ask me to improve. Just like a blogger or a twitterer might put out a bunch of posts, and if they get positive feedback, try doing similar posts to engage and expand their audience, I’m going to try doing a bunch of little projects to see what I get the most positive feedback from.

Now, like a blog/twitter audience, clients can be fickle, and lose interest in something they seemed really interested in, so I have to always be adjusting to demand, just like a successful blogger.

The information that helped gel this idea was in a marketing video by Giles Bowkett where he introduced the concept of Test-Driven Decision Making. That’s the concept I’m using here.

Text

· · to read

Note: After letting this sink in, and participating on the Year Of Hustle forums, I think I was just making excuses. When I’ve had success “prototyping”, I was doing it with the intent to ship. I could have released my idea and repurposed it later. I think shipping is the habit I should be trying to form, and that it will help me hone my skills better than prototyping without the intent to ship (i. e. dabbling).

Some ideas just aren’t ready to be shipped out. They need more time to germinate. Ideas that aren’t ready to be shipped, though, are often ready to be prototyped.

I had one idea where the plans for building it felt complete, but I wasn’t sure what my goal would be with the released product. I wanted to do more than impress people with pretty graphics. A few weeks later, while I wasn’t thinking about the idea, I thought of a goal, and while I was trying to think of a way to achieve the goal, I realized my idea would be a great way to achieve it. I also came up with another feature for it, that I think will help it stand out.

It would be nice if I’d already prototyped it, and had it sitting in a private repo on GitHub. There was nothing stopping me, except I was hung up on making things I could show people. If, at the time I knew what I wanted to write, I’d shipped other smaller things recently, I might not have run into this stumbling block.

this is Roy... Roy the killbot by Don Solo

I’m not sure whether it’s shipping that makes prototyping work, or the other way around, but I think developers ought to have a steady diet of both.

Text

· · to read

My friend Andrew Hyde recently launched a really cool service for freelancers called pick.im (pronounced (pick ’em). Here’s what it looks like in Mobile Safari on the iPad:

It searches based on three things: location, type of service, and budget. Yet one of them doesn’t show up in the form: the location. The location is auto-detected using either HTML 5 or the ip address. If it gets the location wrong, it can be changed on the results page.

What I noticed is that people can try out the site without ever pulling up the keyboard. The only reasons to pull up the keyboard are to change the location, to contact a freelancer, or to sign up to be listed as a freelancer. Many won’t start using the site until at least the second time they visit it, so the first time they visit the site, it will be without ever using the keyboard.

When I use my iPad, I like being able to accomplish many tasks without using a keyboard. Subtle changes to a design are sometimes needed for this to work in practice. Pick.im could show the guessed location before searching, but it doesn’t. If pick.im guessed Denver when I was in Boulder before searching, I might correct it, even though I would get reasonable results with Denver selected, due to its proximity to Boulder.

While I really dig the minimalistic design of pick.im‘s search, that’s not all there is to it. Andrew has big plans for it, including helping freelancers spend less time dealing with things like billing and accounting, and more time doing the kind of work they enjoy. For that, the interface will need to be more complex, but by the time people see that, they’ll have already started using it.

It’s nice to hear about new businesses starting up right here in my town. Boulder has a lot of exciting startups right now, and the summer hasn’t even started.

Text

· · to read

I added a new feature to grem: if you’re somewhere in your ~/github directory, you can simply type “grem” and the program will use launchy to open an appropriate page on GitHub in the default browser.

For example:

This is handy, because often I’m in someone’s repo and I wonder what else they worked on. All I have to do now is go up a directory or a few, and run “grem” with no arguments, and I’m there!

I chose to make it go to a repo, rather than a directory in the tree, when I’m in a subdirectory of a repo, for simplicity’s sake. This way, I don’t have to worry about when a directory has been added to a local copy of a repo but not the github repo.

What do you think? Is this command-line tool useful? Do you think my directory structure makes sense? Are there any other ways you can think of that I can take advantage of having a system for organizing my copies of repositories?

Text

· · to read

Meet grem. Short for gremlin, grem is a tool for managing local copies of github repos. Grem is also my first gem. It was remarkably easy to create a gem with newgem and push it to gemcutter.

gremlin (from Inti on flickr)

Right now, all grem does is clone a repository to a default directory. To try it out, run

sudo gem install grem

…and then:

grem benatkin grem

…and grem will clone my grem repo to ~/github/benatkin/grem, creating directories as needed.

I got this idea from a comment on my earlier post, Organizing github repos, by KevBurnsJr, where he suggested making a bash script for cloning repos into my directory structure. I decided to take it a step further by making a gem, and adding more features later.

By the way, standardizing on ~/github/username/reponame has worked wonders for me. It’s lowered the friction for downloading repos, looking at them, and coming back to them later. This script should lower the friction even more.

Speaking of lowering friction, with Heroku‘s help, I deployed a mini-app. Check it out at http://last7.heroku.com/ (github).

Text

· · to read

Earlier this afternoon I was explaining to a designer I just met why I want to work on some projects that probably won’t make any money, but might get buzz. I said that I want to market myself. I felt it sounded cheesy, so I elaborated.

It came out like this. It sounded even cheesier, but rung true for me:

“Sure, I’d like to make money, and be able to buy a house someday, and nowadays you have to be rich to buy a house, but life is short, and I want to hang out with interesting people, and work on interesting projects.”

I now understand why so many artists take a long path toward making money. Or don’t get around to it at all.

Text

· · to read

When I hear someone talk about how nice it would be to have a companion iPhone or Android app to a website, I want to know why. There are two reasons, and I think that one is more valid than the other:

  1. They want to provide the customer with a better user experience.
  2. They think that if the user has their app installed they’ll be more likely to use their product. Thus, it’s a marketing channel.

I don’t think reason #2 holds up to scrutiny. First, I have 5 pages of iPhone apps, but two of them, Tweetie and Dan Bricklin’s Note Taker, account for more than 90% of my app usage. Many of them I haven’t touched since installing. Second, after the initial flurry of installing and trying out apps, I rarely install a new app because I don’t need more apps that I don’t use.

Now, I’m not a typical user, but I’m inclined to think that most casual iPhone users either don’t install many apps, don’t use many of their apps, or both.

Another angle, though, is that to me, it sounds kind of arrogant to think that just because you have your app on someone’s phone they’re likely to use it. That’s like the marketer who thinks that if they get a nice commercial on TV, sales will roll in, even if the product isn’t remarkable. I think what Seth Godin says in Purple Cow is right: you have to be remarkable to be noticed. I don’t think you’ll be noticed just because your icon is on peoples’ iPhones.

I think some people are attached to this idea, though, so much so that they’ll argue to project managers or developers that it will provide a better user experience, and express doubt over the ability of alternatives, like HTML 5 mobile sites, to provide a good user experience.

Text

· · to read

Right now I’m studying the discipline of shipping, in several different ways:

It’s a bit of an obsession, but I think it’s important, especially for me, since none of these things came naturally to me. Also, I think that the best time to learn about something is when you have a seemingly unhealthy obsession with it. If I’d latched onto Ruby on Rails back in 2006…

Text

· · to read

I’ve seen more than one screencast where the narrator has invited me, the viewer, to pause the screencast to try going through the steps myself. Usually, the invitation is accompanied with the author saying that I’ll learn more if I do.

Of course I’ll learn more, because I’ll spend more time watching the screencast. But will I learn more efficiently? I’m not so sure. Here’s why:

  1. It disrupts flow. The author goes from teaching me something about the topic I’m learning about to talking about something he or she isn’t necessarily an expert about.
  2. It breaks up the screencast if I don’t have a long enough block of time to watch it with breaks.
  3. It makes it take longer to view the screencast more than once. Too long, for me, anyway. I remember reading somewhere in Brain Rules that repetition works better as a memory tool if you repeat something on a different day than if you repeat it back to back. I know this, intuitively, to be true. I also remember John Medina saying that if you vary where you are when you hear something, or what medium it’s in, it works even better. That’s why it’s smart to distribute example code with screencasts.

I wish the suggestion to pause and try following the instructions would come as a little text blurb distributed with screencasts instead of narration. And if, on the second or third viewing, I decided to follow along with every little thing, I would pause more often than the video suggests. So whether I’m pausing or not pausing, I find being instructed to pause to be distracting.

By the way, Brain Rules is a great book. So is Food Rules. They’re written by different authors, and are about different topics, but both are written by experts in their fields, who are also great writers, and both are awesome.

One final point: for screencasts that aren’t immediately relevant to me, but are still interesting, watching them all the way through without trying things makes even more sense. That way I can peruse more screencasts to find the ones that are most relevant to my current interests. I can learn about more tools and domains and better decide which ones I want to work with.

Text

· · to read
  1. Limit your number of tweets per day to a certain number. Use them wisely.
  2. If you get close to the limit, start saving tweets for future days.
  3. If you want to say more online, find interesting blog posts and leave insightful comments. Comments that require work outside of composing the comment tend to be insightful.
  4. Exceptions should be exceptional.

Backstory: I’ve lost readers (sounds less narcissistic than “followers”) by tweeting too often. I’ve changed how I’ve tweeted since I read Gwen Bell’s twitter bio, which used to say that she was limiting her number of tweets to a certain number per day. Sometimes I still have been tweeting too often, though. As I started blogging more regularly, the idea to switch from tweeting to leaving comments on blogs came to me.)