Ask HN: Typical Startup or Abuse?

Second the Elance (or third, whatever). It's hard to compete with the third-worlders there, but man - you're starting from nothing. You should be able to double your income in your off time.

As soon as you're making $500 a week - which will really not be a problem on Elance for anybody competent with a good grasp of the English language - quit. Just walk out the door. No notice, just at the end of the day, go to your boss and say, "I'll be leaving now."

Then tell him your new hourly rate for consulting. Make it a good one. If you're as indispensable as you sound, you'll be working the same job with a reasonable rate within a few weeks.

If you end up quitting, please name the company so that everyone else can avoid getting cheated.

You're right, of course. I would never list any of these skills on my resume, or tell any interviewer that I could do them. I would never try to get a freelance contract that requires these skills. They're completely self-taught, completely untested, and I have zero confidence that I really "know" any of them. When I said I have no proof—I meant I have no proof for myself, either, as an empiricist.

Really, what it amounts to is that when I come home, I spend twelve hours (that is, 4PM-4AM) "studying": reading programming books, testing out bits of code, writing scripts and hanging out in places like /r/coding and LtU. It's basically my sole hobby, and I started when I was 11 (with a website run on a scrounged Pentium Pro off a Slackware LAMP stack.) I'v continued teaching myself various skills since then, never producing useful output, just reading and testing myself. I don't have confidence that my skills are anything more than a bunch of academic knowledge.

If I recall, these are the most code I've ever actually written:

* Stargazer, an interactive galaxy creation program in SDL/Ruby (you plot and name stars, create flight/jump/trade paths, and classify arbitrary three-dimensional regions with arbitrary metadata; it's for sci-fi writers.)

* Persona, a webapp where you create a user, that user creates several fictional characters (personas), and then, as a specific character, you answer questions out of a user-generated pool in order to flesh out your individual character. It's sort of like OKCupid in reverse—you specify the "factors" your graph of characters should display in advance (love, hate, admiration, apathy, etc.) and then the service helps you answer questions in a way that will conform to those pre-ordained relationships.

* Nameclasser, a Bayesian classifier trained on the details of individual words (sound, length, derivation, etc.) You feed it a dictionary; it spits back a subset of it usable as "interesting" character names.

* Folio, a mark-up language (and reference parser) similar to markdown, but intended for fiction (distinguishes pages, has footnotes, does neat things when it recognizes sections of screenplay-like dialogue, etc.)

* Christmas, a graph adventure (it's a text adventure, but with the interface being clickable words in bubbles—basically an ever-expanding tree of circle-menus.) It's two-player, networked: the client(s) are in C with Lua extensions, server in Clojure. It also features something I've never seen before: network-transparent undo. (Only works under certain world-model-specific conditions, of course.)

* SMS Importer, a little tool to sanitize a copy of your SMS database, copied from your iPhone's backup folder (SMS data has always been stored in 3d0d7e5fb2ce288813306e4d4636395e047a3d28.mddata, if you're curious), and present it as a folder of formatted-text chat logs. (It also keeps its own gateway database, just merging in previously-unseen texts, so you can delete an SMS record on your iPhone—it makes it a might bit faster—and still keep the record after re-importing.)

* An unnamed, unfinished project involving editing timelines of narratives and meta-narratives in time-travel stories.

* Nodepad, a hierarchical outliner (where every "node" was a folder+rtf file underneath, so you could make any node the working root), and Sponge, a visual to-do list (all the tags were importable 16x16 icons), both in C#.

* Wikirei, a wiki designed from the top-down to look as clean, presentable, and non-wiki-ish as possible when you don't have editing rights, and elegantly expose editing features when you do.

And each and every one of those is crap, in my opinion, and I would never release any of them. ...Having said that, and looking at that list, my problem might more be anxiety at releasing my work, than actually producing it. I've been working in a silo for so long, with no feedback as to whether my code has any quality (except what books say) that I have no idea what others will say when they see mine.

This time, I think perhaps you don't give yourself enough credit. There are a lot of interesting ideas in that collection, things that would grab my attention and make me curious to ask you more about how you did it. Even if you never polished those projects to a professional standard, it is impressive if you actually wrote that many useful/interesting things by your age.

Again, I would recommend picking one or two examples in the area you're most interested in pursuing first in your career, making some effort to polish them up to what you would consider a professional standard, and then using those as your "portfolio pieces". I've done my share of interviewing, and really, not much shouts "Hire me!" faster than someone who can show that sort of interest (really important when you're hiring for a position where no applicants have much experience yet) and who has made the effort to show what they can really do.

Also, for what it's worth, it's very common to be nervous about showing your code to others. I've been programming professionally for a long time, and I still hate it. I'm never 100% happy that there wasn't a better way to do things, or that something wasn't a little bit untidy. But programming is a world where the best is the enemy of the good: there is rarely one "right way" to do something, and there comes a point where you've written code of sufficient quality that does the job it needs to do. Trying to refine it further is usually just a form of pride/vanity at that point, and with experience you will learn to recognise this in yourself (and, in due course, in those you work with or manage) and to just say something is done and ship it. You can always see neater things you might have done in the code with the hindsight from writing something once already, and sometimes that will really pay dividends later, but adequate imperfection is the world we work in most of the time and it's the same for everyone.