RSS

Category Archives: Management

Studying for PMP same as being a Zombie??

Zombies & PMP !!!  What is the correlation one may think

Well after watching Zombie movies, I always wondered what would go on in a Zombie’s mind if they were real. I mean all they did was run after a single goal by letting go of everything else around them.The goal being killing the living for food [?] 

Well , I kind of found out…

http://shounakspandit.blogspot.com/2014/08/zombies-and-pmp-certification.html

 

 

 

 

 

 
Leave a comment

Posted by on August 4, 2014 in Management, PMP

 

Tags: , , ,

Humble recipe for Success : Nice one

Got a forward from a friend the subject stated “Recipe for Succes” the contents were even more thought provoking than the subject.
Pasting it here for benefit of others….

Setting Goals
but NOT in concrete

Staying Focused
but turning aside to Help someone

Following Plan
but remaining Flexible

Moving ahead
but not too fast to miss the smell of flowers

Climbing the Ladder
but not stepping on Toes

Fighting to Finish
but choosing your battles

Taking a Bow
but applauding those who had a part in your success

 
1 Comment

Posted by on September 12, 2009 in Bouncing Wall!!, Management

 

Tags: , ,

Best frequency for code review… how to code review

Had an interesting discussion with a peer while coming back home..and it got me thinking..  he was complaining about the quality of code by his developers and was inquiring what approach I follow in my projects.

To tell you the truth I don’t follow a specific time frame or frequency for performing code review.

Just to give you some food for thought

The frequency of code review should be directly proportional to the number of developers working on the project.

More the number of developers on a project more should be the code review frequency.just to give you a rough idea How many lines of code do we write in an hour? or in an day? we write lots of lines of code… multiplied by the number of developers is the lines of code you will have to review !!!!!!!

He was arguing about the time a PL/TL gets to do code reviews. well yes indeed he was right in his argument, we as PL’s definitely do not get much time but who says we have to do code reviews every time till the release of the project?

The way the developers will write code in a project depends directly on the way they write code in the first couple of weeks of the start of the development phase.If you get them into the habbit of coding it right from the start of the project i guess we wont have to monitor much.

Of course that depends on the quality of the resource 🙂

The way i do code reviews is through automated tools & mentoring of good developers to perform code reviews on the team mates.

Naturally PL’s dont get much time to get deeper into the code review process but yes all they have to do is

  • Identify the good resource who has a good style + approach at coding and mentor him/her to get into your shoes of performing code reviews.
  • Dont completely rely on that resource you do your surprise random code reviews.
  • Encourage peer reviews amongst the team. This will in turn ensure small coding issues get addressed at your subordinate level.
  • Utilize automated tools for code reviews there are loads of them in the market
  • There also are some preventive code review tools which get integrated into the VS IDE as a plugin and correct you with regards to naming convention/ style to a certain extent while you are writing code.Makes sense doesn’t it? to be told what not to do while you are doing it rather than being told after you have already done it and moved on to the next piece of code.
  • Generate a check list for coding standards.

Copyright © Shounak Pandit

These are my views, my thoughts need not necassarily be the same as yours….. 🙂

 
Leave a comment

Posted by on September 19, 2008 in .NET, Management, Problem Solving

 

Tags: , , , ,

Effective Code review or How to execute a Succesful code review

Code Review…. The dreaded words for a newbie ears ..or in most of the cases even for the experienced developers!!!!

How to code review ?
Over the years of being the code reviewer or me being the reviewee have noticed a few things which i feel are worth mentioning for an effective and pain free code review to happen.

What exactly is a code review i guess everybody knows that , ill try and point out some of the things which should be taken care of for a productive and pain free code review to happen.

  • Objective: Make sure the objective behind the code review is well known to the developers involved: Developers need to understand that the code is being reviewed and not the developers ability to code.
  • Coding Standard: Make sure you have a predefined set of coding standards circulated with the team before coding. Developers wont have any clue as to what you as a reviewer feel is the right coding standard unless they know what needs to be followed before they start coding.
  • Dont Accuse:Code review shouldn’t be used to accuse the coder, but to point out the improvement areas in the code.
  • Ask / Discuss: Ask reasons for deviation that have happened than assuming: Its better to let the developers explain the reason for deviation rather than assuming.Lets face it many time there are some theoretically correct statements which cant be possible practically.Hence ask reasons for deviation, understand the developers thought process.
  • Listen: Remember the coding approach you use isn’t like the ten commandments.Just because you feel reaching point C is better by going via point A not necessarily everybody will think the same.Let the developer explain why he felt going via point X was better as per him.
  • Understand: Remember the code review is about the coding style not about you.: Dont get offended if there are any improvement areas in your coding.Keep one thing in mind the person reviewing your code has also gone through the same phase as you currently.and till the time one understands the improvement areas we wont be able to improve and do coding expected by a seasoned developer.
  • Contribute: The coding standards wont contain all the development situations we face under the sun Hence contribution from the developer is absolutely necessary.Just because the person reviewing your code is a TL or PL doesn’t mean he is right all the time.Express your view, understand the reasons why there are improvement areas.Keep one thing in mind we do those things best in which we believe in!!! hence if you do not understand why we are doing certain thing in a certain expected way you will never do it correctly so discuss and understand.
  • Appreciate: Code review isn’t just about finding improvement areas. Utilize it also to appreciate someones coding style/Approach.
    Lets face it whether we like it or not we have to go in for code reviews some because their leaders make it mandatory while some because they understand the importance of code review.As long as code review happens in the right manner and for the right reasons it is always healthy for the complete team.

    Have seen or rather experienced developers who would argue over coding standard violation with pointless reasoning.reasoning that would be treated as childish excuses.Listen and explain to them anyways try and make them understand.Ofcourse in many cases you as a TL/PL need to put your foot down or do a little booting to make the developer sunderstand that crappy excuses wont be tolerated.

    Also one good thing to do beyond the coding standards document of what to do is to create a coding standard checklist for developers to check against as when they are coding.

    Copyright © Shounak Pandit

    These are my views, my thoughts need not necassarily be the same as yours…..

 
 

Tags: , , , , ,

Code Review / Peer review…..

One wonders ….Why in the name of God would one want to spend (waste as some people say) time on performing a code review on any piece of code which we/peers have written and seems to be working properly and providing the functionality

I remember back then when i was an intern and i was assigned to a project in which my PM was a guy working in our US branch…people having worked with US bosses might be knowing thr are 2 types of techies our there… one who have less knowledge than you and the other lot who has so much knowledge than you that they make you feel like you are learning the alphabets of development while they are shooting out complex phrases after phrases of sentences….

man how i hated that guy i can still recall his words “Shounak, Dont even show me the functionality i dont care about it, first make sure you have it as per the coding standards” and i used to think what kind of a weirdo have i got as my boss ..he doesn’t even want to see if the requirement has been met but cares about some stupid code review…..and i used to laugh at his code review obsession…

but over the years as i grew into a techie…into what they call a seasoned developer ..i realised the importance of code review

Code review isnt a tool to find mistakes in others code…its a tool by which one ensures the code is going to meet the standards expected of a seasoned developer.

There are various technical ways of achieving our requirements…or rather let me put it this way there are abundant ways of screwing up the way you meet your requirement.and there are some ways in which you meet the requirement in one of the optimum ways…and code review is a tool that helps us walk on the optimum path or close to the optimum path…

for an example check my post on string builder usage vs string concat… at String Builder Vs String concat/

Code reviews are important for a developer to understand how to keep improving his coding style ..

there are various good tools used for having automated code checking one that i have used extensively in my development days is FxCop and one more that i can’t recall the name of…these were tools which would use the assembly n metadata as source and parse the assembly for any coding style /optimization errors

will try and write up about one of them soon

Cheers

© Shounak Pandit

 
Leave a comment

Posted by on September 11, 2008 in .NET, Management, Problem Solving

 

Tags: , ,