It's UWAweek 48

help2002

This forum is provided to promote discussion amongst students enrolled in CITS2002 Systems Programming.
Please consider offering answers and suggestions to help other students! And if you fix a problem by following a suggestion here, it would be great if other interested students could see a short "Great, fixed it!"  followup message.

Displaying the 3 articles in this topic
Showing 3 of 919 articles.
Currently 5 other people reading this forum.


 UWA week 37 (2nd semester, week 7) ↓
SVG not supported

Login to reply

👍?
helpful
7:26pm Sat 17th Sep, ANONYMOUS

Hello, This isn't really a question that focuses on this unit but one that I still want to ask here. Every time I'm involved in a group/partner project for any of my CS units, I realized that all we end doing is work on the entire project individually and end up comparing our approaches at the end and choosing the one that looks "better". Obviously due to this I feel as if the whole process is very inefficient since there is not difference in working in a group and working by one's self when the above approach is taken. So I was wondering if anyone here has any good tips in coordinating with a partner(s) when working on a programming group project. Thanks!


SVG not supported

Login to reply

👍x1
helpful
11:05am Sun 18th Sep, Matthew C.

I didn't partner up for this project, my schedule wasn't suitable, but in the java unit my partner and I had a ~ similar level of knowledge. We both worked individually on our project, but 2 or 3 times each week we had a microsoft teams meeting where one of us shared a screen with both our current code side by side, and we went through each method verbally and explained to each other the reasons we had approached a method differently (in some cases we had basically the same approach, so it was just a matter of deciding who's looked neater/ more readable), in other cases after discussion it was usually clear which of us had come up with the superior solution. We definitely ended up with code superior to what either of us would have produced alone. In essence, I think the important aspects of working in a group are not leaving peer code review until the end, make it a continuous process. (you might be busy, but most people can spare an hour every couple of days with the ease and convenience of the uni's teams platform from wherever you have internet access and comfort). Both people should attempt to solve each part of the problem, if you try to split up the work neither of you will give anywhere near as useful feedback if you hadn't had to think deeply about a problem. I think it is important to work with someone of a similar level of knowledge (and motivation), you will not have a good time if there is a lack of mutual respect of each others ability and effort. And importantly don't have too much of an ego. Even if you are the slightly more experienced and better coder, I guarantee your partner will have done at least something in a better way than you did.


SVG not supported

Login to reply

👍?
helpful
4:52pm Sun 18th Sep, ANONYMOUS

Thanks for sharing the detailed account. I completely agree with making it a continuous process, and having mutual respect for ability and effort. If they have a better method for existing codebase which is cleaner to implement and read, don't be afraid to scrap some of yours. If they are not familiar with a concept or technology, do take time to teach them. I didn't have a partner for this project either, but had one for a group project in CITS3403 to build a full stack web app, with a database and all. ([Link][CITS3403]) Due to the scope of the project, our approach was much more encapsulated: We discussed at the high-level about what features and functions we needed, and the outputs we required to pass as parameters/arguments. Then we'd part ways and work on each feature independently. After a module was completed, we'd share the Git pull request and briefed the partner on what was achieved. Then it would be fitted into the main codebase like a jigsaw piece. Honestly, sometimes I'd have a faint understanding of their implementation, and I often didn't do more than skim over it for clarification, but it passed me the variables in the correct format to feed into another feature or function. For our encapsulated approach, that's all that mattered. I didn't have to have fine-grain knowledge of everything written. I didn't see or talk to the lad until our final presentation, but discussed our code and progress through Teams chat consistently, as it were a continuous process. We did score in the high 90s and walked away with more confidence, and a full stack project that could be used in our portfolios to boot. I'm not sure whether this approach would be as effective in this unit, nor for a group size larger than two, but hopefully it provides some insight for larger projects.

The University of Western Australia

Computer Science and Software Engineering

CRICOS Code: 00126G
Written by [email protected]
Powered by history
Feedback always welcome - it makes our software better!
Last modified  1:17AM Sep 14 2022
Privacy policy