Friday, March 26, 2010

Development Achievements

A couple months ago, I came across this question over on StackOverflow.  In a nutshell, the question was wondering what people have experienced and recommend on how to go about training an intern developer.  I took the approach of any developer as opposed to focusing solely on an intern level person because to some degree we are all "that" person when we first joining a new company with new practices, products, and code.  My recommendation for that question revolved two ideas.  First, around training the person on the product(s) that the person would be using as if they are an end user so they have the context of the application(s).  The second idea was a peer programing/mentoring aspects that many of us have heard about yet not as many have experienced. 

A Missing Piece?

Since I posted my answer though, I began to feel as if there was something missing.  My answer to that question revolved around my own experiences as a new developer in a company as well as mentoring/training new developers that join a company that I'd been at for years.  Something still felt like it was missing though.  What if the person didn't like the direction of the product/application and is uncertain about speaking up?  What if they are anti-unit testing when they join a team that does such?  How do you make sure that the developer made the right choice by accepting the offered position while providing long term motivation for more veteran developers on the team? 

These questions outlined the missing piece.  How to motivate and keep the people involve is a huge thing to new developers.  Sure regularly going out to eat for lunch with other team members can help build friendships and a sense of belonging but what if the intern's job for the first 3-6 months is doing nothing but very remedial work?  If I was an intern and been able to do a large amount of coding but was told to only do unit tests for the first 3-6 months at a job without the ability to truly change directions or suggest tools, I'd be questioning my decision of joining the company or (if I was brand new to the industry) the career as a whole. I'd probably feel that I was capable of more even if I was a bit naive.  We all have to do the grunt work but how do you mitigate the ceremony and monotony of the pieces that cannot be automated?

Is Achievement System Possible?

This got me to think about the theory of inconsistent rewards which says, in a nutshell, that inconsistently awarding rewards can lead to continued behavior.  This behavioral theory is what makes gambling addicting as well as the badge systems (i.e. FourSquare, StackOverflow) and achievement systems in video games work so well.  Could this work for developers and development teams?  In my opinion, yes and no.

In my opinion, the ability to apply an arguably meaningless recognition system together for the greater developer community with regards to experiences is impossible.  Yes, there are a few pieces of low hanging fruit that could be applied to just about every development shop like "Wrote x Unit Tests", "Refactored x lines of code", "Demonstrated good SOLID Practices", etc.; however, those things don't truly map well beyond the basics and theories when applying such to an internal team's focus.  With such a low common denominator of options that could be applied across the board, I wouldn't be surprised if such acquired the same stigma of most industry certifications.

However, what if the focus was moved from the global scale of all developers down to an individual team or company?  All of the sudden you have achievements associated with adding new technologies into the company, migrating legacy code to a new platform, did X to project Y, an "expert" in project Z, and more.  This can turn into motivation tool in that you want to obtain those achievements as well as help identify the "go to" people on certain things.  If someone doesn't have the "wrote first unit test" achievement, then more than likely that's not the person you'd want to talk to if you have a mocking question.

What Would It Take?

Looking solely at a team/company level of implementation, there are a few things that would have to be done in order to ensure that an achievement system could be implemented. First, there'd have to be some place that showcases each developer's achievements.  What's the point of awarding something if it's not known by people?  This could be a bio page on SharePoint or something else.  Personally, I don't like hanging certifications or anything like that on my cube wall and the purpose of an achievement system would be to obtain more and more so hard copy forms of the achievement probably isn't a good idea.  Hard copy would also be pointless if you have remote workers.

Second, there needs to be a consistent method on how to evaluate if the achievements have been obtained by a person.  Many development teams practice peer reviewing their code in some fashion; some aspects of a peer review could be quantified and the achievement system could be based on such.  Things like "First Unit Test", "1000th Unit Test", etc. could very easily be addressed in this way; however, there should also be a way to identify details of other achievements for giving a presentation on a new technology or similar.

Lastly, as much as I think it could work as is, I'm certain some managers in some companies who wouldn't buy the idea unless they could figure out a way to tie it into performance reviews or other process.  Since the idea around the system would depend on inconsistency of awarding the achievements, I don't think it'd be a good idea to use such a system in a quantitative fashion; however, it could be used for qualitative analysis. If this need is present, it would ultimately turn into the needs of the team/company and what achievements they define.

Ideas for Achievements

Below is a list I have been thinking about that could possibly be such achievements.  The list isn't in any order and are more or less me thinking "out loud".  A community site could be cool if the idea works though.  Some of the ideas here are criteria while others would be the idea/concept of what it's trying to convey.

  • Wrote First Unit Test
  • Wrote X Unit Tests
  • First Project Task Finished
  • First Project Task Finished Without any bugs found.
  • Project X - Novice
  • Project X - Craftsman
  • Project X - Veteran
  • Language X - Novice/Craftsman/Veteran
  • First Project in X Language
  • Multilingual (development languages)
  • Novice Presenter
  • Occasional Teacher
  • Educator
  • Implemented Technology X first

This list is not all inclusive and can grow as needed.  I'm curious to know your thoughts on the idea as a whole, what else could be considered for achievements, and what implementation issues may arise.  I just had the idea and figured I'd throw it out here and see what people think.


kick it on DotNetKicks.comShout it

Thursday, March 4, 2010

Looking Ahead a Bit

As frequent readers have noticed, my cadence for writing has dropped as of late. Between work and the other usual excuses, finding time to blog hasn't been easily located. However, that doesn't mean I don't have a lot of things coming down the pipe in the next month or so. Below is some of the topics that I'll be talking about as soon as I can find time.
  • Using Automapper to easily implement MVVM in ASP.Net MVC
  • Looking at db4o - an object database
  • Using MEF with MVC

I don't know how many posts will be associated with each topic; however, there's a lot to write about and some interesting examples associated with such.

Stay Tuned.