Wednesday, April 10, 2013

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.

Monday, April 1, 2013

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.  

Saturday, March 23, 2013

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.

Friday, March 22, 2013

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.

Tuesday, March 12, 2013

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.

Friday, March 8, 2013

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?

Wednesday, March 6, 2013

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)

Monday, March 4, 2013

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.

Friday, March 1, 2013

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.

Wednesday, February 27, 2013

Looking to learn something new? Try Rebol

Rebol is an odd language with an odd history.  It was originally put together in 1997 as an answer to the many things that plague modern programmers.  The goal was to create a language construction set using what we've learned from all the crazy trial-and-error in other languages.  For instance, have you ever wondered why we use curly braces?  In Rebol, square brackets are used (saving your shift key a lot of work [0]).

Alright, enough semantics, let's get into the real part of coding.  Download the Rebol binary.  While you're waiting, notice that you're not waiting, because the binaries are only half a megabyte.  This gets really impressive when you realize just how much is in Rebol.  Anyway, don't forget to chmod +x if you're on a good operating system.

So let's run through a basic "Hello World."  Step one:

>> print "Hello World!"

Well, that was boring.  How's about instead of going through the same boring syntactical tutorials, we check out the constructing power of Rebol and write helloworld in our own language?  Alright, now we're cooking.

To do this, I'll need to get a bit academic for a second (sorry, it'll be quick).  Everything you punch into the interactive shell (also known as REPL) is evaluated in Rebol's DO dialect.  In Rebol, a dialect consists of a set of instructions to work with a given input [1].  Let's take a look at the PARSE dialect, which takes the following format:

parse input rules /all /case

Let's ignore /all and /case for now and focus on the cool part.  Let's make an incredibly basic language where "a" is syntax for sending the string "Hello " to system.out and "b" does the same, but with the string "World!\n".  We could implement something like this in JavaScript like so:


While it's only a couple lines, it's still very difficult to extend.  In Rebol, it looks something like this:

parse "abc" [any ["b" (print "world!") | "a" (prin "Hello ")]]

The first two bits are simple: parse enters the PARSE dialect and "abc" is the input we're passing in.  The rules section is what we're really after..  Let's break it down:

[any ;If the parser finds any of the following
  ["b" ;an instance of "b"
    (print "world!") ;Output "world!" with a newline
                     ;parens mean that this code block will be executed in the DO dialect
  | "a" (prin "Hello ")] ;Same as above, but using prin, which doesn't output a newline
]

There you have it, your own special language (an incredibly contrived one, to be sure, but one nonetheless).  However, that's nowhere near as powerful as PARSE gets.  Let's taken on an interesting problem: determining if a mathematical equation is valid.  Benjamin Gruenbaum provides the following example in JS:


As you can see, this task is much more difficult for JS to express. It's a tad harder in Rebol, but not nearly as much.  To simplify things, we're going to do some assignment (using a colon instead of the equals sign, example taken from the Rebol docs slightly modified to reflect the latest version of Rebol):

expr:    [term ["+" | "-"] expr | term]
term:    [factor ["*" | "/"] term | factor]
factor:  [primary "**" factor | primary]
primary: [some digit | "(" expr ")"]
digit:   charset "0123456789"

The important thing to notice here is the recursive nature of the instructions.  "expr" is the top-level one you'll pass to the parse command:

parse "1+2*(3-2)/4" expr
== true
parse trim/all "1 + 2 * ( 3 - 2 ) / 4" expr ;use "trim/all" to remove whitespace
== true

There's much more in Rebol, so come to our our chat room and find out!  (This is a StackExchange chat, so you'll need 20 reputation on StackOverflow to talk).

[0] US keyboard only (sorry!)
[1] It's like a function, only more powerful.  Every expression runs in a dialect.  You can read about dialects in the docs or Wikipedia.

Monday, February 25, 2013

The hardest question on the YCombinator application

For the past two years, I've worked at becoming a better programmer, all with one goal: my own startup.  After lots of work, learning, and discussion, my friend and I have an idea and a half-done prototype.  It's finally time to do what I've been waiting for all this time: Go to YCombinator.

Well, we have to apply first.  Naively, I thought the application would be like anything else I've ever applied for.  I'd fill out my name, answer a few questions about myself and my idea.  I was incredibly mistaken.  Writing up answers took up four days of writing, editing, and thinking.  It forced us to finally look into how we'd split up equity, made us think through our entire pitch (four times), and had one really, really hard question.

No, it wasn't the money one (though I'm still not sure how to answer).  Nor was it "What is your company going to make?" (though that was the second hardest).  Surprisingly, the most difficult question for me was:
If we fund you, which of the founders will commit to working exclusively (no school, no other jobs) on this project for the next year?
Founding a startup is a big risk.   I could find myself penniless in two years with no property and fewer prospects.  I owe it to my parents to finish my degree, and to my fiancee to have a secure job after we get married.  The startup life can't promise either of those.

Every startup founder has an incredibly tempting out: the day job.  As Dilbert-esqe as they are, a day job is a siren call to the guy who has been subsiding on Ramen singing the promise of a salary and a solid night's sleep.  I know at any time, I could drop the whole pretentious startup thing, finish my degree, and get a nice comfy job somewhere where someone else will make all the decisions.

Answering yes means that I'm giving up on finishing my degree in a timely manner, if at all.  It means I'm accepting one of the most stressful jobs I could have.  I spent a lot of time staring at the screen, wondering if I could be daring enough to put down an emphatic YES.  I almost didn't do it.  I almost said "I'd like to work on a startup, but..."

You may not be an entrepreneur.  In fact, you don't even need a job to hit a decision like this.  Our culture (and parents) emphasize a conservative lifestyle, playing it safe at every turn.  Today, take a risk.  Do something different.  Don't let yourself worm out of it.  You'll be surprised at the results.

If you've read this far, you probably should join the discussion on Hacker News.


Friday, February 22, 2013

Is JavaScript's ubiquity a bad thing for Node?

There's no doubt about it, JavaScript is as close to a universal language as one can get, at least in terms of developers with passing knowledge about it.  Regardless of server-side language preference, virtually all web developers know some level of JavaScript.  Unfortunately, most only have a very basic level of JS ability, instead using jQuery or the like.

The truth is, it's pretty easy to write bad code in JavaScript.  Consider the following:

$(document).ready(function(){
    $(document).ready(function(){
          a = $("*").find("*").find("#myDiv")
          a.onclick=function(){
              alert("U CLIKD")
          }
    })
})
Ouch.  Two document.ready, horrid abuse of jQuery's universal selector and not a semicolon in sight.  I don't know what's worse, the code itself or the fact that it'll work on every major browser.  The web's been incredibly forgiving to programming mistakes and it's showing.

This isn't a rant about terrible software.  Instead, let's talk about one of my favorite technologies: Node.js.  One of the biggest advantages that Node brings to the table is the ability to use one language across the board in your project, but Node is a lot less forgiving of poor code.  The big question is this: will the use of JS for node help or hinder the Node ecosystem?

As a part-time optimist, I see this adaptation of a universal language as a net benefit for Node.  Many great programmers attempt to be always learning new things.  Why not chose that cool new framework that's in a language that you already know?  That's how I got sucked into Node awesomeness.

Others think that bad programmers will give Node a reputation for being incredibly difficult (even though it's pretty simple) as they try to build a Node app and fail.  They'll spread the word that Node is a harsh language and "totally unradical" (or whatever dialect they use).

What do you think?  Post your opinion in the comments here or at Hacker News.

Wednesday, February 20, 2013

My dumbest productivity hack yet

I've talked about productivity before.  Figuring out new ways to work harder is almost always more fun than actually working harder.  For bonus points, you can efficiently organize how you read all your productivity blogs.

Enough editorializing.  Remember when I wrote about to-do lists?  Yeah, those are still important.  But behind every item on a list is a greater goal that you want to achieve.  "Mop floor", "Do dishes" and "Dust cupboards"  all have the goal of a clean, livable kitchen.  A more difficult challenge is determining what the overarching goal of "Organize Database", "Fix bug #133", and "Check analytics" is.  Clearly one wants to have good code and a better product, but what's the point?

Google knows what their point is, and it isn't "Don't be evil."  It's to organize and index all of the world's information, be it websites, books, or photos.  Whatever you do, there should be a goal.  Currently, our startup is looking at the state of education and saying "Yeah, we can fix that."  But "do something 'bout that" isn't a goal unto itself.  Acknowledging that something needs to be done and actually finding something to do about it are worlds apart (unless you're in politics - then the second bit is irrelevant).

So we've got a subset of the problem identified and are attacking it, slowly but surely.  We already had two pivots, one tech and one ideological.  The problem is that the answer to our Big Question [0] of "Heck, is this even possible?" is quite clearly no.  No matter what action movies say, two guys with computers simply can't change the world.

Our big ideological pivot has been from "Hey, let's build a thing" to "Hey, let's try and create something that other people will want to join."  Our startup will almost certainly fail unless we bring others on.  These others don't have to be additional co-founders (too may cooks will spoil the broth) but investors, supporters, and early clients.

So we now have a goal that all of our to-do items can point towards: Get others on board.  Despite arguments to the contrary, we still think that an accelerator is the best place for us as it will provide "others" better than we could solicit on our own.  Any accelerator worth it's salt will also know what others we need much better than we could.

We won't accept anything less than the best, and the best accelerator is without question YCombinator.  If you need any evidence of that, just read through Paul Graham's essays.  I certainly have, and it's made a world of difference.

The funny thing is that it's not the content of the essays that makes the difference (though it's immensely helpful).  Remember what I said about goals?  It's very easy to lose sight of the overall goal as you're closing bugs and documenting.  When I feel exacerbated and miss the whole point of what I'm doing, I can look at that tab and remember why it's all happening.

So there you have it folks: The dumbest productivity hack to date: A tab in a browser.  It's also one of the smartest - Set up your work environment so you remember why you're working.

[0] The reason that particular post is so poorly-constructed is due to the fact that I was confronting the reality that all startups must face (we'll fail at it alone) with the mentality that we must do it alone.  Die Hard, you're a great movie but you give terrible startup advice.

Monday, February 18, 2013

Winning is easy, you just have to try

I've noticed an odd phenomenon among people in general - they're afraid of failure.  Yeah.  Me too.  So much so that I'd often rather do nothing than risk failure.

Let's move on from the "well duh" department.  There have been plenty of studies, blog articles, and crazy uncles telling you to try something because Failure Isn't Bad.  Bah.  Failure is bad.  Otherwise, it wouldn't be failure.  There are many different good things that can result from something going wrong (say, vulcanized rubber) but on the whole, one wants to succeed.

Learning how something doesn't work is often a step on the path to discovering what does, but we've lost sight of what the whole point is.  Instead of seeing failure for what it is (a step on the path to success), we have made it into an end of itself.  Failure isn't something to be proud of.  Instead, be glad you're further along the road to success.  Focusing on failure tends to create a more-permanent failure.

When I try something new, I want to learn, and I want to win.  I accept that work needs to be done and things will never work out the way I want them to on the first time.  That doesn't mean that success can't be easy.  Instead of looking at failure as the metric, why not break success down into smaller parts?  (astute readers will notice that this is the basis behind A/B testing and to-do lists).

For instance, I've been working to make myself a more sociable person.  I could list off the many times I've "failed" and what I learned from that, or I could look at just how easy small changes for the better can be.  As it turns out, saying "hi" as you walk past someone makes them feel a lot better and more likely to reciprocate.  Making that change was a small success, but it was a success nonetheless.

Not all changes can be as small and simple as that, but when I run git commit for something as basic as adding a <br />, I could let it roll pass me and move on to the next thing.  Instead, I choose to see that as my product becoming one step better, no matter how small that step is.

Friday, February 15, 2013

Is there a place for Java?

While Java hasn't elicited elaborate rants like PHP, there's still a good bit of hate out there.  The disadvantages are well established: Java, while fast at executing, slows down development through an incredibly verbose syntax.  It's also much easier to create tangled webs of classes, so much so, it's coined the term Lasagna Code (Spaghetti code with too many layers).  Still, it's the most popular language out there (or at the very least, in the top #3).  Cynically speaking, this is because Java makes it easy to look like you're working.

In terms of productivity, where does Java fit in?  Is it a dead-end of a language, doomed to be a litmus test for the quality of a programmer?  Will Java's entire contribution to the hacker community be to confuse newcomers to JavaScript or can we find a happy niche for it in some academic job?

Actually, yes.  There just might be a place for Java in learning programming.  There's lots of debate on the topic of a first language (though Python seems to be a consensus).  Don't get me wrong, Java is a terrible first language (I don't care about your "standards").  There's so much overhead (Hello World can barely fit into a tweet), teaching Java to newcomers feels like requiring a full APA paper for each homework question.

So Java isn't appropriate for beginning programmers, nor is it a good choice for those who want to Get Things Done professionally.  However, there's a huge gap between the two, and that's where I think Java might actually be useful.  Remember my rant about the misuse of jQuery (and by extension, all other abstraction libraries)?  Here's me, a fairly liberal programmer, advocating the use of verbosity!  Next thing you know, we'll all be riding our airborne pig-mounts to work.

Seriously though, the one place verbosity shines is learning.  It's much better to learn the system underneath what you're doing in order to write better code when you move to higher levels.  In that case, Java seems designed to teach Object Oriented principles.  Everything is nouns!  Suddenly, absurdly classed systems become teaching examples exaggerated for effect.

This exaggeration also helps teach design patterns.  Here's an admission: I never got around to really learning design patterns until I had to in software engineering.  Up until then, I was using event listeners without realizing that they were a great example of the Observer pattern.  Java's ridiculous explicitness forces students to learn both the how and why of each pattern.

Regardless of how much OO is useful to the professional dev, it's good to know it.  One could almost make the argument that learning Java/Extreme OO at this stage will teach our hypothetical student why they're a bad idea.

Wednesday, February 13, 2013

The Big Questions

Steve Blank describes a startup as:
a temporary organization in search of a scalable, repeatable, profitable business model
This is the Big Question of any gathering of geeks in some semblance of a business.  They're assembling a product to see if it'll even work - and it seems like it takes forever to start getting that question answered.  It's vastly important to start getting external answers to that question early.

There's a lot more questions than the Big One.  Some are subsets (Will customers want feature X or Y?), others are external to the specifics of running a business.  We've stumbled onto quite a few questions, some even bigger than Steve's.  Some that have crossed our minds:

Can two guys in a technically-conservative city in a technically-conservative college create a startup, one of the most liberal tech things out there?
Is it even possible for first-timers to learn all the intricate parts of a startup and still succeed at some level?
Will we be able to take on an entrenched bureaucratic system that's resistant to change?

Yikes.  I could spend all day worrying about one facet of one of those questions.  Sometimes I catch myself falling into this trap (what happens if this was all a really stupid idea?)  Downward-spiraling negativity can be deadly to my productivity.  There's a counter to this - reading inspiring books/articles that push me onward to build.

It's also important to acknowledge these questions and try an answer them.  The whole startup process is designed to tackle Steve's question above, but there's other questions, most notably, "where are the facts?"  The key to remember is that there are no facts in the building.  As such, I went to interview two people in key positions in our target market.  I'm glad I did.  Turns out there were fundamental assumptions that we got wrong and it's time for discussion and pivot.

Monday, February 11, 2013

How can I do better?

I had a pretty rough/busy weekend and wasn't able to hammer out anything acceptable last night, so I'm turning the tables.  Recently, I got my 10,000th hit on Recoding.  Awesome.  Still, I'd like to improve.  Steve Blank is fond of saying that there aren't any facts inside the building.  So, in the startup spirit, I'd like to ask you guys some questions (you can answer here or in the HN comments, I'll be watching both):

-What are your favorite types of articles?  Is there anything interesting you'd like to see me write about?

-What sort of thing are you likely to comment on?  One of my big goals is to inspire life in the comments section.

-Overall, how can I do better?

Friday, February 8, 2013

What's taking you so long?

As I've alluded to earlier, a friend and I are working on building an MVP for a startup.  Awesome.  We've got the idea, have key connections in the industry, little competition, and are ready to tear into some code.  I had hoped to have the MVP finished by Jan 14th. so I could write about it here and we could start generating hype.  No dice.  We reset our due date to Jan 31st and hacked all weekend.  We got a LOT done, but looked at our to-do list and realized that it had grown.

Obviously, startups are not a walk in the park, even when life's handed you some great opportunities.  We seem to have fallen for the idea that code is trivial.  Technically speaking, the core of the product was implemented in November.  Since then, all we've done is build up awesome things around it (and school, both of us being full-time students).  We've learned a lot in the past few months.  Here's just some of the things we've encountered:

Stuff creep

This isn't scope creep, as the scope has stayed pretty much the same.  Rather, we find ourselves adding page after page to our todo list of things we never thought of that are must-haves (For instance, a user should be able to reset their password).  It's very important to know what done is.  Sadly, one can't determine everything at the beginning of a project, especially if this is the first time.  We've had some issues with figuring out what we should do next.  We're using Trello (an awesome site) to organize everything (have I mentioned it's drastically important to have a todo list?).  Despite the amount of planning we have put into this, there are still things that we completely missed out on.

Technical difficulties

We're building this with Node.js for two reasons:
  • We only have to work with one language from start to finish (very helpful for first timers)
  • Node.js is just plain awesome.
Still, various frameworks and asynchronous idiosyncrasies pop up and bog us down as we learn new things or fight back bugs.  It's very easy to assume that everything will work just fine the first time you write it, and schedule for that.  Make sure to allocate time for learning and fixing (most likely, you'll be doing more of those two than anything).

People difficulties

I'm an idiot.  We all are.  I'm sure even the best developers have confessions about how they've managed to shove some code through a trash compactor.  It's ok.  We all suck.  It'll slow you down but that's part of life.  Remember to take a break and eat healthy.

Regardless of above, we're not only still working on our MVP, we're accelerating!  Stay tuned for more updates.  Our latest due date is either March 1 or February 22, depending on who you ask.

Wednesday, February 6, 2013

What you shouldn't do as a boss: Complaints from the trenches

Today's post is adapted from a talk I gave to managers in training.  Even if you're not a manager, I hope that you too can pick up basic principles and help implement them in your organization.  If you're interested in hosting me for a talk, you can find me via email or @RecodingBlog.

My first job was with a small IT-turned-web-development company that accidentally developed a software division.  Most of the people there were playing at their jobs, using congratulatory back-patting to reinforce the idea of how "great" they were, instead of acknowledging weak points and moving to reinforce them.

They had an excellent market position but were slowly losing it thanks to the above reasons.  There's a life lesson here: If you are not pushing you and your team to excel, someone else will and you'll find that your customers don't have nearly as much loyalty as you thought they did.

Management has the biggest impact on the velocity of a team, software or not.  Here are five simple "don'ts" that can have a huge impact on team productivity:

Don't ignore workers


There was a very flat management structure at my old job.  Virtually all of the ~20 people reported directly to the CEO.  This made it very difficult to find direction.  While flat management styles seem to be all the rage nowadays, the studies show that managers should have no more than 8 people reporting to them or else chaos will ensue.  Even if you've got less than eight people reporting to you, make sure that you stay in contact.  I strongly recommend a weekly one-on-one meeting just to check up.  An employee that feels that they are heard is happy.

Don't demand perfection


Scope creep is a very real danger to any software project.  Yes, there are many cool features that your product can have, but there's a limited time.  In most industries, you're racing against your competitors.  The (unwritten) spec of my project was subject to the whim of the CEO and all changes must be implemented before we release 1.0.  The project has been going on for over 1.5 years and still is in development
"If you are not embarrassed by the first version of your product, you’ve launched too late." -Reid Hoffman, Founder, LinkedIn

Don't keep information away


We woke up one infamous morning to discover that the CEO had announced that we'd be developing a mobile version of our product.  Now, he announced it to our customers, and us employees were CC'd in.  Ouch.  How "the boss" communicates with employees says a lot about their attitude toward them.  Instead of CCing, become an information conduit.  Remember those one-on-one meetings?  Use them to bring relevant information.  Make sure you don't assume that an employee doesn't want to know something.  Asking only takes ten seconds.

Don't make status reports anything significant


I once got three requests for project status on the same day.  I don't know what management expected to change over my lunch break.  Status reports only slow progress, as the employee has to put time aside to write the reports.  Instead, use that one-on-one meeting (aren't these handy?) to find out what's going on.  Need more information?  Chances are, your team is generating a lot of data through commits, bug trackers and other useful tech.

Finally, don't let bored people quit.


The tech world brings about an incredible amount of mobility.  It has become incredibly important to nurture professionals.  I don't mean pampering them, but rather ensuring that they have the ability to gain new skills.  I've moved on from my first job and settled into a place using cutting-edge technology developing a product that's never been made before.  Needless to say, it's much more exciting.  An important, but oft-overlooked point here is to respect free/learning time.  It's very easy to override this as it doesn't produce anything short-term.

Tuesday, February 5, 2013

Being Programmers

Today's post comes from Ryan Kinal and touches on something very important to us here at Recoding: people who can't program.  Unfortunately, we have met the enemy and he is us.

A common source of frustration in the web development community is programming done by non-programmers. There is plenty of code out there written by people who have little understanding of data structures, efficiency, and architecture, and that can be frustrating to those of us who have some training in those areas. When we're hired to work with this kind of system, we wonder how the hell it could have gotten to be like that.

Why on earth would someone store all that data in plain text? Why is the login system a flat file? Why is this web service one gigantic file? Why is everything so tightly coupled? This is miserable!

The cause is, often, that the people designing and building the system just didn't have the knowledge necessary to do it well. Maybe databases were foreign to them. Perhaps they had never heard of an event-based architecture, SOLID and DRY, or even taken a class in Object Oriented Programming (or whichever programming paradigm you prefer). And even if there is knowledge of these concepts, perhaps the implementation of them is confusing or not intuitive in the current environment.

It is easy to look at this from a perspective of knowledge and experience, and say "Those people are not programmers." After all, these are fundamental concepts - essential to writing good code - and they have never even heard of them. I'll be the first to admit to thinking these kinds of things.
But here's the truth: If this kind of knowledge is essential to being a programmer, then none of us are programmers.

If we, as developers, are doing our jobs correctly and passionately, then we will always be learning. Just as Ryan from today looks back two years (or one year, or six months), and sees serious flaws in fundamental areas of architecture, design, elegance, and efficiency, Ryan two years from now will likely look at what I write today and think largely the same things. It's inevitable.

So, when you next encounter a bad piece of code, keep that in mind. Yes, it's frustrating, and I don't blame you for being frustrated. But keep in mind that it could have been a younger you writing that code, on a step to wherever you happen to be now. I would be unlikely to berate my former self, for fear of scaring myself away from the profession I sincerely enjoy.

Do the same for others.

About me

My name is Ryan, and I enjoy learning. I also enjoy teaching, though I don't think I could teach professionally. Like many others, I find that teaching promotes learning. Writing a blog post, such as my previous Object Oriented JavaScript posts, I have to think critically about the subject matter. I have to clarify it for myself before I clarify it for others, and that forces me to learn. I end up with a better understanding of the subject matter.

I've been interested in the web for a long time. I've written JavaScript for a long time, and can honestly say it is my favorite language (and I will likely write more on that subject over at Blogascript). I consider myself lucky that I have found a profession that allows me to be creative and expressive, allows me to truly own what I create, has such a great culture of teaching and learning behind it, and is considered monetarily valuable.

I'm one of three full-time web developers at McKissock Education, where I work with great people to provide professional education to those who need it. It's also where I met my partner in SlickText Text Message Marketing, my fairly-young startup.

Monday, February 4, 2013

When you have nothing to do

We're in the thick of our second weekend trying to bang out an MVP to launch our first startup.  It's harder than it seems (already).  There are tons of stuff they never taught us in class (proper password resets, for starters) that we've got to learn.  Node's modularity has helped immensely, having the ability to drop in a single module in to do a single thing is so useful.  I don't know how I developed without it.

Still, we can't slam a bunch of packages and Bootstrap together and call it a day.  We're building a quality product and there's still a lot of work to do.  Our problem is figuring out what work to do.  I'm sure those of you who could rattle off all sorts of nitty-gritty that needs to be done are laughing at us right now [0] but we're new and this is difficult.  Give us time.

I have found myself sitting down to get some more coding done and having no idea what I should do next.  Yes, we've built a to-do list.  We've had several mini-discussions where we determine what the next iteration will look like.  And yet, I find myself at a loss of things to do.

This is partially due to my resistance to lean into the pain and work on things I really don't want to do (writing a Terms of Service, repeating code just to add Yet Another Form).  I've had some success challenging myself to come up with inventive ways to refactor.  Some refactoring leads to security holes, but at least fixing those is interesting and we still end up with better code.

I alluded to our bigger problem earlier: We're first-timers.  There's a lot out there that can only be learned by doing.  One of those things is what to do.  I've found myself going to other sites that have features like ours just so I can see what features they've got.  It fills in a lot of holes in my knowledge.

Simply having something to do doesn't completely solve our problem.  Once we've got something, we're flooded with different ways to accomplish that task.  Most of the time there isn't a general "best practice" for everyone.  Instead, we're stuck with the ubiquitous "do what's best for you" mantra that almost never is followed by a discussion of the options and who they're best for.

We are stumbling in the darkness but at least we're stumbling toward something and that gives me hope.

[0] If you are one of those people, could you rattle off that list into a comment for me?

Friday, February 1, 2013

In defense of strong types

Anyone who knows my coding style probably thinks I'm going to completely contradict my title.  Nope.  I've found a new appreciation for strong checking [0], if only a little bit.  As it turns out, the additional security found in strong typing can be a cure for my least-favorite part of programming - those that absolutely shouldn't be programming at all but still managed to get higher-paying jobs than me.

Those in the strong typing camp claim that their method helps produce better programs, thanks to the additional compile-time testing.  This is absolutely true, and helped me find a handful of errors back when I wrote Java on a regular basis.  The trouble is, this extra security comes at the expense of language verbosity (ArrayList<String> stuff = new ArrayList<String>(); anyone?).  Being a liberal when it comes to programming, I prefer to have a concise language that allows for rapid prototyping and development.  This does create errors but not nearly as many as my CS Professor would predict.

Of course, this entire entry depends on strong typing being used exclusively as a sort of baseline test (My freshman mantra: "It compiles!  Ship submit it!").  It's not, I know.  Compiled, strong languages do have significant speed improvements over "lesser" languages like PHP (Others say that speed of language usually isn't nearly as important as speed of development).  However, strong typing does act as a rudimentary test.  Whenever a variable is declared, there's a "test" to ensure that it's correct, otherwise ERROR.

Liberals argue that this provides false security.  "How can we tell if the variable's value is correct, not just the type?  We need more tests!"  In either case, more tests are needed.  If you're building something significant, you need tests.  Liberal programmers are free to throw caution to the wind and depend on their own tests, claiming that the time lost to writing tests is made up by writing in a simpler language.  (I haven't found any studies to back this up, I'd love to hear it if you've got one).

So far, I agree with the hippie liberals.  It's much better to write your own tests to determine what's going wrong.  Who knows your code better: You, or a compiler?  Using strong typing for testing purposes also breaks separation of concerns, but that's a nitpick.

If you can't tell, I don't really like strong typing.  Oddly enough, I also don't like it when a program doesn't fail on what should be an error, but continues soldiering on with weird results.  (thank heaven for 'use strict';).  Back to where I was: People who get paid more than me to write terrible code.

It's a sad reality that there's a huge amount of terrible code out there.  A large portion of this code is glue between several plugins mashed together into a "website."  Scary.  However, strong typing (thanks to that very breaking of separation of concerns) forces basic testing onto whoever is using the plugin/API. The "programmer" (and I use that term loosely) must provide semi-correct data.

Of course, those who write glue code are looking for the easiest plugins to steal use.  Ones that force them to provide better code will be dumped by the wayside by both glue coders and higher quality coders with liberal leanings, so this is mostly a pipe dream.  (Conservative coders will already be working in a language with strong typing.)

So strong typing is bad because it forces you to write extra code that amounts to more tests that you'll have to rewrite anyway.

[0] In this case "strong typing" means that the language gives an error if a variable is of a type that wasn't expected.  This means that the programmer

Wednesday, January 30, 2013

Distractions, or how I learned to shut up and love the list

I hate getting distracted.  I always amaze myself when I get "in the zone" and slam out some really great code.  Unfortunately, I'm in a college dorm (one of the most distracting places in the world) with an internet connection.  What's a poor ADD kid to do with all this information overload?

I've tried lots of things.  Post-it notes, coffee, regular sleep schedules, moving to the library, giving myself too many breaks, not giving myself enough breaks (fine line there) Writing Things Down, Pomodoro, etc, etc.

There's a zillion "productivity" websites, books, what-have-you out there each claiming that they've got "the best" way to Get Things Done.  (Spoiler: they're all wrong).  One of the awesome things about us humans is that we are all different.  There's no best way.  We've all got our own way of doing stuff, from The Four Hour Workweek to coding six days a week because we're having a blast.  Thus, take my advice with a grain of salt.  This is just what works for me.

I tend more toward six days a week.  I love building stuff.  My work usually can be divided up into two categories:

Stuff I don't want to do
Sadly, this is the majority of work I've gotta do.  While it's less of a majority every passing year, there's still a whole lot of it.  The big problem is that I'll spend most of my time inventing creative ways to avoid this kind of work.  In my mind, I've got a gigantic ball of homework, errands and todo to get done.  Creating a list of some sort (my favorite style is to put each task on a Post It, that way I can tear it up when I'm done) helps me conceptualize my workload.  It's a lot more realistic when I've got everything written down.

Stuff I want to do
Coding.  Lots and lots of coding.  Also, some learning and other coding-related activities.  While this is the "fun" stuff, it's still difficult to avoid distraction.  Good coding requires good focus which requires few distractions.  The advantage here is that I can get in "the zone" once I've started.  It's much harder to start than one may think.  The trick is to keep a todo list - it's much easier to overcome my stagnation when I have a goal.  I also semi-organize my list by the size of task.  It's great to start off with a quick, easy task to get that immediate sense of accomplishment.

Once I've started, it's easier to keep going.  The cycle of success pushes me onward to achieve more.  That is, until I hit a bug.  Bugs are evil.  Some bugs are simple and are only the result of my inability to type.  Others are fiendish little things that explode into an entire afternoon lost to misconceptions and other idiosyncrasies.  As time drags on with no new progress, it becomes harder and harder to rationalize continued work.  It'd be nice if I could just "work on something else" but these sorts of bugs usually block a large segment of the project.  We'll see if this changes as our codebase grows (don't worry, we're keeping it modular).

Stuff I want to do but gets in the way of stuff I really should be doing.
Hacker News is great.  You guys have a way of promoting absolutely fascinating articles.  I just spent half an hour watching and reading about lots of 0s and 1s blowing each other up in spectacular fashion.  There's two dozen inspiring articles that hit the front page every day all of them begging to be read.

Truth be told, I only actually needed to know about .5 of these articles, maybe more depending on what stage my startup project is at.  This is where I could use some improvement.  I've got to figure out a way to limit the amount of time I spend reading blogs.

Got any suggestions?  I'd love to hear them.

Monday, January 28, 2013

Learning new things is stupid

I'm tired of learning.  I want to do something.  This may come out of the fact that I started (briefly) with Ruby, then actually got started programming with Python.  Our CS program did a rather obtuse about-face and taught us Java for two years, then had a rather abrupt plunge into PHP as I tried having a real job and finally am settling down with JavaScript.

Along the way, I've had all sorts of cool projects [0].  Most of these projects were fairly basic.  Along the way, I learned several things that were building blocks for the next "level" of project (which you'll notice is the whole basis behind my project learning model).  I jumped onto a different language before I could make that the next jump in learning.

I was forced back into the basics after every language switch.  See, learning's different at the basics.  Time spent programming is mostly time spent learning programming.  There's less time spent learning as you tackle each subsequent language but that advantage only goes so far as you've learned in the previous language.  If I spend 50% of my time learning Java while I'm "programming" and then switch to JavaScript, I'll have a speed advantage until I hit that 50% time.  Roughly.  Things like data structures and design patterns tend to stick beyond languages.

As we move from spending our time learning to building, a curious change happens.  More of the learning time is spent fixing mistakes, rather than determining how to do things the first time.  I'm only qualifying part of debugging (mistakes due to language/framework) as learning here.  For instance, Jade allows inline JS as control flow for HTML output, but the indentation's wonky.  I lost no small amount of time to this, eventually creating a StackOverflow question/answer pair so others could figure out what went wrong.

These debugging moments are different than others because of the technicalities learned.  If I spend a day because I wrote var hammerTime; instead of var hammerPants; then my time was spent learning how to code better rather than if I had misused var, which would be me learning to code.  Got it?  [1]

Alright, back on track.  Learning new things is a tedious process, not to be undertaken lightly.  Half the point of coding today is to become the person who'll want to strangle your now self.  I've written "Hello World" in everything from lisp to Java.  I'm coming very close to actually building something worthwhile.

Or at least I think so.  Every project has been worthwhile in a sense.  Sure, coming up with crummy haikus that only occasionally explode doesn't feed the hungry, but I enjoyed the project and it's provided people with some entertainment.  I certainly have created wealth, if only a small amount.

So when I say "I hate learning [the basics....again]" what am I saying?   What's this "worthwhile" project I keep pursing?  I'm beginning to believe that this project that'll actually do something is my next  project, and always will be.  I'm ok with that.

Working on a current project is absolutely fun but there's a certain dissatisfaction with a solved problem.  The dissatisfaction differs among developers as well as the definition of "solved."  Speed isn't that much of an issue to me but others may see anything as unsolved if it can go faster.  Either way, problem solving, not learning, is the priority.  The best learning happens to be a blissful side effect of the problem solving.

What I want to do is learn clever ways to do things I already know how to do, instead of the basics.  I'm tired of "solving" problems in a new way.  I want to go deeper instead of wider in the T paradigm.  Thanks to Node's help, I finally have a language to do it in.  Now, where do I start?

console.log('hello world!');

Again?!?

[0] For various levels of cool in various completed states.
[1] Yeah, there's lots of semantic games you could play with those two paragraphs for karma on Hacker News.  You could also do something productive with your life.  It's your choice.

Friday, January 25, 2013

Mitnick: Both sides of the law

[Ed: this is adapted from an essay for class, so the style might deviate from the usual]


Kevin Mitnick is a perfect example of Paul Graham's “unruly” hacker who breaks into things not out of malicious intent but simple curiosity. Or so Mitnick claims. Before he was arrested, he was the most wanted “cyber-criminal” on the FBI list. After his release, he has authored several books and become a world-famous consultant. In a recent Twitter update looking back on his incarceration, he says “Glad that nightmare is far behind me. How things have changed.” [0]

Apollo Robbins (a theatrical pickpocket in Vegas who some consider to be the best in the trade[1]) also had dreams of creating a team of ex-cons turned good consulting with security forces around the world. Apollo found that his teammates were “nervous” when working with law enforcement and both members of the team with a criminal record had relapsed.

There are many other examples of criminals turning the tables and working in the same field, this time as law-abiding citizens. Some relapse, some don't. Most people are reluctant to hire an ex-con which contributes to the relapse rate. The potential downside is so strong that many don't consider the statistics.

Back in the days of Mitnick, cybersecurity wasn't nearly as understood as it is today. (Heck, they still used “cyber” as a prefix). One didn't go into “Information Security” as a profession. Even tech companies dropped the ball on security. The lack of employment opportunities combined with the social “hacker” stigma and corporate resistance to change meant that most security opportunities lay outside the law. This is not to say that everyone working in security was malicious. Many were initially motivated by simple curiosity – there was a whole new world to be explored. Some, like Kevin Poulsen started using newfound skills for material gain. (Poulsen manipulated the phone lines of a radio station to win a Porsche [2].)

As rogue crackers exposed the need for technical security, large organizations found that these very crackers were the ones who were the best at what they did. It suddenly became advantageous for hackers like Mitnick and Poulsen to consult. A new breed of hacker emerged: the reformed criminal. Suddenly, having a criminal record meant that you knew what you were doing, rather than being a liability.

Technology continued its explosion across the world, leaving little untouched. With this explosion came new security opportunities, and the field flourished. Security workers began to be able to learn the tricks of their trade without illegal activity. Once able-bodied workers sans criminal record were available, the industry turned to them, shunning most crackers.

Today, if anyone wants to enter the world of information security, they would do well to stay well within the confines of the law. It's incredibly cheap to set up a test system (thanks OSS and FSF!)

Wednesday, January 23, 2013

Beware: Limbo Dancers!

Graffiti's bad, right?  We can't have these hooligans spray-painting various obscene terms all over our beautiful city.  Something should be done!  We should create laws establishing strict penalties for destroying the inherent beauty of our stark concrete.  Police squads will be created, a community watch will be established and sanity and order will be restored.

At this point, society has successfully eliminated the graffiti problem.  Sadly, we've also eliminated the limbo dancers.  At the bottom of a bathroom stall door in our science building lies a warning: "BEWARE LIMBO DANCERS."  There's also a helpful arrow pointing to the bottom of the door indicating where said limbo dancers may enter.

The draconian laws earlier would eliminate this bit of graffiti alongside all of the "ugly" stuff.  Here, we'd only lose a bit of amusement.  Elsewhere, overbearing laws have much worse effects.  It's far too easy to say "this is bad" and outlaw it without contemplating the implications.  The heart-wrenching case of Aaron Swartz shows what happens when lawmakers pursue career over country.

We're a country of hackers and that's what has made the US what it is.  Sweeping legislation can only leave us surrounded by graffiti or devoid of limbo dancers.  We need to establish a middle ground, as hard as that may be, or perish.

This will be incredibly difficult for the politicians so long as the current system remains in place.  Who this won't be difficult for is us hackers. If we want to inspire others to challenge the binary status quo, we need to set an example.

What can you do to find that edge?  Explore compromise today.

Monday, January 21, 2013

Becoming teh awesome

One of the things that defines a good hacker is their drive to improve.  This often stymies young hackers as they desperately want to push forward and improve their skills but don't know how.  There are infinitely many wrong ways about it.  One path that seems to have met with some success is emulating "good" programmers by attempting to emulate their public attributes [0].

There are three different buckets that these attributes fall into.  First, there are things that will directly influence your coding skill through programming.   Then there are things that will help make you a better hacker but aren't necessarily "programming."  Finally, there are some things that famous programmers do that don't actually contribute to skill.  In rough order of importance:

First, never stop coding.  I mean it.  Make an effort to code every day.  There are a ton of different ways to accomplish this:

There's also something to be said for both reading code and teaching others how to code.  Reading code exposes you to other coding styles and formats for getting things done [1.5].

Teaching and blog writing forces you to be honest with yourself.  It's much easier to fake it if you never interact with others on an intellectual level.  Some of the most rewarding work I've done is with my co-founder, where we both were able to teach each other as we programmed [2]. 


Less direct (but no less important) are indirect methods.

Software engineering is about a lot more than just writing spiffy code.  Sure, you can "learn" about it by reading yet another book but there's nothing like getting actual experience.  There are tons of great communities that would love to have you on board (and you don't need to be an expert!).

Reading blogs expands your coding world view (and hey, you're reading one right now!).  Blogs (and their comment sections) can be excellent places to find new and innovative ideas, so long as you take them with a grain of salt.  It's easy to start reading blogs instead of moving up to the more important things on this list, which brings us to things famous developers do that don't really help at all:

One thing to remember when looking up to coding idols is that they are way smarter than you are.  It may seem cool, even edgy, that they argue about the languages they use.  Arrogantly arguing about languages and style won't make you Douglas Crockford, just Doug Crock-full-of-*ignored*.

Don't use libraries instead of languages.  This is a good shortcut for those rapidly putting together prototypes but will hinder your development as a developer.  It may seem like everyone's doing it but there is incredibly real value to learning the language, not the library.

Finally, don't claim that "Real X use Y" While I'm guilty of this myself (Heck, look at this entire post), there are exceptions to the rule.  Saying "real developers use Ruby" or "You'll never be a good developer until you learn lisp" only makes you look like an idiot.  You may be correct but it's better to not come off as a bigot.

BONUS: Write Read books.  You may not be up to the challenge of writing a book but reading one is much easier.  The "holy three" are Code Complete 2 (very close to the metal), The Pragmatic Programmer (Good advice for any coder) and The Clean Coder (How to write code that will work and be understood).

[0] C.S. Lewis said it best: "People have a habit of becoming who they are pretending to be."
[1] Amaan wants to remind you that he had the idea first.
[1.5] For the sake of your sanity, DON'T learn JavaScript by viewing the source of random webpages.
[2] I'm usually not in favor of pair programming except for teaching scenarios  as they allow both the student and the teacher to get the "meat" quicker.

Friday, January 18, 2013

Is your software too big to fail?

In my short career as a hacker, I've played with a lot of environments from Java with NetBeans and Swing, to Joomla running PHP and finally, Node + JavaScript.  All of the languages/frameworks I've worked in have their advantages and disadvantages (though I'd have to think harder about some to find advantages).  When it comes to application size, Node is unique.

This isn't about how many megabytes Node core is vs. PHP core.  Rather, let's investigate the average size of a supporting application.  Disclaimer: In each ecosystem, there are many different ways one could form a product.  I only have experience with a limited segment of them.  Read on at your own risk.

PHP and Java both have large, complex systems that try to do as much as possible.  Joomla in particular has a wide variety of functions and methods that'll "save you time."  (So long as you can understand their obtuse docs).  WordPress, ZendFramework, et. al. all try to provide the user with as much "stuff" as possible (and if they can't, the user can also get plugins etc for above).

Node doesn't.  Node has the philosophy of simple.  Each package in npm does one thing.  At first, this may bug you.  It seems inefficient to have such a decentralized system, ripe for error as some plugins don't connect with other packages and middleware.  Plus, you've got to learn how to work with all these systems.  There isn't a magical button to push to make everything work (yet).

Despite these downsides, I still think that Node has the advantage here if flexibility is your priority (and it should be).  If one were to build a website with Joomla, you'd be forced to either use their database object which still doesn't use prepared statements [0] or roll your own PDO system.  If you have to replicate work done by the system you're working in, there's something wrong with the system.

Node's decentralization prevents that sort of problem.  Even if I choose the most popular "framework" on node, Express, I still am free to choose other solutions (or roll my own) to my heart's content.  Even better, npm provides a one-stop-shop for organizing and updating all of the packages.  As you'll come to learn, decentralization doesn't mean we can't have standards.

Fortunately, the world of open source has virtually guaranteed that we won't be left adrift if the original authors leave the project.  This still doesn't mean that relying on a single software package for development is a good idea.  If something goes wrong or isn't available, you could be stuck high and dry.  Consider refactoring and reorganizing if you find you've been leaning on products too big to fail.  They probably will, at the worst moment.

This is all based on personal experience.  Want to hear more about it?  Ask me on Twitter, or in a comment below.

[0] They're fixing this in 3.0, but PDO's been around since 2005 for crying out loud!

Wednesday, January 16, 2013

CRUD with Mongo Helper

MongoDB is an excellent database solution that has it's quirks.  Node is a great server-side solution.  I'm using both in my latest project to revolutionize online education.  Unfortunately, the combination of the two can be verbose and prone to errors.  There are other solutions but those can be unnecessarily complex in their own way.

Let's say we wanted to add a new record to an existing collection.  Using the native mongodb driver, we'd need the following:

var mongo = require('mongodb')
  , server = new mongo.Server('localhost', mongo.Connection.DEFAULT_PORT, {auto_reconnect: true})
  , mdb = new mongo.Db('blog', server, {safe: true});

module.exports  = {
  insert = function(insertQuery) {
    mdb.open(function(err, db) {
      db.collection('recoding', function(err, collection) {
        collection.insert(insertQuery, function(err) {
          if(err) { /* handle errors */ }
          db.close();
      });
    });
  }
}
and that's only for a simple insert, without a callback.  Instead, I wrote up a simple CRUD app to help out, which reduces the above to the following (which is simple enough that one wouldn't need a whole function):

var mongoHelper = new (require('mongo-helper'))();
module.exports = {
  insert = function(insertQuery) {
    mongoHelper.insert('recoding', insertQuery);
  }
}
The one thing that's become more complicated is the declaration of mongoHelper.  Using the native driver allows for a much more flexible application with regard to settings.  I tried to keep it simple, while still allowing for customization.  The new method allows the user to pass settings to Mongo Helper, while letting defaults remain default.  For instance, if we wanted to use a different database:
var mongoHelper = new (require('mongo-helper')({dbName: 'users'});
Mongo Helper only supports the four basic CRUD operations for now. I plan on adding support for things like findOne and database storage of settings soon.

You can find the code/docs for Mongo Helper at my Github.  If you liked this, follow me on Twitter for more updates.

Monday, January 14, 2013

College? Heck yes

I'm back for another fun semester of college.  Now, I know that there's a wide variety of opinions on college in the hacker world.  I'm not surprised, given the average full-time programmer first started programming at 13.  If you've got 5 years of experience by the time you've got your high school degree, why spend lots of money to get yet another degree?

First and foremost, having a college degree will be good for your career.  You may not use what you learned in the process of acquiring that degree in the real world.  In fact, by the time the average CS major gets to their junior year, half of the stuff they learned in freshman year is obsolete.  Yikes.  For a very long time, virtually all professional jobs (Engineering, Business, etc) required the knowledge from college to work.  That's still somewhat true today (gravity hasn't changed significantly with regards to bridge building).  While you may be able to get by with independent experience in programming, many people will consider the lack of a bachelor's against you.  It may not make sense but that's the way the world is.  Think of it as hacking the hiring system.

That's not to say getting a degree will be pointless.  Four years of college can rack up a lot of debt.  One might be able to alleviate some or all of that financial burden by going to a community college instead.  However, you'll miss the most important reason to go to college.  MIT is incredibly costly at $57 thousand a year.  Ouch.  I understand that many of you probably can't afford that.  Loans, grants and scholarships will help.  Once you're there, you'll be surrounded by the type of people who go to MIT.  College is expensive because once you've arrived, you'll be with the type of people who are either smart enough to get scholarships or have rich (or financially savvy) parents.  Either way, these are the type of people you want to be around.

Secondly, if you're just about to graduate from high school, there's a good chance you really don't know how hard the real world is.  Let's be honest: If you're smart enough to be a competent programmer, high school academics were probably a joke.  College may be the first difficult thing you encounter.  Regardless of major, learning how to do difficult things you don't want to do just might be the most important thing you'll learn - ever.

You absolutely don't need to go to MIT (though I hear it's a very cool place).  Learning about more abstract things like data structures will be useful.  Try and shoot for the best college you can (remember more expensive !== best, do your research).

Reactions?  Comment!  I would love to hear what you've got to say on the topic.

Saturday, January 12, 2013

Thoughts of the future in the wake of death

Before today, I had no idea who Aaron Swartz was.  Until today, I sat content with the ideal of an amazing life ahead of me.  Something in that ideal has broken.

I'm a certified genius with an IQ of 135.  I've also been identified as "special" thanks to my brain also running ADD and borderline Aspergers.  Most of my life has been attempting to use the former to conquer the latter.  Only recently have I come to realize what needed to be done to capitalize on my strengths to overcome my weaknesses.

It's been a lot of work.  Like Aaron, I had to battle against the demons of depression[0].  I've had to find and break habits that have been there for my entire lifetime, and then beat them back when they resurface.  I'm gaining ground against my own shortcomings slowly but surely.

One of the things that motivated me to begin this massive path was Paul Graham.  I'm attempting to start a company with the goal of being funded by YCombinator.  Aaron co-founded reddit and was funded in YC's first batch.

I wish today didn't happen.  I wish that Jan 12th could have a redo.  I want to change the world.  I want to stand at the walls of bureaucracy and academia itself armed with technology and innovation and charge until they are walls no more.

I'm trying to fight for change in a world solidly against it.  It's a lot of work, and I haven't even started.  I'm often tempted to give it up and get a simple, well-paying job and take it easy.  I haven't.

Aaron Swartz's suicide has provoked a strong reaction from the hacker community.  Suicides usually cause an intense emotional reaction.  In part, I think that this particular response is due to the fact that Aaron was in a position that we could all see ourselves in (save the pending litigation): Child genius who grew up to be a successful startup owner who didn't sell out and kept true to his hacker roots.

His death, like all deaths, tells a story.  It's an incredibly sad one that does not bode well for our future.  I know I'm not the only one who is striving to build and accomplish something with my life.  Now, I look at Aaron's choice and once again consider that desk job where I don't rock the boat.

I want to arrive at success.  What will be waiting for me?

[0] If you're struggling against depression, tell someone.  I don't care who, so long as you know them in real life.  Writing also helps enormously.  If it gets serious, see a professional.