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)

Coding Fuel

I will often find myself exhausted at the end of the day, despite not accomplishing much of anything.  This used to frustrate me, but I think I've discovered why.  Hacking in and of itself is not difficult.  Rather, it's the getting there that becomes a problem.

Imagine a starship at rest in hard vacuum.  In order to accelerate, the starship must fire its rockets but when an acceptable velocity is reached, the rocket will be able to cease acceleration.  In the same way, it takes concentrated effort to get into the zone of coding but when the zen is reached, coding happens in an almost weightless manner.

That is, until something gets in the way.  Meetings, class, or other interruptions can sideswipe the coding zone with the same impact as a small moon colliding with our starship.  All velocity is lost and we're left off-course and disoriented.  We must bring our starship back on course and fire the rockets again, this time with damaged motors.

On a good day, I can make it past one, maybe two major interruptions.  After that, I'm pretty much out of my own rocket fuel.  There are a few extra boosts I can add (coffee works once and then ruins my sleep).  Most literature on this topic is focused around eliminating the interruptions, but I don't have that option.  My college has seen it fit to schedule my classes so the provide maximum interference to my productivity.  Some of you out there might be able to sympathize with meetings or other frustrations.

So what's a guy who just wants to hack away to do?  "Not hacking" isn't an option. I'm drawn to it like our starship would be drawn to a black hole.  Reading seems to be the only acceptable substitute my brain will take, and only sometimes.  It also might be possible to get there faster and burn less fuel.  Most of the advice here is psychobabble, self-help profiteering or both.

I could not go to class.  Failing out of colleges seems to be something of a tradition among the greats of hackerdom.  In fact, I don't plan to return to college if YCombinator accepts us.  In the meantime, I'm taking the reasonable option of staying in school, so no regular skipping of class.

I've also tried moving my creative hacking work to later at night but it's difficult to start that late.  The only good solution is to spend my weekends coding, when they're not already booked with homework or other events.  This does open another possibility: train myself to get into the zone faster by associating a non-zone thing (like time of day) with good work.

This is an ongoing experiment.  It may turn out that there's no right answer and I need to be patient until the semester's over.  Until then, I'd love to hear your thoughts, either here or at Hacker News.

What Hackers Need

As a senior Computer Science student, it's hard to miss the absolutely abysmal education that hackers get.  Instead of spending my time in all-night coding sessions, I find my time disrupted by homework and classes that are tangentially related to my career at best, horrible time sucks at worst.  I'm not here to discuss why this horrible tragedy has occurred, but rather to investigate what I think makes for a good environment to learn hacking in.  Just a note, this isn't to say that you aren't a hacker if you lack these (I missed a few myself) but to investigate the "hacker primordial soup."

First and foremost, I think that good hackers need access to a free coding environment from a young age.  "Free" has multiple meanings here.  The environment needs to be free of charge (at least to the aspiring hacker) as well as free from rules.  The average full-time programmer began learning at 13.  It's amazing that such a useful skill can be learned at such a young age.

It's hugely important that the environment be as free from rules as possible.  Mistakes should be both allowed and appreciated.  Too often we create narrow-minded tutorials that teach, but never allow room to hack.

I think that starting young is important because us adults haven't ruined the child's mind yet with their silly rules.  The forced conformity (at least from adults) starts at around 9th grade when we begin to pester the child about college.  The free flow of imagination is incredibly important to the magic that is hacking and early experimentation can cement the fairy dust before grownups can blow it away.

Secondly, our young hacker needs a mentor.  I have several friends who found their mentor in their programming classes in high school, while others just found an older student to learn from.  Personally, I think that the best place to find a mentor is in an active online community.  The mentor can provide direction and provide feedback far beyond what a compiler can provide.

Finally, our hacker should have a job.  I can't decide if the job should be a grueling minimum-wage one or entry-level programming.  Either way, this teaches what the "real world" is like and just how much a job sucks.  The burger-flipping level shows just how little those above you care about anything other than your ability to produce.  The programming intern position also teaches that to a lesser extent, but more importantly, it teaches us how much fun is lost when the coding is entirely directed by someone else.

I think that these three things will give any hacker-in-training a great head start.  There are many other things that I haven't delved into here (a passionate willingness to learn), but that's a topic for future essays.

I'd love it if you joined in on the conversation at Hacker News.