1. The team engagement practices that were both used by my team and useful to the project were:
Meeting frequently (weekly, and if not weekly than at least bi-weekly), talking about common interests to actually get to know each other and be comfortable enough to work efficiently together, and getting pizza together! Getting pizza with my group was the first time I felt comfortable enough to speak with them like friends, and it made doing work together and hopping on meetings much more enjoyable.
Weekly in person meetings helped a lot for us to mesh with each other
One of practices was sitting down in person to do work. When doing this, the ability to directly converse with members and their code made debugging and understanding the overall project much easier. We only did this a few times but it was mandatory for us when finishing the project for the CDR.
My team and I held meetings often to discuss what was going on, where we were at, discuss any blockers, work together, etc. It was sort of like a mix between a SCRUM standup and a working session. - We had a "What Did I Do Today" channel where everyone was required to send a quick message at the start or end of their day on what they did. This was useful for our teammate advice at the end of the week, but it also acted as a way to hold us accountable. Like nobody felt good saying "nothing" for their response, multiple days in a row, so it forced us to work harder and more consistently. - We implemented many team policies at the start which I think seriously helped throughout the team project. For example, we all aimed to hit 10 hours with a minimum of 6 hours per week on the project, and there would be consequences if we didn't hit them. Nobody was allowed to approve their own merge request and each merge request had to have an issue with it. We utilized GitLab's issues to the utmost potential and used it especially to keep us organized.
Communication using discord so that everyone could talk together and also unlike just texting for example discord ppl could also do from laptop or any other device connected to the internet. Also by using discord ppl were able to have impromptu meetings in a voice channel and screen share to fix any problems they are having in their project. Also along with those impromptu meetings since they calls are accessible to all people can join and help even if not explicitly asked to hop on a call for example if I was free but saw that some of my team members were on a call I might join and see if theres any way I could help them. Additionally, the team did every week put out polls so we would know when the best time for a meeting in person would be(in addition to any impromptu meeting)
Also outside of direct communication we had a "what i did today" to hold people accountable and make sure everyone knew what they and others did for the day so would be easier to track.
Frequent team meetings, keeping track of tasks in Jira, and communication in Discord.
We went bowling once to boost team morale before CDR. I'd say it worked pretty well. Besides that, in person meetings were always a lot better than virtual ones.
Weekly in-person meetings. weekly online meetings within team and with client. Team meeting after every client meeting. Discussed things outside of scheduled meetings on discord. We talked about things other than the project, that seemed to help ensure that everyone was engaged and on good terms.
Our group had several weekly meetings which held the group accountable for the work that needed to be done because we had to not only show it to the clients, but also the professor every week. This meant that we knew we had another demo just around the corner basically at all times, and prompted us to keep up the effort.
The mentoring tips also were a big help in the beginning of the semester. I think once we got closer as a team, they became less necessary since everyone was already well acquainted with how the team functioned and worked within the parameters of the team.
Keeping constant communication daily to ensure that everyone is on progress. Meeting in person at different places to ensure that team chemistry improves.
Meeting in person was probably the best as it was able to make sure everyone was on the same page as well as had everyone locked in instead of just going through the motions of a call. The peer mentoring was also helpful as it made you think about what you have done every week and kept you accountable.
Consistent communication to discuss what is going on during the project, which was something similar to Morning Standups. How my group did this was by meeting 30 minutes prior to our Monday Client meetings, and time after Tuesday and Thursday Lectures to discuss and plan out what each person had done and needed to do.
We had two weekly meetings: one on Wednesday with our clients, and one for only us on Friday. We also had a group chat where we would update each other on progress as needed. The client meetings were good to keep up to date with our responsibilities and get feedback. We would often stay longer after the clients left to talk about their feedback, and other work. In person meetings were not super useful for actually getting work done, but were nice to improve our relationships.
Regular group and pair meetings with clear agendas, assigning tasks based on individual strengths, scheduling meetings with our stakeholder to ensure their expectations are met and to clear up misunderstandings, and maintaining accountability through time logs (we created a Discord channel where everyone reports their work at the end of the day, even if they didn’t do anything that day).
Using a Trello board to track tasks and group chats for frequent updates on progress.
Our team mainly used a group chat to communicate with each other. At the beginning of the semester, we set up a fixed time each week for our team and client meetings. We also created a joint email address for the team to make it easier for us to all be contacted at once by our client, the previous team, and Professor Purtilo. In person meetings also allowed us to get really close to each other as we would learn more about each other by talking about things outside of the context of CMSC435.
GitLab issues: We put the tasks that needed to be done into gitlab issues and marked ourselves as assignees for the ones we would work on. The time we spent working on each one was logged within the issue with a description o time spent. Discord Channel: We made a discord channel called #what-i-did-today where each day we would summarize what we had done that day and briefly state what we wanted to get done the next day CI/CD: All our merged changes were automatically pushed onto the our live site
A big engagement practice leveraged by the team and useful to the project was working in person. All though working from home was convenient, it proved difficult to communicate from there. Software engineering is an exercise in communication, which made working at home not viable if we wanted to practice software engineering. Another engagmenet practice that was good was when we would meet in person, begin by writing out a checklist of things we wanted to get done, and potentially adding to that as needed throughout the session. In this way, there were a set of goals to work towards and to stay focused on.
Weekly meetings with team and the client, some fun stuff at terpzone, agile sprints stuff
Software Engineering is truly an exercise in communication and that was definitely the key to our team's (partial) success. Communicating among ourselves - through messages and team meetings - and taking responsibility for different tasks was crucial to keeping everything running smoothly. On top of that, communicating with our client to understand her expectations and making sure we were on the same page about what was possible with the app was equally important. Without this, I don't think we'd have gotten as far as we did.
Keeping team members accountable to the team by mentioning what they did that day (including saying they did nothing).
Trying to have or at least emulate daily standups. We used a discord channel called 'what-i-did-today' that people would write in daily to ensure members were engaged and up to date with the status of the project. Aiming to have two meetings a week with as many members as possible. Having the occasional in-person meeting with pizza, especially in the beginning, before big deadlines, and after to celebrate.
the #what-i-did-today channel, which was an easy way of gauging what the rest of the team was doing while also pushing everyone to do even a little bit of work every day. Also, actually using most of the features on GitLab, from tracking time to the issue board to merge requests. GitLab was a key tool that we used to stay organized and efficient.
had at least 2 meetings a week (Wednesday client meeting, oftentimes we would meet for at least an hour the client meeting as well, to talk about current progress and next steps + Friday team meaning, which were in person, and allowed us to bond as a team, work together, and build friendship). discord and I message group chat for communication and immediate updates. meeting as a group after every 435 class. Trello to assign tasks and monitor progress between team members.
I think one was collaboration, it didn't matter if you worked on different aspects of the project, but people were willing to help each other out on certain tasks and sometimes did work for other teams. I think another thing that we did well was set goals for each sprint. Everyone knew what to work on, and having achievable goals made people more engaged. Its easier to work on something and have motivation to do it when you know specifically what to do, rather than something more abstract and ambiguous.
I think stand-ups were useful. Teammates talk about what was accomplished, what are some issues, what needs to be done. We didn't do this as often as I would have liked, but the times that we did, I got a lot out of it. Before the CDR, we all went bowling, and that got us all together and feeling good. I also think leveraging agile practices kept up more engaged because we knew that we had a client meeting on Wednesday and we couldn't just show up empty handed.
We had a facilitator for meetings (xxxx) who would lead team dicussions. We also had hard set team and client meetings. Just overall, being polite and nice with each other while keeping it fun helped motivate everybody and create a good mood within the team.
We had frequent meetings which allowed us to plan stuff out was pretty helpful in keeping the team engaged. Furthermore, our team had a GitLab which allowed us to keep track of team member progress and keep everyone engaged.
I think the best pratice was being willing to be unserious. While there were many moments where we focused and did nothing but work on the project. The willingingness to be fun made everything feel better. After the many all-nighters, actually liking the people I have to spend all this time with was huge to morale. We had moments where we deccided to take a short break and just chat. Espically early one, when making the team charter, it was a big boon to be unserious when we could afford to.
The in person meetings and the very active Discord server were the most useful practices to our team. They truly helped with our team engagement and helped us all stay on the same pace to bring value.
Setting team meetings to be every week. We had team meetings in person on Monday which helped plan for the upcoming week. Then we had client meetings on Wednesday to ensure our client was up to date on what we were doing and what they expected of us. We also held mini meetings on Thursday online to check in with work to see if anyone had issues and to reiterate what needed to be done in case anything was completed during the past few days. Lastly, we had spontaneous meetings near due dates for big assignments like the CDR to ensure everyone was on the same page and was working towards a common goal.
Weekly meetings where we first met together and then met with out client were super helpful. Stand-ups allowed us to all say what we were working on/what progress we made and where we might be stuck. We also go to put our work together so that we could accurately update the client. This kept all of us on one page and engaged.
2. If I could make ONE change to CMSC435 to make it a great class, it would be:
Make it slightly less dependent on groups to hold their team members accountable. I think that some students get the feeling that they do not have any work to do because there is no specific instruction from the teacher, and although the point of the class is to navigate your way through the project and overcome real-world obstacles, other students’ short-comings weigh too heavily on the rest of their team.
I would make the scrimmages one week shorter so we could have more time for the actual project
To provide resources for how to deploy websites on the VM, specifically how to connect the project to the web address (e.g. Vidal.cs.umd.edu). This was the scariest part of the scrimmages and was a task where some guidance on it would have been nice. The process was cool but the short timeline especially made it nerve racking.
I know Professor Purtilo heavily encouraged us to do it on our own, but when you have a big team like ours (SEL), it was really hard to get together just to bond or hang out. So I think a nice change to make to the class would be after the scrimmages and after we know our new main teams, that first class (after knowing teams), we just sort of get together, break the ice, introduce ourselves, and just get to know each other.
Assignments -- they were pretty infrequent which while may be good for some students also means that grade isn't gonna change much for months at a time so like for me I think my grade is not the best so since the cdr a month ago Ive figured the final and team report which I assign each have decent weight in class grade ; also with assignments on stuff such as in class quizzes I did not feel that any feedback was really given
Slides not being posted for whatever reason makes it so have to try and keep a semesters worth of information in your head while students are also dealing with 12ish other credits worth of classes and the in class quizzes add more stress to the class then help remembering stuff to me and if the quizzes are just for attendance could just say that or do it another way
I personally felt that being in such a large group for the semester project even tho I always did what my teammates asked of me and tried to help when people had help Im worried about how much my impact on the project will be weighed and judged and how my final will go even tho I know what I did and what the overall group project is I believe it shows in the costs doc or something that I had the least hours worked but I think I always did what was asked of me and am worried that as a result of this might have less to write about than if i was maybe on a smaller team or something cause even when planning usually like 1 person was assigned per module and my role was help when needed like one time when roles were spelled out for what to work on my role was literally "XXX: He'll do whatever you tell him" and so there was minimal stuff for me to do even as i asked if ppl needed help that week even in my weekly advice some ppl said like I didn't do much and others were like he helped when needed to but that was literally my role so may have been detrimental to my success in this class
Slightly more formatting in the class blog, often times key pieces of information is hidden within a larger block of text. It can sometimes be difficult to find that information again when looking back at the blog in the future, maybe just a title of what information is in each post?
We had 'team time' during class on Thursdays for a few weeks. I would've found it useful for there to be some sort of team exercise to get us thinking together.
Make it at least a 4 credit class. The workload for this class far exceeds any other class I've ever taken and I feel like only receiving 3 credits is pretty annoying.
I would probably only change the duration of the scrimmage project, and make it even shorter. Realistically, the project can be banged out in a night or two by one person, so giving us as much time as we get does not set a realistic standard for the main project, which ultimately required significantly more work and time to pull off, to the point where I felt very pressed for time, despite having already put a significant amount of effort into it.
Shorten the amount of time for scrimmages to give slightly more time to development and proposal writing
Making the assignments a little bit more clear of when they are due and when we have one. I've missed or almost missed assignments because they were listed in a long blog post. So making maybe just a place were the assistants were by themselves so it would be easy to find and know when you have something would be great.
One thing that I would change to make CMSC435 a great class is adding more interactivity to the actual lecture. What I mean by this is including more activities similar to the self driving car discussion, as this allows students who are less likely to speak publicly, to at least have a space where they can try and convey their thoughts of what is being taught.
I would like the scrimmage portion to be much shorter, so we could have some additional time for research, possibly even additional testing after implementing feedback from acceptance testing. I also did not see much value in the Gallup survey we had to pay for. Are there other similar instruments that are free? Maybe they are not as detailed but I did not enjoy having to buy a personality quiz for $25.
This turns out to be the hardest question to answer because the course already exceeds my expectations—this is my first time taking a capstone course, and it's been a fantastic experience. Perhaps if you brought more snacks to the room, it could add an extra layer of comfort and fun to the learning environment!
Acquire data on, specifically, what programming languages people are familiar with as trying to both do a project and pick up a new programming language aren't ideal.
I think that the time spent on scrimmages at the beginning of the semester could have been cut down a little bit to allow for more time later during the development and testing phases.
I would add early on leadership focused exercises and leadership theory. I have received significant leadership training in my background but not everyone is familiar with what it takes to be a good and effective leader and bring a team together to achieve success.
One change to make CMSC435 a great class would be a doing a better assessment of how much manpower each project required. I know that for the plants project specifically, we could have definitely used more people to help gather and annotate the dataset, because having to balance that on top of integration seemed too overwhelming.
I think having a lighter version of this class and provide to freshmen would be nice. They can see what they are getting into before acc get into it?
One thing I think would make a huge difference is having a longer timeline for the semester projects. From my experience, having some dedicated time at the beginning to do research and build out a realistic greenlight proposal would help a lot. This would give teams a chance to figure out what's actually feasible before diving in too deep. I know this was an issue for my team, but making it a required step could help everyone. Another thing I'd suggest is making the projects independent of work done by previous groups. For us, integrating into an existing tech stack was really difficult, and it limited what we could do with our model. Starting fresh would give teams more flexibility and creativity. Overall, the course is set for the students success if followed thoroughly.
Maybe a little bit of guidance on expectations for certain critical junctures for the project.
I'm not sure, it felt structured pretty well. Maybe if there was a lab to practice requirements gathering (maybe our lab will be useful!) earlier on students would have an easier time getting necessary details out of their client.
Making the lectures more interactive, which was the aim for the SEL project. Our typical lectures are 75min of Prof Purtilo standing there and speaking. While I love to hear what Prof has to say, 75min of lecturing can get exhausting, so having activities sprinkled throughout the lecture would help with retention a lot.
the timing of the different things we did in class. I remember we spent the 2-3 weeks of class doing exercises before starting the overall capstone project. I would change that to either cutting that to one week, and starting on the capstone project from week 2 or not spending as much time writing the proposal. This is because I felt like we spent a lot of time on the proposal, which made the development process feel very rushed. Moreover,there were multiple challenges our team didn't forsee during the proposal but encountered during development (RTStruct to Seg Conversion for example) Overall, I just wish we had a little more time on development of our product.
I think i would get rid of one of the scrimmages, i think having an extra week to build would be helpful
More talks about motivation and accountability. I think more talks about the slow points in production is important. When one teammate slows down, then another, and another. Once everyone is in the that mindset, it is very hard to get out of.
I think some of the lecture topics were drawn out too much. I really liked the classes where the in class lecture would be around 1 hour and then the rest of the time is for the teams to meet. I liked it because My attention span caps around 1 hour Having more meeting time with the team helps the team make progress better
I would maybe make one day of class per week to allow for team work. Our group was 10 people and it was nearly impossible to meet in person to have quality in person work time. This would allow us to discuss the project for about an hour and half in person and face to face. I like that we got some time in class to meet but I would have appreciated some more time as those were the times we got quality discussion and progress going.
I think that there needs to be some more work to make each project feel even. I am aware I could be biased, and from the outside it doesn't look like this, but it was really disheartening to see what I percived as easier project compared to my own. It felt like the standards were even across the board, which is a good thing, but then group A will have to spend signaifigantly more effort and time to achieve the same reward. The other thing was that I really disliked the group sizes being signfigantly uneven. It felt really bad to have moments of "If only we had one or two more people" when another group that appeared to not need all the extra manpower is chugging along.
I want to say that emotions are high, and maybe in a week I will think differently, but from my perspetive it felt a lot like some groups got soft-balled and others were on an endless amount of catch up.
I think there could be some clarity on the git situation. It was definitely my fault to just go ahead and move to GitHub, but I think it should of been explicitly stated that you could provide a GitLab instance.
Probably remove the advice section in the mentors site. I get it, it's supposed to be for giving advice to team members for how they can improve, but I had no idea what some team members were doing since I don't want to micro manage them. I trust they will get their work done on time and if they need help they will ask/communicate it to the rest of the team so we can help. Getting points for filling out those advice sheets did not make too much sense since unless you were everywhere all the time, there may not be any slightly negative feedback comments to be made.
While it was super cool to see what they were working on, perhaps set days where we presented to each other in smaller groups and then had to give feedback about what we like/disliked could be helpful. Also just a nice way to practice some speaking skills and engage with the classmates that were not in our group.
3. The one thing that most gets in the way of me doing my best work in CS (CE) here at UM is:
Time commitments for other classes, such as gen eds and upper level concentration classes, often get in the way of me being able to dedicate the amount of time I want to my CS classes. However, with CS being my priority over other classes, it is usually the other classes that I end up slacking on if I have to choose one or the other.
Extracurriculars that I have worry and prepare for(internship/leetcode)
My ability to pay attention and learn. It's been a lifelong problem which I'm able to cope with, but prevent me from getting the grades I want. CS is special because it's the only field where it is mandatory to constantly learn new things on the job. If I want to prosper in the field, I need to get comfortable learning new things, even if the process/materials are dull.
The response rate of professors/TAs. To elaborate, if I have a blocker or a question I need to get answered right away to continue working, but don't get a response until days, it can seriously impede on my progress. I understand that some professors have big classes and are super busy, but that's why you have TAs, so at least enforce the TAs to do their job. I also understand that TAs are students and are just as busy as us, but the difference is they willingly signed up for the job, if they can't make the effort or time to do their job, then don't work. Professor Purtilo certainly broke the standard because I would always get super timely responses, which I really appreciate!
Taking multiple classes-- Im not saying that taking 2 classes is too many but in my experience it seems that some classes tend to have a pretty similar assignment schedule, while besides then have a couple weeks off or so between projects. For example last fall I took CMSC430 and CMSC420 and neither class felt extraordinary difficulty and I felt like on each individually I had a good handle on the material but both classes would have like 1 week to do a project and then like 3 weeks of nothingness so id end up doing a kinda rushed job on both and then having no work to do for long periods of time while my grades for both I dont think reflect my handle on the class as oppose to ideally would have a project for class 1 on week 1 then project for class 2 on week 2 and be able to do my best work on both and give them proper attention and get grades that reflect how I do on both.
Also for just grading there have been a few classes were being unable to install dependencies even with teachers help and teachers not answering emails related to grading issues and questions have resulted in me getting a grade that brings down my morale when grade doesn't reflect how I was doing in class.
Also besides 435 many just say go code this which any idiot online could learn from a youtube instead of teaching people more career relevant skills that they may only learn in software engineering.
Medical issues, sadly. I would prefer not go into detail about it, though.
The lack of emphasis on collaboration (the active discouragement of it in fear of XFs?)
Boring lectures. CS classes generally don't employ active teaching enough nor is there enough hands on experience, the few projects in the classes generally aren't enough.
I feel that the degree promotes memorization of certain topics when it really should be about enhancing a student's problem solving and critical thinking. I was able to breeze through much of the early coursework at UMD simply because I had already had coding experience and many of the projects were simply an adlib to fill in the missing lines of code. They did not really teach me anything new or of value to me in the future. I should not have to go to class to get a rundown of a specific function in a programming language, as I could just read the documentation for that function in 10 minutes at most. Instead, I would have much preferred computer systems for example, to cover some of the basics of computer architecture so that when I walked into computer architecture, I was not totally lost.
For this reason, I think that the more math heavy courses such as algorithms or discrete math were the most useful, but also most challenging courses at UMD, and when I would struggle it was not because I had not spent time memorizing flashcards but because I did not practice enough with the concepts they covered, and did not understand them at a fundamental level.
Writing code is the easy part of software development, writing it effectively and in a way that others can understand is the difficulty. I feel that the degree promotes a value of “just make it work” which can lead to poor code being viewed as acceptable because it runs without errors. The degree does not promote value in efficient designs, and this leads to a lack of care in the code students may write in the future.
Not having as much hands-on projects that are applicable to industry, feels like most projects here are based heavily on theory and implementation, not new technologies and exposure to essential frameworks.
Time management having other classes or being busy. Ending up doing hackathons for each project.
The one thing that most gets in the way of me doing my best work in CS at UMD is the larger emphasis of understanding programming languages rather than more broader topics that would need to be understood no matter the language. An example of this is CMSC 131 and 132, where most of that class related how to apply concepts to Java, when I think an approach similar to what is done in 330 might be somewhat ideal where projects use different languages in so that students are more likely to remember the concept rather than the language.
Taking other difficult classes (math, for example) while doing 435 was definitely a mistake. Also, even though the geneds are fairly easy, they still add on busy work that got in the way. I think it would be good if 435 was more credits, maybe even covered some gened credits (no idea if that is possible). The issue is that learning how to do software engineering is much more involved than the other random 400 level CS classes and I felt that everything else going on in school took away from the experience of 435.
Dealing with people who contribute very little close to nothing and fail to respond when prompted. Their lack of participation can significantly hinder group work and progress. For classes where collaboration is not allowed, the hardest thing is staying motivated when facing complex problems alone without the option of discussing ideas with peers.
The impracticality of a lot of it. Realistically, I'm not going to be one of the people working on very low-level stuff such as the Operating System or with assembly. However, learning it is a requirement. While I understand the point is to build a broad and deep understanding of how the machines work, it doesn't feel like it's fostered a deep understanding, and has rather forced me to resort to learning things in depth for a single semester, then forgetting all about them as I cram information in the next.
I think the biggest obstacle for me has been the amount of gen-ed requirements at UMD that have forced me to take 2 of them per semester to finish, allowing me to take less CS courses. Also, most Of these gen-eds assign a ton of busy work that takes time away from my ability to focus on my CS coursework.
Having to optimize what I do to pass my classes and look good on applications instead of what best helps me to grow in my knowledge and skills. I focus the most on learning what I need to do to succeed at UMD rather than to succeed in life.
What prevents me from doing my best work in CS is myself. My habit of procastination can at times prevent me from starting early and in turn prevent me from having ample time to put forth my best work. If I want my best work to be reflected, I need to be at my best self and have no one else to blame but myself.
Myself. There are so many resources here that I did not use. Getting a spirit guide or some kinda mentor assigned so you are in check with your goals would be nice starting first year.
The biggest obstacle to doing my best work in CS (CE) at UM is balancing time between classes, assignments, and projects. Limited time for learning new skills, lack of resources like advanced tools, and occasional group misalignments make it challenging to focus deeply and deliver the best outcomes. In reference to this project, my main obstacle was not having enough time to understand new languages and the existing code base. Juggling other classes and assignments made it tough to focus all my energy on this one project. Also, the lack of resources was a major constraint-it really limited what I could achieve with the tools we had.
Fluency in the technology I'm using to develop in.
My own time management skills. In terms of what's maybe in the hands of the department, I'd say a lot of classes end up being so large that the professor's ability to work directly with students and assess them in effective ways is limited.
The disconnect between what I am studying and what I actually am interested in and plan to do outside of school. A lot of the CS curriculum at UMD feels bulky and unnecessary. It constantly feels like I am trying to juggle classwork and preparing for the job search, which is a lot of menial leetcode questions and creating side projects. The few classes where I am working on projects that I am actually learning in or projects that can be valuable on resumes are usually the classes where I am doing my best work.
the pressure from the overall CS culture. Doing my best work in CS at UMD requires a good amount of effort and time, but managing the amount of time and effort that goes into 2-3 challenging CS classes, other classes (double major), outside activities, while ongoing job/internship search - all at once can be overwhelming. But since this is the norm for many students in the CS department, it creates additional pressure when you're not doing that, and it sometimes gets in the way of being able to spend the amount of time and effort I want to spend on my academics.
I think in general just the workload and the fact that some CS content doesn't help you build real products, it would be helpful if some classes were a bit more practically oriented.
When an assignment is due on Monday and you start an assignment on Friday, after office hours, you have to resort to emailing or piazza. It is very often that all the TA and professors don't respond and you are on your own. I understand that professors and TAs should enjoy weekends, but at the same time, weekends are for when students are catching up on work, I feel like there should still be a support system set up on weekends.
Just myself, pure exhaustion from other classes and most importantly, life outside of classes.
I believe the typical way of office hours in CS classes is not to super organized. I would often need help on projects and there would be up to a 1-2 hour wait to ask for help. While I understand the department and Task were constrained of resources, that should not be the norm. I do not mind waiting but many students would jump the line and hog the TA time which didn't seem right to me. I believe this can be improved. I don't the solution but this actively hindered my experience.
It's myself and procastination, I am confident in my work, and I think I can do some pretty good work when I do, but I am very aware that sometimes I wait too long to start. I am endlessly working on this, and I have improved, but it something that I will always struggle with.
Some of the interesting classes here at UMD get brought down by their focus on theoretical or mathematical aspects of the course that I do not find to be directly applicable in my future endeavors.
Im constantly worried about not being able to find a job and my attention is split between job hunting, leetcoding, and doing school work. This class was also more time consuming than I thought.
I think the pathway for the curriculum is sometimes a bit odd and often times the the work we do doesn't feel like what I thought the class was going to be about. Sometimes teachers will teach the things they like which I understand but sometimes isn't what we as students actually need. In addition, sometimes I feel like a care about my grade so much that I prioritize what I need do for a good grade rather than what I need to do to actually learn the topic better and be able to apply it. Also it is sometimes impossible to get the classes I want because instead of finding interesting you are checking off boxes for the 3 different area requirements.
4. The obstacles that prevent me from knowing what is expected of me in my degree program are:
Nothing. There should not be any reason to not know what is expected of you in your degree program. A degree is what most people will be utilizing in their future jobs; in order to get your degree and learn in the most efficient way, you MUST know what is expected of you to get the most out of it and be as prepared as possible for when you graduate.
Clear instructions of what are expected from me for that class, especially before signing up for classes
When I'm doing the general education path for my CS major, it feels like I'm missing critical aspects of my learning. Especially when core classes in other universities like "operating systems" are optional here (and popular to avoid). My goals is for my career path to have the widest possible scope, and I feel my desire to do what sounded coolest got in the way of doing what is most practical (e.g. I took Computer Vision when I should have done Operating Systems). It becomes difficult to focus on what my degree expects of me due to the ambiguity.
I wish paths were clearly defined from the get go so by the time we get to upper level classes, we knew exactly what to take and when to take them. I know there are plenty of resources out there (most are honestly student made), but it takes a minute to find them. I know many fellow peers who get to the upper levels and are lost on what to take and just take the wrong courses for their career goals and screw themselves over. This is also partially on the student because they themselves should meet with their advisors and utilize them. Just to elaborate a bit more, like it would be nice to have a tool where I can put my career goals, what kind of job I want to have and aim for, then it gives me the best classes to take at UMD, in and out of the major, to reach that goal.
Testudo having hrs so cant audit lmao idk
None, I believe that I understand what is expected of me in my degree program.
I think it's always been clear to me what I need to complete in order to graduate
The program seems to be all over the place depending on what professor you end up with, some professors focus too much on the details of specific programming languages when that doesn't seem to be what's important for software engineering. There doesn't appear to be much consistency. There is also a severe lack of seats, meaning that I often can't take classes I'm interest in because they fill up immediately.
Mainly, it is the lack of concrete requirements for degree tracks that has been an issue in my experience. I am currently on the Data Science track, yet have a very baseline understanding of data science, and even that might be an overstatement. It is only required to take a single 300 level data science course, which was really not particularly informative and only covered broad strokes. Considering this is my concentration, I feel that I should not be mostly in the dark about more niche or complicated techniques for analyzing data. Machine learning is definitely a very useful class, but ultimately deals with too much theory to be directly applicable to real world application, since it is mainly discussing the base level techniques which are no longer used outside of an educational setting.
Uncertainty about industry outside of classes, leading to slighly uninformed decisions on course selections and the optimal courses to take to land a job.
I feel like I know what is expected of me for computer science degree.
I think that the biggest obstacle for this scenario is that if you are in the general track for the CS department there is a total lack of direction in terms of courses that build on each other, as some courses will cover the same topics and depending on the professor the required information on said topic could differ.
The biggest obstacle is that for most CS classes, I have no idea what is expected of me outside of completing the assignments I am given. To be honest I don't even know if the university really has any expectations of their CS graduates. I guess that was fine a few years ago but now that the job market is cooling, I am starting to question the approach that universities (not just UMD) have towards CS/SWE. As an example I do not remember a single thing from the 400-level CS classes I took last semester, nor do I feel like they've improved my problem solving ability or anything.
Lack of clear, consolidated communication about degree requirements and course objectives.
Lack of clear instruction in certain classes. Particularly higher level ones where concepts are gone over in broad strokes, but then we barely look at any concrete examples, and then we're expected to implement, or show what we've learned, meanwhile our only experience with the topic has been a slideshow and a handful of pages on the topic.
I remember being really confused as a freshman about the degree requirements for CS majors as all of the resources on the school website are very confusing. It has also been very unclear which 400 level courses I should be taking and which ones would be best for a certain career path.
There is no one information source that has all the things we need to know and there is nothing actually forcing us to learn the information about our major. The UMD websites are disorganized and confusing and often even advisors do not understand the requirements and expectations for specific programs and questions.
A lack of guidance from adminstration. What I mean by this is, we as students take these classes that teach us about different computer science. We come out of those courses with understanding of the subject matter, but not what it means to us as up and coming professionals. More emphasis should be placed on the bigger picture and how this plays into our future as software engineers. 435 did this well, but no other class did this.
Didn't even know I should have to ask that question to myself?
The biggest obstacle to knowing what is expected of me in my degree program is the lack of emphasis on practical, industry-relevant skills. While course requirements are clear, it's not always evident how they align with real-world applications or career goals. Some classes also assume prior knowledge, increasing the learning curve unnecessarily. This was the first course after CMSC 320 that made connections to how we as software engineers would perform post gradutation and helped me assess my readiness and personal capacility of success as I step into the cooporate world.
Clear indication of degree progress.
The lack of frequent checkups outside of terpmail. Maybe a half-way or near graduation class that has students set up linkedin, create applications, and maybe even some cort of coop program would be helpful.
the lack of clarity in what the degree program aims to accomplish. Does the Computer Science Bachelor's Degree at UMD aim to prepare students to be successful in the workplace? If so, then why is there a lack of focus of preparing for technical questions? Or why isn't there an internship/co-op built into the degree (e.g: UMBC's Public Health major) We see online courses and bootcamps doing a decent job in training people to be programmers, so why don't we shape the CS degree to prepare students more than the inexpensive alternatives?
I think the only thing I would consider as an obstacle in what is expected of me in my degree program is the Area requirements I have to take. To elaborate, for different computer science degree tracks, 400 level courses are split into different Areas, and its required that you take a certain amount of courses for each Area. This can sometimes be challenging because it forces me to take classes that I find not as beneficial over courses I think would better fit my interests/career aspirations.
I think i came in not knowing how much effort you need to put into your career outside of academics. This expectation of putting in effort into clubs, internships, etc. is something that's expected of all cs students, but you sort of have to figure it out as you go. This is really the only thing I can think of, but I wouldn't say theres an obstacle preventing me from knowing this. Its just the expectation I had, and getting this information and learning about career came from my peers rather than my professors.
Nothing. I know what is expected of me. I think UMD does a good job at orientation at explaining your degree and the paths you have to take. If you don't understand the first time, the occasional email the advisors send are useful. If those don't reach you, your interactions with peers will reveal enough for you to inquire more on your own. Within each class, the first day of classes go over the syllabus and the structure of the class. It is ultimately up to the students to really make sure they understand.
Transparency. Going in and even in the early years, I did not know what things would be. But learning is apart of the whole process and I have grown tremendouly from it.
I don't really have anything to say for this question. Almost all of computer science classes I took were well-strutted in terms of expectations and I knew what I was getting myself into. I never wondered what was expected of me and don't think I have a useful answer for this.
I think that the current advisors, at least mine, feel unreachable. I always think that every email I send them is a chore for them to respond to. Having to wait 2-3 business days for a simple yes/no question to be answered feels terrible, and I would rather try and fail to find the answer myself that just sitting on my hands waiting. Maybe other advisors are better, but I never feel that talking to mine is best option. Other than that, the requirements can be fairly clear when they are publishes clearly, but sometimes the answer is buried in layers of text and is not made obvious for no real reason.
Many professors don't try to link their class material to how it ties into our CS education as a whole, how it will help us outside of our degree.
The amount of random classes you need to take. I don't understand why we can't take more cs classes. We are only able to realistically take 2 cs classes every semester and then the rest is just random gen eds that do not matter to me at all. The degree requirements are kinda random and advisors sometimes suck so you need to be constantly checking your degree audit to make sure you get all the classes you need to graduate.
In terms of classes I feel that often times there is a guideline that is laid out in terms of what is expected of me in terms of grades etc. I think this school has lots of resources, but sometimes it's not always obvious where this stuff is.
5. The best way to predict when students will be compatible members of a successful team is:
When they take the initiative. The members that take initiative often lead by example and are confident in their abilities, which is a good sign that they will be active, productive group members. In a class as rigorous as this, showing initiative is the best way to prove to your group that you are invested in the success of the group.
The scrimmages helped a lot with that, I think demoing our scrimmages will also show that more
The best way to predict the compatibility and success of a team is to see how enthusiastic they all are when it comes to doing the work. Apathy towards the work is a major sign of someones contributions. Being committed to the class and to the success of your teammates is crucial to keeping oneself motivated and on top of their work. When it comes to compatibility, reducing chances of resentment is a major necessity. This is why I mentioned ALL group mates having to be enthusiastic. If some people are more committed than others, and the committed ones have to keep pushing the others to pull their weight, it will inevitably lead to intolerance for each other.
In my opinion, I think the best way to predict when students will be compatible is after a quick trial project. Like we had the scrimmages, which was a perfect trial run! Only problem is that we switched to different teams, which is fine, but it would have been nice to do maybe a very quick trial run on a scrap project just to see who does what and how teams work together.
If them passing a class is on the line or I guess if for a class they spend $25 or so on a personality test
Willingness to discuss & compromise combined with taking pride in their workPlease be as specific as possible in answering the following.
The results from the scrimmages. I think a lot can be learned about a student from their performance in the scrimmages. Someone who slacks off in a short project is not very likely to engage in the semester long project.
The metrics used in the beginning of the semester were for the most part fairly successful in determining the compatibility of the group, assuming that our groups were put together using those metrics. While we did end up having a team member that was clearly well versed in lying to make themselves look better, the rest of the team was extremely well assembled and we ultimately became quite close over the course of the project. These would include our resumes, the Gallup survey and list of previous classes. To an extent, it is a good indicator of how much effort they are willing to put in over the course of the semester, and how well suited they are for the task at hand.
Another metric that I would like to have considered is mostly just the effort put into the scrimmage project, regardless of the stated credentials in a resume or the classes they have taken. I was in a scrimmage group with the one group member that did not contribute much to our final project, and knew from the beginning what to expect because they played absolutely no part in the scrimmage project and were equipped with a number of excuses when confronted with this fact, all mostly blaming the rest of the group. I am not certain how to effectively achieve this however, but seeing as how the scrimmage project was a simple coding project, commits to SVN could be a valid metric.
if students are able to easily communicate with each other and hold each other accountable from the start.
Making sure not to many leaders are together so they don't end up butting head but also making sure a team has some leadership as its needed for the team to have a direction.
I genuinely do not believe that there is not a best way to predict compatiblility for success as students could on paper appear to be the most sucessful team, i.e. each member having a four-oh GPA and each knowing everything about CS, but there personalities clashing or vice versa. However I do think the method of using Gallup strengths is a good start, as it is the closest thing to trying to get an understanding of an individuals personality, but I think that the biggest downside is students buying into that system as many students were somewhat dismissive of it during the class discussion of the tool. I also do think that general trauma bonding on the respective projects could also form a sense of camaraderie, as that is what occured with my group.Please be as specific as possible in answering the following.
if they are technically capable and reasonable good at communicating. But also I think it depends on the project. If the project is new and requires a lot of exploration, it is good to have someone who is eager to learn new things. Otherwise, it is good to have someone with specific expertise that can implement their own parts. Student who do not procrastinate are also easier to work with. In a group, there should be one leader who is good at planning.
through effective communication. I believe clear and frequent communication fosters understanding, resolves conflicts, and ensures alignment, which are essential for team success.
Enthusiasm/"Energy"/Attitude - Team members with different levels of energy will grate on one another and conflict in many aspects. This isn't always due to a difference in work put in. Team members with low enthusiasm may desire to go with the first idea suggested, while team members with high enthusiasm may want to discuss details and pros and cons in depth. One may want a thorough group contract with detailed provisions, and another may just want the bare bones provisions so that they can move on. The conflict between these two approaches can and will cause conflict down the line, and end up dividing the group. Some people "sweat the small stuff" and others don't, and the difference in those approaches are indicative of major personality differences.
I think that students who have common interests are the most compatible for a successful team. Teams get along best when they have something to talk about outside of the project at hand. For our team, we were productive but still had fun because of shared common music tastes and hobbies.Please be as specific as possible in answering the following.
Their technical skill and leadership skills. Leadership includes being able to be be a good member of the team when not in a management position.
One can do all the surveys they like, but the only way to get a good grasp of a student's compatibility with others that create a successful team is to see how the student works. That is why I think the scrimmages were essential, albeit stressful. They illustrate how people work under pressure and with technology that is mostly unfamiliar. Once there is an understanding of that students work style, then you can compare their style to others and fit them in to a team accordingly. Please be as specific as possible in answering the following.
I think the assessment and scrimmages are nice. In addition, see their horoscope? Jk. I think maybe having some team building activity for 1-2 classes that are non CS related to see how people bond?
Honestly, I don't have this completely figured out yet. If I were a professor, I'd try to assess how students work based on their grades, assignments, and maybe something like their Gallup strengths to see if they'd get along and complement each other's skills. As a student, I think it's really a process of trial and error. In my experience, successful teams usually happen when people genuinely get along with each other. That's probably why so many people team up with their friends-they tend to share similar mindsets and work ethics. While my team faced plenty of challenges, those challenges brought us closer and made the process fun, regardless of how the final product turned out. It was the willingness of everyone to contribute to the best of their abilities, for not only themselves, but for the success of the team as a whole.
constant and forthright communication.
How long it takes for them to open up to eachother/ show that they are comfortable socializing, relying on team members, and being relied on. Of course in CS there are plenty of students that are more introverted than otherwise, but i find that when group members have certain shared interests or similar personality types these people seem quicker to open up and be cooperative.
their level of communication with the team, especially at irregular hours (weekends, early morning, late night) usually is a good indicator if they will be engaged and meaningful contributors to a team.
This class is functioning as a capstone for me as this is my final semester at the University of Maryland. After taking classes and also working on the SEL project, which got me thinking about the level of education UMD is offering to its CS students, I think that the program needs more work. Our SEL project aims to improve the education in CMSC435, but how we even teach CS concepts to underclassmen needs to be restructured. For example, there isn't a class dedicated to the introduction of data structures, which is a key part of thinking like a programmer and preparing for technical interviews. The extra fat from coursework needs to be removed and instead replaced with intentional work on preparing students for working in the real world, which is what CMSC435 does well.
I thought the Gallup Survey we took in class was a pretty good metric to show team member strong traits and respective compatibilities. Either that, a student survey, or a time to time questionnaire would also be ideal to predict whether or not students would be compatible working together.
I think it depends on how driven they are. I'd rather have a teammate that wants to help out and is proactive than someone that is knowledgeable but doesn't do any work. I kinda get now why interviewers ask so many questions on motivation and interest, because technical skills can be taught, but motivation and discipline are more intrinsic.
Honestly, I think teams will succeed if most of the members have a light semester and can allocate more time to projects. This is a double edged sword though, sometimes students will slack off when they don't feel constant pressure. I think each team needs to have a STRONG leader that can enforce accountably. I honestly do think good, willing communicators end up being successful. I think these students will act like a natural leader/ glue that bonds the team, they need to be stern when they need to be. I think having a strong leader can partially set up a team for success. I think compatible students are students that are decently extroverted and not afraid when the focus is turned on them.
Personality and Work ethic. Getting along is the most important thing for team cohesion and if everybody has the apptitude to do the reletive same amount of work, things go smoothly.
I believe the best way to know this is through observation and seeing how they perform. I think surveys can sometimes be misleading and the only way to know when a student is compatible is when we observe them performing and being an active part of the team and helping out.
I will be honest, I think random works, I feel that there is never an exact science to this, and that attmepts to "make the perfect group" will end in failure a lot of time. Too simlar and these people will step on eachother toes and grow to dislike each other, and too different they will just never talk to each other. I honestly think that taking random pairs from the scrimage and putting them semi-randomly into groups will result in more successes than trying to hand select groups. People are not predictable, and there is no way to know if a group will work well, so beyond giving everyone one "friend" from the scrimage, it is mostly up to luck if they work well. I do not think the gallup traits really give a full picture of someone, and if a group wants to succeed, they will find a way to regardless of who is in it.
Their communication and demeanor towards the project are the biggest predictors to me. They should communcate effectively with valuable insight. Their demeanor towards the team should be positive and should show that they give importance to the team goals.
a successful team is: How often members communicate with each other. No one likes a bad communicator. If anyone gives you warnings about being late or not making meetings it is often more excusable if it is said prior to the meeting even if only by half an hour. Changes can be made to make the meeting online instead or delayed. People are willing to take on more work in this major if they themselves are not too busy since everyone wants to do well in this class.
I found the best way to predict was if people were active and willing to show up. I think for me, having people around me that are willing to actually show up means a lot. Often times I have been with kids who refuse to show up or will opt for an online option. I found that will my team this semester it was awesome that everyone was willing to actually show up. Had teammates not been willing to come to the first few meetings I think that's a good indicator that they might not come after that either.