Motivating software developers

      Here are a few general known statements: success is about passion and motivation. You need to put your heart and efforts into it in order o fully succeed. You cannot take something to the limits if you don’t believe in it and if you are not ready to make some compromises on the way.

      Compromise is when you decide for example, for one of the following:
      >  Career. When you see that investing in one technology / company / team / location / brand / trend… might mean something to you for the future. Might lead you to where you actually want to be, no matter what that is. What mattes is that the compromise you make, the crap you accept for the moment will take you one step closer to your career path. Of course if you have one.
      >  Money. Usually money does not come on the first place if you are truly honest with yourself. If money comes on the first place when you make a compromise, then yes, you have an income issue that has to be fixed or a planned investment. Otherwise money is a general motivation for a career path. They come either with your skill growth or evolution on the hierarchical scale.
      >  Environment. Especially in software area environment is key critical to assure an innovative state of mind. Creation and invention is about being open minded, having a friendly environment that welcomes any crazy idea, eventually inspiring crazy new ideas.
      >  Team. Even if team is part of the environment, I especially named it separately since it has a special influence. Of course you can be a lonely freelancer, but show me a freelancer that is not part of some community. Team, communication, bounding… are all very important even if this is sometime virtual.
      >  Technology. Again something surprising, something that you might as well consider it as part of the “career” section, but it is not. Don’t full yourself, as much as a guy grows as a manager / career path, he will still stick to one or more technologies and he will still get back to code something. Maybe less, maybe more, but once a developer, always a developer. It is not about what you do, but it is about that satisfaction that you create, that you figure it out by yourself, that you find a fast solution, a better solution.
      >  Ego. Hmm… what is that? Well it is something that does not eventually translate into 0 or 1, not even in OOP, not a web-service or anything in this area. It is about us humans, being sometimes so proud or so foolishly honest, or anything that has to do only with us. Sometimes ego drives developers (known as having a huge ego) towards decisions and compromises.
      >  Amount of work, time, exhaustion. This is, of course, part of any job. Within software development, same as other brain efforts, this is important and, depending on the level of it, certain compromises are made. It is very often combined with one of the above. So it usually has a hidden reason. For example you might love a job that allows you to have spare time within working schedule so you can actually focus on studying a technology or on a product or on… making money for other clients, etc.
      >  Coolness. Yes, this can probable be included in one of the categories above or defined as a certain percent of each of the above combined. Developers have their own world. If you, the one reading my blog, are not part of software world, you would be surprised that we have here our own fashion shows, our trends, our online meetings, our chat, our social networking, our brands, our certifications, etc…

      Of course there are other reasons and compromises but I will not get into personal issues such as location or region or economical trends, etc. for the goal of this article we basically stick to the ones above.

      So what we learned so far is that a software developer will basically make some compromises and chose his work, keep his work based on the above statements. Sometimes his work and decision is defined by a combination of them, sometimes only by only one direction.

      If you as a manager really care about your team and need to keep them motivated, not just working, not just showing up at work, but really impassionate and long term committed (whatever long-term might mean these days for software industry), then you need to know your people. You need to know what drives them. What is the element (for example from the ones above) that really drives the individual?

From my experience a software – related person will be motivated if:
      >  You, as a manager, make sure you identify and assure a combination of the above
      >  You, as a manager, make sure you intensify the most important element for each resource.

      So far it is all logic and somehow applicable to a range of industries not only software.

      If we relate only to software, then I would insist on the ones I mentioned above as special for the industry. You will not find an accountant choosing to work on a specific part of the accounting because of coolness or because of the trend. They will work on it because of the income, because of the market demand for such jobs, because of the general opportunity, because of the corporation brand, etc. They will put passion into it, but they will not chose it because of technology. They will not chose it because of the ego or because it allows them to innovate more.

      More than this, software developers tend to become introverts, tend to give up or never grow communication skills, tend to make software their world. Impassionate software developers become their work and behave their work and vice versa: their work will reflect their character and behavior. Sounds freaky or scary? It is so real.

      I had friends (yes more than one) that made a mistake when they were tying their shoes and their immediate thought was to do a “Ctrl + Z”. Not laughing? You’re not a developer, then. Oh yeah, there are so many jokes about it, but so many are real. You behave as you think and if you think in algorithms you will behave as such. You will end up planning your life by bubble sort so you organize things fast... Etc..

      One of my favorite examples when presenting Software Project Management Tips and Tricks is the one related to shopping list. You may choose a specific methodology (agile, extreme, waterfall, scrum, RUP, etc…) when you do shopping and approach the “cash and carry” shop by using that specific methodology: faster, better, by shelf, by brand, cheaper… depending what you aim.

      I can continue but I won’t. I made my case in giving you a glimpse on software developer’s state of mind.

How do you motivate them? Go by their passion.
      >  By technology – round robin them on technologies (move them from one to another), give them the opportunity to know best one but also constantly get the new ones evaluated.
      >  By growing their EGO in allowing them to invent and take the credit. Make them special. Make sure the product become their child. Make compromises on decisions when it is THEIR decision.
      >  By the coolness – stay up with trends and what is cool to learn and put them on that technology / methodology / state of mind /environment. Even if you don’t have the opportunity: invent one. Make all possible compromises that all new requests are going to be built with the “cool” stuff. The results will really make a difference.
      >  Create the craziest environment. I learned by myself so many times that environment with basically no restriction and actually invitation to wild will not cause you productivity decrease, but even more, will build a team that is productive in spikes but with the average of success and quality clearly above any corporate restrictive environment.
      >  Select very careful your team. Involve anyone in your choices and never make compromises. Once part of the team and fully accepted, the guy will glow and the team will count on him even if you have some doubts on some of the skills.
      >  Keep up / high the amount of work. Yes you read it right. A developer with nothing to do will find something to do somewhere else. Keep them very busy and even more, ask extra 3 to 5 cool tasks out of them. Most of us (yeah I am part of it) will go home, do the boring life-related stuff, then switch back to work on the cool tasks.
      >  Monitor their behavior constantly in order to check all these. Never give up. Not monitoring a resource will lead to loosing it.
      >  Invent personal projects; encourage them to work on personal ideas for a certain amount of time. Most of them will be useful later. Plan time right and allow them to grow freely their ideas.
      >  As much as possible make sure money do not become an issue. If handled well all above, money will not become a burning issue. This is of course subject of discussion and economical constraints but I’ve learned that when a developer is reaching to constantly think about money even if YOU DO all that I mentioned above you either are paying him crap or he has issues and you don’t need him.

      Is this all? No, there it is so much more in motivating people. This is no general solution, no magic methodology. Really knowing each of your team members and really communicating with them will lead you to so much more thing you can do just to motivate them and keep them focused.

      Each one of the above criteria and suggestions can be detailed within a long chapter: environment, ego, money, technology, etc… Maybe I will.

.

Commenting your code...

      Do you work organized? Do you comment your code properly? Well... what does "properly" mean?

      Are there any official code commenting standards, something you just take over?

      I've been always using something quite plain and clear. My rules of thumb on commenting code are basically:
      1. Always comment the complexity! Be generous, it will always turn back on you if you don't.
      2. You don't have to comment all methods. It is obvious that the method doSomethingAndReturnAnInt(int intSomeIntVariable) will do something and return an int after using some integer variable. You don't have to just say it. Any comment has to add serious value.
      3. Always comment inner loops where you have too many. Of course you rather don't have such things for performance considerations, but when you do, make sure you know what are you looping through.
      4. Always use file header generous comments. Who modified what, when? Mark changes on "other people's file" with your name and date of the change and basic reason for changing it. Of course visual source safe does a similar thing but I can afford to have my reasons and still use this rule.
      5. Always comment external references. Web Services, external libraries, even references to other modules within your project. A 2nd developer looking at the code can find out everything by looking within same code. Specify what is that and why do you reference that, what are the parameters… etc.
      6. Always comment “flags” or defaults or conventions that lead to constants usage in the middle of the code. If you have code like if (x=193) {executeSomeCalculation(intSomeValue)} then you better specify what 193 is. Of course that if you have code like that something is wrong with you, but I rather know what was in your head at that moment then worrying about your development skills.
      7. Always comment when you feel like it. When you create something, when you are impassionate, tell the world about it. Document your creation. C’mon, I know you feel like that from time to time. Why do you code otherwise?
      8. Always use proper variable and methods naming. This will lead to less need of comments.
      9. Always add details for multi-layer applications where you are referencing sql stored procedure. It is very usefull to look in the code and see a method named getSomeDataFomBD(param) that has as comment something like /* will cal stored proc named returnSomeDataFromDB */. It definitelly helps for gebugging.

      There are more, but enough of that…

      But this is what the priest says not what the priest does :) It doesn’t mean I always do. I always try.

      From my experience, coding comments is a matter of corporate culture within software providers. They all start with the basic and adapt to their best practices. Most of them have quite good practices and methodology as reference, but very few apply it right.

      If there it is no rule enforced and no strict policies, including the validation after, then no one will do anything.

      There are various reasons for adding code comments:
> Because you are very organized and experienced
> Because you are working 12 hours a day on 5 projects and you will forget if you don't add comments
> Because you are working on other developer’s code and you want to make sure you "mark" down your place
> Because you need to impress customer tech representative
> Because you are not sure about what you are doing and you hope someone will eventually have a look at it
> Because you are going to be checked by your boss
> Because the client will check it randomly and you are always lucky
> Because you build custom software but you will probable reach in 4 years from now to maintain it.
> Because you are just thinking you are inventing something cool and the world has to know about it
> ...

      Depending on all these above, you might have more or less comments, more or less useful, more or less logic.

      There are basic rules that definitely have to be respected. I did not see good commented code too often. I saw "standard" code comments in most of the cases or no comments at all.

      I think that standard code comments can be easily removed by having very good and self explanatory variable naming or by having a general organized coding style. What is the need of describing each function name and parameters if you get it from the name. I would love to see code comments that mean something, that describe something interesting, something that will let me understand the complexity by reading it and not invite me to dig a lot in order to fully understand.

      I've seen those and they are showing up especially when you put passion on what you're doing, when you feel you invent that thing and you want to come back later or show it off or train someone, etc.

      Most of the development shops are actually trying and doing their best with it. As a customer you do not want to hear about it since it seems it will cost you more. You would love it done somehow in the background or, if you buy the final product, you just don’t want it done at all.

      As a provider, you add comments when you are going to maintain the thing for years or when you want to live out of the product. And, very important: you pray that the other providers DO add comments for the time you will end up maintaining other guy’s code.

      Here's a link that made me laugh a lot. It reflects many of the above by examples from real code comments. It worth reading and please focus especially on the comments on the article, not the article itself. They are hilarious!!!

      http://stackoverflow.com/questions/184618?sort=votes&page=1

Other references (please come back with more):

Some basic information here:
http://www.gnu.org/prep/standards/standards.html#Comments
http://www.cs.swan.ac.uk/~csbob/teaching/laramee07commentConvention.pdf
http://www.winnershtriangle.com/w/Articles.XMLCommentsInCSharp.asp

Wiki info:
http://en.wikipedia.org/wiki/Comment_(computer_programming)

ToDo or not ToDo
http://www.approxion.com/?p=39

.