1. The team engagement practices that were both used by my team and useful to the project were:
Team engagement practices our team used included encouraging all members of the team to not be afraid to speak up during our meetings no matter what they had to say. Furthermore, we also believed it would be helpful to get to know each other on a more personal level outside of just working on our project. This included playing games prior to a meeting to interact socially. By having this relationship with our team members that was just more than trying to solve a problem, I felt that were became closer as a team and were more open with each other.
I think the weekly meetings that our team established early in the semester were crucial to our success. We met with our client, Dr. Purtilo, and as a team at least once a week to address questions, critiques, and progress. I also thought the mentoring site 'Advice' feature was useful throughout the semester. It facilitated constructive criticism and refined our teams dynamic. Last, I think the possibility of pop quizzes were a useful incentive to attend class on time each day.
Daily standup meetings. Kept us in the loop every day. Very useful.
SCRUM style meetings. I also enjoyed the Gallup personality test.
Using Jira as a method of facilitating our agile development process helped us immensely with organizing our tasks and staying on track as a group. Also, keeping fairly constant communication avoided accidentally duplicating work, allowed us to help one another when someone was blocked, and keep each other motivated. When we began doing sprint planning sessions and setting weekly goals for ourselves, even if we were not strict about the actual deadline, we were much more productive.
Imessage for communication and Jira for project managements seemed to contribute the most to our groups engagement in the project. Honorable mentions to our weekly stand-ups, but the participation in those were often minimal, thats if everyone showed up.
I think tracking to-do lists in meetings (sort of our version of trajectory), ticketing, and peer mentoring were all useful to the team and the project. Tracking beforehand was a way to make sure everyone knew what tasks needed to be completed, as well as what tasks needed extra attention. This was a preemptive way to ensure that the time we set aside for Answermator was well spent. Ticketing and peer mentoring were both reflective tasks that helped us improve as the semester progressed. Ticketing was a personal reflection of what work was being done, and whether that method was effective or not. Peer mentoring was a way to hold each other accountable, and share some compliments or rewards for jobs well done. I found that constructive criticism and praise for good work were both effective means for getting team members back on track or to continue doing excellent work, and led to more project success.
Frequent meetings, we had a short meeting every couple of days and we would have a stand up everymeeting. In the meeting we would list what we did, we are going to do, and what is our blockers.
the thing that helped us was the abundance of meetings with ourselves and with our product owner. This was really instrumental in ensuring some miscommunicatin was elminated. Unfortunatly, this did not eliminate all miscomunication, but it helped in the reduction.
Reaching out personally to team members to check in on them, see how they're doing, see if they need anything, etc.
We made an effort to meet just to hang out and play games during spring break and that paid dividends in improving the relationships of the team. After that everyone was a lot more comfortable with each other and had no problem communicating challenges they were facing or asking for help. It broke down most of the barriers that people had up.
I found that using Trello to organize our tasks as a Kanban board was very helpful for understanding where we were at, what we needed to do, who was assigned to what task, etc. My group also did a great job about communicating early and often when issues arised, which helped push us to complete our tasks on time.
Live meetings every Tuesday and Thursday after class (and other days in between as necessary) where we came together to update each other on our individual (and pair) progress and used the time to merge our pieces together, check each other's work, and make more progress/improvements/adjustments as a team.
Agile development as constant checkups led to constant improvements on the project.
Our team did a great job enforcing a positive work environment that encouraged openness and honesty. In being honest with each other, there were times when people had disagreements about project-related decisions. I'm of the opinion that a dose of friction within a team is a good sign that everyone is actually engaged and cares about the project's outcome, so moments of disagreements were not an issue for me. Most importantly, each member was patient and lenient with one another due to the extraordinary circumstances we all find ourselves in. Everyone was decent and respectful to each other.
We used pair programming, which helped a lot since we would take turns coding and testing, and only one person could use the device at a time. The other person would do what they could to help speed up any bottlenecks or do things in parallel where possible, and provide advice, feedback, and notice typos.
Daily meetings. Though often people didn't attend, the stand up meetings were great because it allowed everyone to know the state of the project, what they should be working on, and allow for an easy place to ask questions.
Definitely having a roadmap and plan before developing is the most useful thing I learned. We need to all understand what the requirements and needs of the group are before developing or it will lead to problems and bottleneck in the future. If we would have just jumped into the project without outlining what we should do I know that our project would not have been nearly as successful.
Team engagement practices my team used that were also useful to the project include frequent stand-ups, check-ins on discord, regular communication, and regular meetings with the clients and the professor.
We met up weekly in the beginning of the project and as the project got more and more demanding we met more frequently. Everyone was constantly engaged in our Discord. There were chanels for everyones subteams, there were mentions that were specific for the different roles that people had (@unityGuys would mention R and G, etc). We had a evening where we all got together and just played games. I think after that day everyone felt very comfortable with each other and speaking up in meetings and asking questions became a whole lot easier.
Originally we had scheduled meetings 3 times a week, early on in the semester we added on another to meet with our mentor/customer once a week. This schedule of meetings was going well but as we reached the end of the semester we realized that we had our work cut out for us, so we switched to daily meetings. These daily meetings allowed for the team to check up on each others' work and hold everyone accountable. This switch to daily meetings allowed for the team to pull together a great demo presentation and win the people's choice award. Another practice of sorts was assigning a leader. Although we never officially labeled W as our leader, he took on the role of a project manager of sorts. If nobody would step up to complete a task W would assign a member with little on their plate to do it, and they would listen. This leadership gave the group a sense of structure and allowed us to work more efficiently compared to if nobody had stepped up to lead the group.
Daily 9am standups, even just thinking of the project and syncing with the group everyday saves us a lot of time later. Team members who frequently missed standups needed things explained to them more and knew less about the various other parts of the project.
Having meetings after class to discuss not just the project, but also class material. We also had a note taker at all the meetings so that we could easily reference decisions or discussions from those meetings.
Setting clear expectations, communicating progress.
I believe that doing long meetings with small breaks in between where we talk about other things that interest us was productive. The best work that got done was in long meetings between me and J, where we would go aon tangents here and there about things that interest us outside of the project. The rest of the team was not engeagee often as seen in the time logs, so its hard to say what practices were used by everyone. There were a lot of scheduling issues and this was not a priority for most of the team, so we could not do daily meetings.
Having weekly Monday meetings as a team, with another time set aside on Wednesdays to meet if necessary. Additionally, we met after class on Tue/Thur as needed and if lecture ended early. We also had weekly meetings with our Clients on Tuesday nights which helped us to have a deadline for new development since we would have to demo at these times. We also had a team GroupMe that we used for regular communication. We had a discord with separate channels for each sub team for more specific conversations and video calls. We had a wiki on our Gitlab repo that we updated weekly with progress. We also kept detailed notes for each meeting and had a comprehensive google drive folder that had all materials related to the project for reference.
Weekly team meetings (at a minimum).
Some weeks we met two or more times, and while toward the beginning it seemed like overkill, by the end it was instrumental in terms of keeping production and testing coordinated.
Weekly meetings with the client
Meeting on a weekly basis with Larry kept us in tune with his wants and needs regarding the product. It also kept us accountable, as it became a hard deadline when we needed to have aspects of the product (new pages, the demo, the db schema, etc.) nearly or totally complete and at the minimum, presentable.
Weekly meetings with Jim (you)
While our meetings with Larry gave us a hard deadline to have things presentable by, our meetings with you were used (in my view) in a similar way, where we made sure progress was made since our last meeting with you and we that we were on track for the next week. Our group got off to a kind of slow start, and I think that initially, our meetings with you were what got us off our behinds and in motion.
Keeping meeting notes
Meeting notes allowed team members who couldn't make a meeting to catch up. They also allowed us to go back and make sure of team decisions, including who was assigned to what tasks before we started using Trello to track this aspect. I think keeping meeting notes also helped keep team members at meetings engaged, even if they were not always the most vocal (definitely me at some points).
Trello task tracking board
This was something that I initially didn't think was really necessary. After all, we got through the first few weeks of the project without it. However, after a month or so using it, I definitely see the value and appreciate the positive impact is has on the team's workflow. It keeps us in sync, true to deadlines we set, and lets others know exactly who worked on or is working on what. This allowed others to reach out to the most knowledgable people for help and also to hold others accountable when a task was left incomplete for a long period of time.
Maintaining a groupme group message
This was the main form of communication between our entire group. It kept us connected at virtually all times, allowed us to coordinate meeting times easily, and communicate any issues: whether we would be missing something, late to something, or if a task would take longer than expected.
Filling out the weekly peer reviews
I'm not sure if everyone else valued this as much as me, but early on I got a few recommendations to be more vocal. I'm usually more of a quiet supporter in a group, especially if that group is already on the right track. Because our group had so many strong members, I didn't feel that I needed to speak up a lot of the time.
However, because of my teammates recommendations, I started to consciously voice my opinion, even when I wasn't the most confident in my ideas. I think this really helped me feel like an integral part of the team, and it also pushed me to play a different role than I probably would have had I not gotten this feedback.
Team meetings often and status updates between the subgroups. This allowed my groupmates to tell what was happening within our group and hear the progress of other groups.
Multiple stand-ups per week. This helped our team keep on track with all of our tasks. We discussed what needed to be done each sprint and we were able to ask for help if any of us were struglging.
The main way we made certain to have the entire team be engaged was meeting in Zoom calls. With only 4 of us, it was easy to call out people to join Zoom calls that wouldn't talk otherwise.
The peer mentoring was very useful to me. In the first few weeks, I received feedback that I was too quiet in team meetings. As a result, I made an effort to be more active in communication during meetings and I think that helped the project as a whole. Its likely that my team members have similar experiences.
I found the peer reviews to be helpful from my end at least. While not everyone in my group did it to the level of detail I did I found it a good way to give general feedback and some of the specific advice I did get was helpful. I think it helped motivated people to pick up on their efforts if they were slacking in between.
I think the status bar on the 435 site was also a good way of making sure our progress on the project was timely and reminding us of important dates.
Planning out a proposal. This made us more organized than we would have been, and it brought up issues earlier. It did not cover all our bases and we felt pressured by it later on, though.
I think that engagement practices often seem trivial or not relevant to the project, but that ultimately they still provide value, because they get the group to think together how to finish them efficiently and force us to think over issues we might normally hand wave, especially the specific timelines and effort tracking. My only critique here is that it felt too punishing when we tried our best and were happy with the engagement tasks we were able to deliver, but then they were not up to expected standards and we felt less motivated to continue to press forward.
Paired programming and weekly plans were our main strategy. The main benefit of both was that we were held accountable (at least socially) for doing the work we said we would do. Our monday meetings frequently included a written list of what everyone would be working on, and we followed up on Wednesday and next Monday.
The weekly meetings, because make us think about what we did during the week and what we could get clarification or help on. This helps us stay on track and focused on the project.
I think these were pretty helpful. Often times the most important part about working on a group project is not necessarily that everyone is constantly going full steam ahead, but that the team members are meeting to touch base on a semi-regular basis. I found that the regular short check-ins were hugely important for keeping engaged in the project.
Daily / Weekly meetings. The more we met, the more everyone was on the same page. We origianlly began the project with few meetings and very little was getting done. Progress was slow. We then moved to a daily morning meeting model. While the turnout for said meetings varied, it did help keep the group more enagaged and on top of work that needed to be done.
We initially had once a week meetings on Tuesdays after class but realized later that we needed to have one every morning at 10am. We also met with our client every week however stayed close in contact over discord. We also stayed in communication throughout the day on discord with the team and sometimes had multiple meetings in a day.
2. If I could make ONE change to CMSC435 to make it a great class, it would be:
Not being in-person was a big hinderance this year, however possibly having the guest speakers scattered throughout the semester and not just at the very end. Though I apprecitate the breaks near the end, it is nice to hear experiences and applications of content we learn throughout the semester. We could ask better questions relating the content to the real-world as it is fresher in our minds and possibly a more memorable experience.
To allow students to have some sort of input on what team they are on once the projects are chosen and also to make the teams a little bit smaller.
I thought the use of SVN repo to host class materials was difficult to use. There were many instances where I would've liked to access class from my phone but could not due to the fact that the link was embedded in the SVN repo. There also was no introduction to SVN, we kinda just jumped right in. If I could make one change, it would simply be to host class materials on ELMS.
Making it in person would help...maybe next semester.
Allow the students to choose their own project.
I think having important lessons from lectures in written form or as slides would be extremely helpful. Although I attended every lecture possible, I still found myself missing some important information that I think I would have benefitted from being able to review on my own time.
Less assignments due before the add/drop period. I'm sure you do that for a reason but being down 10% without joining the class makes the rest of the semester a lot more stressful than it need to be. Wish I was more worried about learning than stressed.
I think something that would be an interesting idea would be if the projects were defined and then students were able to make a list of the 3 projects they found the most interesting and if this could be taken into account during team formations. Or generally if students had more of a say or view in the team formation process. I know this is how some companies try to match new employers with teams by considering interests along with past experience, work ethic, and team needs. Not that however it was done was ineffective as my team got along very well by the end of the course, but I think this would have taken away the initial uncomfortable setting that we felt, and as I mention in question 5, would be a way to make sure everyone on the team cared about the end result, rather than feeling like it was a project they were thrown into.
To shorten the time for scrims to increase the amount of time to work on the class project. I felt like we started the class project a little late, as the work after the proposal happened after spring break.
I would not make the instructions vauge.
Spend time near the beginning of class on how to write proposals. Technical writing, particularly proposals, is both a difficult and valuable skill.
Tell future students about the blog bot and svn scripts I'll be putting on the GitHub @xxxxxx. These saved us tremendous amounts of time and kept us on top of class activities while we were up to our necks in work with our project. More automation really helps to stay engaged.
I would recommend maybe giving some points to teams who are frequently engaged with their clients. I understand that the value of meeting with your client is partially reflected in your project, but some explicit points would be a good incentive to have you meet with your clients often.
One more thing would be to make the powerpoints publicly accessable. I know the idea is probably to want the students to take notes, but the powerpoints are so valuable and I would like to be able to view them whenever I want and use them as a constant resource.
To allow a little bit more freedom in choosing our semester-long project. I don't mean letting teams do whatever they want, but maybe offering a small selection of potential projects to each team and allowing the team to choose one.
The only thing that's I would change in this class is the online part even though I know it is because of corona virus. Other than that, I think this class is a level above all other cs classes I have taken in past in UMD.
Allow for more student input in the projects that they work with. While it was an interesting and successful project that I worked on, not having any experience with APIs beforehand really reduced the initial interest in the project which affected productivity.
I would perhaps try to place a bit of emphasis on student interests when assigning project groups. I don't think the groups were assigned poorly, I just think it may have been easier for some people to be more engaged in their projects if they were more closely related to their areas of interest.
Impossible. Our spirit guide already made it a great class.
I don't know of any major changes that would help, but the ticket/advice website UI could be improved to make it more intuitive, maybe add an edit button to tickets to allow you to edit it for at least a few minutes after it was added.
Allowing for teams to think of a project idea, propose it to you, and then work on said project. It was hard to initially get motivated for this project, as it was not one that resonated with a lot of us. Me personally, when I read the initial project description, I was kinda like booo. It wasn't awful, but it wasn't interesting / cultivating. Allowing students to pick their own projects to propose for a green light would drive more engagement for sure.
Definitely the website. Its extremely hard to navigate and se what is expected of me. I would highly recommend making a calendar on the website that describes every day of the semester that meets and what is due and expected at that time. It just feels like I never know what is actually due and when.
One change I would make is for the duration of the scrimmages to be shorter so that there is more time to get acquainted with the main project.
I really appreciated all the textbook options that Purtilo offered and I have a list of them, but I thought it would be helpful to know what to read before the class so that I could feel more prepared for what we were learning and what we would be talking about for that day.
To allow for the groups to propose their own project. A friend is taking 435 with the other professor and he showed me the project he had proposed and developed. It was a neat web application for splitting bills using Venmo. It was pretty cool and I could see how passionate he was. It's hard to find the drive to code up someone else's dream, especially when you can't see its usability.
More complex projects need well-defined problems so most of our time isn't spent attempting to solve something we barely understand. That being said there was a lot my group could've done to combat that from the beginning and it was a good learning experience. (I would also make the class 6 credits)
Adjusting the amount of side work. It was a lot to handle along with the long hours we spent on the actual portion of the project.
Better use of lecture time. I enjoyed the lectures that featured guests, and I did learn some topics from lecture. Though, there were a lot of days where it was difficult to pay attention due to my lack of interest in some topics. Some of my friends in other groups believed that it was provided an initiative for groups to meet before/after class.
Have the control of the scope of the project be up to the team a bit more. Having ownership improves engagement and I think that could be improved more instead of giving a project.
Make lectures more relevant to the project and other assignments.
The blog to be clearer about what needs to be delievered and at what time. In the beginning I had a lot of confusion about the small tasks.
If lectures ended around 20-30 minutes early consistently, or once a week, so that there could be designated time to meet and work as a team it would be very helpful. Having multiple weekly meetings on top of regular class time took up a lot of time.
I would include EE courses on the past/current courses taken survey. I know you're really methodical with how you split groups up, and you most likely take into consideration the prior knowledge students are coming in with.
Since I and a sizable group of other students in the class are CE, there are a fairly decent number of classes we may have taken through the EE curriculum which apply to what we do in this class and may give a better picture of our complete skill set.
Other than that, I really do think this is a great class. I got more out of it than I ever expected, and I'm not just saying that to flatter you.
Maybe allow a list of projects for groups to work on. Honestly I am pulling at straws here, I believe this class is already as good as it is.
Maybe have more resources to help students? A majority of the class are thrown into a project they know almost nothing about and those without prior experience with any web development or current technology will struggle.
An ELMS site so that it was more easily viewable when the deadlines are for assignments. Can be hard to balance things with a lot of classes over multiple sites.
I think this class is already great. I would say maybe a more involved assignment on ethics that is perhaps a discussion post that really requires involved thinking from students and requires them to engage with others to hear other perspectives might be helpful.
Change the way we collect tickets by turning it into a group retrospective. This helps make everyone accountableand encourages people to brainstorm about the important decisions that took place. As a team, we think we would have benefitted from something like this rather than a retrospective at the end of the semester through a final exam. We partially did this through the quiz questions, but capturing this feedback more regularly would have been helpful.
Getting more freedom in terms of what the semester long projects are, and who the groups are. I understand the rationale for the method that team members and projects are assigned. However, it seems like getting a good project and team members is luck based (I was one of the lucky ones), which is not conducive to ensuring that my experience and learning outcomes in class match those of my classmates.
Reduce some instances of ambiguity/cryptic language. I understand that ambiguity is an important learning tool, it forces us to be engaged, set our own deadlines, and organize our own plans (which I think is effective) but there are times when I feel it would be more valuable to provide a clear definition. For example, in understanding what the CDR is or how the cost estimation should work a little more clear and simple introduction could've been useful.
One change to CMSC435 would be to have all groups have projects that have more similar scales. Some projects took a lot of background understanding compared to others so having them on the same timeline as a project with completely different requirements felt a bit unreasonable and very anxiety inducing to someone who may have gotten a project that required more understanding or more complicated technologies.
Helping students understand that the failure or success of their project does not make them worse or better students if they learn from the results.
Using ELMs or some other software with a calandar to note the dates of smaller assignments. I know each student only has three svn repos (personal, class, project) but when you add it to all the tools used by teams (i.e. trello, gitlab, monday) and the peer mentoring website, I become worried that this course is teaching scattered and complex communication practices.
A clearer expectation of the project. Early on I knew the project would be more involved than the usual CS project, but I wasn't quite sure what that meant until we were already past the proposal and working on the project itself
I'd actually like to be more engaged with what the rest of the class is doing in terms of everyone else's project! We only really got the semi-regular status reports at the beginning of class, and the demo during the second-to-last week. Maybe we could officially make those status reports a weekly thing and have each group prepare an actual presentation of some kind each week for that. That's even another way of making sure teams stay engaged, and it lets us know what everyone else in the class is up to. Another suggestion I would have is, maybe try and make it so we get our final group/project assignments a little earlier in the semester? We definitely felt a little rushed when doing our project, and it would have been nice to have those extra couple of weeks.
Definitely organize the assignments better. Expectations, assignments, due dates, etc are all scattered around multiple pages across the site. From the Blog to the timeline to the status page. Many of my group members lost points on forgetting assignments because it wasn't always clear what needed to be done and when. One simple way to make this better would be to highlight assignments or important info on the blog.
One thing that I would change is how assignments are announced. It would be nice to have an assignments or things to do section in the website that way there is a one stop spot to go in and look at everything that is due for the day or week.
3. The one thing that most gets in the way of me doing my best work in CS here at UM is:
Honestly, the class procdures and sizes at UMD. The class sizes overall are way to large, not particularly 435, so it limits my ability to be as connected with the content, instructorm and my classmates. It makes it feel like it is just another box to check off due to the lack of engagement. The lack of collaboration is also a problem, since I feel that I do some of my best work in collaborative settings.
Having to worry about other classes such as general education requirement classes.
I think the lack of education on post-graduation outcomes is the biggest flaw with the CS program. I have done ample research and investigation on my own on what I can do with my Computer Science Degree after school. Although the technology field is constantly changing, there is much more that could be done to educate students on what comes after graduation. The knowledge of what comes next would likely incentivize better work and lead to better student outcomes.
Being online. It's hard to get motivated and stay focused on school when I'm sitting at home every day.
Time. There is just too much to do across too many things and managing it all can be stressful.
Myself. I sometimes found it hard to work on projects that I could not get myself interested in even though they were assigned to me. When I did get myself to enjoy a project, however, I found I achieved my best work.
My living situation especially during covid. One thing I learned going here is that I am more than capable of succedding in this enviornment when I put myself in the best position to succeed. I do admit that most of these circumstances are in my control, but if they were something I didn't have to think about in the first place I'd be killing it here.
My major to be honest. As a CE major, I feel like I was unable to master either the EE side or the CS side of the cirriculum. I definitely believe I have gained some keen advantages from my major, such as problem solving and technical thinking perspective on many problems, but I do notice that my CS skills are slightly less refined than a lot of my peers. I believe if I went back and did college again, I may have gone with computer science as my major, which I think would have led to more free time to develop my skills outside of the classroom, which is an assumption I have made by talking to CS majors over my 4 years here.
I feel that the one thing is the amount of credits I have to take that is not CS. It is expected of me to have 40 credits of CS, Some professors have "ineresting" teaching styles. As a result I don't lean from those classes in person. SO, I ensre I am following the book in order to catch up with what was said in class.
Other classes, mental health, and ADHD.
Not being able to talk this students. This was the first class in the entire major where I was actually able to get to know other students in my major really well. I really wish I had more opportunities to work with other students and create lasting friendships.
I wish the CS department allocated more resources to the students during office hours and study sessions. There's just too many of us and too few TAs.
Not being as knowledgable and experienced as other CS students when it comes to being able to do many different specific things with different languages. A lot of this comes with time and experience, but I often find myself having to look up how to do certain things which I feel slows me down and prevents me from doing my best work.
My tendency to procastinate and got easily distracted by the internet.
Large student/instructor ratios that limit that amount of personal engagement I get with instructors teaching the courses.
My life circumstances. Being in the Army had exhausted me mentally and physically for the past four years, so I wasn't able to give my best work in CS.
For me, mostly the depression from the pandemic. Some of my friends said that their professors were not good at teaching remotely, but I guess I got lucky with good professors.
I answered #4 before I answered this one, so this answer is going to be similar. When it comes to getting a career, employers look for internships and experience. When it comes to getting internships, recruiters often look for personal passion projects. When it comes to getting the experience, it comes from internships, personal projects, and rarely from projects within our classes. I learned early that the stuff we were being taught, a lot of it won't be relevant in my day to day as a Software Engineer. Because of this, I became disconnected very very very early on. Was I disconnected and always working on projects, no by any means. It was hard for me to focus and learn things that I learned from professionals wouldn't really matter so much in the long run. That is the biggest deterrent that got in the way of me doing my best work in CS at UMD.
I think I big problem in the CS school is the lack of collaborative work. Computer science is a completely collaborated field and should be treated as such. How come everyone acts as every man for themselves during college and once we are in the work flow the expectations completely change. A lot of students struggle to effectively communicate with one another.
The online nature of classes this semester has been quite mentally taxing, and that has been the main obstacle getting in the way from me doing my best work in CS at UM.
In certain classes, they are specifically designed so that there is a large curve at the end of the class. I think that this is extremely harmful to the learning process. It often pins students against each other because it is not about how well you know the material it is about how well you are doing in comparison to other students. There is incentive to sabotage. In fact, I have seen it in previous semesters and overall it just adds more stress to everyone.
As of right now its online school. I can't focus and I've lost motivation. Otherwise pye-covid I'd say nothing. I have enjoyed all my CS courses and never found issue with pushing myself to do my best and truly understand the material.
The feeling that comes with most classes that it is temporary and I have no personal ownership of or investment in the work I'm doing. Software engineering is unique in that regard.
Getting stuck on a portion of code and not being able to access help.
My EE classes. Really wish I had more time/credits to take more CS classes here at UMD. (Most) EE classes brought down my interest in school, and I was more inclined to take "easier" CS classes rather than the ones I had genuine interest in :(. Another overlooked aspect is the quality (more important) and quantity of professors that both genuinely care about what they're teaching and are good with communicating (expectations, course material, etc.) with students.
CS is rather unique as many of the top companies don't place too much significance on grades or academic success, so for me its just been a lack of motivation as I have my immediate career plans pretty set.
Not having enough time to fully commit to assignments. Sometimes all my classes have heavy work weeks at the same time and I have to rush and cut some corners and sometimes not complete or give best effort for some work.
The rest of my group not being engaged by not coming to meetings, coming late, not listening to my opinion.
Workload from all classes makes it difficult to really invest time in any one class to retain a significant amount of material.
My machine. Coming in, I was unsure of what to get. My dad works with software engineers, and they all use Apple computers, so that's what I bought. Maybe it's more because I'm CE, but there have been plenty of times in CS classes as well where I regretted buying a Mac.
Taking multiple different classes and having to manage so many different things at once. Also working at home does make working much harder.
Time. CS courses are time demanding. On top of that we have other classes so it is hard to just be able to set aside time to solely code and work on projects.
Myself and procrastination, with long deadlines and no middle deadlines I tend to wait to the last minute to complete work.
Limited access to professors. There were a few classes where professors were truly always available, and others where professors never responded to my emails. Getting to interact with these people would have given me great perspective on why I'm taking the classes and the broader context of why it matters.
Vague project descriptions and the submit server have always been the biggest roadblocks for me at UMD.
Gen eds. I believe that there are some useful gen ed requirements (like professional writing), and it is important for graduates to be well rounded individuals, but more often than not my gen eds felt more like time sucks that were distracting me from my actually relevant CS courses. Of course this was dependant on the courses taken, but I cant help feeling a little annoyed by them.
For me it felt like exposure to "real world" problems was limited in class and that i would only be able to experience it in internships. So CMSC435 was definitely a great experience in that respect.
Lack of engagement and motivation in an online environment. It has just been hard for me when people are not there in person to work together.
No class in web development. That is mostly my own fault; upper levels do exist. But I wish I were taught some fundamentals earlier since it seems so important later on. Maybe also development paradigms (this class is the first one where I heard 'fullstack').
I can't really think of anything
My own laziness and unwilligness to perform to what I know are the best of my abilities. I think the engagement skills I've learned in 435 will really help me fix this in the future!
Exams. I know this might seem like a joke, but I'm serious. I feel like exams are only a detriment to our experience. They are stressfull, time consuming, and don't really prepare us for a future in the industry. I personally feel like projects and HW does a better job of testing our overall knowledge and ability to succeed over timed sessions were we basically have to speed-run problems.
Honestly, its always hard for me to do my very best because of the work load in a lot of my classes. I took a summer CS class once and with that being the only class I was taking, I was able to do my very best and get the most out of that class.
4. The obstacles that prevent me from knowing what is expected of me in this degree program are:
Classes not being specific enough when it comes to assignments.
For the most part, I think the expectations in the Computer Science department are pretty cut and dry. There are ambiguities that exisit within individual courses but the program itself is very clear. If I had to name one, I guess one obstacle is the size of the department. It can be difficult to get into courses that are essential to graduation, which usually puts students in a very uncomfortable position.
Being online. Some parts of it are nice but a year of online school is too long.
I do not feel like there are any obstacles, I have access to the requirements online can verify them.
I would not say any obstacles prevented me from knowing what was expected of me in this program. I believe most professors were readily available to explain what they expected from us and the department makes its requirements clear.
Can't think of any.
While I don't think there are many obstacles that have gotten in the way of me understanding expectations, one is sometimes lack of a cohesive department. Sometimes (as with 216 and 250) courses don't communicate and the work piles up and students are stuck choosing what to focus on, but at the same time we know what is expected. This was great with 330 and 351 as they accomodated each other. The last piece would be difficult professors who don't provide rubrics or explanations for project descriptions. Personally, I thought I knew what was expected of me throughout my time, and how to proceed and receive help when I needed it.
that guideline, I did 33% of Computer Science classes while I wish I could have taken more. There are some professors that want to make their gen ed classes harder, which just takes away time for me to learn more CS.
No obstacles, I understood what the degree program expected of me.
I feel I knew what was expected from me early on. As someone who was had been programming for a decade before I entered college, and coupled with the advice of others who had graced the path before me, I felt I had a good idea.
I think I have a pretty good idea of what is expected of me.
There is an emphasis on trying to make the students fail in this major so I saw all the obstacles as the college itself. I think it takes effort from within your self to want to accomplish this program because the odds are stacked against you.
A lack of communication with professors and TAs when I encounter problems.
Not being disciplined enough to properly keep track of when every single assignment is due, especially the smaller ones. Sometimes not being confident in my skills can also get in the way of me not knowing what is expected of me.
Unclear direction and lack of guidance from the advisor. My former advisor very slow in replying email and sometimes did not answer all the questions I asked on the email.
Not much for me, I have been fairly knowledgeable of expectations from the ECE department.
Not having anyone to regularly share experiences with as an Army ROTC cadet and a CS major was a huge obstacle because I always felt like I was alone all throughout college. Although there were three older cadets in the battalion that were doing the same degree program, they were always out of reach and couldn't really relate to my struggles since I'm the only CS major in commissioning year 2021. Also, I didn't expect nor was I academically prepared for UMD's Computer Science program. Coming in, I had no idea how hard the program really was until it was too late. However, I have no regrets and am proud of surviving this rigorous academic program.
I don't know if this is what the question is asking, but it was sometimes confusing to have multiple different places to check for upcoming assignments rather than having everyhting on ELMS, or at least mirrored to ELMS.
There were points during my degree where I realized that what I was learning may not be applicable in the Software Engineering career path. We learn a lot of theory and other shenanigans, but a lot of that is thrown out of the window when it comes to the career. When I learned that the skills I needed to be an engineer didn't align with the curriculum we are taught, there was a disconnect and an almost disdain for UMD. I learned that my personal projects and internships were way more important for getting / maintaining a successful career, as opposed to focusing 100% on my school work.
This doesn't really answer your question, but it kind of does. I know what is expected of me to an extent, but do I agree with those expectations, not necessarily. After my internship at Twitch this semester, I knew what was expected of me to be a successful engineer (to an extent). When I looked at my course load for the next few semesters, I was kinda disappointed when those expectations didn't align. If I knew I was gonna be working in GO and JavaScript, it made me said to be taking classes on Kotlin, concurrency (not awful) and security. The biggest obstacles are the disconnect between curriculum and the requirements of the real world. Because once I learned about how far the disconnect is, I began putting less and less effort into the lesser relevant classes. (I could rant about this forever). C's get degrees, but C's also allowed me to pursue passion projects. Those passion projects is what got me interviews and my foot in the door for these opportunities. I believe that the curriculum should be reevaluated entirely to reflect the needs and skills of a modern day Software Engineer because I want to be a programmer not a Computer Scientist.
Nothing. I know exactly what needs to be done to complete the degree. I just wish there was more transparency on what classes will help for specific areas.
The past year specficially, the online nature of classes sometimes caused delays in communication and hence delivery of expectations. Generally, as a student on the general CS track, I have a better understanding of expectations for me in individual classes but not the degree in general. So far I have assumed the general expectations are an aggregate, but it would be more helpful if these were laid out more cohrently as it is not possible for students to take every single course offered by the CS department.
I didn't quite understand what upper level courses I was expected to take and how many of them until I had to start taking them. I didn't know about the degree audit until halfway through my degree.
My lack of knowledge concerning the real world application of the skills I am learning. I've been told to choose a specification such as AI or machine learning and they're simply buzz words to me. Up until this class I had been solving pre-made puzzles, filling in the blanks of skeleton code projects. While this class stressed me out a ton, it was my first taste of CS in the real world. But yea, to answer the question: a lack of real world examples/ application of knowledge prevents me from knowing what it is expected of me, what will I do with this knowledge of a PR Quad tree?
The largest problem with expectations is what is expected of me from CS classes is very different than what is expected of software engineers in industry. Most classes exist just to teach a specific area within the field (algorithms, data structures, etc.) but I think it would have been helpful to teach software engineering topics like development principles and defining requirements throughout the degree.
Having more contact with an advisor who keeps track of graduation progress.
Not being able to talk to a CompE student that is further down the undergrad path when first starting out. I think some sort of mentor program (for a month/year) would be helpful for students looking for guidance and/or are interested in a major would have been absolutely amazing for me. The program would consist of a junior/senior <insert major> student and a prospective student in UMD looking to get into a major. It would provide a small connection and valuable insight on paths/classes you will/can take.
The amount of automation and non-personalization in this program. Often times CS at UMD is so large it feels like a factory assembly line and not much room to set yourself a part. Luckily, I've been able to do that on my own, but the CS program did not help with much of that.
Professors not communicating well and being vague about assignments and other requirements.
I believe the overall expectations were fairly clear. Smaller graded objectives could have been made clearer.
(CE - old track) Not having sufficient exam prep material even when exams can be up to 40% of the total grade
I think the problem I've had is not so much that I don't know what is expected of me, but that I don't the best way to make the most of my options. With the tightness of scheduling at UMD, it's easy to pick classes that fit into a time frame rather than by consciously considering what will help achieve specific career goals. I also think part of the issue here is how some classes have a very detailed syllabus, but one which left me wondering exactly how it would be adding value to my degree/future career.
The number of 300-400 level classes I can take, but having a large majority of them being required in one way or another. (For example 435 being a "must have" since it allows students to work in a group setting while working on code, 411 and 414 are also semi-required due to being helpful for interveiws and job hunting etc.)
Classes. This class is the only one that seems to have tried to prepare me for the real world. Almost every other class just teaches theory and no hands-on experience. Allowing students to have real-life experience with projects through classes is a must.
Knowing what is expected to be known in what classes. There isn't a uniform system of languages and it seems that classes bounce between things and there's an assumption of knowledge that isn't necessarily had.
None. I had a really fantastic advisor that always helped keep me on track. I knew exactly what classes I needed to take to graduate, and had great flexibility in planning towards the later semesters. Keeping the second half of my college career lighter on classes really helped me spend more time on things that mattered to me.
Many professors simply do not inform students of what is expected of them in this degree program. I was fortunate to know what was expected of me throughout my experience in 435, which I am thankful for.
I never had a close relationship with any advisor. I don't know if I am the minority in this regard, but I never consistently met with the same advisor. Because of this, my advisory meetings simply boiled down to "yes, the classes you picked (somewhat arbitrarily in my case) fill the requirements.
I was not really aware there was supposed to be expectations of me unless I am misinterpreting this question. Maybe that in itself is an obstacle? A lack of awareness of the fact that there are expectations of me as a CS major at UMD.
In general, I think upon graduating from UMD as a CS major one should be comfortable learning and adapting to new technologies they will encounter in the workplace. I guess not a lot of people in this major realize that you will never know everything you need to know for a job and that the importance is the ability to learn and adapt what you know.
No clear guidelines on what skills are useful in the world outside of school and expectations of finding everything out by yourself.
None. I know what will get me to my degree, and the kinds of academic and personal mistakes that may stop me.
I didn't have any problems figuring out what classes and such I needed to take
See my answer to #3 above.
It's difficult to tell what classes will actually be helpful to my career and which are just fluff. I'm aware that the school has "tracks" for certain fields like data science and cybersec, but I feel that this isn't enough. It'd be nice to have a general idea of what upper level classes would be a good fit for me.
5. The best way to predict when students will be compatible members of a successful team is:
I believe that the best way to predict this is somewhat similar working styles and personality traits. Having a little overlap in working styles and engagement ensures that there will at least be some common ground that the members of the team can build off of and use their non-overlapping traits to bring something extra to the table. I noticed that in my own team, as we were a pretty compatable team, and we had somewhat degree of overlap in traits and working styles so we understood where the other team members were coming from, yet we each also brought something different to the table.
To discuss strengths and weaknesses of all team members and get an understanding of how you can work together with other team members.
I think the Gallup report is probably the best indicator of compatibility for a given group. Each team should have a nice distribution of strengths across each category. Another metric which probably serves as a good indicator for compatibility is technical expertise. Teams with a wide array of talent in different areas (i.e. Backend, Frontend, DB) are probably more likely to succeed. Last, communication skills have proven to be essential in development, so a groups communication skills may predict how compatibile and successful a team is.
Their engagement with meetings and other class activities. Those who show up and participate will make a great product. Some people want to do the minimum.
If they have personalities that work off of each others' weaknesses. I think the best way to predict when students will be compatible members of a successful team is by making groups diverse. Having different perspectives, upbringings, experience levels and mindsets in one group makes brainstorming easier. Also, I think that assigning a leader is typically not necessary as it allows those who want to lead or believe they have ability to lead naturally rise into that position and motivate others. What they are looking to get out of the class and pairing them up with individual with similar goals or skillsets that can help provide what a student would like to get from the class. Though I wasn't thrilled with the group I ended up in I do have to admit that it seemed like everyone else got along just fine and I probably would have fit in much better a year or two ago.
Personality meshing. This is a term I just made, but I really think that various personalities make it easier for students to get along. You need diverse styles to work together in a cohesive manner. I belive if everyone is a leader, then no one can truly lead. We still want team members to exhibit leadership qualities when it is helpful, and know how to lead, but it is more important that everyone knows their roles on the team. My analogy for this is the 1990's Chicago Bulls (take your pick of year). Phil Jackson got the most out of the players by trusting them. He was an extrememly effective communicator who knew how to get the best out of everyone. When Michael Jordan would get heated in practice he would tell him that is not how to act, and when Dennis Rodman needed time off and took random unannounced trips, he let him do it, because he knew how to come back from these trips a better team player. So, as far as predicting compatible team members, I think they need to have similar outlooks/attitudes on what they want to achieve, while having different approaches to how to achieve this goal. This way the problem at hand can be attcked from multiple angles, while the big picture is kept in mind. This is something that I believe my team accomplished near the end, as we noticed how everyone would contribute and mesh to develop our product the way we initially imagined.
The best way to predict when students will be compatilable members of a successful team is the engagement levels, that is both engagement in the communication and the work. I feel that the most problems happen in groups is when people feel that other group members is not matching their level of engagement.
We like to have the student build prototypes. If the new student is able to try at least, that is a sign of efort and a sign o fufure group success.
I think your engagement metric was really spot on because everyone on my time consistently gave effort and we didn't have any random slackers. If people were going to contribute less that week, they made sure everyone knew and understood why. Look out for students with webcams on and/or active in the scrimmages or doing things beyond the scope of the assignment.
Attitude, sense of urgency, empathy in extenuating circumstances
Analyzing what things they have in common. I feel that people who have more things in common with each other are often more likely to get along and work together better, especially because that will allow them to feel more comfortable and start engaging with each other much sooner. All of the members have aiming for the same goal. The team communicates properly from the beginning and starts early.
How they work, in the sense of do they work in bursts or consistently throughout the project. This was an issue with my team plus the fact that some people like working during the day and some like working late at night. - Seeing how well their work styles and skills compliment eachother. However, it can also be somewhat valuable to place students with non-complimentary styles together to give them experience working with people who they may not mesh the best with.
How engaged they are with other group members. Even if they lack the skills, I can tell who has good social exposure from those who don't which makes those more exposed better in communication and bouncing off ideas. I know some of my teammates didn't like each other, but thankfully they kept it between themselves. In relation to me and everyone else, I was in good terms with everyone. I was privileged in being a part of a team that was professional. This is a hard question, especially with my limited data of 1 team (if you include other similar teams I've been on, maybe 3 or 4). Things that have made teams I've been on successful include: agreeing on a good team structure (leader, sub-teams, etc.), everyone taking ownership of parts of the project, initiative, also just hanging out and having fun sometimes, a willingness to learn from each other, and passion for the project or goal.
Allow for students to maybe meet each other or discuss with each-other before hand. If there were a few group exercises where we were forced to meet new people, then allowing for us to rank teammates we would love to work with. If you compiled teams based on how they ranked their peers I believe that would be a good way to predict students will be compatible members of a successful team. The best way would be aligning interests, which is why it makes sense that we had to take a personality test, but at the same time you don't want to have too similar groups because you want differing skills and interests. If everyone in the group thinks the same way it could lead to a lot of problems in development. Diversity of ideas is key in computer science.
A student's communication skills are often indicative of their compatability. A successful team has good communication between members, and hence it makes sense that a student who is compatible with such team would have that quality.
Their level of engagement and interest. If they all have similar goals and attitudes towards what they want to accomplish with the project. For VLEARN we all had the success of the client in mind and we all had similar positive attitudes towards working and how to get things done efficiently that allowed us to work very well together.
If they can hold a conversation. If you can hold a conversation with someone then you must share some common interests and hence a bond shall developed. With this bond conversation concerning the project will be easier and the expression of opinions concerning the project will not be an issue in meetings. If a conversation cannot be held between members then how will they ever be able to communicate their vision of the project? A lack of communication will result in mess of a project compiled of a heap of different clashing ideas.
Early in a project members who either make important decisions for the group or voluntarily take on the harder tasks generally have more initiative and will contribute more to success.
How often they take the time to talk with each other.
ADC/Support(Tank/Peel)/Mid(Mage)/Jungle(Initiator/Tank)/Top(Magic dmg mix).
Jk, but that's a hard question. Interviewing (for this course) would be interesting (but time consuming), since you would be able to look at communication skills. Possibly an interview (or some form of communication) between the client/student beforehand. Though, it would be hard to control students who just want to go to an easier project. Another possibility would be an interview between the professor and all of the students (lots of effort/time). Easier to gauge communication skills and see a recurring pattern, but harder to formally document and isolate/identify variables for pattern recognition.
Have the students work together in a demonstration/scrimmage environment and don't be afraid to move people around as needed.
Determine how good they are at communicating and being proactive. Not sure what the best way is, but this way definitely worked against me. THe level of engagement between me and the rest of my team was vastly different, and they expected higher grades when 2/5 of the group was doing all of the work.
Engagement, communication style, and what grade they are going for in the class.
I think the best way to predict when students will be compatible members of a successful team is one of the questions in the poll you sent out: "My ideas and opinions seem to count". I think the reason my group worked so well together is that even if there were times when someone wasn't listening/giving another's idea a chance, there were more people attentively listening and ready to address the person's concern.
I believe that more central than being friends beforehand, being told you did a good job, or knowing that your team is committed to doing quality work is the feeling of being listened to. I don't say this because I think these other aspects are unimportant, but because I think that a team that listens to the input of each member will give congratulations when it's due. A team that values everyone's input will be an environment where team members become friends. A team that listens to each other has already shown their commitment to quality work.
How enthusiastic the general group is. If a group of students don't wanna work on a project, their motivation will be lowered and make them less willing to work.
Have a wide variety of specialties. For example, in my team we have some members who were proficient in unity, some members proficient in front-end etc. It worked really well for my team and having a variety of specialties will benefit other teams.
Have polls that talk about their work flow for personal projects and school projects and match people with similar work flows and the situation that they work the best in.
Same levels of communication and availability. I really clicked the most with team members that were quick to look at my messages and respond, always attending meetings and taking an active role in planning and development. I did not get a chance to talk to some team members because they were always busy, missing meetings, and otherwise preoccupied, so this made it harder to form a connection with them.
Initial engagement. Those who were active in the group from the start were the most compatible at the end.
I think the personality assessments like the Gallup strengths were highly effective in creating diverse and effective groups. I would like to see some more metrics that evaluate personal interest (maybe past courses taken) being used to group students of similar interests. I will say the current method for grouping students worked well, I thoroughly enjoyed working with all of my teammates.
I think it is important to know from early on who are the people who take on initiative and who are the people who work well when given directions. In a team there will be a mixture of both kinds of people but when dividing the team in the subgroup there should be at least one "leading" person otherwise the team tends to lack direction. Even if it someone leading the team for purely non technical things like scheduling meetings or checking in on progress it is important to have that anchor.
Compatability is hard to measure from the get go and I've learned that definitely not judging someone too quickly is important. People tend to have different working styles or ways of staying motivated and sometimes people (myself included) get into slumps where our progress is limited. If you judge a person too harshly at their worst you are not giving them a chance to show their best. It is eye opening to see how someone can succeed even by following a work style very different than your own.
Knowing of their prior connections. Knowing someone well and being their friend automatically puts many people on the track to success because of positive peer pressure. Friends motivate each other. It is hard to get many people who are more introverted to take the initiative to get to know each other well and have trust in each other, even if extensive team building exercises are used. Expecting people to want to know each other and become friends in one short semester is a long shot.
Of course, this is not really something feasible to implement in this course in most instances, but this is genuinely my thoughts on how to build a successful team. It takes time and trust. They have similar levels of skill and attention. Everyone needs to feel valuable and needed.
I don't think there is a good way to tell. There are probably some patterns to pick up on, but I don't think any of them are reliable
Early on in the project, when the team unofficially sets the norms and standards. If you go to that first team meeting and not everyone is there, people seem too laid back and unconcerned about the work, that's how you know it's going to be a bad time. You need to make sure that everyone is as engaged as you are and that you all have the same standards and expectations for yourselves as members of the same project group.
It's tough to say. Obviously, there are so many different personalities and people with varying goals regarding college, and many times said goals are in conflict. For example, some people have the Cs get degrees mindset while others want to get the highest GPA possible. I think that a key way in determining compatibility is to put people with similar academic goals into the same groups. Those who want to achieve can do so with other highly motivated individuals whereas those who are content getting by with the minimum effort can do so with like-minded individuals.
I really think the Gallup strengths work. I know that thats what was used to form the teams and I really enjoyed working with a lot of my team members because we all had different traits that made it work.