Learning takes place everywhere at any time (2011, World Innovation Summit for Education). We can be learning from anyone regardless of how experience they are. In this blog, I will be describing my learning points relating to the development of my team’s product: plan for unexpected events, research for better ways to code and avoid ‘stubbornness’ pitfall.
Plan for unexpected events
My team did not take midterm tests and assignments for other modules into consideration while planning for the project schedule. We also did not expect that team members are unable to open codes properly. These may seem trivial but when there are more issues, it contributes to a large amount of time. My team had to reduce the number of features to be implemented to compensate for the time lost. Hence we are implementing fewer features than expected.
From this, I learnt that we should allow some buffer time for such events in our schedule. Thus, it would be useful that I can plan more accurately for my future software development projects. Inability to do so may cause late submission of the project, reduced numbers of features, incomplete features or worse, incur cost.
Research for better ways to code
A problem can usually be solved by various ways. Out of these ways, there would be a best or a few better ways to solve it. Since we are inexperience, it is good to learn from others on how to code in a better way. We should research on how to ensure our codes are easy to understand, allow more features to be implemented easy and allow ease in linking up with other systems. There are programmers who would post online their experiences in coding. From this, we will have the knowledge of the existing problems of the programming language and potential problems. Thus we should also research on the specific section we are going to code to find a solution which has less potential problems.
To judge whether this is a better way to code, we can follow this priority order from high to low:
1. Code is easy to understand
2. Code has less potential problems
3. Code allows easy extension
4. Coding time required is least
5. Code is efficient
This priority order takes in consideration of the limited time for the project, merging of teammates’ codes is needed and there may be future developers working on these codes.
From this, I learnt that researching in advance reduces a great amount of time required to code. It also reduces the number of problems occurring during merging of teammates’ code.
Avoid ‘stubbornness’ pitfall
Many a times, programmers tend to fall into this pitfall of being very stubborn with their codes. This is because we are confident in our codes and we take pride in what we do. Being able to accept criticism is a crucial factor to help us improve. After receiving these criticisms, we should reflect on how this would help us and make necessary changes. We also need to take note that not all criticisms are useful thus we need to evaluate whether it is beneficial to us.
Nevertheless, many are unable to master this skill, including myself. Here are some ways to improve our taking of criticism:
1. Hold your emotions back and keep yourself calm
2. Keep quiet and do not defend
3. Imagine the criticism is directed at someone else
4. Analyse it in an objective way
These steps need to be repeated every time we get feedback until we are used to accepting criticisms (Mokhov, n.d).
This is very useful for my future projects as there will be criticism on my work. Being able to obtain this skill would allow me to enhance my work.
To conclude, we should be open and learn from anyone. When criticisms are given, we should listen and reflect on it. We should also do research before implementing our features to save implementation time. Also, it is impossible for us to predict the future; hence we need to ensure that our plan can withstand unexpected events.
References
Oleg Mokhov. (n.d). How to take criticism. Think Simple Now – a moment of clarity. Retrieved from http://thinksimplenow.com/happiness/criticism/
World Innovation Summit for Education. (2011, November 16). Learning Anytime, Anywhere: Lifelong learning is about people getting control of the learning that is happening in their communities. World Innovation Summit for Education. Retrieved from http://www.wise-qatar.org/content/learning-anytime-anywhere-lifelong-learning-about-people-getting-control-learning-happening-
I strongly agree that we should consider the other factors which do not have the direct relationship with the software development but can affect our work. When we are planning the schedule, we should consider these uncertain factors. Your buffer time suggestion is a good way to solve this problem. I want to add another strategy to overcome this. It is a "greedy" solution. We can list all the important features we have to implement in our software. Once we start the coding, we will fist accomplish these important features. If we still have not used up the buffer time, we can implement more bonus features to make our product more competitive with other group.
ReplyDeleteResearch a better way to code is also a good suggestion. But, I think it consumes time for us to research and learn many materials before we start the work. If the buffer time is not used up, we can spend time on the research.
Hi ZhenYang,
ReplyDeleteI strongly agree with your "greedy" solution as higher priority tasks are completed early. Our team has somewhat used this strategy however it is not very obvious.
By spending time to research, you can write better codes and reduce the number of possible problems occurring, thus reducing debugging time. Not spending much time to research means higher chance to have more problems and thus more time is used to debug codes. However, doing research does help us gain more knowledge which is definitely useful to us.
That is an interesting take on criticism, especially the step “keep quiet and do not defend”. I actually doubted that was the right thing to do and read more about it using the link you have provided. Now, I am convinced. There is no rush to defend our point of view, and we could always do it after we have analysed the criticism objectively.
ReplyDeleteThe article also got me thinking on how we should criticise. The following are some possible ways that I have thought of:
• Do not criticise face to face, use a medium such as email instead. This may sound like a cowardly thing to do but it actually allows the target of the criticism to have the time to think before responding.
• Do not criticise a person in front of others. That person may feel that you are humiliating him in public and would not take the criticism well.
• Use a gentle tone.
Although I feel that each member in our team is receptive to criticism, there is no harm in taking the steps you have suggested into practice. With our different backgrounds, there are a lot we can learn from each other and criticism can be a useful medium to do so.