Dorodango code

One of the first applications I wrote as a fledgling programmer was a threaded BBS in 1999. It was heavily used by a small group of people for a number of years and I continuously tweaked and improved it. Running on Classic ASP with an Access backend, performance was always always a problem and with each tweak I would make it a little faster and learn a little bit more about each layer of the stack.

The greatest technical lesson I learned was that trips on the wire are really, really expensive. Sending a single query to the database and sorting and filtering records using VBScript was an order of magnitude faster then relying on multiple database queries to render the threading. I eventually further improved on this by re-generating the board as static html on each post. The performance was incredible, but also resulted in some tricky IO locking bugs.

I still consider it to be one of the most satisfying pieces of software I’ve ever written. In addition to the joy of creating something useful, I had a real sense of pride and accomplishment in the code itself.


Dorodango is a Japanese pastime/art form where mud balls are polished to an incredible shine. It may not be a terribly practical activity, but it can apparently be a really satisfying one.

We all sometimes have to throw code together under a tight deadlines that will be pushed into production shortly afterwards. It’s not a fun experience and it can be draining.

So I have dorodango code. Code I can work on and feel revitalized when I’ve had to work on a particularly draining codebase (primarily legacy software). Like polishing mud balls the work doesn’t have to further any other purpose, it just needs to be something you find joy and satisfaction in. The code can be something to scratch a personal itch or a professional pet project.

Whether it is squeezing a few extra milliseconds of performance out of the application or polishing the design a little more, working on these applications is deeply satisfying and fun.

So do you have a dorodango application? Something you keep polishing and improving and feel personally proud showcase and talk about as a developer? Do you feel good talking about that application? Do you get excited talking about it?

git religion

I was raised in an SVN household and later converted to Microsoft’s TFS. It was a conversion of convenience and I never developed the zeal of a true believer. I would listen to the followers of other systems proselytize their way, but never gave their way more than a cursory investigation.

Then these git guys started showing up.

They were different. They were weird. They didn’t want to talk about how git was better than SVN or TFS. They just wanted to talk about how much they loved git, and how much git loved them.

Intrigued by these crazy git prophets, I decided to embark on some source control tourism. I was going to try them all out. I was going to go back to the source control of my childhood (SVN), join these git guys for a while, finally get around to dropping by the Mercurial temple, and even go check out those Bazaar and Perforce sects I had heard about.

Two years later, I emerged a distributed source control convert who worships in the house of git.

Why I became a distributed source control convert

I am git disciple, but my true conversion was to the way of distributed source control systems. Mercurial, the other popular distributed option, is also a fantastic tool. Both of these tools essentially worship the same gods, but differ on how certain tenets of the faith should be followed. I am going to talk about git, but most of the points apply to Mercurial as well.

1. Git asks for little

Git doesn’t ask you to setup any special places of worship. You can practice git alone in your home, with a group, or in the beautiful GitHub cathedral. Git doesn’t care.

TFS and Perforce – on the opposite side of the spectrum – have very exacting requirements for their places of worship, which are extremely expensive and tedious to construct. SVN is certainly better then TFS or Perforce in this respect, but the setup and maintenance of a separate place of worship seems needlessly complex after git.

2. Git forgives much

Git is very forgiving. It is pretty hard to irreversibly screw something up in git. Even if you are tempted to try something insane (like rewriting history) backing up git is as simple as copying your .git directory elsewhere.

This contrasts starkly with its centralized predecessors where backing up and restoring repositories is not trivial and mistakes are not easily forgiven. I am very wary of trying potentially destructive operations in these systems and as a result tend not to explore them as readily as I do git.

This forgiving nature removed any dread or trepidation I felt exploring the system and made git a lot of fun to learn.

3. Git sees all

IDEs like Visual Studio and Xcode have the disconcerting habit of asking if I want to save changes even if I am pretty sure I didn’t make any changes. Git restored my sense of sanity on these occasions. A simple status lets me know which files have changes and a quick diff shows exactly what changed.

The centralized brotherhood requires me to inform them when I want to check out a specific file and appear incredulous when I try to get them to understand that I’m not sure what changed.

IDE plugins for the centralized systems automate this notification, but should you edit a file outside the IDE and fail to inform central control, your change will not get picked up. As a result there is always an unsettling feeling in the back of your mind that there may be an orphaned change floating around out there.

Git’s omniscience gives you a warm fuzzy feeling that all is well and all changes are accounted for.

4. Git believes in many paths

Branching. The concept is supported by the centralized systems, but implemented as though branching is a serious and weighty decision that requires pre-branching counseling and a decision that should not be taken lightly. As a result, branching in these systems tends to be reserved for major changes.

Git treats branching like breathing. After you use git for a while branching will become an automatic reflex. Branching is so easy with these tools that it changed the way I actually write code.


Git is a wonderfully simple, flexible, and forgiving tool that just works. At first, to be honest, it’s a bit weird. Centralized systems are a lot easier to grok and the git merge model looks like a mess from the outside. But then you realize: development in the real world is a mess, and git works with that instead of against it.

The caveat of a novice

I can’t claim more than a novice’s understanding of all of the source control systems I tried on my trip. There might be some magical level of proficiency you can reach with the tool where the experience is transcended into bliss (I keep hearing that’s what finally mastering emacs is like). If it exists for TFS, SVN, or Perforce, I never reached it.

The Jeff Atwood and Scott Hanselman motivations

In the pantheon of programmers there are gods like Anders Heilsberg and John Resig — whose abilities and talents are beyond the reach of mortal coders — and there are the Heroes: coders whose talents may be within mortal comprehension but whose feats are the stuff of legend.

Jeff Atwood and Scott Hanselman are two of my favorite heroic programmers. Both are extremely passionate about their craft and are driven to continuously improve themselves as developers.

The primary drive for their respective passions however appears to be subtly different.

The joy motivation (this is neat!)

Atwood appears to be primarily driven by the joy of what he does. There is constant sense of awe and wonder in his posts and podcasts, and it is immensely infectious.

The strength of this approach is the seemingly unlimited font of energy and excitement he taps into. He is as passionately excited about the user experience as he is about the code.

The joy motivation prevents burnout and keeps a level of energy in the pursuit that is hard to match. This is also the weakness of the joy driven developer. Purely pursuing joy may sometimes look like a cat chasing a laser beam to outsiders: chaotic and unorganized. If your joy manages to take you where you need to go, fantastic. But if not, you may not be paying enough attention to other subjects (say your code’s security) as you need to.

The guilt motivation (why aren’t we better developers?)

Hanselman’s motivation sometimes appears to be a guilt that he isn’t a better programmer. He relentlessly strives for perfection in his craft and as a result often achieves a level of excellence that is unmatched by many.

He certainly exudes joy as well (listening to him and Jeff discuss hardware and movies on this podcast is an experience in joy and excitement in itself), but what seems to drive his passion as a developer is a professional craftman’s guilt and desire to be better.

The strengths of this approach is that you stay on task and end up being a much better professional developer. The two main weaknesses are that either you will burn out quickly or that you will get tunnel vision. Some of Hanselman’s views (like 100% unit test coverage) in my mind start allowing perfect to become the enemy of good. If you become too focused on the guilt of what you have not accomplished you may not be able to take a good look at the landscape and pace yourself on the journey to becoming a better developer.

You need both motivations

All developer’s, to some degree, possess both motivations.

Without finding the joy in what we do we would burn out rather quickly. The joy is why we enjoy building our own machines, learning a new language, or tackling the difficult problems.

Without that professional guilt we might half-ass important, but less exciting, aspects of our code (like security). You need both motivations if you’re going to be a developer for a long time, but most developers do have a primary motivation.

My primary motivation

I tend to fall into Jeff’s camp (that’s neat!), but acknowledge that cultivating some professional guilt will make me a better developer.

Which is your primary motivation?

Visual Studio Achievements: You're doing it wrong

Microsoft published the really neat Visual Studio Achievements plugin a couple of days ago and I am both terribly excited about and disappointed in the plugin.

I absolutely love the concept. Programming is often a solitary activity and a developer’s triumphs and tribulations usually private ones. The achievements system would allow developers to record and share some of their victories, glimpse into the lives of other developers, and even help them become more effective programmers.

My disappointment is in a specific category of achievements: “Shame” achievements.

The current state of achievements

Gamification and the badge/achievement concept is still in its (relative) infancy and as such it tends to be implemented differently by everyone. With that caveat out of the way, there are three types of badges/achievements I generally see:

  1. Status achievements: Achievements worth bragging about. You collected 1,000 widgets, killed 10,000 ogres, or answered 100 questions.
  2. Exploratory achievements: Achievements that encourage players to engage in actions that they may not have otherwise engaged in. You used intellitrace, updated your profile, or completed 10 side quests.
  3. Surprise achievements: Achievements that are awarded for completing standard actions but remind you of your progress. They can also be used early on to help acclimate users to your achievement system: You installed the software, you rescued your first 100 villagers, you have been coding for 1,000 hours.

The thing that all of these achievements have in common is progress. They indicate forward movement on the part of the user towards either greater proficiency, better familiarization, or even just more time spent on an activity. Achievement in most systems are positive reincforcements.

How Visual Studio is doing it wrong

Visual Studio has an entire category of achievements called “Don’t Try This At Home”. These achievements include:

  • Go To Hell: Use of the goto keyword. Um, I heard it was a best practice that you weren’t supposed to do that anymore.
  • Scroll Bar Wizard: Write a single line of 300 characters long. Who needs carriage returns?
  • Job Security: Write 20 single letter class level variables in one file. Kudos to you for being cryptic!

The content and descriptions of these achievements indicate in a very edgy and snarky (or bitter?) way that earning these achievements isn’t exactly a good thing. The existence and phrasing of these badges is in contrast to the generally positive and rewarding nature of most achievement systems.

These are “Shame” achievements: Achievements that you really don’t want to earn.

Even outside the “Don’t Try This At Home” category there are number of achievements that do not reinforce positive behavior:

  • Potty Mouth: Use 5 different curse words in a file. Wash that mouth out with soap!
  • Lonely: Code on a Friday or Saturday night. Coding? Tonight? Ouch.
  • Regional Manager: Add 10 regions to a class. Your code is so readable, if I only didn’t have to keep collapsing and expanding!

Shame achievements have their place

There can absolutely be a place for shame badges (calling them “achievements” actually just sounds wrong): badges that get published and badger us into correcting our ways. It’s not the most positive way to do it, but it has its place.

And this is actually an area I am interested in seeing explored more. Negative reinforcement is tricky to do right but it can be useful in certain situations.

The way it was implemented here however is just bad.

Lumping shame badges into the same bucket as standard positive achievements actually harms the system and might do actual harm to the developer community.

How it harms the achievement system: It is going to reduce the attractiveness of the badge system in general and more specifically it is going to reduce the desire may have to share their achievements. Earning badges like “Potty Mouth** and “Job Security” are not things I am going to be proud of and forcing them on the same page as all the other achievements reduces my desire to my achievements “wall” with others or post it on my blog. A list of accomplishments generally doesn’t include speeding tickets and mug shots, and forcing them into the same system isn’t going to foster adoption.

How it might harm the developer community: People may actually think that earning these badges is a good thing. It. Is. Not.

Even if everyone recognizes that the behavior in the badges is not positive, their sheer presence and comradery with the other achievements invites people to earn them. I don’t want developers earning these achievments “sarcastically” or implement the functionality described in these badges to rank higher on the leaderboard. This is not behavior we should be encouraging and the mere existence of these badges on an “achievements” page encourages that very behavior.

The solution

Shame badges should not be permanent. These badges should be associated with a specific problem that you can solve, and when you solve the problem, the badge should be removed. Or better yet, a “turn-around” achievement can be awarded both as a historical marker to indicate the shame badge existed and also as a status badge to demonstrate progress for that developer.

I think the Visual Studio achievements plugin has a tremendous amount of potential and I hope it doesn’t shoot itself in the foot or cause any harm by botching some of its achievements. We can do better!