IHATEYOU.SH

You may have repressed it, but remember the "climax" of Episode 3, where Anakin, full of rage, screams "I HATE YOU!" at Obi-Wan?



Wasn't that great?!  Truly Oscar-worthy.  If only we could replicate that utter rage when things go wrong in our terminal.  We can, thanks to IHATEYOU.SH!

This script uses bash's builtin compgen to list all of the commands available at the time, then iterates through that list, adding an all-caps alias.  These aliases will be local to your shell, so you don't have to worry about screwing up your pretty ~/.bash_aliases file.

To get rid of the aliases, either close the terminal session or apologize with the youareprettyok.sh script.

Why we built textbooktrad.es

We're building a new way for students to interact with colleges, essentially inventing a new market.  Naturally, the first thing we've publicly done is enter a crowded arena with textbooktrad.es  While we are tackling the problem from a different angle (we're students, instead of cash-hungry bureaucrats) by creating a P2P system, eliminating the middleman.  Still, there's very little chance of success, and a smaller chance of getting rich if we ever do hit it big.

So why even build it?  Why not focus on our main product?  As full-time students, any time to code can be precious.  Class schedules conspire to reduce our days to small chunks, devastating to the makers schedule.  Still, we think that Textbook Trades is the best way to spend our time.

We're still relatively new to the world of startups.  While it's important to stretch our coding horizons  it's a bad idea to tackle a project several orders of magnitude beyond our current ability.  Textbook Trades is within reach, letting us firm up our grip on the start-to-finish project in a live-fire trial run.  While we accomplish the same work in the time we've got, a larger percentage of the project is completed, a big morale boost.

Unlike a mock object in testing, Textbook Trades is live and solves a real problem.  We're accumulating users slowly but surely.  Student users, interested in furthering their education with nifty websites.  In other words, this is the perfect audience to launch our real product to.  We don't plan on discontinuing Textbook Trades and risk alienating our users (thanks to Google Reader for teaching us that lesson).

I realize that this isn't the ideal path for every startup.  We think that the time spent on Textbook Trades will be valuable.  We've made plenty of mistakes along the way that we now won't make as we progress on the project as a whole.  

Build it the wrong way first

Like I've said before, learning as an activity that blocks coding is annoying.  I want to Get Things Done, not browse unanswered Stack questions trying to figure out why your API returns an error.  I've also noticed as we continue working on textbooktrad.es that there are plenty of times where a library might come in handy (templating, for instance) but a vanilla implementation just works for now.

I'm sure we will eventually see the light and move to a proper system.  Until then, what we have works.  The crazy thing is, I think that this is the right way to do it because we learn the basics.  Writing a faux template system may lead to difficulties as we expand, but at that point we can move to an established player.  Until then, we're learning more about the language we use, instead of yet another API.

So try and build something, and fail.  Think of it like ablative shielding.  The purpose is not to make something brilliant out of the gate, it's to help the craft as a whole arrive in one piece.

A word of warning: don't do this with anything involving security.  Rule #1: don't roll your own crypto.

Startups by the window

A project manager at Microsoft recounts this story:

I once was at a meeting with Bill Gates himself.  Right before it started, I noticed that Gates was staring directly at me.  I flushed, not knowing what to do.  After the meeting, I got up and realized I had been sitting right in front of the window.  Gates' stare had nothing to do with me, he was just enjoying the view.

Everywhere I turn, it seems that there's a different startup demanding my attention and impressions.  Each one claims that it's the new $PRODUCT for $MARKET, and I absolutely need whatever they're selling.  90% will ultimately fail.

Paul Graham says that the one way a startup dies is by running out of money.  There are many ways to run out of money, and one is to put yourself in the wrong position.  Many startups take a position "by the window" and claim that the're doing great.  After all, everyone's looking at them!

99% of startups in the social media space are crowding the window.  It's very easy to be successful: make something that fixes a problem people have.  Does anyone really have a problem communicating [0]?  Posthaven bucks this trend, finding a critical need (data storage from Posterous shutdown) and filling it.

Startups should be against a wall.  Walls are boring.  People only pay attention to a wall-based startup when the startup has something important to say.  They're also much less crowded, and the people you find there are (generally) more committed to their work, avoiding the spotlight.  Two excellent (and sparse) walls are cell service providers and academics/education.

Fortunately, the world of startups is a strange-looking conference room, with vast, unoccupied walls and a few overcrowded windows.  If you feel that no one's paying attention to your startup, you just might be in the right place.  Keep at it.

No startup dies mid-keystroke

[0] Other than, of course, managing all of your social media efforts, and there are plenty of startups there.  Some of them are pretty successful.

Half-Boats

I was talking with a friend who was frustrated at his lack of accomplishment so far this semester.  "None of my classes are challenging." he lamented, "I feel that I haven't done anything in the past five weeks.  I'm coasting."  This is a common complaint.  After three years of classes and homework, I too, am beginning to question the worth of a seemingly-endless cycle of papers, projects and reading.  At the end, we get an average-sized piece of paper and a couple new lines on our resume.  After a lifetime of cultural pushes toward college, I wonder exactly what I want to do.

After pondering the predicament that the two of us found ourselves in, I finally had an answer for my friend.  He needed a boat.  Or rather, half of a boat.  His reaction was to be expected: "What am I going to do with half a boat?"

You put it in your garage, of course!  And then, every Saturday, you go out and work on it.  Screws go in one place, glue in another.  And the you discover you've got them backwards, so it's time to go to the local home-improvement store and pick up more supplies.  Eventually, it's 9PM and your wife is wondering just where you are and what was so much more important the now-cold dinner.  As the weeks go by, the half-boat starts looking more like a full-boat.  Eventually, the boat is finished.  A shining example of nautical finery sits in your garage and you realize that you really had no interest in helmsmanship but rather the process of building a boat.

Not everyone's natural inclination is toward boat construction.  My friend specialized in philosophy and thinking rather than mechanical engineering.  This doesn't mean that we can just "Your boat project is to philosophize something," in fact, the incredible amount of projects that could fulfill this statement might overwhelm and result in a fast-track back to coasting.  No, boat projects must be specific.

On the other hand, they can't be too specific.  Part of the fun is adding nifty new things to the boat that you never would have thought of.  If we limit ourselves, then the project will be too specific or easy to really exercise the creative freedom required.  That's why a boat is the example - it has a definite end, but still allows for tweaks along the way.

At this point, several half-boat ideas are already ping-ponging around in your head.  Excellent.  Go out and do it.

Doing It Wrong

How many times have you discovered that your previously-clever way of solving a problem was actually a terrible practice?  As a naive PHP coder, I remember foreach-ing over arrays for all sorts of reasons when PHP's native methods would have done a much better job.  Even simple languages have more features than conceivably be loaded into the human brain.

For instance, after my earlier experimentation with Rebol's PARSE, I wanted to give it a real run.  Regex is horrifyingly bad at wading through HTML but PARSE can handle it with ease.  With a few false starts, I finally had a decent script that'd grab all of the URLs linked from Hacker News' front page:

collect [
  ;TODO: currently skips "Ask HN" type questions
  non-quotes: complement charset {"}
  yclink: ["http://" any "news." "ycombinator.com" any non-quotes]
  ;HTTPS compliant (doesn't work on my build)
  ;weblink: ["http" any "s" "://" some non-quotes]
  weblink: ["http://" some non-quotes]
  parse webpage [
    any [
      thru {href="}
        [yclink {"}
        | copy link weblink {"} (keep to-url link)
        | some non-quotes {"}]
    ]
  ]
]

I was rather proud of this, and posted it to the Rebol chat for comments.  Sadly, one expert pointed out that I was doing it all wrong and should replace it all with a simple one liner:

some [thru <td class="title"> set link tag! set anchor string! (keep anchor)]

Ouch.  Good thing I don't have an ego, or it'd be bruised right now.  Fortunately, this isn't just me.  We all speak languages that are just too big for our brains to handle.  Here's some things that I've found useful in rounding out the corners of my knowledge:

Tutorials: Not just for noobs

Simple "Hello World" tutorials are great for installing and demonstrating the syntax of a language, but they're not all there is.  If you find yourself with a bit of free time, find an in-depth tutorial on a part of your language the you aren't familiar with.

To this end, I skimmed through a tutorial on creating a simple blog engine with Node.js.  In particular, I  was looking for how they rendered arbitrary pages, a problem I'd encountered on my own Node journey.  While the solution they offered was different, it didn't solve my problem.  I still don't consider this time wasted, as I've now got another way of handling things for future projects (say, when I finally get around to polishing my own blog project).

Programming community

As the Rebol example shows, running your code past experienced hackers can show us things we'd never heard of before.  Interestingly enough, you don't need to be incredibly lucky to get expert advice - just show a willingness to learn and ask properly.  As a rule of thumb, people don't like giving away free advice when the advisee has shown little to no effort to research on their own.

Find a problem, write a package

Most OSS communities are developed to the point where the basics are covered in terms of plugins.  Instead of picking the best plugin, try developing a basic version of your own.  Compare what you wrote to the "best" version and see what you can learn.

Got other tips?  Let me know!

[0] But you're here, so you already knew that, didn't you?

On standing out

It seems that a massive amount of time spent on the internet is spent solely on attempts to stand out from one's peers.  I may be taking the cynical view of this, but individuality is a big part of western culture.  It seems that most Twitter users are there solely to promote their "personal brand" - whatever that is.  Still, the market is pretty flooded for those who do have something to disperse, be it blog, library or startup.  Now that we've established that promoting your product on the internet is a fruitless endeavor  how can we make the impossible happen?

The social media space is full to bursting, but news aggregators like Reddit aren't, having created an artificial constraint by limiting the "front page" to a certain number of entries.  Obviously, you need the right aggregator for the job - a post about the local church's bake sale won't make Reddit's front page any more than an image macro will hit Hacker News.

So we're back to "Make what users want," but with a twist: We get to choose the users.  This isn't a simple process, whatever you make will be affected by user feedback, so finding the right community is important.  It should be small in order to have a better chance of hitting that front page, and smart to provide quality feedback.

I'm not trying to say "Join a community, it'll solve all your problems!"  It won't.  There still needs to be a good product.  Despite your best push at promoting, there's still a larger element of luck involved.  The factor of luck can be minimized by shipping on a regular basis.  Dice came up snake eyes?  Roll again!

Passively creating a product won't cut the mustard anymore.  It used to be that you could design something cool and tell your friends, and they'd tell theirs and so on.  Then bigger companies got wind of this and started exploiting it with "Social Media contests" and the like.  Now, if you try and tell your friends about something, they'll ignore it or worse, see you as a corporate shill.

In the days of the Altair, it was possible to wow audiences by making a game.  Every new game has to live up to the greats of it's genera (hard) or create a new one (harder).  And yet, books have been around for millennia and great ones still come out.  I think it's safe to say that it's absolutely possible to come up with good material, perhaps even easier now that one can study the greats.

If you found this informative, you can help me reach the front page at my chosen aggregator, Hacker News.

(Thanks to dystroy for reading the rough draft)