1. The team engagement practices that were both used by my team and useful to the project were:
Our team used a variety of engagement practices including several team meetings a week, documenting work on Jira, communicating through discord, and more. I found that our most effective communication strategy was through discord, in which we could ask questions to other team members and we could read through messages to stay updated. Having one in person meeting a week was also very helpful because it provided time for us to be engaged and more present with the work as opposed to more distant communication like online meetings and online messaging. Jira was also very helpful in keeping track of who was responsible for what.
We had a weekly in person meeting that I think contributed the most to our team as both a focusing excersise as well as a bonding thing. I think that we def spent a large portion of the meetings locked in and working but also a decent portion was spent just discussing careers, school, and just general joking around. I think that this practice really helped galvanize us as a team and bring together a congealed product rather than a bunch of pieces.
They were fun to do and made us work together before going deep into the project. It was helpful. I really enjoyed them too since I am a talkative dude. ahahhaah
2 weekly meetings one in person and one online which allowed us to stay in touch and make sure everything was on track. We also were very honest on per reviews which allowed for us to figure out when we were slacking or slipping up with progress. For the most part though I think that meeting up and setting expectations early on allowed us to be engaged.
Communication! We talked a lot throughout the whole process with eachother and our clients. We set up a meeting schedule and we frequently communicated via discord. Another thing that was very helpful was maintaining a lot of documents of meeting notes, wireframe drawings, and other information in a shared drive that all of us could use.
Our iMessage group chat. It seems so simple and obvious but it was our primary and best way to communicate. When someone had a question and asked the group in this chat, it would be answered by someone almost immediately. When someone had an update on something they were doing, they would text the group and everyone would react to acknowledge it. Using a simple way of communication like standard texts means that no group member has to go out of their way to open some app like discord to check if there were any new messages.
Trying to meet right after class was really helpful for us to work on the implementation of our program just so we can talk about the things that we discussed in class and tried our best to implement those topics discussed in to our project to make sure the lecture learning point worth something. It helped both me and my team.
Jira, peer mentoring, ticket obligations, regular meetings, and constant text communications. A combination of Jira and texting meant everyone understood to-dos and who was working on what. I believe ticketing and mentoring obligations also help to keep everyone accountable, where if they had fewer contributions in a week due to exams or other obligations, they would pick up someone else's slack in the following week.
in person anad virtual meetings
Keeping track of things that are needed to do in Jira and having consistent client meetings. Having a group chat also helped foster constant communication and helped make sure everyone is engaged and understands what needs to be done.
Effective communication, weekly meetings between ourselves and the client. Branching and understanding GitLab, milestones and planning, and teamwork.
2 weekly meetings were conducted and attendance was 5/5 duing the 10-13 weeks. Team Meeting Wed (in person): Planning, developments, blockers, and other project develpments. Team meeting Sunday (virtual): Meeting to start off the week and set the agenda for develpment. Making sure we have set deadlines and having dedication to work for the project. Assiging roles based on strengths.
Meetings and calls including and excluding with the clients. Initializing/sectioning the work although this also came at the cost the group not being as familiar as we should be of other portions of the project beside our own. Demoing was really useful as a practice to get across what the idea of each portion of work was.
Honestly, the biggest win for us was setting up short, consistent check-ins. We met twice a week for like 30-60 minutes just to sync up, decide who was doing what, and make sure nobody was stuck. We also kept everything super transparent using a shared doc and a group chat so people could drop quick updates without needing a full meeting. Last thing that helped a lot was doing early code reviews, as catching issues before they got big saved us so much stress.
Using Discord. It is very easy to message someone and communicate with them, and it is also convenient because it is generally informal. It helped prompote team bonding, organizing important information, and communication.
I guess the weekly meetings with our client, but I wouldn't consider those "team engagement" practices. Unfortunately, I don't think we did exercise any real practices. Everyone just kind of worked at their own pace and only gave updates in the chat if they felt like it. Meetings to ensure we were all on the same page would have been very useful I feel. Any form of team bonding would have been nice, because even at the end of the semester, I feel no sense of camaraderie with my teammates. If there's anything I feel about them right now in the end, it's the polar opposite. Regrettably, we did not meet together, nor eat together once. :(
Weekly meetings within the team, the client, and the professor, which helped keep everyone aligned and avoid surprises. Becoming comfortable with each other early on, which made communication more natural and made it easier to ask questions or admit confusion. Clear task breakdowns where people could choose what they wanted to work on. Flexibility in task ownership; if someone aws stuck or uncomfortable with a task, it was normal to hand it off without any issues. Consistent class and meeting attendance from all team members. Ongoing communication via group chat, not just during scheduled meetings. Shared documents, notes, and diagrams that everyone could reference at any time. Using SVN and GitLab to track progress, changes, integration issues, etc. Some social interaction outside of strictly project-related work, which helped build trust and improved collaboration.
Having a group chat was helpful but also having smaller chats for specific features was helpful. We also had weekly team syncs which was useful.
My team relied heavily on strong, consistent communication and structured coordination to keep the project on track. We used iMessage for quick, convenient conversations about clarifying requirements, asking for help, confirming deliverables, and scheduling meetings, while Discord served as our platform for longer debugging sessions and virtual collaboration. JIRA helped us organize tasks, assign ownership, and track progress so everyone stayed aligned. Each member worked proactively, often beginning tasks before deadlines, and we intentionally leveraged each other’s strengths to divide work efficiently. Throughout the project, we also kept in close contact with our clients and Professor Purtilo to confirm we were meeting expectations, which prevented major misunderstandings and ensured our work stayed aligned with project goals.
The engagement practices that were most useful to the xxx team were weekly stand-ups, clear task ownership, and holistic planning and communication. After class, our team would review the work that we had done for the week, work through remaining and blocked items, and discuss strategy for future tickets. We also assigned specific, measurable tickets to each member to ensure that there is explicit ownership and therefore accountability for the key components of the project. Finally, with detailed planning and communication, we maintained a good idea of where we stood in terms of deadlines and were able to adjust dynamically to changing requirements and inevitable, unforeseeable project obstacles.
Weekly meetings in person with the client was a practice that was really useful to the project. In person meetings really helped hold everyone accountable and showed our client that we were serious about delivering. Another practice that helped with team engagement was posting updates in the group chat when a deliverable was met. This practice got us all happy whenever we succeed and a positive message was mentioned or got us more focused when something went wrong.
Meeting in person was paramount to the success of our team.
The team was in constant communication. If anyone had anything on their mind, they would put it across. We had a pretty friendly environment. We would talk about after meetings about stuff not necessarily with regards to the project. Since our project was split into 3 main phases, we split ourselves into different sub teams and worked on different aspects of the project. 2 in construction, 1 in learning and 2 in simulation. We also had one member who took charge and acted like a team coordinator/lead. He was responsible for setting up the VM and took charge of deploying it. He was also the one pushing updates to prod constantly.
We had a groupchat that we would use to talk to each other and update each other about how our parts of the project were going. We also had weekly meetings in person that were good for informing each other about what we were going to work on.
The most important thing that we did was have an in person meeting every Friday. Unfortunately, we would often have days where only one or two of us attended, which diminished its effectiveness significantly. When everyone did show up though, we did our best work. We knocked our green light out at one of these, for example. Another thing that we did that I think kept us engaged was constant communication about what we were currently working on. We almost always let our fellow group mates what our next step was and when we were/would be able to complete that. Unfortunately, that did not always translate to tickets, but it certainly helped us as individuals to have a clearer picture of the project status.
regular/weekly stand-up meetings with the team, clear task ownership and frequent communication (digital channel)s
2. If I could make ONE change to CMSC435 to make it a great class, it would be:
I personally dont like using the svn, I understand the point but personally I find it annoying to use especially because most of the professional world uses git. In addition, I think that this should be a two semester capstone, The depth into each portion of the development practices isnt fully explored. For example, we only got to do a week of AT's, in that week we got so much information that we couldve kept doing them and iterating for probably a month straight. I think that having a longer period of back and forth and learning would be beneficial.
MAKE IT LESS SCARYYYY. Yk that one or two friends dropped after the first day. The friends of mine that survived believed in the class and loves SWE. I also remember you sent an email during summer and this was a good move I really like it so you prepare us for whats coming.
Make a sperate announcements page that's not on the blog page so it is easier to get an idea of what's happening in the class. I think the blog page is too informal for actual deadlines and announcements about the class.
I would make it have more information about the specific software components we could use. I think the class overall was amazing and provided a great experience, and it would be nice if we could learn about specific software, systems, and tools that are used and have in class excercises where we could brainstorm and plan how to leverage them.
The few "pop quizzes" we had the first couple weeks of the project before we had even started coding helped to keep us on our toes in regards to thinking about certain things that we wouldn't have even considered otherwise. I think it would be a good idea to have more of those throughout the semester.
I think adding a small tutorial or guide on how to access svn and the vm. If it is on the website then it would be best it is was make it more visible because when I first started the class it was really hard for me to navigate through the website and find where everything is.
Possibly more emphasis on version control and group coding practices in git or SVN. Not necessarily with my semester team, but in the scrimmage, I noticed some students thrown in the deep end without understanding how to use these tools. In my experience, git is taught only if you take the right course with the right teacher or on your first day as a software engineer intern.
Two semester class.
Less slides and more lab or activity time with the groups (although, I can see this being a chore for people that don't particularly like their group).
I think this class is already great.
2 semesters would be even more golden; I know it is to make people take intiative but telling the studnets about the blog notifications
Give more consistent quizzes and in class assignments to incentivize attendance further. Every group would have benefitted from a greater attendance. Perhaps a graded reflection of peer reviews since peer reviews were really helpful and doubling down on this would be better.
Hmm, I am not sure to be honest because I believe that it is already a great class! This class was so organized and the professor was very experienced and knowledgeable. This was not an average computer science class. It was a very well-thought out and structured course where every week of the semester was planned out. The group formation was planned out. The project you work on was planned out. It was all planned out based on how much effort you can give to this class, which I really liked. CMSC435 was easily the best class experience I had at UMD and I would not make a single change. I learned a lot and developed as a software engineer taking this course.
Take out the first few weeks of the course. I would have loved to work on this project some more, and I honestly could have used those two weeks to do some good things and really make it bulletproof.
More nagging from Dr. Purtilo. I talked about the spec in one of my meetings with him, and he mentioned that other teams went through several revisions with him before the deadline. I think getting an earful from him (from you? You're the only one reading these right doc?) along the lines of "hey you got a spec yet" would've gotten my teammates to think more seriously about sending it in for early review. Back then, I was only one to have had that thought cross my mind, and even then I only got the idea from rumblings of past 435 students.
I get that the lack of babysitting is to get us to do the right thing and actively seek the answers we need, but I think a better balance could have been struck. You clearly have a knack for sensing when things are wrong, like that one time you asked what the deal was with only half my team showing up to lecture. Similarly, there were the emails about our failed spec. Those were extremely effective wake up calls that things were wrong and we needed to get our act together. More of those, especially since we didn't have an approved spec, would have been nice. Though again, I do get why you run the class the way you do. That's just my two cents.
I'd remove SOME of the ambiguity. I know ambiguity is an unavoidable issue we'll encounter in the 'real world', but sometimes things felt more frustrating or intentionally vague than they needed to be. I actually want there to be some vagueness in the class (so we have to think, like you've mentioned), but it felt difficult to understand what you expected of us for certain delierables, even after asking for clarification. I still remember my scrimmage team and I being incredibly confused on what scrimmage three should do, and after having multiple in-depth conversations with you, we still weren't certain. Albeit, it wasn't the easiest tool to use, but when we ended up with a ~70% on that assignment (even after getting your approval through a short demo), it felt demoralizing when we tried so hard to make sure were meeting your expectations but were met with ambiguous replies.
The same applies for the other deliverables; it was difficult to find much of what you wanted us to have on them. For the Greenlight document, for example, my team and I simply based ours off of previous teams' because of that. What I'm really trying to say is that I wish there was less guessing students had to do, especially when their grade is directly on the line. I believe there could either be slightly better instructions for major deliverables, or students could be better rewarded for going out of their way to ask questions and understand expectations (similar to how they would in the 'real world').
I promise none of this is meant to sound rude; CMSC435 has directly prepared me for my career more than any other class I've taken, I think you're one of the most passionate professors I've had throughout my college education, and I believe you care about your students' future more than most. To me, the extent of the ambiguity just felt unnecessary.
Let us vote on which projects we like. Shared interest in a project might be helpful for engagement.
CMSC435 is already a strong and engaging class, especially due to Professor Purtilo's teaching style and the hands-on lab sessions, but one improvement would be increasing opportunities for individual student connection. I think the course could be even more impactful if Professor Purtilo spent brief one-on-one time with different students after class (perhaps 10–15 minutes with a rotating student) to better understand their perspectives on the course, their interests in industry, and their overall academic experience. This personal engagement would not only help students feel more supported but also create a richer learning environment where students can connect classroom concepts to their long-term goals.
Rather than using personality traits and performance in the class to construct the teams, I would have preferred the opportunity to choose what projects seem most interesting to me. I understand that this is not always realistic because many people may want to do the same project but some input would have made projects more fun.
Ability to pick teammate or switch teams. If you are unable to work with team or want to work on a different project I think there should be a way to switch. There were many interesting projects in the class and I wish I had an opportunity to rank the projects by the ones I wanted to work on the most!
I wish there was more of a push to invite initiative from the class. I feel like some of the class, like any class, just run on autopilot at the start even if they may take more initiative later once learning about the class. I'm not sure how to try to "turn the autopilot off," or if it is even possible, but I think if it could be done it would be beneficial.
If I could make CSMC 435 an even greater class, I would make the class span another semester. I wish I learned more about software engineering practices through lecture. While the professor did a great job at attempting to cover maximum content over the semester, I feel that there is a lot more to cover and even as mentioned by the prof and there simply wasn't ample time. The end result of the project would have also been a lot more impactful and meaningful to students and customers if this was the case.
I would make it a 2 semester class.
I would prefer to have class MWF instead of TuTh. I would prefer the more frequent check ins (both by the professor and with my group) and am willing to sacrifice class length for that. In particular, when we met with our groups, we were either done in five minutes or went way over the end of class. This means that even if class time was shorter, we'd still either be done before the alloted time or we'd go over. My real ideal class setup would be the same as when I took ENES102 (I think) where it was 50 minutes on MW and then a 2 hour discussion section on Friday that was actually just a 50 minute lecture with a group work section stuck on at the end. I think the two hours would allow us to have more varied labs as well as allow you to give a full lecture and still have a lot of team time.
A stronger emphasis on taking initiative and being exploratory as this is a very new and often contradictory behavior for most people. I think this needs to the very first focus of the class to get people in the mindset before scrimmages.
maybe better synchronisation between the client and the professor; sometimes the client would add new features or requirements (this is after we have defined our initial deliverables), so we were still doing a lot of development work later into the semester, which was at times perceived by the professor as delays or procrastination on our side. but these are edge cases, overall the experience was pretty good and it was good we got to have meetings with the prof and client together.
3. The one thing that most gets in the way of me doing my best work in CS (CE) here at UM is:
One thing that got in the way of me doing my best work was having to juggle the intense workload of this class with 4 other classes. Although this is to be expected and there are several warnings about this at the beginning of class, I still struggled with this.
The advising stinks.
The amount of students on the field. That is why I am taking more than one degree and finishing more than one minor so i be top candidate for future jobs. Other than that we have great program with experienced professors like you Dr. Purtilo that makes CS a great program and if you survived means you are one of the best.
Extracurriculars and jobs/internships. I think that I am a proponent of having a life outside the CE program and that means sacrificing some time that would allow me to do my best work in the program.
Probably other commitments. I think it's easy to get busy on campus, so try to make sure that you leave a lot of time in your days to do your work. I also think some great advice is to protect your weekends, because it's very easy to burnout if your continously working all the time.
Myself. These last few years my social life has been pretty much dead (which I'm fine with for the most part) so I only really have myself to blame when I can't stay focused on work.
The one thing that most get in my way of doing my best work in CS is basically other courses and if in group environment then not having every group members involvement.
I think the thing that gets in my way of doing my best work in CS at UM is the numerous gen eds assigning busy work. Assignments that produce little value are frequent at UMD and get in the way of more valuable and difficult classes. You could pick all hard classes but that is a hard sell to most students. I'm unaware of the solution to this but I fear I've optimized for GPA instead of genuine value which is supported by the school.
Work and other classes
Not being able to get into the classes that I actually want to without them filling up before my registration time. Also having engaging activities and not just monotone lectures. Especially in the 400 levels, discussion periods are removed which I found sometimes helpful to communicate with peers and foster idea together. More class should probably take times for in-class group activities where people have to get together to solve a problem (not those group activities where its just ice breakers and time fillers but actually something with some sort of stake).
Myself, I get lost when having to do things that I am unfamiliar with, and I think that was what set me up for failure.
The lack of advising and realstic framing of the major. I would hope that advisors were people who are actually know about computer science and cna direct me towards specific field and companites that I cna target instead of me just mass applying.
Which is what alot fo my peers are doing.
Poor grade distribution between tests and project. Projects needed to be weighted at the maximum and needs to be in more quantity to be able to refine the work/experience.
I believe that would definitely be juggling heavy workloads from multiple classes at the same time. A lot of CS courses have big projects and exams that overlap and when deadlines stack up, it is very difficult to give each assignment the focus it really needs. It is not the difficulty, it is the timing.
Consistency. A lot of classes feel like they are designed for being done in sprints that only unlock every few weeks. Let's say there's a project that takes 20 hours. I'm not going to do it over 20 days? I'm going to do the project and then worry about the rest later. Then I have kind of a gap where I forget everything. Honestly, I think its just a skill issue.
Personal burnout and exhaustion. By time I got to my 400 level courses, I was sick of school and wanted it to be over. I don't mean to come off as edgy, but I don't know how else to put it. This was fueled by my severe lack of a fulfilling social life and engaging activities outside of my studies. I wish I had found solace and community at the university, but it was difficult to do so as a commuter and general introvert. Better emotional wellness would have kept me going at my full potential, but as was, facing assignments that genuinely felt impossible was unbearable.
I think too much of the curriculum is theory-focused, and that's why I took CMSC435 in the first place. I really wish software engineering was a track here, and I would've done that without a second thought if given the choice. In my opinion, "my best work" would be work that directly prepares me to enter the workforce, and as I've been interviewing for full-time jobs, I've realized that employers genuinely don't care how much theory you know. They need to be able to see that you can apply concepts to something tangible. And this is one of the few classes I've taken here that does that; the vast majority (especially the mandatory CMSC Degree courses) don't focus on that at all.
Course load as a CE student it can be a lot. God forbid you would like to add any honors program or activity and you are drowning.
The biggest challenge I face is staying fully motivated when the material covered in my CS courses does not always align with the tools, technologies, and workflows I use in industry positions. This disconnect can make it harder to appreciate the immediate value of certain academic topics, even though I understand their long-term importance. Despite this, I remain committed to attending lectures and engaging with the material because I recognize that foundational concepts may appear later on, and having a strong base ultimately makes me a better engineer.
I think that the thing that gets in the way of me doing my best work in CS at UMD is the emphasis on assignments that are just time-killers to just keep students busy rather than assignments that have tangible outcomes and involve critical thinking. Busy work kills around 20-30% of my time each semester and I feel even after finishing them that it did not contribute to learning outcomes. That was one of the main reasons I took 435 because I prefer to work on projects with impact and real-world scope that will actually prepare me for my career.
For me worrying about course grades gets in the way of me learning the most because I start doing work to get the best grade rather than learning the most. I start studying just for the exam format rather than trying to understand the material holistically sometimes for certain classes.
Needing to take 4 classes every semester. If I could take just this class alone for a semester, I feel like I could do so much more. I do best in summer semesters for this reason.
One obstacle I face in the CS program is how many different requirements, paths, and opportunities there are. Between prerequisites, electives, specialization areas, internships, and upper-level course expectations, it can feel overwhelming to piece together the big picture of how everything fits. Another challenge is that I the syllabus is designed and awards rote learning in many classes. Its feels like a competition of how much can you remember as opposed to being along the likes of how did you understand. Every semester I forget what I learned the previous semester. Mostly because I don't revise it though, but also because I spent the last week prior to the exam cramming as much I could to get that "sweet" A. Also the noise and fear of AI and not being able to cope with it, fearing of not finding a job post graduation etc.
The classes not having enough seats which forces me to take classes that I don't want to take.
Technically what gets in my way the most is myself. Related to that, I think that the thing that most consistently causes me issues in my degree is the lack of individualized disability services. This is primarily a consequence of UMD being such a large school. I have audio processing issues as well as migraines. The audio processing issues make it so that I frequently miss what professors are saying, especially if they are also writing formulas at the same time. In college, you don't learn by copying what's on the board, you learn by writing down what the professor is saying. Unfortunately, my processing issues mean that I very rarely get the full picture of what is being said until we are already past it, and then I miss the next few things. UMD doesn't provide any accomodations that actually help with this, so I end up cobbling together random accomodations to try and make it work. I can do fine in classes that are more lecture focused from the start, which are generally more conceptual classes. With technical classes, any form of written note works very well for me, so I often end up reading the textbook. My biggest issues tend to come from classes that cover multiple different textbooks and professors that speak quietly, because I am unable to grasp anything said in class unless I verbatim write what they are saying and reading the textbook doesn't actually help. Usually, when I do poorly in a course, I am aware of what specifically I should have done better at every turn, but the handful of classes that I've had like I described above often leave me feeling confused and depressed.
The required set of classes is illogical at best. The concentrations the department provides hardly feel like an actual concentration and there are several courses I was required to take that are completely unapplicable to my goals.
Being an exchange student at UMD this is my first and last semester here. THe nature of my selected coursework and schedule actually allowed me to pursue multiple projects at the same time. so i dont have much to say here haha! the only actual blocker I faced was when my laptop got damaged the week before thanksgiving and I have been working on library PCs since then (which is a great provision from UMD)
4. The obstacles that prevent me from knowing what is expected of me in my degree program are:
The advising stinks.
Fear. The stereotype of the major that is difficult and impossible and you will not survive and switch to info science. All that fear is an obstacles that prevent student from knowing what is expected of them in the program. In my case I never doubted myself and even though i had this fear but being an engineer is rewarding that is why i kept pushing this fear away and focus on the present.
Testudo's website being down at certain times in the past few years prevented me from knowing what is expected of me in my degree program but it seems like that has been fixed.
Probably lack of commitment to course planning at the beginning. I remember as a freshman I had no idea what classes I was gonna take later on in my career, and because of it it was planned a little poorly. Going forward, I think that if I were to give some advice you should plan ahead of time, as in decide what courses you will take throughout your whole college career during your freshmen year. Then, leave some room for different courses if your interests change, but keep it relatively similar.
Unclear expectations in each course. Most I've taken have just been "do the work and get a grade" and that's it.
I don't think there is anything that prevents me from knowing what is expected of me in my degree program. For what obstacles that prevent me from knowing what is expected of me in my class is that the information being posted on the class website and us not being notify unless we keep on checking the website. I know it is our responsibility to check the website everyday but sometimes we can forgot and miss a important due date.
The advisors are probably the obstacle to knowing what is expected of me in my degree program. While I mostly figured things out myself, I know many friends who have been burned by listening to the supposed advisors' advice.
No career north-star in class content
All the classes after the 300 levels don't have particular order or deep connections with each other. This makes it feel like completely separate things at times and feel more like temporary tasks rather than valuable learning.
Abstraction. I need to learn how to deal with the unknown a little better.
Now it has gotten better I feel since computer science has so much influx but when I started the image I had and what it actually was were very different. Although I grew into it I would love to come back tell students about what they are getting into.
The lack of direction in upper level courses. There doesn't seem to be an incentized path as there is in math courses. At least knowing what the goal end classes would alleviate this somewhat.
Sometimes the requirements feel scattered across different websites, advising sheets, and departmental announcements, and they don't always match perfectly. Prerequisites change, electives get swapped out, and it's hard to tell what's current. I usually figure it out eventually, but it shouldn't take detective work.
Honestly, none. Everything is pretty clear with a few Google searches.
Nothing? If I'm understanding the question correctly. In terms of raw degree requirements, the CS ones are pretty cleanly laid out on the associated website. Even with many options for 400 level courses, I didn't have a problem picking which ones to take while satisfying the requirements. If the question refers to individual things I believe I should learn in my degree program, then I would say it's quite vague. I'm in the general track so it feels like I'm just given the freedom to explore whatever topics I'm interested in, which I have enjoyed for the most part. But as for any concrete skill whatever the bigwigs in charge of the whole university operation think I should be learning, I got no idea.
I believe there should be more guidance on how skills and expectations translate across classes, or there should be more structure based on an overall standard rather than based on individual classes. If you pick the "wrong" classes, I think you could graduate with a bachelor's degree in computer science with very little meaningful knowledge. Especially with regards to the general track (which I'm doing), you can pick classes that have no overlap, and by the time you graduate and get a job, no matter what that job is, you wouldn't have much knowledge in it. It makes it difficult to grasp how much I should know or how to know if I chose my classes well.
CE does a good job with the degree plan tracker however I do wish we put more emphasis on the learning outcomes of individual courses.
The flexibility in choosing upper-level electives can sometimes make it difficult to know what is truly expected of me in the degree program. With so many course options available, it becomes challenging to determine which classes will be most useful for my career goals and which ones contain essential knowledge I should have before graduating. This lack of a clearly defined path can lead to uncertainty about whether I’m making the best academic choices or missing out on foundational skills that would benefit me in the future.
I think there arent any notable obstacles because the University makes it very clear how to obtain all the learning objectives of the area of study and graduate. I think for CS, the less intuitive part is how to learn software engineering principles outside of code. Things like testing, planning, communication, tech stacks, system design, etc. These concepts are only attainable through internships, research, and personal projects and the University does not really discuss this in depth or give a cookie cutter way to obtain these learning objectives. Part of becoming a successful SWE is going out of the way to pursue these opportunities but I would not say that is much of an obstacle.
I feel like I understand exactly what is expected of me in my degree program. Other than having to take some classes that I'm not the most interested in I feel like I have a good opportunity to take the classes I truly want to take.
Expectations vary a lot between professors and classes, so the level of depth or workload isn’t always clear until I’m already in the middle of the semester. This doesn’t stop me from progressing, but it does sometimes make it difficult to feel fully confident that I understand the requirements and what I should be prioritizing. Some professors tend to be way to mathy for a cs class others are more project oriented etc. I think its also unfair that when the same course it taken by 2 different professors, the assignments, exams etc are so different and one can feel much harder than the other. Harder is not necessarily the issue but more the end result of what the student might have learned might vary.
The lack of help from advising, the system of categories they have for the cs degree requirements, and the lack of preparatory classes for most of the higher level classes.
For me specifically, it is probably just the convoluted nature of my enrollment. I entered as an Engineering major in Fall 2019 and completed 2.5 years of it. I added a CS major the semester before I dropped out (I think). I was out of school for 1.5 years and came back in Fall 2023. I then dropped the Engineering major and added a Math major. There are a lot of changes that were put into place for the Computer Science degree that started after I was enrolled as one (technically). I also have way too many credits and had to be granted a bunch of exceptions regarding milestones. A lot of the math credits also double count for CS, and I have to be careful of that because I am completing a double degree and not a double major. Mostly, I just rely on my audit and my incredibly early registration date to guide me.
The advisors are not advisors and in my experience rarely advocate for students resulting in classe that are useless or out of date but frequently advertised while classes that have considerable value go under the hood.
Perhaps my own laziness or hesitation to reach out to professors or classmates to seek any clarification or guidance.
Something I struggle with is the culture of not being able to ask questions if there is something confusing. Not necessarily something I felt in the class or in my group, but sometimes I find that people in the CS degree program are a bit elitist with their knowledge and frown upon people who might need more help or more clarification, which in my opinion fosters a somewhat toxic learning environment.
5. The best way to predict when students will be compatible members of a successful team is:
How they act from the start. If they are immediately talking and discussing creating communication channels, initial plans, etc. That is the best predictor of a teams success. That is because at the end of the day engagement is the biggest key to success compared to all else. Having people who can put the team above themselves. is the most important thing that you can have.
Trying from DAY 0. Since the time the student click register, they start looking into the materials maybe contact the professor send greeting email or whatever. Shows to class every day and stay after class to talk and chat with the professor. Also another way to predict would be the effort spend.
I think that tickets should be submitted in the first 3 scrimmages and that should also be used in predicting whether a team will be successful.
Is when they are able to comfortably express and communicate their opinions and work efficiently towards solutions. I think groups that are willing to comprimise and explore alternatives with effective communication are those that would succeed the most.
The way they act outside of the class/project.
I think the best way to predict when students will be compatible members of a team will be based on their CS background and compatible time that will work for all the team member, and maybe after selecting team having a exercise that will assign roles to each members of the team would just clear up any confusion and keeps the team on right track.
To measure their engagement and passion for the class. I think this is successfully determined via the scrimmages and ticketing, with the difficulty of determining who's faking it. The other question is whether you should spread under performers out so there is always a slacker, or doom a project from the start, and group them together.
communication effort.
Their ability to communicate and delivery on their promises.
Personalities, tendencies, and people who take responsibility.
Not alot of awkward silences. self motivated -> meaning they don't need the team to be motivated all the time they can work for themselves and be motivated to succeed. Being passionate about a project no matter the scale (we got kinda lucky). Being able to laugh together and make fun of people we don't know ( at times the class). Treating everythign as a collective and reminding each other of little assignments for the class so no one is missing anything.
Student work schedule. Specifically for my team I found the biggest struggle was between when time investment/committment happened. Goals and drive are also very important as I felt there were disparities between group members in this regard as some were looking for more out of the project than directly explained by the clients (ie. bare minimum vs. looking to satisfy). Since we used gallup at the begginning of the year the best way to compare this is seeing personalities that fit more the mold of "getting it done" being put together apart from groups more aligned with trying to look past what is directly asked.
I think the best predictor is their communication style and reliability, which I think matters much more than technical skills alone. If someone responds on time, is clear about what they can or can't do, and actually follows through, I feel like the team will run smoothly. Even a quick "Hey, I'm stuck on this part" goes a long way. Pairing people based on communication habits and work pace would probably lead to the most successful teams in my opinion.
I have no idea. Somehow the team worked out pretty well.
How often they communicate and how enthusiastic they are about the project/each other. I think what defines "compatible" team members is how much they want to work together and how aligned their goals are, not necessarily their personal traits (though of course that never hurts). A list of green flags to me would include showing up to meetings, being active in the chat, following through with what one says, and active listening/consideration of what others say. All these would bring everyone together on the same page and demonstrate enthusiasm. Demonstrate that they care. When it feels like everyone is in the game together, that produces high morale, and thus a successful team. I can speak from my experience with this class. It felt like everyone had vastly different goals and investment levels for the project that we felt way too scattered as a result. I think if more individual members frequently exhibited those green flags I mentioned, the semester would've had far smoother sailing.
I think you have a pretty good structure for measuring this. I believe it's mostly based on whether students show up prepared, participate regularly, communicate consistently, and follow through on commitments. If students perform similarly in those caregories, they'll likely work well together on a team.
Shared interests, similar technical skill levels, and comparable clarity in communication.
The most reliable predictor of whether students will work well together on a team is the presence of active, consistent communication. Teams that communicate openly are able to clarify expectations, assign tasks efficiently, ask for help when needed, and maintain a shared understanding of project goals. Good communication naturally creates accountability and collaboration, while its absence is often the root cause of team dysfunction. When students are willing to talk, coordinate, and support one another, they are far more likely to become successful and compatible teammates.
I think the best way to predict when students will be compatible members is just through shared interests, passion for the product and learning, and clear communication throughout the development process.
I feel like a students GPA is a good indicator of how serious they are about the program, and students with similar GPA's likely have the same outlook on computer science. Aside from this numerical metric I think experience level and courses taken are also good indicators to predict if members of a team will work well together.
If they are willing to meet in person. Unless they are a commuter, then its probably how talkative they are.
It's data and history. With AI being the hot topic, predicting anything needs a good amount of history. So as done so in CMSC 435, with various small activities, scrimmage groups etc outcome of the team placement is almost spot on. If the class is smaller, you might not find someone you know. So forming random teams can be hit or miss. But teams formed after genuine deliberation is often spot on.
The best preditor for if students will be compatible members of a successful team is their personalities. The better they get along with each other, the more successful they will be as a team.
I think that examining styles of communication can be incredibly important to success, especially virtual communication. In person communication is much easier to tell when things aren't working, and people often feel more comfortable talking face to face in general. Over a screen, it is much easier to create a scenario in which no one talks to each other and everyone is resentful. Although the ideal scenario is to increase in person communication, even if the team meets every day, a significant amount of discussion will still happen virtually.
Can you take criticism? Can you accept that you will be wrong sometimes and be able to think objectively about a problem? Can you put yourself in the life and experience of a teammate and/or user?
I think the best way I can put it is having a good personality and being positive and respectful. I found that my group was very positive and respectful in our communications, but I can imagine how that can quickly cause tension and issues completing a project. I think having at least one or two members who are very technically knowledgable is absolutely necessary to have a successful group, otherwise the group will be very lost and unmotivated.
if they laugh together