Thoughts about a different StackOverflow reputation system

I love StackOverflow. It's my "go to" place when I run into a tough programming problem.

Reputation on StackOverflow can be a bit intimidating, however. Even when you have a few thousand reputation points (placing you in the top 20% of all StackOverflow users) - the top users have 100x that many points! It can make you feel pretty insignificant. "Catching up" to the leaders doesn't feel like a realistic option.

This week, I listened to a podcast about Cortes' conquest of the Aztec empire. During the conversation, the Aztecs were described as a civilization founded on war. Warriors were celebrated. They earned their own "reputation" - in the form of feathers and other ornaments - by conquering neighboring peoples. What I found most interesting, though, was once a warrior earned a badge for conquests on a particular village, they couldn't earn more rep by sacking the same towns again and again. This forced their warriors to become fighters with diverse skills and experiences as they fought new or stronger opponents.

I thought this example might provide a good alternative to the current StackOverflow reputation model where reputation point gains happen at a constant rate - regardless of the type of answers you provide.

Let's say that a user has gained 5K reputation points for answering Java questions. The top user reputation for questions with the Java tag has upwards of 20K reputation. Is the top user, really 4x more reputable as a Java expert? I wouldn't think so. It could be that the top rep user has just been a StackOverflow user longer. Or maybe they have had the good fortune to provide an answer to a question with a lot of views (and up votes).

I guess my point is, once you've gained a certain amount of reputation answering a particular class of questions, you could be considered an expert in that particular field of study. You've exhibited you know what you're talking about. What, really, does additional reputation provide past this point?

I know earning points is a large part of the appeal for many users so instead of turning off reputation gains outright after reaching a certain plateau, couldn't the rate of growth just slow down a bit? Instead of earning 10 rep points for all up votes, maybe the point rate would decrease by 1 for each 1000 points earned for answers with a particular tag, bottoming out at 1 point per up vote . I don't know - I'm just spit-balling here.

Another nice side effect of this change would be that users with a diverse set of skills, could still earn reputation quickly. Once they've hit the expert experience level for answering Java questions, for instance, they could still earn full reputation points for answering SQL questions, or AJAX. Users with a deep understanding in many, diverse topic areas would rise to the top. Like the Aztec warriors - to gain the most reputation - users would need to expand their skill sets outside of their comfort zone.

Comments

Post a Comment

Popular posts from this blog

I Believe...

A recent reorg at my company left me with a new manager - and a different approach to software development than my team had been previously following.  Our new approach is one that I don’t necessarily agree with, but it led me to think about - and reevaluate -  those tenets of software development that I think are important and that I believe lead to increased quality and productivity. This post will consist of fairly high level discussions about how to organize code, teams, and projects - but contain very little actual code. Many of these ideas will not be my own.  They are mostly ideas I’ve learned from others and their willingness to share their experiences with me.  They are, however, ideas that I’ve practiced and hardened as I’ve worked to build my own ideal environment for delivering value through software . Many of these ideas I now take for granted as commonplace (even though they aren’t).  I felt a need to document them anyway - so people can understand what to expect (a
Read more

FRail :include

I really like developing with Rails, but I've been frustrated the last few days by some things Rails should do quite easily, yet doesn't. I've already written here and here about some of my struggles with Rails :include clause. Here's one more... Let's say you have a has-and-belongs-to-many relationship. If you :include this relationship in a find query, Rails will automatically create the join clause including the lookup table! That's cool. Unfortunately, it looks as if only the :include clause provides this piece of functionality. Why isn't the same functionality provided via the :join clause or through a general purpose module? This doesn't make any sense to me! I'm working on a database application where I don't need to display a lot of data, but the data displayed is heavily filtered by it's connections to other information in the database. I need to join a lot of tables to perform the filtering operation and using :include
Read more

Performance Tuning JCAPS - Part 2

It's been close to 2 months since my first Performance Tuning JCAPS post. Since then, we've noticed our servers running out of TCP connections under heavy load. Researching this problem, we learned that the JCAPS' JMS server makes heavy use of TCP in implementing Request/Reply queues . We approached Sun for guidance and they assured us that they've had success implementing high throughput applications using the JMS request reply solution... but how? It appears a multi-step solution is needed. First, running out of TCP connections in a scenario like ours is a JCAPS bug addressed in an ESR (110348) and rolled into JCAPS 5.1.3 Update Release 3 . We installed this update and noticed a marked improvement. Running my simple 75 user simulated test, transactions took 2521 ms to round trip (compared to the previous time of 20128ms). While this is great improvement, an average of 2.5 seconds is still really slow for this simple transaction. We reported our findings to Su
Read more