Peer Review

Su Yuen sent out the peer reviews a few days ago, so I thought I'll write about it (and demonstrate how I'll read it.) It turned out to be quite funny, because I had different working styles in both of the assignments, and people dislike both of my working styles. For Assignment 1, I knew what was going on, so I didn't really ask questions or anything. For Assignment 3, I think I was a bit annoying, and Div doesn't look like he enjoys me asking him questions, so I gave up on asking Div questions. In case he's wondering why I stopped asking him questions, it's because I can tell that it's annoying him. 

The Good

- Strong coder. Quick learner. Tries hard to be useful
- Learnt new technologies really fast. Got work done. Detail oriented
- Invested time in learning a new stack, and was able to contribute to the project. Also contributed to the report-writing, which enabled others to focus on the dev a while longer
- Steady, patient, and good to have girl-talk with
- keeps everybody in check. Ensure all work is done. Very responsible
- Very dedicated, Fast in coding, Has good overall sense of the project

All the good points weren't edited out. I personally think I tried too hard to be useful in Assignment 3. The second half of point 3 feels like a euphemism for saying, "you didn't code much", but I'm happy that they think that I did something remotely useful. Point 4 is from Yujing because I am terrified of the idea of having 'girl-talk' with the rest of the people. The last point has terrible capitalisation. Umm, it feels like I'm criticising my peer reviewers (for the good points), but I'm really grateful for most of the compliments.

The Bad

- Code needs to be rewritten sometimes. Didn't contribute much to the code =(
- Improve on communication with teammates.
- I think we assumed different levels of independence in our work allocation
- Too calm??
- Don’t like others to help out, Priorities can get mixed up, Communication breaks down sometimes
- She did her allocated job really well.

Actually, I knew my code had to be rewritten. As to why someone would write code that they know would be rewritten anyway... there are various reasons. (I just didn't expect someone else to rewrite my code, to be honest.) But the bottom line is if I'm learning something new, the best way to learn it is to do it. So even if you know that it's not going to work, writing code for a new framework makes you a better coder still, since you gain familiarity with the framework. I am also equally =( about the fact that I didn't contribute to the code much. 

For the second point, I'm going to say "it takes two hands to clap." I get frustrated over this also, when I feel that people aren't communicating well with me, like they will go "Hmmm" or stay quiet. To make myself less frustrated, I end up playing a very silly game and that is to try and think of what the other person is trying to say/currently thinking of. I end up thinking, "chooooo~ chooooo~" for Jin Guan and "Baaa Baaaa~" for Div. (So if you don't want me to think weird thoughts about what you're thinking of, you better speak up. :P)

Third point is incredibly to-the-point about our problem with Assignment 3. I think for Assignment 1, I was more independent, but for Assignment 3, I was worried about implementation because it was all new to me. Any idiot can tell you of course I'm going to be more dependent for Assignment 3.

For the point about "too calm", it's because I can't panic. I "got lost" for an hour before but I was still calm throughout the entire thing. I see things drop and I'm like "oh, let it be."  I am incapable of panicking. My panic scale has only two discrete points, and that is "calm" and "full-blown panic attack". Seeing that the second is not remotely useful, I don't think being "too calm" is a problem. 

The fifth point about not liking people to help out has to be from Assignment 1. But if you're not having problems, why would you ask people to help? The only problem I had, I solved it really fast. And I do ask people for help - I asked Chun Teck about CodeIgniter, I asked Michael about node.js/BB etc. I think my priorities are correct, just whether you agree with them is another thing. I also like giving off certain impressions of myself, so whether you understand what my true priorities are, it's well, another thing. With regards to communication, as I said, the same goes for the other party. 

The last point Su Yuen edited out because it doesn't fit in. I figured that it's either that, or the person thought that I should do unallocated work well too. (Note to people who are writing peer reviews: write better please.)

Suggested Improvements

- Learn more frameworks in free time. Learn how to work with all kinds of people. Learn design work?
- I think this assignment highlighted a team dynamics problem that we had and we failed to resolve. I'm guilty of this too. We all are. I'm not sure how we could have done things differently but I know we didnt do everything right.
- Use an external, quieter keyboard while on a video conf? :)
- Suggested improvements: We need to have some sense of urgency at times!! Hahahaha
- Maybe chase the rest of us more so we can finish the work early
- Sometimes relax your hold a bit, let us do/learn some of the things. Consider your own health also

Yup, it's something that other people also ask me to do, so yes, I will go learn more frameworks. Actually, I'm getting tired of working with all kinds of people, and in my mental checklist of people to experiment working with, I have a lot of types of people checked. Besides, working with different people doesn't actually mean you'll end up learning how to work with them. With regards to design work, I'll do more design work if coders are more open-minded. Because coders are terribly powerful in this course (they decide the end-product), if they don't like something, they won't implement it. I guess I could always implement it myself, but I realised I can't think with my left and right brain at the same time. <-- Okay, I'll get better at this. (BTW, when I talk about design here, I mean less of the interface elements, and more of the general concept of the design of the application.)

The second point failed to make it to Su Yuen's initial list and I can see the problem - there's no constructive feedback. However, it's still a good point because I can see that the other party is also thinking about this problem. There are ways to resolve it, but I have a final solution that would definitely resolve it, and that is... don't work with people that you have no idea how to talk/work with. ^^ 

For the point about my noisy typing (btw, this didn't make it to the list also)... it's my birthday today; buy me a keyboard. kthxbye.

I'm not very capable of panicking and having a sense of urgency. This, I admit. But I don't hurry people because I think they are fully capable of hurrying themselves. (Can I link this to extrinsic and intrinsic motivation? If they are motivated, they will end up hurrying themselves anyway.) Also, I don't really like people to hurry me either, because it's not as if I'm the type to slack. If I'm not done with my work, maybe my work is hard and hurrying me isn't going to help. 

The last point is something along the lines of "you cannot satisfy everyone". I think it's because when people mention something, I like to direct them to appropriate places (e.g. "if you need to do this, just learn this part, don't need to learn the rest.") That is useful for people who need to do things fast. Anyway, it's not as if I can put up an embargo on learning. If I end up doing work, it might also be because I am genuinely interested/ have a good idea of how something should be done. In that case, why should I give it to someone else who might not have thought about it. (I concede that they might have other good ideas about it though.) It's terribly annoying if people give you work and you have no clue on how to do it, and when you do it, they end up lecturing you because you're not doing it based on their image of how it should be done. It also takes too much time to communicate how you want it to be done sometimes, and if you're nit-picky about it, the other person may get offended too. To conclude, if you want things done in a certain way, sometimes, it's better to do it yourself. But, I wasn't a superhero at all this time round, so it's actually not that bad. 

With regards to my own health, I don't think my Assignment 3 groupmates will write that, but interesting statistics here: I didn't really lose any weight over Assignment 1. Sleep, yes, but not weight. For Assignment 3, I lost 3 kg worrying about it, until I decided not to worry about it. 

Conclusion!

After reading the peer reviews, I don't know whether I'll change much. I can't actually make myself less independent and more dependent at the same time. People also seem to assume that I am not constantly improving myself on my communication skills, which I am, by the way. I'm not bull-headed enough to think that I don't need to change, but there's a limit on how you can change, and whether the change is logical. If I don't help people by directing them to resources, will they end up complaining that I am not a helpful person? If I don't do things that I actually have a good idea of doing, then it's likely that the product may be affected adversely also, e.g. no AI in CS3217, no actions and objects in the Facebook assignment. (Okay, not saying that my AI in CS3217 or the actions and objects were perfect.) I think I was actually really lax about both my assignments, and that it might have gone better if I had more control. But people don't like it, so I don't do it.

So at the end of the day, I'm going to defy the idea of peer reviews (i.e. to "improve" yourself), and stay myself mostly, besides the learning more frameworks and doing more design work part.