** In tasks management:
1. You should know the planned time for each task u take ... and you should estimate your needed time for the task ... compare the results ... clear your responsibility about the quality if the time is not enough.
2. Expect the worst cases, when decide your tasks time.
3. Understand the roles of each person in the project, and try to execute the correct cycles of decisions.
4. Be sure that the delivery manager knows all the problems in the produced build -if exists-
5. Don't plan a vacation depending on a project end, just define a suitable date and don't care they will behave.
6. Every period, Talk with the other members in your team to know what are tasks they took
and what are the problems they faced in them.
7. Don't ignore or postpone any task, finish it as soon as possible before time stresses on you.
8. Don't produce code in a build without testing it well .. WHATEVER the conditions and whatever your trusting in your code.
9. Divide each task to sub tasks and distribute them at days.
10. Try to participate in the estimation of your tasks in the plan.
11. When you do a task in cooperation with other teams: if you stopped because of other teams components (or servers) , if the problem take more than 15 minutes, send formal mail to this team asking solving the problem (cc project manager) to make the project manager tracking the issues times.
12. Don't work more over to finish the delayed work, more "over" working means more faults.
13. If you will document steps that you are executing for first time and one time, then document step by step while you execute them (to not forget anything).
**In Implementation :
1. Always check on null parameters for public methods.2. When implementing with XML(or any defined message structure), Check on null for the optional elements.
3. Be sure that you are working on ONE design/SRS document only.
4. Work on the design/SRS document, exactly. And any requirements are not in the document, Send a confirmation e-mail first.
5. Take a confirmation e-mail before commit anything on the production version path.
6. It is preferred to update your "current" workspace daily from version control.
7. Divide any problem to sub-problems, then begin to solve the simplest one.
8. When use any new technology method/API, you should read its documentation and understand it firstly, don't take it from Google examples as it is.
9. write log statements before and after any interaction with outside component (DB, web service, Queue, File system, ... ).
** In testing:
1. Ask about character encoding.2. Check floating numbers (Add/multiply/divide) for multi numbers.
3. write every note u got while testing.
4. When changing any small part, you "should" test all related units again carefully --> if no time, Tell the manager to clear your responsibility
5. Define all "successful criterias" -Take care with the stored DB values-
6. Define test cases with defined inputs (files/cases) and the expected results before.
7. Take care with date ranges (in future/ too old)
** In Communication skills :
1. Don't give feedback for conversation/talking you don't understand well, however the number of times you asked the other to repeat to understand, it is better than wrong feedback.2. Don't give information you don't ensure from it. Don't be embarrassed to say "I don't know", it is better than to be embarrassed when the other discovers that you mis-leaded them.
3. Firstly, Think if the required info from you is related with another person, redirect the requester to him. Why do you carry the responsibility instead of him ?!
4. Fight for your opinion, and discuss with higher level managers to prove that (if the company policy allows that)
5. When discussing any problem, try to divide it to sub-problems and discuss each one separately.
6. Improve the conversation:
- Clarify your objective
- Structure the conversation (problem / solution, ...)
- Manage the conversation speed / slowness
- Find a common background
- Move beyond argument (story, example, explain, ...)
- Summarize often time (check what you understand with the other person)
- Use visuals (presentation, paper, body language, ...)
