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.