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