Breaking News: Simple is important

Here's a link to a giant research paper.  Don't click it.

The researchers were studying how someone's altruism is effected by the effort involved.  They categorized the two types of effort into "active" and "passive" groups.  What they found was that people were much more likely to cheat when effort was required to not cheat, instead of the other way around.  Surprise.  Glad we've got empirical proof now.

The interesting thing was that they also tested how requiring active effort impacted someone's willingness to help others.  The researchers asked volunteers to assist a special needs student.  The trick was that half of those studied were given a simple "yes/no" decision and the other half had to click n times to reach that decision.  The first group was five times more likely to click yes (if the decision page was reached at all).

Any guesses as to what n is?  How big a number would be needed to eliminate 80% percent of potential signups?  It must be huge, 10, 20, perhaps even 50 clicks.

Nope.  This drastic change was caused by requiring only two clicks.  Yikes.  Now, all of the participants in the study knew what the "yes/no" box was for.  Real life is often much more complicated than a study.  While marketing-driven companies may want to push potential users to click on things to inflate (useless) metrics, real organizations need to inform the user.

I'm a programmer, first and foremost.  I'm also a guy who loves open technologies.  Often, there are many competing technologies that I need to choose from.  For example, there's a LOT of NoSQL database solutions out there.  I'd been pointed toward MongoDB and CouchDB.  Both are excellent solutions with a lot of users.  They're reasonably fast and work well with Node.js, my language/platform of choice.  Both of them even have websites!  However, Mongo has me one click away from an interactive tutorial.  Awesome.  I get to play with the look and feel of your product without installing or configuring anything.  CouchDB has plenty of information but it's (relatively) difficult to find the tutorial.  While I'd love to learn both, MongoDB has become the database end of my latest project and I've yet to install CouchDB.

I need to stop complaining about things I don't like on the internet.  Got a better topic idea?  Drop a comment and let's talk.

The 'find me' problem

The internet has a problem.  Ok, there's a lot of problems with the internet.  There's one in particular that's been bugging me lately.

There's four zillion sites out there with information on programming (however you define that word).  Some are pay, some ad-supported, others are wikified and expect "the community" (whoever that is) to do all the writing legwork for them.  Virtually all of them have the same issue: They only do one thing.

Doing One Thing is very important in some instances.  The company I used to work for missed out on many opportunities because they tried to do too much.  Tutorials, on the other hand, *should* do as much as possible (as long as it's within their problem domain). Many tutorials list a basic use case and how to solve it but never look at how one may do it in production.  Others only push a certain framework or technique without looking into alternatives.

Isn't this missing the entire point of tutorials?  Readers are here to learn.  A well-written tutorial should teach something.  More often than not, there's a bit of code to copy/paste to solve whatever problem you've got (badly).  Jeff Atwood characterizes this problem as the bathroom wall of code.

I call this "find me" problem.  Best practices and further information are out there but are buried beneath mounds of tutorials written for hits.  If we're to find out how to work our craft right, then we'll need to go beyond Google and find some *gasp* real people.

Much as I complain about the problems of StackOverflow, they've provided the framework that has grown into an excellent community in the chat rooms.  If your language of choice has an active room, you should start hanging around.  You never know what you might find.  I know a lot of my development as a programmer has been due to my experience there.  (Make sure you know how to ask questions first).

You might also find programmers willing to provide advice on an IRC channel specific to your domain.  I can't offer advice here but here's where a quick search will actually help.

Another place to discover best practices are books.  Take this advice with a grain of salt, as some books are obsolete before they're even published.  Others, like The Pragmatic Programmer or Code Complete 2 go beyond language-centric "Tips 'n Tricks" to universal concepts that will make you a better coder.

Finally, there *are* good programming blogs out there.  It's very easy to get overloaded trying to read all the blogs out there.  Find some good ones (I recommend Coding Horror and Steve Yegge's Blog Rants to start) and read through the archives, picking whatever strikes your fancy.

Finally, don't be afraid to post bad code and ask for help.  (So long as you're prepared for a lot of constructive criticism.)

IT vs. Software

To the surprise of everyone, I used to be an IT guy.  I went through an Infotech program in high school and did quite well, setting the state record for technical certifications on graduation.  I also worked two internships in IT and met a lot of great people along the way.  While it was fun, I've moved on to programming and never looked back.

That's not to say I don't like IT.  I enjoyed it a lot.  However, there are some subtle differences that lead me to become a programmer.  IT is mainly building and maintaining systems made out of solutions created by someone else [0].  Building such systems was an incredible experience, but didn't satisfy my urge to create [1].

To people outside the industry, the two seem identical.  We both work with computers, building solutions and then fixing them.  We both hate deadlines.  Our relatives make us fix their computers over Christmas.  In short, both camps are computer geeks.  Not only that, each camp could benefit from knowing a bit of the other's domain.  Scripting can help a lot with server management and installs.  Knowing how to setup and run a server can save a developer a lot of time.  The two are locked in a symbiotic relationship - a company of either will eventually require the other.

So both domains are full of geeks, involve computers and actually contain quite a bit of crossover.  So what's the problem?  Let me greatly simplify the issue with an analogy: Imagine a simple project is like running a lemonade stand.  Management decides that the stand should also sell cider.  In IT, you'll need to procure a cider vendor and market the cider.  Not a trivial task but still simple compared to programming, which will need to develop orchards, harvesting, cider presses, bottling, and transportation between all of the steps.

The reason for this is simple: very few programming projects are the same.  The differences seem simple but can be deadly for those attempting to "cross the pond."  Treating programming projects like they're IT can cause developer frustration with constant "minor" changes leading to many missed deadlines.  Ignoring IT's extended flexibility for fears of "scope creep" can lead to customers annoyed with sub-optimal projects.

In my time working for an MSP that quite accidentally developed a software division, I experienced one side of this unfortunate misunderstanding.  Fortunately, there's a good fix.  IT and programming can work together, and well.  The important thing to do is make sure that there's a separation of managers.  As always, it's important to make sure those in charge understand the intricacies of the work being done.

[0] The same argument could be made for some programmers, with all the plugins, libraries and frameworks running around...
[1] It's also much more difficult to start and run an IT business.

"Playing" Programmer

A lot of us enjoy playing around with different languages, frameworks, etc.  This post isn't about you.  Others see any kind of coding as "play" because they enjoy it so much.  This post isn't about you either.  This post is about those who "play" programmer like small children "play" house.  They simply go through the motions, imitating what little they've seen of the real programming world.

There's no shame in playing at programming.  Essentially, it means you're a beginner.  The problem arises when you refuse to admit it.  If that's you, consider this article a wake-up call.  If you're worried it might be you, let me tell you a tale of two programmers:

It was the best of jobs, it was the worst of jobs.  There was a lot a freedom and flexibility at the cost of little-to-no structure in projects or planning.  "The boss" could drop a reverse eagle at any time.  Introduced into this ecosystem were two programmers.

The first one was me.  I, a starry-eyed CS student halfway through my college career, knew little about how the "real world" worked.  I started as an intern and did my darnedest to learn as much as I could during the span of my internship.  As I grew and learned, I discovered a lot.  The biggest discovery was that no one else at the company knew what they were doing[0].  Figuring the worst-case scenario would be that I would lose my internship position (hardly an issue), I wrote up a plan to integrate such basics as unit testing, source control, and code reviews into day-to-day life.

Now, I didn't know much more than "these things are needed."  I wrote a convincing argument and the administrative team agreed that they should be slowly integrated.  We started the long, slow process.  (I hadn't learned about Agile yet).

Then a new programmer arrived.  Let's call him Bonzo.  He was a likable person but had several flaws in his programming character.  I hope it's enough to say that he vehemently defended his exclusive use of Internet Explorer, saying "if it works in IE, it should work in other browsers."  Over time, he claimed that unit testing only wasted time and that it'd be much more efficient if we spent a dozen man-hours a month maintaining our own git server instead of GitHub.

What separated us?  We both were midway toward getting a programming-related degree.  We were hired to do about the same job.  However, I was constantly seeking to learn and improve, while he maintained the status quo.

If you're like Bonzo, it's time to make a change.  Doing things because they "make you a programmer" won't work.  Heck, even programming won't make you a good programmer unless you seek to improve.  If you're in a programming rut, good news: You can improve.  Start learning some of the tools of your trade.  The best place to begin is the Joel test.  Go through the list.  If you don't have experience with something (build systems,  bug tracking) get some (even if it's on a personal project).  Make sure to connect with other programmers (preferably outside your workplace) and learn from them.  Even Eric Schmidt has a mentor.  Find an open source project to contribute to.  Learn a new language (or a new use of an old one).  Finally, move into more advanced tricks of the trade, such as unit testing.

The only shame in being a beginner is stubbornly staying one.  There's no excuse.  Go be awesome.

[0] With regards to programming.  It was an IT company that had developed a small software division, and they still treated software projects like they were IT.

Knuth's Mastermind Plan

If you've never played the classic Mastermind board game, take a quick look through the rules before continuing.  This post will make a lot more sense.

Programming's Mafia boss "Don" Knuth devised a way for all of us geeks to never get invited to parties again win at Mastermind in five moves or less.  The premise is basic: Keep track of the moves that remain.  When you've only got one left, you win!  A trained monkey could do it.

Naturally, this simple solution isn't the one that Knuth came up with.  Simply taking the first possible answer as the next guess results in a worst case of 7 moves, vs. Knuth's 5 [0].  What Knuth has done is run through all of the possible states and find the optimal guess at each state.  Sometimes, like the example on page three, the optimal guess isn't actually one of the remaining possible guesses.

Pages four and five contain his entire table, using his propitiatory notation.  While this works great, it's a bit difficult to point a program at a PDF and say "go."  Instead, I've created a JSON version that works just as well with a few adjustments to the code.

At this point, I've got a cute little implementation that solves the generic Mastermind board and will bore everyone to tears explaining it at the next party I attend.  Inevitably, some smart aleck will say "Well, what if there are seven colors?  Where is your Knuth now?"

I have three options at this point:

1. Hide under the nearest bed
2. Punch them in the face
3. Write up an even better algorithm and blog about it.  That'll show 'em.

The core of Knuth's algorithm is the idea of min/maxing possible results.  Programming Praxis has a much better explanation of this, but if you're afraid of clicking links, each possible guess is investigated, along with the potential remaining possibilities with each response.  Whatever guess results in the lowest number of possible remaining guesses at the high point is chosen for the next guess.  Sweet.  We totally showed that jerk.

"Fine" says the critic "You know what it is.  But can you do it?"

My attention is rapidly waning at this point but the challenge has been made.  I slam out some lines of code but am not Knuth.  Still, I sit satisfied that I've done something.

Think you can do better?  Fork me.  Got a comment?  Comment.  Want more of this?  Twitter.

[0] You can prove this by visiting my github page and running `testRig.runKnuthTest()` and `testRig.runBruteTest()` in the console.  You can disprove it by finding bugs in my code.

Learning from mistakes

Jeff Atwood says that every programmer should learn at least the basics of marketing.  We can do brilliant things but if we can't (or won't) convince anyone to look at them, the net result is zero.  He provides three points to what marketing is:

1. people understand what you're doing
2. people become interested in what you're doing
3. people get excited about what you're doing

In a way, this blog is a way for me to practice these three items.  Sadly, my last post failed at the very first step - it was clear from the comments that people didn't understand my purpose behind writing.  I tried to spell it out in the end but it was too late.  My ADD-esqe post had gone off the rabbit trail one too many times.

The post was not about how GRUB and Win7 don't get along well.  The post was supposed to be about flexibility and interacting with customers.  Where did I go wrong?

I'm a storyteller by nature, and find that I can get too wrapped up in the details of a story and miss the main point.  One of the things I've been trying to do with this blog is practice my summarizing skills.  The trick is not to eliminate 90% of the details and call it a day.  Instead, eliminate all of the details that are irrelevant to the story at hand.  As Albert Einstein says:

Make everything as simple as possible, but not simpler. 

Instead of launching right into my Windows tragedy, I should have listened to all the writing teachers who told me to start with a thesis sentence.  There's a parallel in the startup world: elevator pitches.  I hate these.  I love working through all the intricacies of my ideas in a Q&A lasting half an hour.  I don't want to talk for 3 minutes and leave.  My idea is excellent!  I can't sum up all of it in three minutes!

Sadly, I don't have all the time in the world to convince investors to give me money.  Not only do I have to accomplish the three things above, but I need to do it in a short period of time.  I know what I'll be practicing.

Still think I'm a terrible blogger?  Let me know in the comments or on Twitter.

Planetside 2 is a great product in the way Windows 7 isn't

Woohoo!  The semester's over!  I'm feeling a lot more like myself now that all the stress has drained away.  Well, not all of it.  Some friends and I wanted to celebrate the end of a difficult semester by blowing some bytes to bits in the newly-released Planetside 2.  There's a lot of features in PS2 that I like (MMOFPS with RPG elements, large strategy elements, tanks).  There's one feature that almost killed it for me:

It only runs under Windows.

I'm a Linux guy [0], so I understand that we're not the target market for game companies (excluding Valve.  I love you guys).  I'm not being a snobby elitist by disparaging Windows for it's closed source mantra [1].  There's only one problem: Windows doesn't play well with other operating systems.

I grabbed Win7 through Dreamspark and spent the next two days installing, repairing, reinstalling and watching a wide variety of progress bars cross my screen.  After all of this, I only managed to "dual boot" by unplugging the hard drive I didn't want to boot to.  Yikes.

Obviously, Microsoft won't listen to the complaints of a college-aged blogger.  You, my awesome reader, do.  If you want to beat Microsoft, ensure your product is:

• Flexible.  One of the reasons the open source movement is gaining so much ground is that we accommodate a large variety of people.  Microsoft could do themselves a favor and make it easy to install their OS
• An Efficient user of time.  Win 7 decided that the perfect time to install all 112 updates was right before I packed up my computer.  We ended up leaving 30min later thanks to this.  All it would have taken was a "cancel" button after the fact.

On the other hand, Planetside 2 is awesome.  They released early and it shows.  There are quite a few bugs and balance issues.  On the other hand, here's a quote from CEO John Smedley:

Players are paying the bills, so as far as I’m concerned that puts them in the driver’s seat.

He's backing up his claim, spending "a decent amount of time on Twitter" interacting with fans and looking to improve his game.  The dev team has put an incredible amount of thought into making PS2 a game full of variety and teamwork.  They're brilliant people slowly but surely assembling an incredible game.

If you forget everything else from this post, remember this: Personal interaction with your customers trumps everything else.


[0] Currently running Mint 13 with Cinnamon.
[1] If you're looking for snobby elitism, try Ask Ubuntu.

Why I've stopped posting on StackOverflow

StackOverflow has a problem.  They've already dealt with (and conquered, more or less) a lot of the problems that an online community encounters (see Meta is Murder for a great example).  The Summer of Love was met with questionable success.  However, there's another problem that's been cropping up for me.

I've stopped answering questions on StackOverflow [0].  Asking questions helps me get more specific information, but answering questions often helped me to learn even more.  There are some questions that I've really enjoyed working through to find the best answer for the asker.

But I've stopped.  It's no longer worth digging through the never-ending piles of poor "Give me teh codez" style questions where no effort to find an answer is shown.  I learn less and less each time I hit Stack's front page.  Answering has lost the intrinsic value it used to have.

"Wait!" Stack cries.  "You can also earn reputation points and these nifty badges!"  The problem is neither of these work as a long-term motivation.  The leaps between new reputation benefits get too big after 3,000.  My ability to gain reputation has also increased but hasn't kept pace.  As of now, I'll need to gain 5.5k rep to get another neat privilege.  Badges are also nice but don't mean much after the first gold [1].

The reason behind this is that StackOverflow makes it too easy to ask bad questions.  They also have a lot of tools to deal with bad questions but it's no fun closing question after question when I don't learn anything or gain rep from it.  I think the fact that PHP has created an entire system to shut down bad questions speaks to the severity of this plague.

I'm not suggesting that we limit question-asking ability to those who are special in some way.  Meta is littered with ways to "improve" the state of this problem.  Here's my take:

• StackOverflow already has an algorithm that determines "quality" of questions and answers.  Give me the option of only seeing questions above a certain threshold.  I don't mind seeing fewer questions if they're the ones that make me think.
• Make it more difficult for users to ask questions.  Right now, the barrier to entry is very low.  One idea would be to make users take a quiz before asking their first question.

Perhaps I'm too cynical from my time in the PHP tag.  Maybe I should take a break and start answering questions after Christmas.  What do you think?  Let me know in the comments!

[0] I haven't completely stopped.  I'm not answering at anywhere near the rate I was before.
[1] My opinion.  Comment if you've got a different one.

Why I'm disregarding Paul Graham's advice

I'm a huge fan of Paul Graham.  As you can see in my already-outdated About Me post, he's inspired me to challenge myself to much greater things.  I've been reading through his essays and just finished A Student's Guide to Startups.  This essay is a slight change from his usual strategy of giving world-class advice.  Instead, he starts with the postulation that those in college shouldn't start a company (which contradicts some of his older essays) and spends the rest of the essay half doling out world-class advice and half telling us college students that we don't have enough "experience" to make it as startup founders.

To be honest, he makes some good points.  Yes, startups usually fail.  Yes,  every little bit counts.  The two main given reasons for college students to finish before they start a company is that they don't have the extra push their peers give them and they don't have the desire to get away from the real world.  Peer pressure can be an incredible motivator (sometimes more than we'd like to admit).  Graham simplifies this too far.  He also misses the point on "real world" experience.  Many college students go through internships.  I know I did.  I'm very much in favor of leaving the rat race [1].

The finer points aren't what bug me.  They're pretty solid, all told.  What really bothers me about this essay is that Paul Graham himself is encouraging people not to start something.  Starting something, anything at all, is better than sitting around and discussing it.  In an older essay (that I can't find at the moment), he says that the best experience anyone can get if they want to create a startup is to start a startup.  If it's in the 90% of startups that fail, you've gained a great deal of knowledge that can be applied at a consulting gig, another startup, or hey, an actual job.

Paul, your essays are both informative and inspiring.  I try to take each one to heart as I move forward with plans to get the ball rolling with my own startup.  However, I'll be ignoring this bit of advice.  You may be right, but that won't stop me.

[1] I reserve the right to read this paragraph a year after I graduate and slap myself silly for my naïveté.

Getting more hours in the day

Thanks to the participation of a whole zero comments, I'm now forced to reveal my secrets for success without spoiling anyone else's.  Blast.  There goes my evil plan.  I'll get you, Bond!

On a more serious note, the three things that have really helped me increase the number of productive hours are exercise, exercise, and exercise.  I'm a huge fan of practice and going through projects to improve oneself.  Really, the only way to improve in something is to do it.  Secondly, self improvement in some areas will pay off wherever you want to go.

The best thing you can do on a regular basis is physical exercise.  Even a quick 20 minute walk can help repair and renew your brain.  It also gives you energy and helps you focus.  Regular exercise improves your blood flow, helping you regulate temperature better (something very important to those of us freezing in the northeast).  Finally, it also helps you sleep, reducing tossing and turning at night.

The best thing you can do to improve your skill as a programmer is to exercise your most valuable asset: Your brain.  Many find that logic puzzles and the like help your brain "work out."  I haven't had much success with these techniques, as I have a short attention span (thanks, Internet!).  If you're one for logic, check out What is the Name of this Book?  Otherwise, try out Code Katas.  I've suggested some projects for learning a new language.  Another test would be to improve on the classic FizzBuzz (it's possible).  Working on puzzles like these helps sharpen your skills so when you hit that productive zone, you won't need to stop to research.

Finally, exercise spiritually.  I don't mean that everyone needs to go to a place of worship, but rather to pursue peace.  Many have found that 5 minutes of meditation helps them.  In college, I like to take "mental health days" where I don't do any work (things I don't want to do, I inevitably end up getting some coding done).  It's also possible to combine this with mental exercise and discuss abstract things such as morality and philosophy.

There are not 24 hours in a day

As you probably didn't* see in my last post, I'm closing in on finals week.  I'm a natural procrastinator, so this is a difficult time, especially when my hardest class is deathly boring.

It always seems that the biggest lesson I learn at these times has nothing to do with the classes I'm taking.  Last semester, I finally found my breaking point.  Over the summer, I figured out why I hit that point and how to avoid it.

This has been a rough semester.  I've had a lot more work than I bargained for, I spent far too much time in the hospital for an avoidable injury, and we had to put my childhood pet to sleep after almost 13 years of wonderful life.  Combine this with a few terrible nights of sleep, and you get the lesson I'm slowly learning as this semester draws to a close: There are not 24 hours in a day.

Perhaps a better way to say this is "You don't get an average amount of work done every day."  Productivity is annoying.  It's insanely variable.  One day could be incredibly productive, others, not so much.  I could accomplish more on Wednesday afternoon than over the course of an entire weekend.  I've spent too much time trying to figure out what happens on Wednesday instead of working to create the lifestyle that results in more Wednesdays.

I've found that productivity blogs etc. tend to focus on what you could be doing RIGHT NOW to improve how you're working.  Unfortunately, the long term matters even more than any quick fix.  Habit number 7 in The 7 Habits of Highly Effective people is "Sharpen the Saw."  We can dramatically increase the number of productive hours through routine activities that keep us sharp.

Come back Friday for some sharpening activities that have really paid off for me.  In the meantime, what do you do that helps create fertile ground for productivity?

*That was my worst post hit-wise in a long time.  Sorry, folks.

"Like"ing your job

(I managed to do some damage to my eye Friday and subsequently spent too much time in the hospital. Here's a post that didn't make the cut earlier.  tl;dr: "Wouldn't it be cool if we could abuse hormones to make people enjoy work?")

I used to wish I could read people's minds.  Then I signed up for Facebook.

Facebook and other social media can be a huge problem for a business that isn't tech-savvy.  As a Facebook consumer who dislikes ads, I'm frustrated that even the powerful AdblockerPlus misses "sponsored stories" that are just a new way of putting ads in front of my face (you can disable them here).

I think that these businesses (who are paying $200 a pop to put this ad in my face) are missing a key factor of what the web 2.0 world has brought us.  "Likes" are not just another way to get consumers to advertise for you.  They're one of the reasons people consume so much time on these networks.

A brief psychology lesson for those of you who slept through Psychology 101 (like my roommate): dopamine is a brain chemical that makes you happy.  It's released during pleasurable activities such as sex and cocaine (and more benign activities such as eating a particularly good pizza).  In fact, the simple act of getting a "like" on one of your actions can release dopamine.

So this rush keeps people coming back to Facebook.  How can we use it to raise employee retention?  A simple note or side comment from the boss can work wonders.  Is it possible to incorporate this into a scalable system?

The most important part of like-ifying your job is to be subtle.  It's far too easy to create an external rewards system that destroys the intrinsic value of your job.  There shouldn't be a like leaderboard or any rewards tied to likes.  Too often, managers see gamification as an easy way to increase productivity without much effort and end up with a system that does exactly the opposite.  (Another great example has developers ranked by how many lines of code they've written, with more === better.  I'm sure we all know how how well that worked out.)

The simple suggestion would be to add a "like" button to whatever source control/bug tracking system you use.  I'm not aware of any systems that currently do this.  It'd be a nice first step but would take time to implement.  Perhaps GitHub could work out something like this.

Startups for our Parents

(With apologies to mom and dad)

Us young geeks don't understand a life without technology.  Thing is, virtually all of our life online has a non-web counterpart.  Email?  Actual mail.  Ebay?  Auction halls.  Social media?  Phones, dance halls, and intricate musical numbers (at least that's what West Side Story tells me).  The millennials grew up with the virtual side of things.  It's the natural way we live and communicate.  It's also fairly difficult for the average millennial to conceptualize a life without the internet.  Not so for other generations.

Can I fantasize for a moment?  How many people do you know would agree with the following:
"We have to find someone from a different generation to show us how to use [technology]"

Learning technology requires a time investment.  Have you ever tried to learn a new language or framework through a bad tutorial?  How many things have you never done because learning them took too long?

With that in mind, I propose a new website: oldpeopletutorials.com

Ok, so that's not the most flattering title.  Perhaps we should go with BabyBoomerTutorials.com or something like that.  We could direct our parents toward it anytime they need to ask about technology.  It'd have pleasant videos narrated by Paul McCartney detailing the basics of Facebook, Google, and Twitter.  They'd also have an ease-in forum where they could adjust to textual communication, with how-to's on emoticons and proper use of abbreviations.  We youngsters could also develop API's that would parse email from our parents and reply with a link to the correct tutorial.

Aside from this pipe dream, how could we make online life easier for older generations?

My parents are of the Baby Boomer generation.  They've grown up and lived with a disconnected world, are used to offline interaction and have become very good at it.  In short, they're digital immigrants.  Rather than looking at the fascinating new uses of technology, they see what they already have and say "so?"  New technology needs to convince them that it's better (read: simpler) than what they use now.

If we want to reach people who fit the description above, we need a new way of marketing.  Instead of "this is cool," say "this is the new way of doing [offline activity X] (and here's why it's better)."  We laugh at startup ideas that say "It's Facebook for pets!"  In reality, this may be the way to market startups to immigrants: "It's like mail but electronic!".

Focus on introduction.  There's a huge wall we need to scale in convincing non-natives to use our product.  Make it as easy as possible to actually use the part of your product that replaces what's currently being used.  Focus on the specifics of why it's better.  Remember, "better" doesn't mean "more features" in this case.  Make sure to run usability tests with your target audience.

Reaching technology immigrants may feel like it's pulling oil from tar sands instead of the usual wells.  There's a whole untapped market out there.  Good luck!

The Universal Language

What if you could use the same language anywhere you go?  Server/clientside, desktop, mobile, game dev, physics simulators, EBook readers, etc.  This sounds like a pipe dream, and it is in a way.  If it was possible, what would we want the language to look like?  It would have to be:

• Fast
• Open and Extensible
• Simple, yet powerful
• Easy to debug  (If it's appropriate to yell "HEEEEY MACARENA" at the end of your message, it might be too complicated).
• Language nesting (You can write the language in the language)
• Well-documented

(An argument could be made for rapid prototyping, but this usually relies more on libraries than the language).

Slightly off-topic, my roommates had a brilliant idea: "Why don't we make a video game?"  After an excited afternoon of guffaws they had several pages of scribbles.  Then, to my surprise, they actually started work using the Unity game engine.  One of the language options for writing code is UnityScript.  While it's not pure JavaScript, it's pretty close.  Most JavaScript developers should feel comfortable in the UnityScript environment.

It's about this time that I first started experimenting with Node.  Node is a powerful server-side platform using (you guessed it) JavaScript.  It's ridiculously fast, posting times comparable to compiled languages (this is all thanks to Google's open V8 engine).

Astute readers will see where I'm going with this.  Can JavaScript become the universal language?  It's certainly fast (or certain implementations are).  The ECMA standard is open.  JavaScript's flexible enough to be used in all of the above examples.  It's also easy to create powerful libraries for JavaScript to use.  The documentation and errors could use some help.  Overall, JavaScript seems like our universal language.

However, this ignores all of the other languages out there.  C/C++ is fast.  Java's "cross-platform."  Python is extensible.  Why is JavaScript so special?

Javascript is unique in that it is the de facto language for client-side scripting.  Thus, anyone with a web browser (i.e. everyone reading this right now) has access to a JavaScript environment.  Secondly, it means that anyone involved in web development (a large segment of developers) should have a working knowledge of JavaScript.  This means it's much easier for a PHP guy to move to Node.js than Ruby.

JavaScript isn't perfect (seriously, who thought it was a good idea to have "with"?).  I'm also not suggesting that we should use one language for everything.  However, if there's a universal language, it's JavaScript.  Learning and improving your JavaScript skills will be a net gain for your career.

Are books worth saving?

I love books.  My family didn't have television where I grew up.  Instead, I had shelves and shelves of books.  Yes, I was (still am) quite the nerd.

Having been a book aficionado for many years, I was sad to come across a recent Hacker News post about a bookstore in decline.  Are print books so far gone that even the hackers, the constant innovators, can't save them?

It seems that blogs are taking over as the authors go-to method for disseminating information.  Jeff Atwood doesn't even want you to buy his book.  There are quite a few reasons for blogging:
-Blogs are easy to set up.  It took me all of 15 minutes to set up Recoding (and most of that was picking a name).
-Blogs are free
-You don't have to convince anyone that you're writing's "good enough" to blog
-If some technology changes, you only need to edit your blog to be up-to-date

So blogs are way cooler than books.  Heck, Jeff Atwood wrote a whole book and then told everyone not to buy it.  Problem is, this incredibly low barrier to entry has resulted in an incredibly low signal-to-noise ratio.  The lack of quality control has had many detrimental effects, including the viral spreading of poor coding techniques.  Recently, a post recommending the use of jQuery made the front page of Hacker News*.

Alright, blogs aren't the savior of independent journalism that we want them to be.  Despite these flaws, blogs are still fairly popular and some of them are quite a pleasure to read.  Is there anything about books that is actually worth saving?

Print books have several large advantages over digital media:
-Books contain a large amount of information centrally.  Blogs typically contain information in "nugget" form.
-The bar is much higher.  While bad information can be published in book form (just look at any political book this season), the signal-to-noise ratio is much better than the internet.
-There are other miscellaneous reasons:Books don't need a battery, you can use bookmarks, they can help you feel disconnected, they're DRM-free, some like the smell of books.

I'm usually in favor of new technology when it replaces the old.  Some may pine for the romantic days where everyone went around with a horse and buggy but I enjoy traveling in my climate-controlled box at 65 mph.  However, the nuggets of data presented to us by the internet simply can't replace classic tomes like Code Complete 2.

So books are worth saving.  How?
Ebooks are one promising arena.  While they run on batteries, the basic Kindle's life is absurdly long.  Unfortunately, ebooks are still restricted in most areas by draconian DRM.  Why can't I share my ebook like my paper one?
Speaking of Amazon, they're still doing well.  Brick-and-mortar bookstores might have problems, but books are still being distributed online.
Both of these are nice but aren't the real issue.  Book distribution needs to be easier.  Create a simple, centralized system for book distribution, with some sort of basic quality control (avoiding stuff like bad code or Twilight).

Any other ideas for saving the humble book?  Think I'm off my rocker for wanting to save them at all?  Leave a comment!


*Yes, jQuery has it's uses.  There's a lot more questionable recommendations in the post I linked to (such as the use of CoffeeScript).

Source Saturday: I'm an idiot

One of the best things about Node.js is that it's single threaded, using a callback model to manage asynchronous processing.  One of the most annoying things about Node is that it uses a callback model...you get the picture.  Callbacks can be immensely powerful but are trickier to write and understand than the traditional blocking methods.  Case in point: I managed to screw up callbacks while simultaneously forgetting one of the nicer features of databases.

I had an array of ids and wanted to get the various items from the database that were associated with those ids.  (Yes, yes, I know about the $in command.  I don't know what I was thinking either.)

for(var id in ids) {
    //Convert text id to BSON id
    var BSON = mongo.BSONPure;
    var b_id = BSON.ObjectID(ids[id]);
    collection.findOne({_id: b_id}, function(err, document) {
        if(err) { console.error(err); db.close(); return;}
        returnObject[id] = document;
        if(id == ids.length - 1) {
           res.render('checkout', {classes: returnObject});
           db.close();
        }
    });
}

This code set the land speed record for fastest turnaround from written code to "What on earth were you thinking, past Randall?"  (2 days).  While most of you probably have figured out what's wrong, let's look into the details.  In a purely synchronous language, this makes sense.  Loop through the array, find the entry associated with the id at that point in the array and add it to a return object.  When we've reached the last point in the array, render our page with the generated object and close our database connection.

Here's what really happens:
for loop executes, adding collection.findOne callbacks to the node callback "todo" pile.  After the loop finishes, `id` is the last `id` in the array.
Sometime after the for loop finishes, the callbacks are executed, all with the last id.  Since the last id will trigger the render and database close, only one callback is run.  The rest encounter a closed database.

Fortunately, this had an incredibly simple answer: Use mongodb's $in function.  I still had to loop through and convert to BSON ObjectIDs.  This resulted in much simpler code that used callbacks the right way.

for(var i=0;i<ids.length;i++) {
    var b_id = BSON.ObjectID(ids[i]);
    b_ids.push(b_id);
}
collection.find({_id: {$in: b_ids}}).toArray(function(err, results) {
    if(err) { console.error(err); db.close(); return;}
    res.render('checkout', {classes: results});
    db.close();
});

Now, there's only one callback, and it'll contain exactly the data we want it to.  Any number of ids can and will be handled correctly.

A whole blog post, because I forgot one ruttin' command...

Preventing the Demo of Doom

I learned quite a few lessons from my disastrous demo on Monday.  Reflecting, I'm glad that it was so bad.  In the grand scheme of things, there was very little at stake and my teacher was very forgiving (unlike a VC). I'd much rather have a colossal failure at this level than in the future.  Problem is, not everyone can demo at this class level.  I mentioned testing your demo like you would your app.  While we can't write unit tests for reality (man, wouldn't that be nice?), we can run through the demo under certain situations to find faults.

Test 0: Create a failsafe presentation
One of the comments from yesterday brought up a great idea that would have helped enormously:

Lesson 7: If you operate a computer in front of an audience on a screen, you instantly become an idiot.

Steven goes on to suggest that a video of the demo running makes for a much better presentation than actually running through the demo.  This allows you to focus on the sales pitch without worrying about technical glitches (at least with your software)>

Test 1: Practice ideal conditions
I practiced my sales pitch a lot, to many different people, so I had it down.  I understood what questions and objections may be raised and how to respond.  What I didn't do was practice the pitch in front of my product demo.  I threw myself for a loop several times because I hadn't practiced moving from the theoretical to the practical and back.

Test 2: What could fail (generally)?
Many things went wrong during my demo.  I could have made it go a lot smoother had I looked at what could fail and how to insure against that eventuality.  While I would have preferred to have my PC there for speed, I should have had at least one other option to access my product.  It could have been on my laptop (Fairly easy to set up with Dropbox) or in the cloud (I had wireless internet but no wired for my PC, so I could have loaded a cloud version on my laptop).

Some general failure states you should look out for (roughly from most to least likely): Slow/no internet (have a local copy), projector failure (don't depend totally on slides),  code failure (have an alternative way to sell/demo), machine failure.  Practice your demo under each of these conditions until you're confident.  It doesn't have to be as good as the original.  All you need is effective communication of your message.  People are surprisingly forgiving if you show you're prepared for failure.

Test 3: Product/presentation flaws
Your product is world-changing, sure, but it has flaws.  What are they?  Unit testing can help reveal some of them.  Others can only be found by putting someone who didn't work on it in control of the demo.  What assumptions have you made about your product and the audience?  For instance, I assumed that people would understand how to use a simple search box.  Most people stared blankly at it until I prompted them even after the elevator pitch describing it as a search product.

Usability testing can also reveal fundamental assumptions about your code, as well.  Running a friend of mine through the demo uncovered a major mistake I'd made with callbacks.  10 minutes of panicked programming later, the bug was fixed and I'd learned an important lesson.

How I hit the front page of Hacker News (and so can you)

This morning, I submitted my latest article to Hacker News, as usual.  Usually, I get 50-100 hits from HN if it's a good post.  Instead of slowly dying in "new" like the rest, this one immediately received enough upvotes to put it at #14 on the front page.  When I came back, I found that the total hits to my blog had doubled in an hour.

Yikes.  When I first started this blog, I had a goal of getting 13+ hits a day.  I never thought that I'd get hundreds  much less thousands of hits after only two months.  I'm just some dumb college student (how dumb?  Find out Saturday!).

Here's the trick: I just did it.  I didn't spend lots of time planning.  I didn't waste time reading books about how to blog.  I set a schedule and kept myself to it.  Admittedly, that resulted in some pretty poor articles.  You can insert your favorite motivational quote here.

So here's my profound tip to everyone who wants to make an impact (and if you don't, why not?): Keep pushing yourself.  Keep working hard at improving yourself, and eventually you'll find you've arrived.

There's a few blogs that have helped me reach this far, and I'd like to give them some love:
Permission to Suck: It's ok to be bad at something, so long as you don't let it stop you.
Always be shipping: Keep producing "stuff."  It's the best way to learn and improve.
Overnight Success: It Takes Years: Success takes hard work.  Don't expect to be an instant success unless you've put in the effort.

I'm incredibly happy with how well this blog is done.  My goal is still the same: 13+ hits a day.  I have some new ones (encourage commenting, get more followers on Twitter).  The central point is still the same: Learn by doing.

How Not to Demo

I had my first demo Monday night at our school's Inventor's Symposium.  While it wasn't a big pitch to VC's, it was fairly significant demo in that:

• It was my first ever
• Most of the people there were my target market
• It was a large portion of my final grade

Everything went wrong.  My computer broke, the server wouldn't work, and I didn't have an internet connection.  While some of these were avoidable, others were my own dumb fault.  Before I go listing off all the terrible, horrible things I did wrong, let me brag about the one thing I did right.

I had a stack of papers that contained details about my product.  That's it.  While I didn't have a live demo, I was still able to go over my product and explain it's purpose, etc.  While I wasn't able to make any "sales" per se, it still was a confidence boost and prevented the evening from being a complete flop.

Lesson 0: Have an Apocalypse plan.  If everything goes boink, how will you demonstrate/sell?  Can you convince someone of the usefulness of your product without your product?

Astute readers will recall that I was looking for a cloud-based solution to host my project.  That never ended up happening (I was lazy, and didn't want to bother migrating databases).  Instead, I decided to cart my PC down to the hall where I'd be demoing.  When I got everything set up, it hung halfway through boot.  After some trial and a lot of error, I got a new error in BIOS.  Then it wouldn't start at all.

Lesson 1: Remain calm as everything explodes.  Worry about broken things later and focus on selling what's working right now (even if it's just a piece of paper).

I also tried to fix the problem during the symposium.  I found out quickly that people wouldn't come over to my table if I was elbow-deep into a computer's guts.

Lesson 2: Have two people to demo.  When something like this goes wrong, one person can perform emergency surgery while the other mans the booth.

When I finally got my computer running by some miracle, I realized that I didn't have an internet connection (duh).  This wouldn't have been a problem, except for the fact that I was loading one of my JS libraries from the internet, instead of local.

Lesson 3: Test your demo like you would an application.  Make sure it's as local as possible (even if there is internet, it'll be faster if the code's local).

When I finally got everything in a remotely workable state, there was only 10 minutes of show time left.  I quickly learned another important lesson as I watched people stare blankly at the app in front of them.

Lesson 4/5: Walk your users through the application.  Additionally, make sure the best part of your demo is the one they see first.  They probably won't have the attention span to see more.

I had brought my PC and two laptops to scale demoing and make it so everyone got the "hands on" feel.  Two people showed any interest in doing everything.  I ended up running through the demo (when it worked) almost every time.

Lesson 6: While an array of computers running your product may seem like a cool idea, one big screen is probably a better idea.

Despite the incredible amount of things that went wrong, I still got a very positive response.  I'll be taking this class project and (hopefully) turning it into a real project.  Stay tuned!

Easy to use gets the views

I know it's been repeated again and again: make your product easy to use.  This is rather easy in theory but practice proves time and time again that making an "easy" product is anything but.  For example, take my recent experience with Heroku and Nodejitsu.  I've got a small node.js app I've made for a class that I wanted to demo online (rather than drag my PC-as-a-server around).  I looked into both Heroku and Nodejitsu but ultimately decided to go with Heroku because I had an account there from three years ago (logging into that was a bit surreal).  If you're wondering what "Google strikes" are, check here.

After logging in, I was redirected to the "my apps" section of the control panel.  I could see the one app I'd created ages ago.  I then spent an embarrassingly long amount of time looking for the "new app" button.  I ended up needing Google to find the "new app" walkthrough.  Strike one.

The first half of the walkthrough was fairly simple.  Turns out I could only create a new app through my Terminal.  I installed Heroku, set everything up with git, and created my new app.  All went well.  Until, of course, I tried to do anything with my new app, namely update code.  The tutorial had Heroku adding itself as a git remote.  Turns out it didn't.  After hashing through a few options (and Google strikes two and three), I finally gave up on the automated method and added it myself.

Thanks to this brilliant problem-solving, I got an entirely new error.  Google strike four.  I discovered that Heroku expected me to add an RSA key manually.  Oops.  My app FINALLY was pushed to Heroku....and died.  Heroku helpfully told me to check my logs.  My fifth and final Google strike was committed trying to find my logs.

Heroku was supposed to be the darling of YCombinator.  I'm a huge fan of YC and was willing to give it the benefit of a doubt.  Sadly, my experience was not very good.  Looking for another option, I found Nodjitsu.  The experience was incredible.

Like most users, I don't like creating an account to try out something.  Nodejitsu created a system that didn't feel like I was creating an account.  I had the jitsu CLI tool installed before it even asked me for a password.  The instructions provided were concise and clear.  There were two issues during setup, both of them mine.  Both times, jitsu pointed out the source of my error and told me what might have been causing it.  When I finally fixed my problems, the app uploaded cleanly (and Nodejitsu automatically incremented my version, something I always forget to do).

There were still issues (I needed to set up a database) but overall, Nodejitsu was clean and helpful.  Jitsu helped me through my own dumb mistakes and kept quiet otherwise.

Have a story about a great experience?  I'd love to hear about it in the comments?  Want more of this in 140 characters or less?  Write a script to parse my site into blocks!  (Alternatively, you could follow me on Twitter).

Source Saturday: No Actual Code

Sadly, most of the code I've written this week has been boring code for a very unboring project.  So instead of going on and on about .getElementById and textContent, I decided to devote the non-Sherlock-watching time of my Friday night understanding whatever HTML5 is.

Honestly, I haven't paid much attention to the various *tmls.  XHTML, HTML[num], etc, didn't matter to me.  I had real coding to do.  The vague things I heard about HTML5 made it seem like yet another buzzword for "hip" business to claim they used.  (I guess I technically used it in one of my Chrome Extensions that never got anywhere).

After reading through large portions of Dive in to HTML5, (and quite a few really lousy tutorials) I realized just how wrong I was.  Let me try and summarize a few important bits:

There's no such thing as "HTML5 compliant."  HTML5's goodness is made up of lots of component parts, including <canvas>, <video>, and non-tag items like localStorage.  Support for these components depends on browsers.  (You can check your browser here or the whole browser ecosystem here).

I'm glad we've finally got a competent <video> element which embeds a video on the page (surprise!).  <img> has been around since the early 90's.  Gifs have been sort of a stop-gap measure between the two, but they're slooooow.  One of the brilliant things about <video> is how it approaches the multi-format nature of video.  Web designers can point to multiple video files, and the browser can select one of the format it supports.

Local storage is another nice thing in the bat-toolbelt of HTML5.  While it's not exactly a tag, it allows websites to store data local to your machine.  Privacy "advocates" will probably yell and scream at this one, but the data can only be accessed by the website that put it there.  Local storage should not be used to store sensitive data, as it can be retrieved/modified by anyone with physical access to your machine.  I technically used this feature in my BlogMe extension.

Another thing that privacy advocates won't be happy about is Geolocation, which speaks for itself.  Fortunately, most browsers will ask for permission before giving away location-specific data.  This isn't technically HTML5, but is part of the feature set that the "new web" is bringing.  (What are we up to now, Web 8.0?)

There are many, many other cool features of HTML5 that will save lots of time and make life easier for everyone.  If you're interested in finding out more, read the full tutorial I linked to at the beginning.  It's wordy but worth it.

Password problems

A recent Wired article makes the claim that passwords are obsolete.  Normally, I'd just pass it off as yet another blogger trying to get hits by claiming that "$technology is $bad for $reason" but this is Mat Honan, who had his digital life destroyed earlier this year.

Honan has done some incredible research into the (lack of) security in our lives online.  He claims that it would only take him minutes to acquire your passwords to a plethora of online services, including banks, PayPal, and email (which is central to your online identity).  In fact, he can do all of these things even if you've got an incredibly difficult password (like Tr0ub4dor&3).

The biggest problem with passwords isn't the passwords themselves.  It's us.  Human weaknesses result in websites providing the option to reset our password.  So long as that option exists (and breaking it is easier than breaking a password), we'll be insecure.

Alternatives to "just a password" exist.  One of the best (in simplicity and effectiveness) is two-factor authentication.  GMail has it, and if you have a Google account, enable it now.  This isn't totally effective, as it's easy to convince the phone company to redirect your call.

More secure solutions will be found but they will invariably result in a loss of convenience.  I convinced my dad to use two-factor but he turned it off because my mother got tired of chasing down dad's phone.  The convenience factor is what's stopping fingerprint and eye scanners from ever reaching the mainstream.

Passwords need to be done away with - but they're here to stay.

(If anyone's looking for startup ideas, Atwood's pipe dream might be a good place to start)

Projects to pursue your passion by

I've always been an advocate of the project learning style.  Simply put, learn the basics of the language (syntax, simple code structure) and then find a project.  The project shouldn't be overly ambitious (you'll be overwhelmed)  or easy (you'll be bored).  The trick is to find a non-trivial example that only involves one or two things you don't know yet.  You'll be forced to learn new concepts while exercising the ones you've learned already.

Finding a good project is harder than one may think.  It's easy to imagine massive projects (we'll be the next Facebook!).  Here are some tools to help you find your next project.

The first thing that came to mind (and half the reason for this post) was an article I saw on Hacker News: Learn a Programming Language Faster by Copying Unix.  This is a nice way to learn language basics like file I/O, interfacing with the user, hashes, and HTTP.  The problem is that most of these examples are incredibly basic.  You could find bigger projects as you learn (apt clone anyone?) but there are better options.

My CS professor always recommended games and puzzles as a learning mechanism (and he's right!).  There are two nice things about choosing a game as your project: They're scalable and impressive.  When I say scalable, I don't mean in server size or users but as a project.  Once you've created the business logic, you can implement a GUI, add more rules, or save sessions in a database.  There's a lot of new things you can learn incrementally through the project.  Additionally, games are impressive.  Not so much on a resume.  It's something nice to show off to your friends.  Let's be honest.  At this level, you won't be winning any coding awards.  Your friends, on the other hand, will be more than glad to help you with ideas for expanding and improving your game.  (One important thing is to keep the game simple.  Clone Blackjack but don't try to make the next CoD or Halo.)

Finally, if you're going to learn a web technology, it might be a good idea to build a blog framework.  Blogs start out simple.  All you really need are two pages: one to post the blogs, and one to display them as well as something to store them in the interim   After that, there's a lot of places you can go.  I strongly suggest that you write them from scratch instead of using a plugin/library/what-have-you.
Here's some ideas to get you started

• Add a template system.  Because what use is a blog if it isn't pretty?
• Create a comment system.  These can get tricky, especially if you add things like voting and authentication.
• Pagination.
• Search.  Bonus points if you do something more than a simple database "LIKE '%$searchterm%'"
• Unit testing.  Not exactly blog-relevant but a good thing to know nonetheless.

You can follow my own journey in blog creation in node.js form at my GitHub.  If you're not interested in node but still enjoy the blog, follow me on Twitter to get notified when I post (I promise, I'll get a real picture soon)

The trouble with StackExchange

I love the idea behind the StackExchange family of websites.  They've taken something that usually was a horrible experience (Q&A on the web) and created an entirely new way to solve almost any kind of problem.  I also like how they're unafraid to branch out to other topics, even beyond technology.  (For the curious, Biblical Hermeneutics and Parenting are some of the ones you wouldn't expect to find).

The problem is that us geeks tend to be very territorial.  We want our sites to be just as we want them, without all the riffraff.  And there's a LOT of riffraff.  Far too many "professional" programmers see StackOverflow as a crowdsourced application to write their code.  Spend a few days in the PHP tag and you'll see what I mean.

The deluge of bad questions creates a calloused attitude among members who have been around for a while.  One example of this is my recent question at Ask Ubuntu.  While Linux Mint is off-topic there, the Ubuntu Keyserver isn't.  My question involved both.  While it was determined that the question was on topic, it still was closed.

This is an edge case that left me with a bitter experience (and no answer to my problem!).  StackExchange has some great tools for dealing with bad answers but very few for dealing with false positives.  The canonical (pun intended) answer would be to flag my question for moderator attention.  This puts the decision in the hands of a single person which isn't very useful.

It would be easy to dismiss this as a one-time edge case.  It may be.  In any case, it should not be taken lightly.  Tales like this can ruin the user's experience.  If you're building a social website, make sure you have an effective system to avoid these false positives.  StackExchange recently added a reopen queue. We'll see if it stands the test of time.

Thanks for sticking with me in this rant.  If you liked it (or have an idea to solve these sorts of problems) add a comment below!

Source Saturday: In which I learn node

Earlier this week I saw a job posting for my dream position with one caveat: They wanted a node.js guy.  Rather than ignore the fact that this once-in-a-lifetime opportunity had opened up, I decided to use this as an opening to demonstrate how proactive I am.  (This also explains why I've got so many job application posts lately.)  After going through

One of the nice things (or so I've heard) about node is that there's a LOT of features I have access to through npm.  I prefer to learn by doing so simply slapping together all the parts of a blog makes me no better than someone who codes exclusively in jQuery without understanding the JavaScript underneath.  In fact, I could pull an entire blog platform if I so wished.

Building the basics in node.js was actually a pleasure.  I really enjoyed the callback model and found it easy to wrap my head around what was going on stack-wise.  The project also introduced me to the noSQL movement (specifically mongodb).  

There's a lot of things I like about mongodb but I found one irritating issue.  Simply put, my code looked something like this:

function handlePageOne(req, res) {
    //Open database connection
    //Put something in the database
}
function handlePageTwo(req, res) {
    //Open database connection
    //Pull something from the database and add it to response
}

Simple?  Yes.  Correct?  Not a chance.  As it turns out, one actually needs to close the database connection as well (this is very important in a single thread environment like node.js).  What I ended up doing was adding a db.close() statement at the end of every database block.  You can view an example on GitHub.

This was only a toy application intended to help me learn the basics, so I stopped there.  On second thought, there are much better ways we could manage this.

We could (like Poet) not use a database at all for managing posts but rather store them as separate files.  This would eliminate any database issues and open new ones, mostly configuration.  Another option would to be to abstract the database calls into a separate function, ensuring to keep callbacks managed correctly.
EDIT: Another alternative would be to use an object modeling system like mongoose instead of rolling your own.

What does "I Know" mean?

Recently, I submitted an application as part of the work I'm doing for my next job.  As a programmer, I needed to communicate what languages I knew.

I'd like to avoid giving the impression I'm better than I am.  That might get me the job but I won't keep it.  If they're willing to take on an energetic learner, then I want them to know what they're getting so there's no issues or communication that could result in firing or bad feelings.

How can a job-hunting programmer clearly communicate their skill in a language?  I've already asked a related question on Programmers.SE.  There were a lot of excellent answers but let's focus on our topic: a resume.

One solution is to simply group them all together, perhaps ordered by experience.  The problem here is that there is still a lot of ambiguity.  If I've listed "C++, C#, Python," does that mean I have 6 months or 6 years of experience in C++?

Another easy answer is to simply list the years you've worked with a language alongside the language.  This also leads to definition problems, as I've "worked" with Python for three years now but my skill in Python is nowhere near someone who's been using it professionally for three years.  This tactic may impress HR but I hope that any competent programming manager understands that experience doesn't make you a better programmer (for more on this, check out Peopleware).  Feel free to try this tactic if you want to impress a non-programmer.  I wouldn't use this.  If a non-programmer is the one hiring programmers, do you really want to work there?

So the simple approaches didn't work.  One could include all of the major projects one has completed.  This takes up a lot of time and space and you could run into NDA issues.

So what did I do?

I've divided up my programming experience into three categories:
Professional: Languages I've been paid to write in (for a significant period of time.)
Project: Languages that I have completed a decent-sized project in.  Something bigger than Hello World.
Familiar with: Anything that I've written in that doesn't fall into the above categories.  Something more than Hello World but less than a full project.  I also put languages here that I have built something in a while ago.  For instance, I once built a virtual stock market in C++ two years ago.  Naturally, my knowledge has lapsed somewhat.

I chose this system because it was easy for me to categorize my knowledge as well as explain the system to others.  In addition, I included a link to my GitHub account to (attempt to) provide proof that I could code.

Apply with Wishlist

I love Amazon's wishlist.  It's a great place to store books that I'm interested in but don't have time (or money) to read just yet.

While I was applying for a job yesterday, a peculiar thought hit me.  Should I include my Wishlist with the application?  This might seem awfully cocky of me.  On the other hand, there are some good arguments for it.  You can learn a lot about who someone is by the books they want to read.

1. Am I interested in general programming, or just one problem domain?  
2. Do I seem like the sort of person you'd want to discuss things with over coffee?
3. Am I ambitious?

I should hope that my list provides a good answer to all three.

(You can find my list here if you're interested in supporting Recoding!)

Scream Moments

Lightning flashes, revealing a drenched man standing in the pouring rain.  He's just lost everything: family, job, faith.  Losing all sense of humanity, he arches his back and howls a primitive scream.  Raw emotion pierces through the night, leaving stunned silence in its wake.

Ok, so this probably doesn't sound like your typical day at the office.  (or at least I hope it doesn't).  You've probably wanted to scream the same way.  Scream Moments can come from many directions.  Perhaps your boss just dropped a reverse eagle in your lap.  Maybe the API you're forced to work with slowly drives you insane.  It could be that one bug that Just. Won't.  DIE.

How often do you find yourself in such a situation?  Why?  For this example, let's look at moments that come from external sources.  The four hours you spent fixing your own stupid bug may frustrate you, but it's not a full-on Scream Moment.  True Moments come from external sources. There are two types of sources for these moments: technical and personal.

Technical Moments

Code is evil.  Lousy programmers are evil.  Dealing with this evil doesn't make us a paladin (drat!).  It just annoys us.  Have you ever worked with an API that was so mind-boggling messed up that you wanted to beat those responsible senseless?  How about ridiculously illogical language issues?

Technical limitations will always be a problem and yet they tend to crop up more on some projects.  It's important to note why.  Is it an external limitation?  Has management been sold on a product that's slowing you down?  These moments are fixable.  After the initial wave is gone, analyze  what happened.  Find the source of the problem and fix it.  That's what a programmer does, right?

Sometimes, you can't fix it.  If you find yourself encountering a lot of problems that you either can't solve or aren't permitted to solve, perhaps it's time to start working your next job.

Personal Moments

Most technical moments are fortunately easy to fix.  A slow computer can be upgraded, language features can be restricted (through the language itself or office policy), and debuggers are a godsend.  People, on the other hand, are a lot harder to change (Sadly, DNA isn't hosted on GitHub).

Personal Scream Moments are much harder to deal with.  They're usually much more than a simple office spat about coffee location.  They're usually caused by the fourth coffee-related spat in as many days.

Solving these moments (from either a management or worker perspective) require a lot of effort and creativity.  There are many books/blogs/seminars about this sort of thing but two that have stood the test of time are Dale Carnagie's How To Win Friends and Influence People and Stephen Covey's The 7 Habits of Highly Effective People.

7 habits teaches us one big lesson in resolving and avoiding these moments.  We should strive to only work within our circle of influence.  Don't focus on things that you can't change.  Centralize your efforts around the issues and problems that you can influence.

One of two jobs

It's no secret in the CS industry that we switch jobs a lot.  That's not an issue.

At any point in time, we're working one of two jobs:

• The job we have now
• The job we'll have after this one

Working your current job is, well, working your current job.  Working your next job is when you're still technically employed by your current employer but your mind and heart are already trying to land your next job.

Currently, I'm working my next job.  Why?
Poor management: To me, it seems that management cares about product instead of people.  They'd rather have a crummy product now (and never fix it) instead of creating a process and framework to create a much better product down the line.
Sales issues: We have an incredible sales team.  They can sell products that haven't even been invented yet.  The problem is, it's now Programming's responsibility to build said product, no matter how difficult or ridiculous it is.
Wrong career direction: What I'm learning in my current job is not where I want to go.  I want to learn how to build great products in PHP, instead of how to hack together a project as fast as possible.

How about you?  Are you working the wrong job?

There are three main questions to ask yourself.

Is money important to you?  If so, can you make more at another job?

In one of it's brief moments of clarity between long stretches of hilarious insanity, the DailyWTF discusses salary.  The main point to be taken is not that we should strive to make as much money as possible, but rather are entitled to a fair salary and should demand it.  If you can't get a fair or living wage, switch jobs.

Is your current job holding your career back?

Java programmers have higher salaries.  The reason for this is that Java doesn't teach you anything new.  In order to entice programmers, Java shops need to pay more.

In order to make sure your career keeps pace in a fast-moving industry, you'll need to make sure you can learn on the job.  Programmers.SE has an excellent article on this.

Could your work environment use some improvement?

Are meetings held only when needed or when the boss wants to feel important?  Is project scheduling done with proper foresight or with deadlines set to the next big conference?  Work environment can be more important than either salary or learning.

Obviously these three things aren't everything but they represent a lot of what you should be looking for in a job.

EDIT: some tips on online job hunting

Source Saturday: While vs Recursion

In a previous post, I mentioned that I had created a Haiku generator.  One response was fairly concise:

Make this recursive

Most likely, it was intended as a joke (albeit a poor one).  However, will recursion really improve getLine()?

In general, recursion leads to code that is more difficult to understand.  Given the stack-based nature of recursion, it's harder to conceptualize vs. regular iterative code.  In some situations, it's worth the extra effort to find a recursive method because an iterative solution is difficult or impossible.  One example of this is reversing a string because recursion naturally creates a stack that the coder would have to implement in an iterative function.

That said, I can't see any feasible reason why we'd need a stack for getLine() but let's be Mythbusters and try it anyway.  I used Python's timeit library to run tests on the two variations of getLine().

testRecursion.py returns the following results:

Iterative: 11.3675792217
Recursive: 11.7112400532

So a recursive solution is slower (no surprise, as generating each function call in the stack takes up valuable number-crunching time) but not by a whole lot.  Sorry Zirak but I'll keep this solution iterative.

Finally, a Haiku about this process (not generated by Python):

Zirak says: recurse!
Never used timeit before
Turns out I am right