We've made good progress hiring UI developers and designers for LiTL. We may hire more on the UI side in a while (please do let us know if you'd be interested), but we have an initial team.
In the meantime we are turning our focus to a couple other positions. See the official job descriptions and if you're interested, please email jobs at litl com.
LiTL is a startup in downtown Boston working on a new consumer product that involves hardware, software, and online services. We have the right financial, business, and design support in place. Our success hinges in large part on the development team. That's where you might come in.
To give a bit more color so you know what we're looking for...
First, the job shown as Release and Quality Engineer probably ends up as multiple jobs. We want a few different skills and maybe you focus on one area. One role: what I would call "OS Wrangler" - do you make custom Linux distribution spins? Hack on init scripts? Maintain packages? Fix problems in the HAL/dbus/udev/kernel/etc. stack? We need someone to put an OS together with our new code into a coherent spin, and tune the OS for our product. Depending on your background this job could involve significant new software development or could be more focused on integration and coordination.
Another skillset or two we're interested in: release and quality engineering - nightly builds, automated testing, test plans, generally ensuring our users have a great experience. We'll need to test both our UI and our web site, and manage new releases and updates.
Second, the job of Lead Server Developer. Here we want a hard-core server application developer who can create a great, modern web site with supporting APIs and services. If you're into web technology, we have quite a few interesting projects to get done that you'd probably enjoy. We haven't picked a platform - we'd rather pick a great team and see what their platform of choice is - so this is a chance to use Ruby or Java or whatever you love. We need someone who can be a technical lead and make the major technical decisions, and we want someone hands on who's going to write a lot of code themselves. We don't want a manager, and we don't want a pure architect who doesn't write code.
If you have some of these skills, we'd love to tell you more about what we're doing, and learn more about your background. Don't be shy with the emails.
I can't seem to write a Python function that will spit out the same numbers for average cost basis that Vanguard puts on their statement.
My many Google attempts are not turning up any description of the average tax basis algorithm (single or double category) that is precise enough to implement. All of them parrot what publication 564 says, but that publication only describes the simplest cases. If you sell multiple times, sometimes with mixed short and long term basis, it is very unclear to me what is supposed to happen. I've tried various things that seem logical but none of them match Vanguard's computation.
Surely there's at least an open source program that implements this algorithm, but I'm not finding that either.
How can there be nobody on the whole Internet giving more info than the few sentences in the IRS publication?
Update: the secret is wash sales, which Vanguard mixes in to the average basis calculation. The actual average basis calculation is the simple thing described by the IRS. A side effect of this is that the total allowable gain or loss shown on the Vanguard statement is the right thing to put on your return, but the average basis shown on the Vanguard statement is NOT correct to put on your return. To fill in the basis column on schedule D you have to adjust the basis Vanguard shows by the disallowed loss they show.
Amy and I broke down and sent our CD collection to Get Digital. I had manually ripped about half of it a long time ago, but the metadata (from MusicBrainz in 2005 or so, I guess) was a disaster, and I didn't have a good system in place so never finished ripping the rest.
Get Digital was far from free, but they did a nice job with fast turnaround. They managed to get the right information for every one of our CDs, including some imports, CDs that came with magazines, small local artists, and other challenges. They did not have album art for some of the more obscure things. Their metadata is completely consistent; they always spell the same artist in the same way. They do "Various Artists" correctly, so the artist for the album is "Various Artists" but the artist for each track is the actual performer of that track. They're consistent about always using "Various Artists" too, so we don't have some albums under other spellings like "Various" or "Multiple Artists" or whatever.
Anyway, I recommend Get Digital overall. I plan to use them again after building up a batch of 50 new CDs. (They have a minimum of 50.) From now on I'm just going to assume all CDs cost an extra couple bucks to get the ripping done, since we won't listen to them enough otherwise.
The bonus - we had to stack all our CDs on spindles to mail them in, in the process we pulled all the paper inserts out of the jewel cases and put those in another box. So now we have two small boxes - one of paper inserts, one of CD spindles - instead of several huge, heavy boxes of jewel cases. The spindles can go in the basement as backups. The empty jewel cases will finally be out of the house.
I meant to toss out a couple thoughts when Robert blogged about index funds, reminded by a Wall Street Journal article yesterday pointing out that the S&P 500 has gone nowhere over the last 9 years.
Here are said thoughts:
"I think everybody should read Jack Bogle's book. ... what you really want to do is you want to own American industry which is going to do fine over time, but you want to make sure you don't put all your money in at once because you might pick just the wrong point. But if you buy in over time into a wonderful business, which is American industry, and you make sure you don't go in at just the wrong times, when people get excited, and you get to keep your costs low ... you're going to beat 90 percent of the people because they're going to run up unnecessary costs."
Anyway. I am not religious about index funds, personally I use about a 50/50 mix of indexing and other strategies. Not to "beat the market" - I have no idea why discussions center around beating the market, since doing so has nothing to do with anyone's goals or their planning. "Beating the market" in this context has a technical academic meaning anyway ("alpha") that doesn't quite match the common sense meaning.
Nobody's retirement hinges on beating the market. Most people's goals hinge on whether they make some kind of decent return or not. A major goal in investment planning should be to increase the probability of adequate returns, in my opinion. (Where "adequate" is defined by your personal goals and resources, it's not an absolute thing. And where the probability includes human behavior - not just what you should do but what you will do.)
"You can't generate alpha so buy index funds" makes no sense to me. I would say, "dollar cost averaging plus appropriate asset allocation plus low-cost index funds is one simple, proven discipline to give you a good shot at decent returns." Whether decent returns are adequate, of course, depends on your goals and whether you are saving enough every month...
Elijah posted a humble note about Easy GIT, but don't be deceived. Easy GIT is completely usable for daily work, and it's a one-file perl script you can just add to your path. It hides git almost completely and is pretty much exactly what I've been looking for.
Elijah rocks, which I already knew, but now I have even more evidence.
git clone http://www.gnome.org/~newren/eg/eg.git, stick the checkout directory in your path, type eg help, and enjoy.
Japan Steel Works apparently melts 600 tons of steel at once into a giant one-piece nuclear reactor component that costs $350 million. They also make $10,000 samurai swords.
For the GTK+ hackfest I wanted to start a discussion about why people are doing custom "canvas" things (HippoCanvas, Clutter, GooCanvas, Pigment, etc.) and how GTK+ could evolve to address the same problems.
The proposal in a nutshell is that widgets should be one kind of object in a more flexible scene graph. But there are many details.
The two GTK+ enhancements I'm most excited about are gobject-introspection and this scene graph ("canvas") problem.
Here is an idea I still like, but had forgotten to keep using:
The old usability cliche "users are busy not stupid" is exactly right, because the issue is that they are busy doing something and they will always only care about things they need to care about to do that thing. So the relevant question is not whether they find something confusing, but whether a specific person would care about it at a particular point in using the software. Much better to talk about "interestingness" than "confusingness" when deciding what to strip down (not least because interestingness is more obviously relative to the audience).
As you design something, ask "is this relevant to what people are trying to do?" rather than "is this confusing?" - I like it. Maybe I'll remember it this time ;-)
It doesn't matter whether people could figure something out. It matters whether they're interested in figuring it out - is it part of what they're trying to do, or an annoying sidetrack?