This April I had to create a Individual Development Plan (IDP) for me as part of the regular official procedures. One of step was to identify the gaps in you compared to the ideal position you want to reach. Thinking more in this line I have created the below table which contains ways to identify the specific areas of development for a developer.
Guide to reading the table:-
Ask yourself the questions in the column (D). If your answer is "Yes" to any of the questions then you needs to consider the action plans listed in column (E).
| A. Sl No | B. Section | C | D. These things happens with You | E. Your Action Plans |
| 1 |
Understanding what to do
| What to do? (40%) |
1. You have missed some of the requirements.
2. You hear others say "This feature was not supposed to work like this"
3. Your completed work gets re-opened during QA or User Testing.
| -Improve your domain knowledge. -Ask more questions to your PO so that you can impove your understanding of the requirements. -Push for improved requirements documentation. -Spend more time in testing your features. -Listen to sprint demos to get the overview of all the new features added. |
| 2 |
Knowledge of Frameworks,
Design patterns, practices and principles
| How to do it - Your skills to do it (20 - 30 %) |
1. You don't know where to start with when you have to implement a new feature
2. You don't know if a similar functionality already exists in the application or not
3. You don't completely understand the frameworks in the application and how they are used
| -Pair program with an experienced developer to learn how he approaches a problem. -Learn more about the frameworks used in your app. -Try creating sample applications using them. -Identify the patterns and principles used in your app and try to use them. |
| 3 | Problem solving, Analytical, Debugging skills |
How to do it - Your Ability to do it
(10 - 20 %)
|
1. You face difficulties when it comes to writing algorithms
2. You are weak in debugging and finding issues in the code
| -See if you can apply some known patterns to solve the problem. |
| 4 | Communicating with your code | How well you did it? How easily somebody can understand how ? (15%) |
1. Your code is not up to the standards or frequently ignores code quality.
2. You don't have enough code coverage
3. You can't write a quality documentation
| -Use tools like sonar to asses the quality of your code. -Spend more time in refactoring and improving the code quality. |
| 5 | Communicating about your work |
How well can you communicate about your work
(5%)
|
1. Your don't follow the process in the team.
2. Your check-in comments are not useful.
3. Your team don't know what you are working on.
| -Understand and adhere to the team policies. If you feel that there is somethings wrong, communicate and get it clarified. |
This is the first draft of the version I have created. Try to apply this to you or your team and let me know your feedback. I hope I can expand each area by writing more in the future.