The Companion Blog for

The Companion Blog for

Wednesday, July 11, 2012

Google Docs Integration

I've got to tell you, Google Docs integration was harder than I thought it would be.

The first thing I needed was to get the relevant library for the Google Docs API for Python. Google, by the way, has awesome documentation, both for Google App Engine and for Google Docs, as well as most everything else they do, so I highly recommend using Google libraries if you can.

That said, Google Docs times out a bit often, so I needed try to do something I'd never done before.

Most of the time out errors in Google App Engine are relatively rare. There is verbose and copious advice from Google on how to deal with the slim chance of a partial commit of an object written to Big Table, but I've found that it happens pretty rarely, and if you just throw an error page, people will refresh the page and move on.

Granted, maybe that's because not many people ever use and that's the reason I don't see a ton of those kinds of errors. But my point is, system reliability wasn't something I had to worry about much.

Not the case with Google Docs, which times like a drunk waitress at a diner of takes fifteen minute smoke breaks. It happens often enough that you will notice it if you try to use the API. So I was left with (what seemed like) a paradox: how can I do something, but at the same time plan to deal with the circumstance where I don't do something?

I couldn't get my head around it. 

This was a profound moment for me, because this is when I realized I really needed some help. So I did two things: 1) I started going to Boston Python Meetups, which was really helpful and I highly recommend, and 2) I started taking O'Reilly School of Technology classes on Python, which is also really helpful and which I also highly recommend.

I talked to a more experienced developer about my problem and he gave me some great advice. First, he explained what exceptions were, and that with them you can do exactly what I wanted to do, which is "try" something, and then if it doesn't work, deal with it.

The second piece of advice he gave me was to have the user deal with it if there was a problem, so long as it was a long frequency event.

So that's what I did; I used the examples from the library documentation to create a tie between the job opportunities you can track in, and if there was a problem with a timeout error from Google Docs, I display a message to the user asking them to "repair" the problem.

And so, I created the ability to add a cover letter and a resume to each job opportunity, as well as use templates to create different versions of your resume for each job opportunity based off a template version.

In retrospect, it looks like I'm a bit outdated in the way I thought about the problem. Most people don't understand why I have cover letters be editable like resumes. This is an artifact of when I used to look for a job, when you did attach a cover letter and a resume to an email when you were applying for a job. It looks like now-a-days, the cover letter has been replaced by the text of an email you send, or some summary text you enter into a company's resume submission system.

An elegant way to do this is the way that Huntsy does it, where there are email cover letter templates, which you choose and then create a per job instance of with a mailto link. In addition, the system automatically creates a unique email which that system generated email BCC's, which then tracks when you send that email. This is very clever, and was on my roadmap actually to implement for At this point though I'd probably just recommend using Huntsy (they also have a better bookmarklet, which has a hover entry window so you can see the "add a job opportunity" window while you're viewing a job posting, as well as some clever logic that tries to pull in the job title and company name into the job add form automatically).

Anyway, it took forever and a day, but I did implement the Google Docs Integration in October of 2011, and then did another round of user testing.

Sunday, July 1, 2012

2nd Round of Market Research

After I launched version 2.0 of Job-Buddy, and did some usability testing, I was at a loss for what to do next. So, I did some more market research.


I sent out a survey to 50 people who were unemployed via I asked them to force rank a variety of feature ideas I had based upon some of the feedback from the usability testing, as well as some interviews with unemployed people while I'd conducted.


Unemployed people are very easy to find, btw. If you attend any networking event, or job advice forum, most of the people you find are unemployed. If you give them your card, and then ask them if you can call them later, it's easy to get interviews (much easier than other industries/user groups).



One thing I dislike about the market research approach I took is that I am limited to the ideas I've conceived of, and am forcing people to rank between them. If they have a better idea than all my ideas, or think all the ideas are pretty bad, I'm not really capturing that. Still, I like to think that some of the ideas were good, and the challenge I had was to figure out what to work on first. So using a survey makes sense to solve that problem.

The results were very useful.


 In the chart, you can't really read all of the options, so I'll spell them out:

  • A1: Ability to draft and manage cover letters and resumes online within the application
  • A2: Ability to share a job opportunity with a friend to get feedback
  • A3: Ability to track emails, phone calls, and interviews and compare against your goals
  • A4: Ability to view your LinkedIn contacts within
  • A5: Ability to automatically calculate your likely commute for each job you're tracking
  • A6: Add an RSS reader that can be subscribed to different job boards (such as
  • A7: Ability to generate a Work Search Activity Log based on tracked activities


As you can see, A1 the ability to manage resumes and cover letters was the winner, followed by A2 the ability to track phone calls and emails versus goals.

So, I started working on managing resumes and cover letters by integrating job-buddy and Google Docs.

Wednesday, June 13, 2012

Usability Testing Version 2.0

Shortly after I launched Version 2.0 of Job-Buddy, I did decide to do some usability testing with Using the same App Sumo coupon I mentioned before, I had 3 usability tests done, the videos of which are linked to below.

User Test 1

User Test 2

User Test 3

All the user tests were useful. I was encouraged that using Google Accounts for authentication didn't seem to dissuade many people. The feedback around typos, while helpful, wasn't quite the kind of feedback I was hoping for. Other the other hand, I was ashamed to admit that it had really never occurred to me that anyone from outside the U.S. might use the site. Another piece of feedback was to add a breadcrumb trail to the forums, which was a super great idea and took a few hours to implement.

The most helpful feedback I think was the third video, where the user indicated that they basically had no idea what the site was about.

I attempted to address that feedback by adding an explanatory page when you login for the first time that explains what each section is for, and by relabeling what used to be called simply the "Jobs" list the "Job Opportunities Tracker", which seemed to get more toward the heart of what I intended. This reminded me belatedly of the advice in the 37 signals book Getting Real about treating your initial, empty-of-data pages as just as important as your in use pages, which I've tried to do going forward.

My takeaway from the usability tests is that it seems to me that usability testing is great to identify discrete usability problems and incremental improvements to the site, but may not yield new ideas that are really revolutionary.

Shortly after the usability tests I released a new version that addressed the some of the user feedback, and began contemplating what major new functionality I wanted to release.

Thursday, May 31, 2012

Version 2.0

As I mentioned in my previous post, this whole thing thing might have ended with version 1.0 if I hadn't shared it with a friend and solicited feedback.


"What about advice?" he said. "And forums so that they can ask each other questions."


This presenting something of a challenge for me, as I'm not exactly a crack web designer. In fact, I have about zero web design skills. And the two-tab interface that the Simple Life creative commons template I started with employed simply wouldn't work if I wanted to add forums and advice and so on.


I was in a bit of a bind until I learned about from a Hacker Monthly article ("Building a Web Application that Makes $500 a Month", by Thomas Buck, Hacker Monthly, Issue 13). From there you can buy web design templates that you can then hack to fit your own code into. For like $50 I got two great templates which are much more expandable then the template I was using. That (with some images I found using Flickr's advanced search that were okay to use so commercially long as I attributed them) took care of the landing page. Also, great icons from It's amazing the stuff you can find on the internet if you keep looking hard enough.


For the forums, I used Krzysztof Kowalczyk's excellent Forums for You github project available under a public domain license, and then hacked together a blog set of pages for the advice section of the site.


The most challenging part for me was actually the image uploading. I could have uploaded a couple of static images and called it a day, but that just seemed antithetical to the whole online content management system thing. So I ended up writing a whole image uploader set of code which was annoyingly challenging for me because of the way that Google App Engine stores and serves images.


Anyway, it all came together on July 30th, 2011, when I released version 2.0 of the site to great fanfare.



Or a cricket filled silence. Whichever! Still, it was an exciting day for me, and I was very happy to see it up and living out there.

Monday, May 21, 2012

Version 1.0

The first version of Job-Buddy was, shall we say, less than impressive.
The very first version only had a simple list feature to list jobs that you were tracking (you can see a demo of it in the embedded video.)

To get to this stage, the most challenging thing was trying to work around the fact that I don't know how to design a web page. Thankfully, I found a very elegant single column template that was available for use called the Simple Life template.

This first version is an example of a simple create, read, update, and delete pattern (the so called CRUD pattern) which you will become very, very familiar with as you create lists of things for people to edit. Building a list of jobs like this is just an extension of the guestbook application that you will learn how to build if you work through the Getting Started guide for Python and Google App Engine (a tip I think I mentioned previously, but is worth mentioning again: whenever you read through a tutorial, actual type the code and execute it to follow along. For some reason that just works much better than just reading the tutorial) . If you just change the data models to what you want, and slap them into a simple web template, you can create something like version 1.0 of Job-Buddy relatively quickly.

I took me maybe two months of weekends and evenings, because I'm a very slow programmer and not very good at this. On the other hand, I'd already been messing around with the Viewpoints system, so I had a leg up, as it were.

A lot of that time was spent working on the bookmarklet, which was difficult. Unlike the straightforward Python code, which I could debug in the Eclipse Pydev debugger, the Javascript code was a challenging when it came to debugging. Now I know more about Firebug and other tools which can help with Javascript debugging, but at the time I didn't, and the whole thing was a bit of a black box.

Another thing I ran into was that, since I develop on a Mac and a PC, I had to write handler for all file includes that switched the direction of the slashes to accommodate the standard on whichever system I was working on without having to flip it back and forth. There is probably a better way to do this, but I don't know what that is.

This is probably a good point to mention that that is a feeling I often have while working on this project; that there is probably a better way to do a lot of the things I'm doing, if only I could figure out what that better way is. That is when I yearn for a person to work with who is very clever and could help me see a way to become a better programmer.

Ah, the god old days. So many mistakes to make. I initially was initially using Dropbox, which mean I accessed the exact same files on the Mac and the PC. I quickly found out this meant I had to switch the python path constantly in Eclipse. Then I got Git working, but kept checking in the Eclipse project file, which completely messed up the project on the other machine, until I learned about adding a .gitignore file to exclude the project file.

Another chestnut is that every time you start the web server that comes with the GAE SDK, the console in Eclipse informs you that you should really be using Psyco, a library that speeds up debugging.

I have tried every package manager I could find and I have not found a version of Psyco that works on my Macbook Air, but for some reason, I still periodically try to find another version.... Why I think that someone might someday make on one that will work for me is a mystery to myself. I think development on Psyco has been discontinued, and it's not like the performance even with the debugger on is bad, it's just that that error message bothers me and makes me wonder what awesomeness I could be experiencing.

At this point, I didn't promote the site at all, or really tell anyone I was doing it; it wasn't something I was proud to show people. I just got a kick out of putting something online. No one used it but me, but I found joy in moving things around on the page and tweaking them.

That's where I might have ended really if I didn't get some feedback from a friend of mine who is really good at user centered design.

Wednesday, May 16, 2012

Prelaunch Market Research

When it came time to start working on Job-Buddy, I wanted to avoid the whole Viewpoints fiasco again if at all possible. So I decided to do some market research to try to figure out whether what I was planning on building was appealing to anyone else.

In my first iteration of the project, the key thing I was focusing on was to make the job search less lonely and to automate the process of working with someone else to copyedit cover letters and resumes. I thought it would be like swim buddies going out into the deep end together. Group hug!

So, I created some wireframes using wireframe sketcher, and solicited feedback from my target market. Literally; I had a coupon from AppSumo for Ask Your Target, and I could embed a video and solicit feedback from ten people who were unemployed and looking for work.

The feedback was immediate and enlightening.

The respondents were asked five questions:
• Would Job Buddy address an urgent need?
• Do you think many would use the site?
• Would you pay $10 a month for access?
• Are there any other features you'd want?
• What could a job "buddy" help you do?

None of the respondents indicated that they would be willing to pay anything for a site like Job-Buddy. Some indicated that they would to use the site in their job search. However, none of the respondents indicated that they would be willing to pay $10 per month for access to the site (though one said they would maybe pay $5.00); some got angry at the idea of paying money to access the site, feeling that that would be taking advantage of those desperate for work.
A few respondents saw Odesk and Elance as better sources of work, which may have reflected some confusion around what the product concept is/was, as Odesk and Elance are markets for freelance jobs, and Job-Buddy was intended to help find salaried work.
One respondent expressed interest in meeting people, and in finding jobs that were not listed elsewhere. Others expressed concern over whether another buddy would steal the job they were looking at, though some thought that maybe not being in the same state was enough to deter that problem. Many expressed interest with help interviewing (interviewing practice).

None of the respondents had graduated from a four year institution, and most had not attended college, which left open at least in my mind, at the time, that perhaps the target market for Job Buddy is college graduates early in their career who are looking for a job.

This was all a bit disheartening. I was thinking of killing the whole project before I started until I went to a job seeker meetup in Boston. There, a few people expressed some lackluster interest in the concept, but I also met a really nice career coach who immediately got the concept, and assumed that the site would offer advertising opportunities for career coaches.

Since the site didn't exist yet, I said, "Sure it will. Would that be something you'd be interested in?" To which she said, "Yes!" and I had found my business model; lead generation for career counselors.

Tuesday, May 15, 2012


I think I should probably explain why I've chosen to work on this job-buddy thing in the first place, because I've kept at it for about a year now. This is rare for me; most of my side projects take up a month or so and then I switch to something else. If you have that problem too, then you might find it useful to hear what has worked to keep me motivated and working on this web app for so long.

There are a wide variety of answers I think as to what motivates me to work on Job-Buddy, and what keeps me working on it.

The first answer is, I'm a bit addicted to releasing new software. I rather love putting something new out into the world. I get a rush; the risk! Will it work? Did I check everything? Will people like it? I need my fix of releasing software, and need it one way or another, even if I have to do it myself...

In addition, I was looking for a hobby that I could do without leaving the house that didn't cost that much money. Programming a website meets that criteria well. I don't watch much television, and it gives me something to do in the evenings that is challenging and rewarding without being too expensive. Indeed, so long as the cost of the project stay moderately low, basically no-one can stop me from doing whatever I want, which is a pretty liberating feeling; it allows me to do what I want to do, even if it doesn’t make sense, no-one will like it, or it won’t make any money.

I can decide to change direction completely tomorrow, and I disappoint no-one but myself. If I want to contemplate a different option, it is my own programming time I am trading off versus a product feature I want to add. If I abandon a set of code, it is only my own work and time I am sacrificing. It feels a bit like camping in that respect; the only work I have to do is the work that seems necessary to do to me, which is nice.

As a side benefit, I feel like I have a better grip on what the other engineering folks are doing and what it must feel like if someone changes requirements mid stream, so while that is probably not a primary motivator, it is a nice added benefit.
The final reason is (I’m ashamed to admit) straightforwardly altruistic. As I mentioned previously, I found it incredibly depressing to be unemployed. I’d like to make it easier for other people who are unemployed to keep their spirits up. Looking for a job is hard, and I figure that anything I can do that might help, might help. This last reason might be the one that has motivated me the most; I am passionate about trying to help folks try to get a job more quickly. I think if you can find something you're passionate about, all the tedious hard work becomes a bit easier.