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.