Some notes from the app development scratchpad.

On the app itself:

Probably the single hardest component was in-app purchases. 

I might try to do a presentation about it in the future, if I am masochistic enough to do that dance again. I probably should, so that I learn how to do it properly this time.

I will say this for now: I sacrificed a chicken over a pile of broken iPhones and iPod Touches, doused everything with gasoline, and set it all on fire. While praying to the spirit of the Apple All-Father. Then it worked.

Usually this is indicative that the person performing the eldritch rituals has no clue what they're doing. That may well be the case. It felt, by far, like the thing I had the least control over. I'm deathly afraid that some horrible bug involving in-app purchases and extremely angry customers will pop up.

Data wrangling on the back end took a lot longer than it needed to. 

I had no idea where to start. In fact, in the initial agreement, I was not supposed to be responsible for getting the data into an acceptable format. It was supposed to be provided to me. But so much time would have been wasted with manually entering the data, and hunting down the inevitable typos, that it was necessary for me to automate it in order to move the project forward.

Valuable experience, but it did derail work on the app itself for a substantial amount of time.

Switching from trying to do things via Unix scripting with bash to doing it in a more full-featured language, like Ruby, made life so much easier.

There's a lot of room for improvement, both in the app itself and on the back end, and I hope I get the opportunity to work on a version 2. 

In particular, I think we can streamline the structure of the lessons. Right now they're very closely based on the podcast, and user control is very limited and linear. My goal would be to give the user control over where and when they want to put more effort and time into practicing.

I also think it's really important for people trying to learn a language to generate phrases and conversations rather than just listen and repeat. I have some interesting ideas on how that could be done.

I learned a few things about how I work best, too.

Getting paid by the milestone beats getting paid by the project. 

Having a series of discrete goals and rewards is good. However, it's inflexible.

New tasks and goals that were not accurately predicted at the beginning of the project inevitably appear, creating a distinction between work you actually get paid for and unremunerated tasks. Spending a lot of energy on time-consuming extra tasks that don't quite fit your milestones is demoralizing.

Next time I consider taking a contract based on milestones, I would need clauses in there that allowed for the re-evaluation of tasks and compensation.

Alternatively, getting paid hourly is probably better in terms of being motivated to work on the project right this moment. But hourly pay for a remote worker causes its own set of problems related to time tracking and trust.

On occasion I can be effective and productive at home. 

Those occasions are infrequent and unreliable.

Getting out of the house, to a café or co-working space or park or really pretty much anywhere (sitting on the train!), is much better. But saying I should go out and actually doing so are two different things.
 
The best solution so far has been to make sure to have something scheduled. Whether it be frisbee practice in the mornings, or lunch with someone, or an errand to run, I can pad that event before, after, or both, with working time.