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.