1. The team engagement practices that were both used by my team and useful to the project were:
The most useful team engagement practices that were used by my team and useful to the project was having a dedicated discord server for all of our communications and resources. This helped keep the team engaged as we were easily able to split communcations for different subteams which kept us organized and on track. Another engagement practice that was extremely useful were meetings with our customer which allowed us reasonably gauge whether or not our current road map would satisfy them. We always had something new for the customer at these meetings and made great progress during these meetings.
Scheduled meetings (2x a week or so) + meetings specifically for subteams.
In-person conference room meetings specifically for major design decisions, using whiteboards and such to make presentations of ideas from different group members.
Beyond that we didn't use a lot of specifically targeted engagement practices - we tended to get along pretty well naturally.
One team engagement practice I think was very helpful is meeting in person instead of online. Personally, I feel like we worked more efficiently this way. Additionally, I think doing this made it more of an obligation to get our work done on time, as our meetings were mainly for discussing issues and planning, rather than implementation.
brought food and had small down time before a few of the longer sessions. utilized Trello in the beginning in order to organize tasks that need to be completed and separated the tasks into front end, back end, and api. utilized and wrote a group log where each team member was able to add thought, remarks, discussion, etc into one large document that had a log for each team meeting and briefing with Dr.Purtilo. almost every week we had a meeting with Dr. Purtilo in order to have discussions on the topic and get his input, this was also the time where our team would be able to ask any questions that we had before those meetings on Thursday
Consistent contact and communication between front end and back end. One of the key factors of our success was the fact that at least one member of both sub teams always knew what was happening on the other sub team. This made for a very seamless 'merging' of the work both sub teams had done. Without this communication, we could have had a very difficult time connecting all the different pieces, rendering everything we had done prior useless.
Another thing that assisted in team engagement was that all members of the group contributed to a high energy, hard working standard. This rubbed off on all members of the group. In addition, group members were comfortable enough and understanding enough such that when one member had other things going on, different team members stepped up.
Maintaining a Trello board and assigning tasks to team members, and consistent team meetings. For the Trello board, having a set timeline of tasks was good for keeping the team motivated. If tasks are not assigned to specific team members, nobody has the incentive to get them done. My team did a good job of managing this resource and partitioning work so that everybody was engaged and being used to their strengths. When it came to team meetings, my team was not always on top of this but our team meetings were often very productive. When people were becoming unengaged with the project, and meeting was good to make sure that everybody was on the same page. In my view, a lack of understanding for what to do next is the most common cause for a lack of team engagement, and our meetings were good resources for giving motivation behind our tasks and providing every team member with an important responsibility.
Twice a week in person team meetings after class in a nice Iribe conference room.
Trello board to keep tasks manageable and broken down. Discord for sending reminders, links to help with development, and for fast and easy communication. Group text chat for quick reminders about class and when to submit assignments. Holding group meetings after every class to work together on development and planning. Holding professor meetings once a week to discuss status of the project.
Regular and consistent meetings with the team in-person. Using communication tools like Groupme, zoom, and discord.
I found the following practices to be particularly effective: (1) Bi-weekly meetings -> This allowed us to stay on track as well as share buffers in between code. This regroup was also effective in coordination of tasks. (2) We had a group chat and discord server that were very effective in communication during devlopment (3) Having a document to track progress and quit phone calls to discuss buffers and problems within the code-base
having weekly meetings either in person or virtually to share our individual progress which was useful for keeping each other in check, marking progress and forming plans for how to move foward best in the future. Another useful practice was having social events not directly related to our project, like grabing food together as a team so we could get to know one another better and bond as a team. Finally, have set roles within the group and forming sub-teams within our larger team made it easier to collaborate and communicate with one another, so we could all work on seperate componenets.
Using a group message and discord. I found the peer mentor advice to be busy work and unfortunately sacrificed many points because I was working on high weighted assignments for other classes. The argument could be made that it does not take much time to do, but any advice I felt the need to share could be spoken in a much more direct, clear, and effiecient manner.
The team engagement practices that my team used and that were useful were twice-weekly meetings. They allowed us to actually know what was going on in the other sub-groups at the time.
helpful, they provided an alternative way for us to communicate what we really feel or don't really feel comfortable saying in person or online. The peer mentoring especially helped me reach out to several of my teammates who were caught up with other classes to hone in on the assignments for this class, and I think it helped moving forward as well to help me express to them that this class was important as well, motivating them to do better despite all the hardship which they did. The surveys I thought were not as useful as the peer mentoring or the other engagement tools, as many of the questions were kind of similar (I know what my team expects of me versus My team expects great work from me) and a lot of my group members ended up not even doing it because they didn't know it was released (which is their fault). Also, I thought the best friend question on the survey was not that helpful, as I don't really see how it can vary as much from beginning to end based on who you already know when the project is tasked. If they were helpful for the teacher rather than the students than my above points are moot.
We created a Discord server and placed people on specific subteams that had different channels. In this way we tried to give everyone ownership over a specific component of the project and increase accountability. We also had weekly/ bi-weekly development meetings where we set goals and made development plans. We had limited success with engagement in my opinion. Many people still waited to explicitly be told what to do instead of taking initiative to do things themselves.
Weekly meetings/individual updates; "Goof off" time to help build rapport; Peer mentoring
It is difficult to speak on what sort of engagement practices our team used. For the majority of the project, our team was only 4 members, 3 of which were already friends and share multiple classes. The one thing that I want to emphasize is this: don't be the person that is unavailable. The stress only snowballs when you start to dread checking your messages. Things go so much smoother for everyone when everyone is in frequent contact. This is one of the reasons our team worked so well together- we were always talking to each other.
We had a slack where we communicated regularly and notified people about upcoming work. We also used a Trello board and kept our documents in google drive.
Simply just having set meetings twice a week were enough. At the beginning of those meetings we would go around the group and everyone would report it in what they had accomplished since the last meeting. At the end of those meetings we would go around sharing what the next task we were going to accomplish was. I feel that those acts gave us enough of a strong sense of obligation as none of us didn't want to have nothing to say at the beginning or go back on our word when we said we would get a task done.
Team meetings in the Iribe conference centers. We needed those rooms to be able to make any progress. Having swipe access allowed us to continue working past official operating hours which was extremely helpful since our schedules during the day did not line up well or often enough. A second necessity was our Discord server that we used to relay team updates and conduct meetings. One last thing that helped the project progress and build trust between us was deciding to get food together and taking a break to talk about past courses, internships and future plans. This bonding enabled better communication and a more relaxed work environment where we knew each other well enough to not let niceties or awkwardness get in the way of project tasking or updates on certain areas of the application.
We set a schedule for tuesday and thursday right after class because we knew everyone was free then, so everyone showed up to every meeting. In our meetings, we started with an overview of what we wanted to get done, and then broke off into smaller groups to accomplish these tasks. We also kept a group log of all the meetings to make sure everyone remembered what happened.
meeting up in IRB during lengthy building sessions and having food to discuss the project, really enjoyed the access to the study rooms; long discord calls where we could also talk about what else was going on in our lives, in addition to speaking about the classify project; the above allowed us to relax about the project deadlines/work we had to do, while still being able to get to know the other members well and work on the project side-by-side.
We met twice a week in meetings, these helped us stay on track and on schedule. the logs were useful for condenscing our thoughts and tthinking about what we did.
Having twice weekly in-person meetings. This allowed for the best communication in our group so that we could clearly and successfully come to the best conclusions for our product.
I don't feel like my team really engaged outside of work related meetings and working sessions. I did enjoy my time in working sessions with specific members to get tasks finished. However our interactions only extended so far as seeing each other in class, in-person meetings in iribe, online meetings via Zoom or Discord, online working sessions with a few select people in call, or in-person working sessions at Iribe. Literally only just today did I play online videogames with Josue and that is completely after the project is all finished. As such the team engagement practices that I think worked best were the on-the-fly working sessions with some specific teammates. I feel like a lot was accomplished, we also set out clearly what needed doing and who was going to do what. The scheduled meetings we've had starting early on felt really tedious, overly long and drawn out. If we wanted to do an agile approach, I think we really need a scrum master to keep things clear and concise, the way we held meetings felt way too inefficient.
Getting food helped us bond. But i think the most important thing that helped us was providing the iribe swipe access. Our group was big and the swipe provided us with large rooms to actually meet. Additionally it really helped with our project since our rpi needed a screen to display and the tv's in iribe rooms helped everyone get a good view of our work.
COMMUNICATION! Communication is stressed in this class and it cannot be stressed enough. Make sure to communicate at every step of the way. Even if you feel like the detail is small. Making sure to stick to the requirements that were given and this will help to keep the group on track to giving a great and full product.
Team engagement consisted of creating a Team charter document where each member got to voice their expectations in the project. This gave us the opportunity to reflect and learn from the scrimmages which is how we came up and outlined group expectations. These expectations guided us in terms of engagement and facilitate how we would communicate with each other which is the most important measurement of engagement. Setting and outlining group meetings throughout the week allowed us to update one another about what we worked on and give us time to discuss how we would move forward and progress with future tasks.
Weekly meetings (multiple times a week), group chat
We had created a trello which was very helpful in diving and monitoring tasks so we could keep up with the work we had we also had team meetings twice a week and nine the smaller sub team meetings like every other day most of us had downloaded slack on our phones so we were not bind in messages and could respond in emergencies the peer reviews were very useful in helping us improve as individuals we also created a gitlab to make coding easier since we are 7 in a team. We needed to work in parallel we also divided our big teaming sub teams and assigned people roles we had like a scrum master for each responsibility like taking notes during meetings, updating the svn etc we had bough more vr headsets to make the coding faster and we had individually learn how to script using unity
2. If I could make ONE change to CMSC435 to make it a great class, it would be:
Amid the miriad of other metrics that were used to make the teams at the beginning of the semester, a When2Meet or other meeting time survey would have been paramount in making more effective projects. I understand that our previous course work, internship experience, and personality traits when working in group settings are import things to measure. However, when we get down to brass tacks this is still one of each group members many obligations inside and outside of school; it became increasingly easy to see which groups would be able to take full advantage of the software development processes we discussed in class and which groups would fall into the apocolyptic hackathon category. Using VLearnVR as an example, I don't believe most of their team had any VR or game development experience and they still turned in what seemed to be an exceptional project. What I am deducing is that it is not so much as important to shove all of the students in the Computer Vision class together on a project that we would have assumed to be interested in and directly apply what we are learning in our other classes. We all have the ability to learn new technologies and make something cool with them. What is most important, is that we would all be able to reliably meet togehter on a regular basis. Our team had a lot of trouble with this even after knowing we were all honest with each other as to whether we actually couldn't meet or didn't feel like it. It would have been nice to know that my team is mostly free when I am instead of getting stuck in a group where everyone can meet at 11PM.
A lecture structure that makes it a little easier for people like me who aren't great at memorizing things or taking quick notes. This is probably just a problem with my attention span, but I found myself often missing details in lectures and being unable to recover later. After all, you don't post any slides or outlines. However, you still expect fairly specific quiz answers.
Some solutions to this would be to: (a) Post slides (b) Post an outline of the slides to help guide independent study (without giving away answers) (c) Provide a canonical support text (with recommended readings) (d) Broaden quiz questions so that no particular phrasing needs to be memorized - have them be general enough that reading ANY good support text cover-to-cover would be enough to answer them
I get that you want this to serve as a lecture engagement check, but I can't help but think there must be a better way to do that - one that offers options for students who want to study more on their own, yet still focus in on the things you're teaching and testing for in particular rather than following a separate, sometimes loosely related support text. The focus on maintaining engagement here might ultimately be harmful to learning outcomes. I think it would be better to trust students to engage if they want to and offer them the resources to do so, rather than driving engagement through fear of missing an important detail.
I think it would be great if there were more flexibility in project tasking. For example, after meeting with product owners, students may be able to switch to another project if they wanted to. This way, it allows students to work on things that they are more interested in.
One change that I could suggest is to potentially allow for students to pick their teams for the semester projects. At least to some extent and it doesn't need to be like picking their entire team. Instead I'm think if someone wants to be paired with one or two people then it would be good. I know that in my case it is very special as I was able to get with 3 other people I knew, but after the semester was over, I could not have been more thankful than now to have been in such an amazing group.
A wider variety of projects. I felt that our project was one of the less exciting concepts and this occasionally impeded my ability to get more into the project. Maybe list a number of potential projects on day one or two, and allow students to vote on their top 6/7/8 so that all students have at least some say in the project space.
More individual check-ins throughout the semester to ensure that each team is on track to succeed. This could be in the form of small assignments or just informal required check-ins. If this is not ideal, frequent engagement surveys could be used, with action taken early on for teams that are not meeting that standards for high engagement.
More small group disucussions in class and less lecture. I feel as a student it is easier to engage with other students when facing them and also not talking to the entire room.
I think another mentor day would be really helpful, it might be too much during development mode, but I think if we could showcase what we've gotten done or asking for help from an actual dev for those roadblocks that we have hit, it would be very helpful. I like the idea of teaming up with another class, perhaps a class in the project management minor of the Smith Business School, since (at least for construction PM in Engineering school), we do not get much hands-on experience with managing a team.
I will reduce the ambiguity of the class. There were so much uncertainties of due dates and true requirements. I know that the purpose of the class is for us to find the information. But most of the time I personally don't know what I should ask to get the information I need. Also if we could have a link that has the slides that are shared in the class would be really great.
Try and follow along a book so that one can refer to something more material before, during and after course.
to have a short description of what we will be covering prior to the class so we can have time to review course material and prepare for the lecture earlier, especially on days where we may be given team time so we can prepare some more materials beforehand and make better use of our time.
Allow more say into what project we are working on. I had little interest in my project, which was unfortunate for a senior year capstone class.
I think I would work to make the documents provided, like the project timeline, more concise and less confusing about what deliverables were needed for each big milestone. Additionally, I think that re-designing the order of lectures would be better, I felt like I would've liked to know some best practices on testing and design before the build phase even began.
Give the students a bit more input into what project they want to do. For example, before releasing the project tasking, students being able to choose their top 3 choices and accumulating the results in order to figure out the teams may be more cohesive and accomodating to the student, even though this class is meant to train and teach you in the unknown of computer science and software engineering, a bit more substantial knowledge into the projects would have helped a little. Since the project is basically the bulk of the grade and the most important assignment with regards to the course, having some preliminary information a bit before project tasking would have been substantial to help prepare for what was to come. However, I can see how this can be an issue because it may be hard to calculate when making groups and one project may be favored more or disliked more than others which may cause imbalance.
I wish the lectures had focused more on application rather than theory. It would have been nice to see example walkthroughs of how a specific project went from problem statement to definition through implementation. Specifically, being able to see software architectures and why certain decisions were made. I feel like this might have helped us apply concepts in our own projects if we had seen how they were applied in a sample problem.
Uploading class slides so that students can refer to them when establishing how to run their teams.
Having some sort of ranking system or input to what project you are assigned to- it is hard to be super passionate or productive on a proejct whose subject is not very interesting to you.
I would include some specifics about management systems like agile, scrum, and include the design principles earlier in the semester if possible
I would want there to be a bit more transparency on the strategies to succeed. Not just when working in the industry, but specifically in the class. I suppose I would have liked more examples earlier in the semester of the practices excersized by successful teams in the past. I just remember having a whiplash moment when we walked into the CDR and Jim was currently in the midst of a conversation with some other professor that was already there, and he said something along the lines of, "Yeah, all of the groups, with the exception of this one, tend to meet privately with me at least once a week". I just remember suddenly thinking, "They do what now?". Perhaps this was truly just our team at fault, and that was something that we should have just intuited what with the whole "concierge" discussion early in the semester. Regardless, I would have liked the idea of regular meetings with Jim, just for the sake of having them, to have been explicitely placed in my mind at somepoint.
Providing coding best practices and exercises that help train us with what good programming looks like. I think going into this class I felt that I would learn some of the key elements that would prepare me well to build code structures that would be accepted on a project or team I work with in the future. While I certainly understand that the learning process and working on these things ourselves will have a good impact on our ability to adapt and grow, I think having that base could have been helpful as many of us are entering the software engineering profession very soon after taking this course.
I feel like the beginning of the class was a little slow. While I still retained the same group members for the first 3 sprints and the main project, I could see how for other groups it may be a waste of time to have one group for the sprints, then a brand new group for the main project. It may be better for the groups if they stay the same for the sprints and main priject, so they don't need to reintroduce themselves to a new group and figure out everyones strengths and weaknesses all over again.
Concise delivery of content within the lectures. Not that it was delivered badly, but some of it felt a bit elongated at times. I remember doing the discussion regarding the (Etihad?) plane that didn't take off properly due to not following proper software engineering guidelines, and while I thought it was definitely an interesting topic I also felt that it was also pretty exhausting.
Put a bit more of an emphasis on using some sort of tool to catalogue who's working on what. that would have really helped us.
I think it is a great class to start with, but if I had to add something I think more in-class activities would improve the overall experience as a student. I think that the slides along with some in class discussions (maybe similar to the ethics self-driving car one) would prompt more class participation.
I feel like the only shortcomings of this class were because of how my group worked for the project. I don't think there are really that many shortcomings to the class per se. However, this class did feel quite stressful with the work and over time I feel like I accepted the fact that I probably won't get an A or something along those lines. I wish I had taken more notes in class or maybe just followed directions more closely. I would also to have liked to know when we would have in-class quizzes, though, to be fair, there were only like 2 or 3 of those and they were fairly projected. Perhaps the change I would've liked to make is more mandatory meetings with you, our soul guide. For our team, Schedplus, specifically we could've used the help to guide us from the start. More structure in the beginning would've saved us a lot of points and trouble when the time came for the CDR. After finishing up other questions here, I thought about the scrimmages. I feel like the scrimmages were unnecessary. It didn't feel like they carried a spectacular in the grand scheme of this class and I feel like that time could be better spent creating teams and letting people get situated with semester projects.
Our team had some issues properly scheduling team meetings because of the team size. If when teams are being formed, schedules were taken into account and so all teams would be guaranteed to have a time everyone could meet that would be great.
To have check-ins with the professor more often. I think that each team should schedule a time to meet with the professor at least every week or so but also personal one-on-one time. I think that each student should sit down with the professor maybe 3 times over the semester to talk about anything they want to academically, professionally, career-wise, etc. [Added: The instructor agrees and wonders more students take him up on the offer!]
To make CMSC435 a great class I think it would be great if there were small assignments outside of class where we have mandatory meetings with an instructor to keep them up to date. Yes this is our responsibility but I believe students will be more engaged if this was graded for small points and would help most team stay on track for development.
Recorded lectures but that might actually lower engagement, so maybe not
I would say creating smaller groups so the project work can be divided evenly and people do not seem left behind.
3. The one thing that most gets in the way of me doing my best work in CS (CE) here at UM is:
The one thing that most gets in the way of me doing my best work in CS here at UMD is undoubetdly myself. I think this is true for most college students and hardly needs additional explanation. At the end of the day only I have control of how successful I am in doing my work.
Imagine that I have 10 units of effort available per semester. In order to do my best work in a class, I need to use 3 units of effort.
However, only 2 units of effort are required to get an A, since it's usually possible to cut corners in a way that may be spiritually disappointing (since you're not really doing your best work), but will still meet all the checkboxed requirements for the class in question.
Now consider this: I usually have 5 classes a semester. Because of this, doing my best work in a class not only offers no advantage, but is also actively disadvantageous. Applying extra effort in one class means I go from an A... to an A. But it brings another class from an A to a B. Bad trade. All I get is the satisfaction of actually doing good work for once.
One solution for this is to make grading harsher until those extra points of effort actually return a reward. I think that would be too high a standard, though. People would agonize over pursuing more and more perfect metrics. I can't imagine the anxiety involved... and anyway, since it would simply be yet another inaccurate proxy for actual "good work", the winners would be people who learned how to game the new system more efficiently. Implementing quantitative rubrics will always advantage people that optimize to the rubric, rather than people who optimize for ineffable qualitative goodness itself.
In the real world, "good work" is all that matters. It just so happens that grades have a very hard time measuring what is good work and what is not, even though the difference is intuitively obvious if you just look at it and think for a moment. I think many students, after 20+ years of chasing grades, have actually lost to tell the difference, though. They genuinely think that shit work that hits every checkbox on a rubric must be good, even if the badness of it stares them in the face. Of course, if all you care about is getting good grades, and the necessity of doing so is drilled into your head, then maybe there is no difference between rubric-optimized work and good work. I happen to not think that grades are good ends in and of themselves, though. I'm just beholden to them for the time being.
Do I have solutions to this? No, not really. It's kind of a tough problem. Maybe you have some ideas. Maybe some total overhaul of pedagogy is needed.
I think the curriculum focuses a lot on backend development, computer systems, and algorithms. However, in my experience, I had very limited experience with full stack development in my classes. Therefore, it was a lot harder to create a full stack project where we had to have working knowledge of front end technologies.
I believe that thing that gets in the way most is due to the lack of knowledge on software and a type of inflexibility when coding. I find this comes up a lot where I will try to come up with a solution to a problem, I typically go for the first solution or at least try to make it work without realizing / researching if there is a better, simplier approach that I just don't know about or didn't think about.
Lack of project clarity. At a certain point in the major, we stopped receiving well detailed and documented project write ups. This would be fine, except for the fact that our project submissions typically undergo very specific testing guidelines, with the inclusion of secret tests. Without a well documented spec, it is exceedingly difficult for students to gauge what is required for each project. While I am at it - secret tests are ridiculous. Especially since the secret tests are not revealed even after the project is submitted.
Unclear directions or communication when it comes to assignments. It is important for engineers to be given a reasonable degree of freedom when it comes to creating a project, but the goals and wants of my professors have often been ambiguous even when there was a specific outcome that was desired. Better communication would make it much more likely that my projects are a success.
Nothing really. I'm pretty satisfied with the work I do.
I find it difficult to connect to professors on a more personal level because of the large class sizes and lack of small discussion sections as we get into higher level CS courses.
Too much work in every class, I can't handle more than 2 classes at UMD, I only do well during the minimesters.
I tend to push things to the last minute sometimes which doesn't allow me to show the best of my work. Having a plan before starting a project or any assignment for that matter is crucial. This course showed the importance of planning as having jotted down the deliverables early on.
working alone on hard individual CS projects and not being able to get support from TAs or instructors because online office hours are so filled up, and each student can only get a few minutes of help if they make it through the queue.
Having enough time when taking other demanding upper level classes. I wish that I could have spent more time in certain classes, but there is only so much time in a day.
I think that the one thing that gets in the way of me doing my best work in CE/CS is probably hoops that some advisors and departmental polices put in place. For example, I am a CE and we are limited to not only the number of classes in CS we can take but both CE and CS upper levels are generally scheduled on the same day/times so I can't actually take classes that I want, which is the whole point of electives.
how much of classtime learning computer science material ends up leading me to having to just do self-learning. This is not the case for every class, but for at least three upper level classes I have taken here that were CMSC classes, I have spent the classtime not really learning much that was relevant to the projects, tests, or assignments. This in turn causes me to expend time outside of class to learn the material on my own, which is enriching but could better spent by applying the knowledge I would have learned in class. Additionally, in some cases there seems to be a disconnect between content taught in class and what's assigned for the coding project, which leads to a lot of confusion and rapid Googling. Textbooks are only so helpful in this case, and online videos do help a lot, but a classtime in a college course should be used to its maximum which is having a good amount of students show up ready to learn the content, which is not the case in some classes.
Large class sizes. Although I really loved University of Maryland as a whole. I would have appreciated more discussion based courses in CS and closer mentorship by my professors. During my time here at UMD I have gotten to know only a handful of my professors. Most professors I have never personally spoken to.
Certain GenEd requirements that I must take that isn't all too relevant to CS taking too much time -- cutting into time that should be devoted to my CS classes.
One thing that got in the way of me doing my best work was doing homework purely out of necessity. Grinding out homework and projects until you have a minimal solution and then handing it in immediately detracts from your ability to actually learn. I did a really good job with this my sophomore and junior year- I felt like I was really intuitively understanding things, but then senior year happened and brought with it the pandemic that we're all too familiar with- senioritis. I feel as though my tendency to just knock my homework and projects out as quick as I could robbed me of some opportunity to learn more.
Not having the overall structuring of code and projects be explicitly taught in many classes except 435. Concepts such as environment and dependency management as well as build systems (like Maven and gradle for java) were not taught.
A sense of incompetence. When I'm put in a group with bunch very talented engineers, I have a tendency to feel outclassed. It tends to make me lose confidence in the quality of my work and kills my drive to take on large tasks and learn new technologies. I'm happy to say that didn't happen in the case of this course, and that I felt like a valuable member for most of the duration of the project. That being said, there were moments such as when a small group of team members where hammering away at the queue portion of Sched+ to get in a functioning state, that it felt as though all I could do was take a step back and stay out of their way. It's this bad habit of mine which tends to make me prefer working along whenever I can.
My work load in general got in the way of me exploring other interesting areas of the CS field and really dive into the courses I was excited to take. I think if I had a lower workload, my performance would increase and I would also be able to contribute more to the projects I was working on and have a more in depth understanding of the material. Managing 5 courses can be hard if you want to really throw yourself into a few of them in terms of doing personal research or application examples.
The biggest thing for me throughout my college career was probably just juggling the time that a lot of CS projects took up. This semester I took CMSC412 and CMSC435 and it was a lot to try an set asside time for both classes, as well as the other two classes I was taking, so I did not feel like I was preforming at my best in all my classes.
My interests shifted, early on I was really eager to be a CE but now I'm leaning towards the CS side, which is why I focused more on my CS rather than the EE classes. I even started to take EE classes that were based off of CS classes (ENEE436 = CMSC422, ENEE447 = CMSC412) I also became very interested in mobile app development over this past semester - after installing a new app (Termux) on my android device, which installed a terminal on my phone. I became very interested in the capabilities of the device once I got it, trying to run machine learning projects and other intensive programs to see how well my phone is able to handle it. Because of interests like these, I may even temporarily lose interest in my own classes sometimes, and work on my own personal projects instead. I also am a part-time violin player, a very serious hobby of mine, and rigorous practice is something I like to keep up during the semester. This takes away from my time to do my best on the CS projects.
The classes and course load is too light. We only have to take 2 classes a semester every semester except for the last, where we only need one. This is crazy considering that engineers often have their entire semester filled out with all engineering courses. The courses need to either be much more rigerous or more plentiful.
The lack of communication between some of the professors/department and students about courses and what is expected. There are some professors that are very unclear with their wants and needs of a certain project and then judge and grade the students harshly based on what they have done based on the holes they filled in. In my experience, the department is also very bad at communicating what is necessary for different things such as advising and registering for classes.
It has to be other courses. CS/CE is one of those fields that's typically relatively well documented, so anyone can learn anything on there own whenever they want. I could simply say the one thing that gets in the way of me doing my best work in CS is myself due to how I manage time across my other coursework. I suppose it's a lack of self-discipline. I want to complete all my work, but I leave this class work for a bit later because it's a long project and even if I finish a bit, there will be more to do later. In addition, I like to play games and procrastinate. In general coursework, it is a lack of understanding what is wanted that really screws me. Once there are unclear instructions (not vague or open-ended ones), it becomes troubling to me because I must contact whoever is in charge to get things clarified and wait upon their response.
Other classes and schedules. Trying to balance workload and attend meetings were a challenge. For this class, I had to skip a couple meetings because of exams the very next day.
The many classes I have to take all at once. I want to dedicate myself to each class to fully understand, be involved and learn but with many assignments to complete in each class, it is hard to fully engage with the material in every class. If I had the time, I would take these classes individually or two at a time to make sure that I would learn as much as I could especially in the classes that I find very interesting.
Extra-curricular activities such as being a part of HACK4Impact and practicing music. I'm super interested in music. I play guitar, piano, and sing, and spend a lot of the day practicing which interferes with my learning in some ways.
Myself, or more specifically, poor time management skills
The workload. I think most professor do not consider that we have other classes so they tend to over work us with the homework and projects.
4. The obstacles that prevent me from knowing what is expected of me in my degree program are:
I don't think there are many obstacles that prevent me from knowing what is expected of me in my degree program. I think I am self-aware enough to both know what is expected of me, but at the same time understand that I don't follow what is expected of me 100% of the time.
I actually think I know what is expected of me pretty well. It varies from professor to professor, but you can usually get a good sense of it from the get-go. Some of them want legitimately good work, others want respect, others just want to fulfill their teaching obligations and get back to research.
If you mean "what kind of overall skills does my degree program seek to instill", well, I haven't really seen them written out anywhere. Maybe a simple list would be a good start. You could cross- reference them with the required classes to really map out the logic of it. It'd be illuminating.
I don't necessarily think there are any specific obstacles. However, I do think that we are not given too much guidance on which degree track to take (either general, data science, cybersecurity, or machine learning).
I believe that for the most part, I know what is expected of me. To me I think it is just coding projects but maybe when teachers do not explain something in class enough or miss out on explaining a task assigned to us, then I can get lost and frustrated because I do not understand the task that I am supposed to complete.
The overload of assignments and due dates. I know it is a bit of a necessary evil, but with the sheer volume of work, it is easy to get lost in it. It becomes difficult to see the course work as anything other than a checklist of assignments, which prevents students like me from being able to get the most out of their work. It feels a bit like a machine, where we just churn out assignments one after the other.
Similar to my answer above, the University of Maryland has not done a good job of communicating all of my requirements to me. I have often gone through my courses without knowing what is fully expected of me by the university. As I reach graduation, I feel that UMD has given me a good education but has often put in the position of rushing to find information that should have been provided to me. For a specific example, I have found myself lost this semester preparing for graduation, as the university has done a poor job of communicating everything I need to do to ensure I graduate. This includes registering for graduation, purchasing regalia, getting tickets, and filling out certain forms.
No obstacles I can think of. Would be nice if the degree pushed joining clubs and extracurricular student run initiatives as requirements though.
Poor advising, lack of mentorship from alumni who have already graduated, from faculty also.
Having an advisor that don't clearly explain what you need to do and your current state in your degree.
Effective communication by my professors in terms of the ultimate goal of a particular course. Having to learn the material developmentally (like a story that builds up) makes it far more fun and engaging. The professors of Level 1 classes should sync their class material with Level 2 professors and vice versa to continue the same momentum and form of teaching.
having to take specific courses from each category of the CS degree program so that we are limited on how many courses we may take from a specific category or field that interests us.
Having to out of my way to read the blog to know expectations. We meet in class twice a week, and this is the perfect opportunity to clarify expectations from me. Even ELMS would be better because it is set up with notifications about action items.
I am a CE and the obstacles that were generally weed out classes and scheduling conflicts. I think that a lot of CE/CS classes really put the stress in the intro classes and then a lot of the skills don't seem to be carried on with students to the upper level courses where they matter. Additionally, as a CE who wants to focus on Software Engineering as a career path, there isn't always a lot of flexiblity with amount of CS and CE courses I can take, so should software engineers be in CE?
teachers who do not communicate well with the rest of the team. CMSC435 was a completely different experience from many of my other higher level computer science classes because the professor was willing to take time out of his day to meet with students and teams in order to provide them with more guidance in order to be successful in the class. Teachers who give out tough and time consuming projects just to not be responsive on piazza when students have questions relating to implementation are one factor that prevent me from knowing what is expected of me in my degree program. Granted however, many of the teachers, especially higher level cmsc teachers, are extremely busy and cannot afford to answer every single piazza post that comes to them. However, taking the time to answer questions in general at least within a day or give some form of a response doesn't seem to ludicrous. One other obstacle that prevented me from knowing what is expected of me relating to the computer science degree program would be not using elms as much. This is more of a personal thing because I like having one centralized school platform rather than flipping through three or four different websites to see assignments or when things are scheduled.
I honestly feel as though I know what is expected from me within my degree program. In my opinion it isn't the role of the degree program to hold hands with their students. It is extremely important for students to take matters into their own hands, take initiative and scope out their own futures. One thing I appreciated about this class is that it came closer to the real world than many of the other CS classes I took. While you were fully available to your students you also didn't force requirements down our throats. Instead you waited for us to scope out the problems ourselves and ask questions where clarification is needed. In my experience with industry this is exactly what is expected of software engineers and I feel like it is the duty of the CS program to prepare its students to face this reality.
Lack of teacher-student interaction; Insufficient amount of meetings with advisor; Unclear/incohesive documentation with 4-year plan and actual requirements
When it came time to register for classes for my last semester of CE, I found that many of the classes I wanted to register for would not fit in my schedule, or had prerequisites that I had not fulfilled. This was true for every EE capstone being offered. This was the case for many CE students. The class prerequisites should be reworked, or should be made very clear to students early in their academic career so that they can more effectively plan their schedules. Otherwise, students can be forced into classes that they have little interest in, out of necessity. It is very hard to succeed at things that do not interest you. This was the mindset I had going into this class, and luckily it was quite an enjoyable class in the end. Likely, this would not have been a problem if I was more open-minded.
In addition, CMSC412. The workload for that class is immense, and I feel as though it is not a good idea to take that class and this class concurrently. The last semester of college was a breeze for a lot of people, this was certainly not the case for me.
There seem to be several different disciplines mixed into one. Software engineering which focuses on how the system is built from the ground up, and computer science theory, which is more about algorithmic design. There is little discussion about how to practically unite the two, which is relevant for postgrad in both industry and research.
There aren't enough courses like this one that actually try and connect what were doing in the course to what we would be doing in a professional setting. This is certaintly the first course I've taken that didn't just feel like I was learning some new tech then being sent out the door. There aren't enough courses that are centered entirely around career practices.
I think the rigidness of our C.E. curriculum has caused a few issues for me in terms giving me the freedom to take courses I am actually interested in and may use in my job. Since as a C.E, I need to take the core requirements of two degrees, there unfortunately isn't enough room for me to go into courses/electives that I like. I think out of all my four years, I've only taken three courses that I genuinely chose to take and even one of those was restricted to being within the EE dept. While my desire to focus my degree towards CS may be the cause of my specific frustrations, in general students in the C.E department have very limited choice in how their degree would be structured. I've leaned more towards CS, but someone leaning towards EE would face the same issue where they would not be able take EE courses they might have been interested in.
I feel that there were several required courses for computer engineering whose concepts were not applied in future classes so it felt like they were a waste of time. The signals courses come to mind for me where three classes I took do not translate at all into math or processes I will use in my job. While I understand that C.E. is more open ended to accommodate many interests, I feel like being able to better tailor your degree from the start can give you a better outcome in the end where you have filled you degree with coursework you will rely on in the future. A more comprehensive track system could be installed that allows first years to be able to see where they might land with different defined trajectories. Time is the one of the scarcest resources and being able to see where your degree will land you can help save you that time, and also set up a balanced structure of knowing what your degree program expects from you and what you expect from your degree program in terms of where you will be able to work or go (for grad school) after your undergraduate degree.
Other than CMSC435 and ENEE200 (the ethics course), I didnt feel like any of my classes actually prepared me for what working a job in Computer Science/Engineering would be like. Having solo projects be the main component of each CS class when collaboration is such a big part of the computer science field is a bad way to structure classes in my opinion, which is why I was happy that CMSC435 was a group project.
There's no set upper level concentration for CE, which prevented me from really knowing which classes I should be focusing on in order to get the job I desire. While the new CE degree design has fixed that by allowing for more electives, the problem still applies to me as I am on the old curriculum. Because of this, I don't really know what to expect myself to be able to excel in once my degree is over. Therefore, I ended up committing to graduate school to pursue an MSCS at Columbia University this coming fall semester in order to take more classes in AI/ML.
Lack of consistent advisors. I had my advisor switch twice during my time here at umd, it was pretty confusing at points.
The fact that the trained CS advisors don't do much advising. Instead they just go off of reviews of classes and just tell you what classes are hard rather than what classes could support your interests.
Once again, I'd attribute this to myself. TO figure out what is expected of you, you just have to be proactive and seek work or just ask someone else what you can do. I feel like some teammates only did this when it was convenient for them (during meetings) which is why we were quite behind at the CDR.
I think myself. For my degree programs, I've been just following the track blindly and haven't really looked at it in depth. when selecting classes for cs, ive kinda just been choosing classes that fall into my aerospace schedule.
Some expectation of teachers on some assignments. Some assignments are not fully clear and the student needs to go to office hours to understand. I think that if some professors were more clear on exactly what they want in assignments and exams, that many students including myself would improve.
The obstacles are lack of planning and over-commitment with other activities, organization, and daily routines. Having multiple platforms can be difficult to catch up on assignment because I use ELMS and primary source of seeing when assignments are due and given some courses like this have their own website, I often forget to check it daily to see the assignment due dates, and tend to be forgetful at times.
Not reading the syllabus
The advisors are not really as helpful. A lot of information is not given to newly admitted CS students as they come in.
5. The best way to predict when students will be compatible members of a successful team is:
Communication. If the other students on my team can't effectively communicate about when they will be able to meet or about even smaller things, then it is definitely harder to trust their communication and work regarding more important design and implementation details for the project we are working on. If they are open to communicating early and deposit more than they withdraw into the bank of good will then I know that I will be a part of a successful team; as long as I do the same. And of course this is much easier when everyone on the team is doing it and engaged.
Tongue-in-cheek: How much they like to complain about the class in question.
More seriously: Overall attitude towards the project in question, and how much work they want to put into it. Above I talked about the difference between seeking ineffable quality in one's work, and looking to satisfy a rubric. Some people confuse the two.
I'm not an overly idealistic person, and I think it's very possible to get along with a group on the basis that you all just want to put in a minimum of effort to meet the rubric. Some of my favorite groups, with very smart people involved, have taken this attitude! If a class doesn't deserve great effort, it's wasteful to apply it. Not everyone teacher gets to have such a limited resource just because they asked for it, especially when they're not doing their best work for you in return.
That said, the more satisfying groups are ones where everyone wants to do great work, and are in an environment that encourages it. This is extremely rare. Usually it doesn't happen in a class, because it requires everyone to have legitimate inherent passion for the end goal - a rarity when a project is assigned rather than chosen. I think our 435 project for this semester was pretty close to this - for a class project. Where I really see it, though, is in bands, or artist's groups. There, there's no one judging you based on a rubric - all that matters is if its cool or if it sucks! You wouldn't even join if you didn't care about that sort of thing.
A mismatch in expectations on this leads to strife. One person will find the other lazy and unmotivated, and the other will find the first overly demanding and unrealistic. The groups I've been in where this is a problem inevitably schism into... preps and goths, basically? People that are bright-eyed believers in the project, and those that are annoyed by the others and just want to go home. Peer reviews are inevitably a bloodbath. This always sucks.
The one theme of this report: Grades and good-faith engagement don't mix! Too bad there's no other solution...
Whether they get along outside the classroom. I think a successful team will have similar interests and can be friends with each other.
I believe the best way to predict this is through first impressions. When I work in a group I first want to try and get to know everyone in the group and if they are enthusiastic or at least have a slight upward tone when talking (some people can be shy), then I feel that they may be a compatible member for a successful team. On the other hand, if that person does a very quick introduction and then just sits back in their chair, arms crossed, I feel that this person would not blend in well with the group and will not be a compatible member of a successful team.
Engagement and when all members know what's expected of them. Engagement is pretty clear - engaged students will be committed to the project and this can often have a contagious effect. When one student displays that they care, other students often will feel a need to step it up to match their level of engagement. In addition, when students understand each other's expectations, they can go forward with a clear plan, and this clarity will enable them to step up when necessary.
Giving them an initial assignment, split into several parts due at different times, and measuring the level of engagement. Truly unengaged team members will become clear at the beginning, and team members that tend to slack as things progress will become clear as more assignments are completed. In my view, there are students that are always engaged, never engaged, and engaged halfway through. It is important to identify these problems before it becomes too late. In addition, early social engagements with the team are a good way to determine compatability. Casual social meetings and meals together are good ways to accomplish this.
If they have been compatible in a successful team before.
If team members have an "all-hands-on-deck" attitude from the get-go. Good consistent communication is also key so no single member is "AWOL."
I think the best way was what was done in class. Using Gallup to determine our strengths and matching up base on strength and experience and the projects match up with our experience.
I believe that individuals that are responsive, active and communicative are compatible as they are contribution is more effective & visible. I believe that the 3 parameters of the Peer Mentoring System are also great parameters to predict compatible members for a successful team. All the team members I rated high through the course on all the three parameters were great team members to have.
to assess whether the time and contributions they put into the project is equal or close to equal, and how well their personalities complement one another, so that there aren't too many disputes or arguments that come up.
A combination of interest in the topic, team chemistry, and at least some prior experience in the problem space by at least one member of the team.
I honestly don't know the right answer to this. At the beginning of this project I thought my team were superstars, some coming in with great internship experience. At the very least I thought we were at the same level when it came to learning a new language, since we had to go through CMSC330. As the semester progressed, team members just started being unresponsive, unwilling to take work on, unwilling to communicate when they had issues, or communicating false measurements of completeness. In short I don't think there is a good way of knowing who is compatiable based off of just gallup polls or what their resume says. I think the best way to predict is to see what their goals are for the project and see if they align with your own and with the rest of the team.
during the initial phase when project tasking, team assginments, and introductory design plans are made. During this time, it is easy to figure out who is motivated, eager to learn and overall willing to put in work to succeed, along with the flipside of figuring out who doesn't care as much or doesn't make the effort to communicate with the team. After working on the project over the semester, communication turned out to be a key factor in order to create activity and move forward with our ideas, plans, and designs. Being communicative and responsive to team members, especially early on, can show them that you are a compatible member and if they reflect your motiviation, then the team can be successful.
I found that many of my teammates were hesitant to learn wholly new technologies which hindered their ability to contribute in areas where they were uncomfortable or unknowledgable. For this reason, I would say students are most compatible to success when they each have prior experience in the technical area surrounding the project. If students have no prior software project experience they will likely not be able to contribute as much.
Observing the way they communicate and go about problem-solving. Besides certain hard skills that are needed to complete the team's objective(s), the way one communicates to one another shows a great deal on if they're compatible for joining a successful team or not.
I think that the best way to predict when students will be compatible members of a team is through trial runs. I think this is the goal of the scrimmages that took place earlier on in the course; I was a scrimmage partner with 2 of the people in my group and found that we were all compatible team members. Maybe if I'm creating a team to work on a software project in the future, I'll do trial runs with the team members on little fun projects to see how compatible we are.
Whether they feel confident in their skills, have a desire to contribute, and are willing cooperate and listen to others' suggestions
Their general level of communication. How often they check in with other group members, how often they give updates on their own progress, how often they throw ideas during discussion, those kind of things. It shows not only a level of enthusiasm and motivation, but also a good deal of consideration for the other members of the group.
I think that the scrimmages that took place early in the semester worked well to show if a team worked well or not. I think that type of interaction, to solve a relatively simple problem, can expose work mentalities/habits from teammates that can then be used to gauge whether two people or a group of people are compatible co-workers. Without seeing each other in action, you cant really tell how dedicated, knowledgable or hard working someone is. These good qualities show up when there is pressure to get work done. Bad qualities, such as not being responsive over text/email or not completing your work, can also then expose themselves through these types of exercises.
To do some preliminary mini-projects
Honestly I feel like a major part of being a successful team member is just communicating and showing up to meetings. Even of you have no expirence in a topic, just being at the meeting shows you are invested in the project and ready to learn how you can best help out.
Take their background knowledge and see what's the best fit for them in a project. Yhis was done very well in our class, where we even had a survey where we had to list the other 400 level courses that we had taken. This helped gather our interests/background experience together. However, this can also be done in different ways, mainly through work ethic. I feel like the more rigorously-minded workers should be sprinkled in groups with workers that don't have the best work ethic. This could make all of the groups more even in terms of work ethic rather than having a single group that works very hard, and other groups who don't have the same level of intensity.
Seeing how they communicate and whether they are willing to admit they are having trouble. Some people struggle in silence when they could get all of their questions answered if they just asked someone else on the team who knows more about the topic then them.
I think the best way to predict compatibility in terms of group members is to look at how they act in a public setting (such as class) as well as how they work. For example, if you know someone is an outgoing, do everything right away type of person then it could be good to put them with somone who is a little shy and is slower to start work. I think those types of students compliment each other. It is a matter of judging a student's work ethic and personality and try to make it so there are similarities but also differences because as the saying goes, iron sharpens iron.
I don't think there is a best way to predict this. I believe the only way to see if people are compatible team members is to just put them together and see how they like it for a bit. Everyone is a fine teammate at the beginning, because first impressions are really quite shallow. Only during tough times do you see who's willing to put in the work. Aside from that, if people get along really easily, then I would assume they'd make good teammates, but who knows.
For me at least, our team had 4 engineers and we were able to get along quite well because we had a lot in common. It was rare for us to meet other engineers in CS classes and we were able to talk about stuff other than CS. A lot of advice, other recommendations for other classes.
Their work habits. When people who same way and maybe even think the same way, they will be able to understand each other better. In this way they can capitalize on their strengths and help each other with their shared weaknesses. When people's work habits are similar, they do things more efficiently and effectively because they already know how and when someone will complete a task and can act accordingly.
I think the best measurement to predict whether you're on a team of compatible members will be to do surveys and having discussion about previous experiences to see how motivated they're truly are about computer science and more specifically the subject of the project teams goal.
If their personalities / work styles align. Not everyone should want to work alone and not everyone should want to take the lead. Balance
Building a relationship with the student. I do not believe you know at first glance or interaction.