Free text answers on CMSC435 Engagement Survey from May 14, 2019

The open-ended questions asked were:

1. The team engagement practices that were both used by my team and useful to the project were ...
2. If I could make ONE change to CMSC435 to make it a great class, it would be ...
3. The one thing that most gets in the way of me doing my best work in CS here at UM is ...
4. The obstacles that prevent me from knowing what is expected of me in this degree program are ...

All verbatim answers (anonymized and in mixed order) are as below.

1. The team engagement practices that were both used by my team and useful to the project were:

• Discord for our primary communication channel, Trello to keep track of what was done/needed to be done, and Slack to keep in touch with Ankita/Brian to ensure we understood what they wanted to be done.
• Having weekly meetings where we all met up as a full team for a few hours to go over what we had been doing and what our next moves were to further the project. There was never a week where we didn't meet up to do this. Having a slack where we could discuss different things, share files, and collaborate more easily.
• I believe building team comraderie through memes and communication worked for us. We did most of this through discord. By the end we had our own recurring jokes, "At least we're not [teamname]." One of the smaller things I did subtly was to get people to take ownership of certain parts of the project. This kept them engaged because now they were responsible for the outcome of their part even though they were still getting help.
• I would say that regularly scheduled meetings, whether in person or online were the most useful. I think some of our team members often felt "disconnected" with each other. In that many of us were just grinding away at our own tasks. Which is not necessarily a bad thing. However, it was nice to be able to know how everybody was doing and have a rough image on our timeline.
• Hackathons, persistent communication through Discord, compulsory weekly meetings on Saturday no matter what (apart from meetings we had during the week)
• Assigning tasks and dividing team members into separate units to work on specific features Weekly in person meetings to get everyone on the same page Contacting you, Professor Purtilo, for advice and direction on the current state of the project
• We used several tools in order to effectively communicate and engage within our team. We always met as a whole team every Thursday at 5pm, often for 2 hours. In addition, sub teams would meet some other days throughout the week. At the end of each meeting, we would run through the tasks each person wanted to complete that week and then put them up on Trello. This system allowed us to make sure we knew what was expected of each team member as well as provide accountability. Finally, in addition, Slack was extensively used to communicate with other team members. If I had a question about an API or whether someone could help with a certain feature, I could ask the group, and since we all had notifications turned on, several members would quickly reply.
• Our team utilized Discord, Slack, and Google Hangouts to communicate project specific information amongst ourselves and our client. Having the ticket logging system as well as peer mentoring also contributed to to the overall activeness of the team members. But perhaps the most useful engagement practice was having a strong leader that was vocal about what he/she wanted and personally assigning and communicating those needs to the fellow teammates. I think with an authoritative leader in the group, other members feel more obligated to do what they were assigned, as the leader offers a sense of urgency and leadership that not only inspire his peers, but encourages them.
• We had three weekly meetings outside of class time. This made sure that everyone was committed to the team. We were forced to keep the project on our mind. At the beginning of most Monday meetings we would each tell the rest of our group what we planned to get done that week. This helped us set goals for ourselves and gave us accountability when something didn't get done.
• We used Discord to communicate with each other and Slack to communicate with the client. Discord was used for messaging and calls. It proved to be immensely helpful for our group. We communicated every day with each other and were always available. This was key to our success. Its ability for calls also allowed us to speak vocally with each other very easily. We often spent hours on call with each other, figuring out parts of the project. On top of this, we used Trello cards to assign roles and duties to complete. It allowed a nice dashboard for everyone to see what not only you were supposed to be working on, but what everyone else was working on as well.
• We used Slack to communicate and for the most part this was very effective. Most of the team was very responsive in there. We also set up a Trello but this was less useful and we eventually stopped using it. Breaking into sub-groups was great for communication because it allowed me to get closer with certain members of the team and was the first time I felt like I had "friends." We had a ton of meetings, some of them work, some of them fun. The laid back hanging-out meetings where we got to know each other were so important. When it got down to the wire I felt a fierce loyalty to most of my team members and it really pushed me to give it my all because we all depended on each other.
• The main way our team made sure everyone was engaged was with biweekly meetings, or more if the project called for such. For most of these, it was strongly suggested that you came but you could miss them if you had a good reason. Some critical ones were made mandatory though in order to ensure everyone was on the same page. We also made it a habit of asking each member what they were currently working on. This serves the double purpose of keeping everyone involved, as well as making sure you yourself know what your team members are up to. Finally, we had deliverables for each respective subteam that we attributed deadlines to. This made sure everyone was keeping up with their work.
• The team engagement practices changed throughout the semester. As a team, tasks were never forced but instead self-driven by team members wanting to get the project done. Due to the lack of JavaScript experience, namely React, Redux, and Electron, it was hard to get more application developers working on the desktop application itself. As people started having more experience with JavaScript the team engagement practices were able to reach higher engagement levels. Once the foundation of the application was built with electron and we had the state/store of the application propagating throughout the components, we were then able to subscribe components to the store and start having components at different hierarchy levels talking to each other. After this was set up, we started using Trello to make a list of all the features that we wanted to work on. This was one way were able to engage team members. At each team meeting, we would always divvy up the tasks to those who had preferences on tickets and set deadlines. On many occasions, tasks that were taken on by team members turned out to be a lot more complicated than previously thought and was then broken down into several subtasks that were further assigned to other team members. This would help to engage others who didn’t necessarily have a lot on their plate to get involved on another part of the project. The project was divided into three sub teams with project action items that often involved overlapping work that promoted cross-team collaboration. The sub teams were search, application, and legacy data. We had a couple people who moved throughout the various sub teams. Dividing into defined sub teams, allowed each of the team members to participate and have more input on their action items. The was another we as a team promoted engagement. Team engagement was a lot high on a sub-team rather than on a larger team.
• Our team met weekly outside of class to keep each other updated on what we were working on and decide what needed to come next. We used Slack for organizing different chats among the sub-teams and group-wide communication. We used a Trello board to keep track of who was assigned to which tasks.
• I really enjoyed the peer mentoring system. It was a simple yet effective way to help steer team members in the right direction and point out any issues without causing conflict. Every Monday we had each member of the team describe their goals for the upcoming week. I think this was a useful way to keep everyone accountable, in communication, and aware of the bigger picture. We also rotated the leader of our client meeting weekly. This helped everyone take some ownership of what we were developing and made people pay more attention in meetings so they knew what to talk about with the client.
• We met religiously, 3 times a week, every week that we had school. This forced us to make regular progress throughout the semester rather than holding hackathons at the end.
• Meetings that occurred at least weekly, often multiple times per week. We also kept up with each other through slack. We really didn't employ any software development models like agile and we just expected tasks to be done once assigned which usually did not happen.
• Meeting frequently- this helped a lot. It helped us keep track of what eachother were doing as well as making us check in with ourselves frequently to see if we're staying on track. It also allowed us to miss the occasional meeting and still be an involved team member. Keeping a clear line of communication- we used facebook messenger to communicate. We chose this because we all have facebook and check it frequently. Saying what we're working on at meetings- this allowed us to update other team members that may not be aware of what were working on, as well as holding ourselves accountable for not being idle.
• Meeting every week, to discuss and work on various jobs. Jobs were completed since last meeting, jobs that are still in progress, and jobs that should/will be done after current jobs. Consistently using, in our case Discord, the group chat in order to maintain check ups with every member to make sure jobs are being done correctly. Communication through both chat and meetings when someone is having a hard time with a part, and various others are able to assist and get it done. Making various "guides" for different processes that needed to be done for the project. For example, I made a couple svn guides for branching and merging, and an initial guide for dev environment setup. X made guides for dev workflow and code review. And overall keeping a very "casual" but still urgent atmosphere when meeting and talking about the project. We'll enjoy doing stuff together, but we all know that things need to get done.
• Unfortunately, we didn't really use any actual team engagement practices for my team.
• The logging practices were actually helpful to not only track our activities at each meeting and apparently also was a outlet for venting for my teammates.
• To engage the team, we used Trello for creating technical tasks that had to be done. This made sure that everyone had a specific task to work on and was not unsure. It also helped us keep track of our goals. Since we had a lot of different components working together, it was important to have a clear outline and schedule to make sure that we were staying on track to be successful. Another team engagement practice that we used was the use of Slack for team communication. This proved to be invaluable to our engagement because it made it easy to create sub-groups, organized our messages into groups (such as announcements vs. fileshare vs. general). Outside of technology, good team engagement practices were having team meetings every week at the same time which made sure our group was working together. We also made sure to get some food sometimes (usually pizza) to make sure we were having fun and had some "brain food".
• weekly team meetings. semi-regular mini-team meetings. shared trello board. group slack channel with reminders.
• We had weekly meetings to stay on the same page. Created a Slack to continue communication away from meetings. Created a Trello to document what needed to get done and keep track of the state of the tasks. Broke the team up into different sub-teams to get big tasks finished individually.
• To be completely honest, we did not use many engagement techniques. We did not use a ticketing system like JIRA to track our progress and divide up tasks, and we did not eat together or do anything together outside of class or meetings to establish a rapport with one another.
• I think one of the main useful team engagement practice was our ability to promote open direct communication. Everyone felt comfortable to talk to each other directly. I feel this is because we did not have to appoint a leader; we kind of just mushed together and someone took the reins to keep us all on tract. I also feel that we let everyone have the freedom to make their own choices, no one was micromanaged in any way. Lastly, I feel that we invited an open conversation. Our messages were not always about 435, we had fun, creating trust.
• I think a very broad yet accurate description of our teams engagement methods was that we all attempted to build positive and personal relationships with each other. We all tried to see each other as friends rather than members of the same group. Soon we began to meet outside of regularly scheduled meetings in each others houses or apartments, as an entire team or in smaller groups. I feel like creating this environment made it easier to talk about our ideas or issues towards the project, and more importantly it embedded a greater sense of individual responsibility towards the team. By the end of the semester, as things got grimy, it felt like all (or a solid majority) of us felt obligated to commit as much time as we could to the project together.
• We had two seperate meeting days. One of the meetings we just focused on doing work with our subteam the other we would talk more about what needs to get done and other logistics.
• Discord, Trello, and Slack were crucial for our success. Trello made it very easy to track what everyone was working on and Discord meant that we had instant communication with each other and could readily ping someone if we needed something urgently. Slack made it very easy to communicate with Ankita/Brian about design choices, meetings, and just general questions rather than having to deal with emails every time we needed their help. These all helped the project because it meant that everything was working when we finally put the pieces together and didn't have to make major changes to the different parts in the project to make them work.
• Our group had three main engagement mechanisms. The first was the use of Trello to keep track of when group members were assigned and completed tasks. The second was the all hands on deck meetings that occured before critical deadlines. The third was the standup meetings that occured via web where group members reported what they had done over the past day.
• We met three times a week, once as a whole group, once with the clients X and Y, and once with our independent subteams. Some of the engagement practices that we used within these meetings were to let each person talk about what they were working on, what needed to yet be worked on, and to suggest any change in development from what we were currently executing. This format helped us all stay on similar pages and understand what we needed from other groups, in addition to knowing when we could expect working functionality from certain aspects of the product. I believe that our group was cohesive and our product came along nicely and timely, so I can say that I believe in this engagement.

• 1. Started later in the development process, We assigned tasks to individual team members so it is clear who is working on what.

  2. We assign a couple of team members to each sub-team to speed up the development while sub-team members can help and check on each other.

  3. We tried to be honest in peer review. Personally I was a little afraid of confrontation, but as semesters goes, I began to be more comfortable be more straightforward in peer review. I think it motivates people to be more engaged.

  4. We set up mandatory meeting each week on Wednesday, so the whole team could get together and keep everyone on the same page. This will also reveal how engaged each team members are, considering some team members would come in late and some team members would leave early.

  5. The whole team got closer as semester goes. Personally, I was more motivated and comfortable when I knew I can trust my teammates and they were having my back.

  6. There will always be conflicts. Most of my teammates were good at being polite when communicating to each other which creates more respect and trust among ourselves.

• Our team tried to stay engaged through weekly meetings and task lists, though they were not particularly enforced.
• The most useful engagement practice we used was the gallup strengths assement, it really helped us get an idea as to what each person was like at a glance and where our strengths as a group would lie. The other most helpful thing we did was allow each group member to choose where they wanted to work. We set up a poll for each person to rank their preferred role in the group, so that we could assign each person to a job that they wanted to be on, and the numbers just so happened to work out in a favorable way. This helped to keep most people engaged because they were interested in the role they were assigned.
• The most useful thing we did was assigning roles which I wish we had been encouraged to do earlier. When there are no roles we get nothing done because its "not my problem" but once we had roles our engagement got much better because everyone had defined responsibilities to hold them accountable. We also worked on engagement with stand ups over discord (in busy times we did them daily). This really helped because we knew what everyone was working on and when they expected to be done, so if they didn't follow through, everyone knew. Saying publicly that you are going to do something is a powerful motivator.
• Weekly status report is a great team engagement practice that allows members in the team to know what others are working on. Especially since we split up into sub-teams, it was hard to know what the other sub-teams were working on. The weekly advice forms are also a good way to understand what the team members expected of me and help me understand what I'm doing good at and what I should improve on.
• We never really had any team hangouts that didn't include any development or class-related work. Nevertheless, the meetings where we stayed together for many hours together and ordered pizza and did work together were beneficial because it built trust between members of the team. The first meeting like this we had was before the CDR, and we stayed in Iribe for around 8 hours preparing. This was the first time we really bonded together as a team because we all had to suffer through the same grueling work in the wee hours of the morning together. This happened a couple more times as the deadline drew nearer, and every successive time, it was clear that we had become closer as a team.
• At the beginning when we were tasked with the project, each team member talked about our strengths and weaknesses and our backgrounds as an ice breaker activity. I think this helped us become more comfortable working with one another early on in the project before getting into the details of the project. Our team used a Trello board to assign tasks to different people and make sure that we knew what all had to be done. We used these tasks to make sure we were keeping up with what we laid out in the proposal. For communication, we used a Facebook Messenger chat to send updates to each other aside from our team meetings and ask for help. Overall, I think our team had strong methods of communication that helped us be successful in delivering a product to our client. We also took breaks from our team meetings to just have fun. For example, we played an online game and would compete against each other to see who got a higher score. Taking breaks like this and not just working on the project all the time we met also helped build a strong team relationship.
• We used a variety of communication methods, such as Slack and Trello, and we also met weekly as a team, and also met every week. Additionally, we had sub teams that met once or twice a week, and we also used in class team time to the fullest potential.
• We mainly engaged through discord, and its channel feature (similar to slack) proved vey useful for communicating with sub teams. The label feature was also helpful, allowing someone to @QA, @dev, or @everyone to send notifications to everyone in that group. At all of our team meetings we held a stand-up, which kept everyone up to date and accountable for the work we were doing. When the work really started to pick up, we held stand-ups in the discord on days we didn't meet in person, where everyone had to report before going to bed. I can say that this definitely helped keep me engaged, and on one particular occasion I was very busy with other work, but made sure to block out some time for this class because I knew I had to report to my teammates at the end of the day. In addition to this, we also kept tickets on Trello which kept people accountable for the work that needed to be done and the work that were supposed to be doing.
• We handled most of our communication through a program called Discord, which is a text-message app and voice-over-IP client. Although Discord has connotations linked with gaming, we used Discord to set up several text channels, similar to Slack, that were used for different parts of our project (e.g. front-end, back-end, questions, references to APIs, GOAT hackathon, etc.). We also created a voice channel which we used to talk to each other during weekly meetings. I think Discord worked for us because we were all familiar with it prior to working on the project, and it was a platform for us to talk about work and non-work related items without being supervised by our clients. We would talk over Discord everyday, and it kept us engaged throughout the project. Some other programs we used were Trello (an online task management app that we used to assign deadlines for tasks and assign people to certain tasks) and Slack (a messaging app similar to Discord in which we handled all professional communication with our clients). Trello helped us keep track of when things were due and who was working on what, and Slack helped us remain in close contact with the clients. The last engagement practice we used was scheduling "mini-hackathons" where we would meet at someone's home, work on the project for several hours, eat, and then leave. Working on the project in-person really helped us solve problems quicker and become more cohesive as a team. After we were done coding in these hackathons, we would eat and have fun, and I think this helped us develop synergy within the team.
• The team used Discord for uses of communication. Even though most of the topics were related to the topic, there were plenty of times where we'd talk about unrelated topics and other things we found funny to bond closer. We have all, to a certain extent, played videogames so we had that as a means of similarity. We also had many self-done hackathons, about 3 not including the GOAT hackathon, where we'd spend many hours working on the project. We normally got food afterwards or during the period so we would cool down while eating and talk about various things. The overall focus was on the project, but there is a time and place to fool around and we got closer due to this.
• Having team time in class was crucial. This allowed us time to meet when everyone was available and was already blocked out in our schedule.
• We had team meetings to do work. That's it. We didn't do anything outside of class to make the team feel engaged (no team meals). We didn't really do any public peer reviews, no formal structure to make sure people did what they said they did, no way to measure engagement either. None us reported our hours to each other. We had a drink & code once, but that emphasized more coding than drinking - and not all of us drink, myself included. I guess team meetings count as being useful to the project.
• Communication between everyone and trust that people would perform their part. Communication was key as it allowed everyone to know what they were having difficulties with so everyone could pitch in to help resolve a issue. It also helped us keep track of our current progression throught the project.
• It would be far easier to tell you what engagement practices our team did not use. The one thing that we did was we had two meetings every week which from what I've heard talking to people was a little bit more than usual. We also ensured that people had individual tasks so that there was some accountability. The problem is that once we assigned something there wasn't really a good way of checking progress because we weren't great at uploading to the svn.

2. If I could make ONE change to CMSC435 to make it a great class, it would be:

• Have the exercises at the start of the semester done with the same group that will be assigned for the main project to allow time to get to know each other and adjust.
• I'm not sure how to change this, but I would make lectures more engaging or worth more points to pay attention to. Maybe offer slides online as well?
• I think mercurial might be easier to get adjusted to than subversion and mercurial doesn't allow you to edit history
• One or two more scrimmage exercises. Personally, I actually found them to be very useful and enjoyable to work on. But I can see having too many of them take time away from the main project.
• Providing the slides on the class website. There are nuggets of information that are very useful but I don't have enough time to note them down. Also just fun things I wish I could've snapped up, like the slides on the software engineering disaster crash course (pun intended) or today's slides with the self-learning materials for the future.
• I feel that CS students have trouble paying attention during lectures, especially since a lot of us are coding on our computers. My suggestion would be to add more interactive cases or real world examples that can tie in with the lecture topic for that day. I think the students would be more engaged overall and would love to share their opinion, especially if they feel that they could relate to the example.
• If I could make one change to CMSC435, I would make the lecture slides available online. I recognize that some slides are merely pictures and that you explain what you mean by talking and not reading directly off the slides, but a significant amount of the slides have a lot of information on them. I believe I could absorb and understand this information better, if I was able to reference back to the original slides later, rather than potentially incomplete notes.
• I would change the version control system from SVN to Git, as it is more of an industry standard. I know that with Git we have the ability to rebase our commits, but I think that our end product should accurately represent the amount of effort we put into our work, and not our commit history.
• I felt like you gave us advice and then said "Now go do it". I can look back over the semester and see what I would have done differently as a team member and individual. Maybe you were guiding us more than I know (I was not often a survivor of your lectures). I would have liked you to check on our team's practices halfway through so we could improve over the semester as opposed to after the entire project.
• Sometimes lectures go on too long. It's definitely not an easy trade to make. I understand material is necessary and the information given was useful; however, often I could not help but want to go to team time. It would also distract me from the material because I was thinking about what to discuss among the team.
• I understand how much of a learning experience CMSC435 was for everybody, and part of that was you gave us guidance but let us make mistakes. I definitely liked that and I feeel like I learned a ton. That being said, it is my opinion that the workload of the CS program at UMD is overwhelming. I believe this goes for a lot of STEM majors at a lot of universities. I know I have almost no free time, and what freetime I do have I often spend worrying about work. I know my friends are the same. I believe this is why an instruction like "watch this hour long video on good team practices" is tough to find the motivation to do if there isn't any immediate consequence for not doing it. I definitely don't want you to start babying the class and forcing everybody to do everything, but I think a little more guidance or motivation would be useful because I know a lot of the students are burnt out. Maybe this advice is very vague, and maybe it's more of a comment on the rest of the program or the students themselves (including me). But it is just a thought that I have had.
• I personally would have prefered it if the class was less open ended. It was always somewhat difficult to pinpoint exactly what was expected of us. I understand why it is done this way, as in the real world there are no public or release tests. It makes sense to want to make this class simulate as much of that as possible. Nevertheless, this isn't the real world. In the real world you don't get a letter grade corresponding to your work. I don't like the fact that we can submit something and only have a very vague idea of what grade we're going to receive.
• If I could make one change to CMSC435 to make it a great class, it would be to start the team project earlier. I feel like the groups and projects only really started a month or so into class and we did not have enough time to develop for as complex of a project as we had.
• The scrimmages might be more useful if they were performed with people who will eventually be on the same team as you. Having these exercises in teamwork only to have your teammates switched out from under you felt a little wasteful. Being able to start on the project earlier in the semester (perhaps as a result) would have also been helpful.
• I wish there was a more structered way to communicate with Dr. Purtilo. I regret that our team did not meet with him very often, and I think it would have been beneficial to have some sort of weekly check-in mechanism. We would usually update him on our status at the start of class, but I wish that during the "team time" classes he had stayed and come around to each team. I think it was just difficult to make time for a weekly meeting between our team meetings, client meetings, outside work for the course, and all other courses. A more structured way of checking in, or a weekly comment personalized to our team would have gone a long way towards opening that line of communication. Perhaps in addition to the peer mentoring students should have to submit a weekly question to Dr. Purtilo about something related to their project, the course content, or even just life. Dr. Purtilo could pick a few questions at random to address in the blog or in class. He could also use the questions to tailor lectures the following week.
• Longer runtime with the main project.
• I think the way teams were made this semester is way off. You told us during our CDR that we were put together as we seemed to be 'similar' people. However, I think an effective software engineering team needs to be comprised of lots of different types of people/workers. I think the fact that all of us are more focused on how to implement a solution rather than which solution to implement really hurt us as a team. Software engineering teams in industry is hardly ever comprised of similar minded people so I don't understand why teams were made this way in this class.
• While I think that Dr. Purtilo is a great lecturer (very well spoken, and obviously tries to make the lectures interesting and applicable), I think that the lectures could be more interactive. As much as I would like to say that I paid attention to them always, sometimes it was hard to sit still for an hour just listening to Dr. Purtilo speak, even though I wanted to learn what he was teaching. If there was a way to enforce class participation other than assigning quizzes and randomly asking questions, that could be helpful. Such as, more mini group activities based on the lectures.
• In my opinion, because SVN is a required tool for the class, I think that a small overview/walkthrough of commands that would be the most important to use would be greatly appreciated. For most people it would also be best to do it in a way that shows commands from Git, and it's equivalent command in SVN.
• Make the slides you use during some of the classes easily available to the class. Other than that I enjoyed the class. Even though my group more than likely performed the least, I still enjoyed my time taking this course. Fortunately, this course taught me what could go wrong even when you try to make everything go right. I have no doubt that the lessons I learned from this course will be used throughout my life as a programmer and software engineer.
• I guess less lecturing? I didn't enjoy sitting through the lectures.
• I would make clearer expectations for the deliverables. I found myself continually checking the "Timeline" document to ensure that I had everything necessary. While I understand this is part of the "paying attention to details" and being thorough, it was often stressful since we would get a pretty severe late deadline penalty if files were not named correctly or if a requirement was missing. Organizing the "Timeline" document so that it had more bullet points of information would be, in my opinion, beneficial to the class.
• to continue having scheduled meetings between the lo-fi and critical demos. Meetings would give an opportunity to touch base and to ensure progress is heading in the right path even if the meetings are short and we have nothing new to show.
• I would love to have had a few more guests speakers that have experience in the industry come and speak to us about what they value in Software Engineering.
• I would post lecture slides. There seems to be a lot of great information on the slides that I may want to reference in the future but I am not the best notetaker and I am not great at paying attention during class so this may just apply to me.
• I really would not change much in 435. This class gave me exactly what I expected. This class really replicated an internship, and may have even taught me more than my internship. I can say that my internship was a little less work. This class was a lot of work, but I guess that if you want to learn, you need to put in the work.
• My one change would be to provide a bit more technical knowledge, or more explicit resources for obtaining information or mentoring on such knowledge(perhaps the individual alumni group mentors you discussed doing in the past). I feel like I was self-teaching a bit too much for a college course, so much so that I had very little confidence in many of the decisions I made. I feel like efficiency would have been improved greatly for the team if we all felt our decisions were more educated. Just having someone with more experience with the tools I would be using to speak with would be more comforting.
• Have some way of keeping the class material and the project work together more than having them feel disconnected.
• A larger emphasis on constructing UAT tests correctly and changing them as needed as time passed. I know for our group we sort of threw them together based on an incorrect assumption sometimes of how data is coming in. I think that a larger emphasis on changing tests only as needed as the product changes should be encouraged and not just designing tests when the proposal is due and when the final report is due.
• If would add some self-selection to the projects teams. Before this class, I had no idea what NextCloud was, and when I was assigned to the Forms group, I was lost as I had little experience in this area. Perhaps emailing students before the semester starts to ask them for project ideas and what they're interested in.
• The only comment I can think of at the moment is that I think some of the earlier assignments (svnfun, two foot putt) were presented to us with little supporting documentation or insight. I was often left not knowing if what I have done was what was actually wanted from the assignment, or to what scope we needed to delineate some functionality. I understand that there was a lesson to behold in the vagueness of the description and you want to see in what directions we head unguided, but perhaps there is a better middle ground.
• The change would be to start assigning project a little earlier in the semester and have more demo reviews. I didn't gain as much knowlegde in the scrimmage team exercises compared to the big final project.
• Perhaps more explicit advice when things are going the wrong direction, but it was definitely a part of the learning experience and it did teach us.
• I would want more clarification about parts that are supposed to be in the proposal and how to implement it. There were times that it seemed like things we wanted to put in the proposal got covered later in class, which either went one of two ways, that we wasted our time doing that section of the proposal because we misunderstood the topic, or that we were wasting out time in lecture because we had to look these things up already on our own to fit them in the proposal.
• I think lack of defined hierarchy teams can be very difficult for low engagement teams. It is also not reflective of the real world. I know that its easier said than done, but maybe after a week (to get to know everyone) teams can be encouraged to meet and discuss/vote on positions of leadership as well as other roles and responsibilities. The real world has those, so it being so nebulous can be hard, especially for people who have never had internships. I also think it could be interesting to make it a 4 credit class and have an extra lab/discussion day every week that would be just team time. Then in lecture you can do less team time and focus more on other topics.
• Having more interactions betweens teams. I believe every team would benefit from knowing what other teams are struggling with and how they overcome the nontechnical/communication problems. Other teams could take inspiration and change how they work as a team to create a better team experience too.
• Depending on the team, students might not realize that all the work that's done in the beginning of the semester and all the logging done throughout the project is all towards a culminating epiphany and reflection. If I could make one change, I would make this point clearer. Whether it be to bring in alumni who can really relate to us and explain that yes, the activities seem like busy work and they seem tedious, but you'll realize the value at the end, it could really help. We had a former student come in and talk to us, but he was unprepared, unengaging, and sometimes even condescending, and it was not helpful for us to understand the commitment and engagement this class requires.
• Looking back on the course, I think that instead of having one full class dedicated to lecture material and the next full class dedicated to team time, it might be useful to spend 1/2 a lecture discussing material and then the other 1/2 of class in teams where we could discuss the related lecture topics within our team's scope. As an example, when we discussed testing and proper documentation of tests, I think it would have been helpful if we had some time in class to apply some of the material to our project immediately after . For my team, we ended up going back later and changing our testing documents to incorporate some of the material brought up in class so it might have been helpful if we did it right after learning it.
• To work on the project longer. I understand the semester is not a very long time to be able to work on the project, but I felt that there were too many weeks in the beginning before the project tasking where, while we did useful things, could've been better used on the project and working with our team. One way I can see this being improved without much change is instead of being able to pick teams for the scrimmage, we should be put into our teams for the scrimmage.
• This question is hard because I feel the best thing to make this class better is more time, which is not possible. It would have been nice to have more time in our final teams, but I believe the scrimmages were necessary and helpful for me in meeting more of the class, and as a spin-up exercise. Apart from more time, having more alumni speak to us on their experiences in the class and beyond, and on how they applied their knowledge would have been both illuminating and motivating.
• I would create less scrimmage assignments so that students have more time to work on the final project. Although I don't think these scrimmages are useless, I think that having the maximum amount of time possible on the final project is critical. This would allow proposals to be greenlit faster, and students could develop more high-quality products.
• I would create a more structured readng plan. This would reinforce the learning and make the topics that we learn in class stick better in our heads. With an unstructured reading plan that was used during this semester, I felt a bit more confused on what exactly I should be reading about and if the topics I'm reading about is going to be gone over in class. The plan could be a simple deadline for when a chapter of a specific book should be read and when we should be ready to discuss the topics.
• More communication from you on assignments. Some of the assignment and documentation descriptions were vague and made us unsure of whether or not we were even delivering what was expected of us. Some in class updates on expectations and addignments would be better than just expecting us to be up to date on the blog. Even when we did read the blog, the descriptions required us to read between the lines.
• If CMSC 435 is a lab class, adding a theory class as a prerequisite, so that everyone is on the same page & knows how to form successful teams/team rules/team dynamics.
• During the later parts of the year, more class team time would be nice.
• Attach a real client to every project so that students actually have a reason to care. I took this class becuase I had an internship and because I'm going to be a software engineer in about two months. I figured it would be helpful. It was in some ways but the experience was vastly different, because people at work are paid to put in the required effort. Some actual stakes might decrease the amount of crash-and-burn groups.

3. The one thing that most gets in the way of me doing my best work in CS here at UM is:

• Currently, the lack of a working laptop - my laptop broke, and as I have a desktop, I didn't want to shell out more money for a laptop, so much of my work is done in my room, and I'm usually unable to reach my full potential during group meetings w/o a laptop.
• I never know what best practices are for the technology/language I am working with. I'm also not sure who to talk to for this information because office hours are a mess or with a TA who barely knows better than I do.
• Mandatory advising. I already know what classes I want to take and I know how to talk to other students to figure out what a class is going to be like. All mandatory advising did was make me waste 20 minutes once a semester. Just let me sign up for classes and only come to advising when I want to.
• This may sound odd, but the lecturing styles of some of the CS professors. I do think Dr. Purtilo did a great job in your lectures. Many professors simply read off the slides and just throw up some code demo on the screen. This especially was a problem in the 300s. Compared to my high school AP Comp Sci teacher, he did an excellent job teaching. He mainly used a white board and a marker. He had no slides, and it essentially forced us to pay attention and think about what we were seeing. I feel like many professors are just accustomed to reading off slideshows. Dr. Purtilo did a good job in using his slides as a supplement only. Most of the tidbits of important information always was spoken.
• Non-deterministic spikes of procrastination or extreme dedication.
• Balancing the coursework with the job search, personal projects, other majors/school activities, and planning ahead for graduation/moving into the real world. Computer Science I feel is a major where your outcome really depends on the amount of effort you put into these things. Some students perform well academically but are not motivated to work on other things. Some students are very successful and career oriented but barely receive passing grades in school. Having interviews, hackathons, and school work, all scheduled within the same week is dreadful.
• Since assignments seem to determine what constitutes as good work here at UMD, the first thing that comes to my mind would be lengthy exams and methods of testing to a point of ineffectiveness about the material taught. One example of this would be Meesh's exams for 420. I have gotten A's on both exams I took for that class. However, given that her exams are very, very long and that you get some points for writing down anything, the best strategy for most points is to skim the question and write down something, even if it's not remotely correct, rather than thinking about the question and giving thoughtful answers. The comments I have heard so far regarding the final for this class is disappointing and not reassuring for my concerns about the effectiveness of the material taught. I have no doubt I will have to think thoroughly and constrictively about my paper and the project and eventually write a great paper. However, given that you said the average person takes 8 hours to complete this final, that does not seem like an effective way of testing. Perhaps if the question was released a couple days before it is due, I could understand the amount of time required to complete the paper. However, given the 24-hour deadline, spending a third of the entire day during finals week for a final exam seems rather ridiculous and ineffective. Hopefully, this will not be the case.
• The gen-eds are definitely the one thing that gets in the way of doing my best work in CS, but they are understandable.
• Myself. When I put in the time required I produce my best work, but when I start projects late and let them stew I don't do well.
• Sometimes the professors are hard to reach. This can extend to TAs as well. I work better with someone I can speak to directly, so having a absentee professors does not work well for me. I have taken classes where office hours are sparse (or TAs dont show up), where Piazza is non responsive, and where there seems to be no help. Other students have had to help me and this does not seem right. Dr Purtilo actually surprised me in the beginning of the semester when he responded to my email quickly. Then, after I did the fix he suggested (I did not email him back to tell him it was resolved) he emailed me to see if I was able to resolve it. This was great and how other professors should be.
• I feel like I do so much learning on my own. The large class sizes are not helpful and I do not believe the professors do a good job most of the time. There are absolutely exceptions, but I take a lot of English classes, and the communication level between instructor and student in these is so much better. I suppose that is to be expected, but I feel like a lot of computer science professors that I have had do not have a great grasp on how people learn. Little details are focused on - often big picture concepts are skimmed over. We get a lot of "what" but less "why." Foundations are often not completely established. I have learned far more from youtube than I have in the classroom. In this way I have learned to become an independant problem solver, which is an upside.
• My engineering classes hinder my ability to excel in CS. I, like many others, am a CompE major that realized too late that he heavily prefers working with software. I would like to be able to take more CS classes to become a well rouneded developer. Unfortunately, I was only able to take 2 400 levels in my time here so there are some gaps that the UMD program was not able to fill.
• The one thing that most gets in the way of me doing my best work in CS here at UM is that it is easy to get distracted when you hear of all these other people getting really good internships and job offers. It can add to the stress and cause you to look down on yourself. I feel like for me personally that, that was one of the bigger challenges I had to overcome when starting CS here at UM. I got distracted and distressed in the fact that I had to get into one of this big "brand name" companies and only then will I be a good software engineer. It's very easy to compare yourself to others in a major so large with so much of presence around campus.
• Poorly designed homework. Having a homework assignment that's more tedious than helpful is extremely demotivating. If I feel like an instructor is wasting my time, I'm less likely to go to class and more likely to perform worse.
• The stressful and unsupportive environment. I think so many students are stressed about classes, internships, jobs, clubs, and everything else that it makes it difficult to dedicate time to anything that isn't deemed 100% necessary. Some professors foster an atmosphere of fear and intimidation (*cough* *cough* 412) that makes it difficult to focus on the learning instead of passing. I am not advocating for easier classes, but perhaps creating a more supportive environment would help empower students to do their best. Yes, threats of failing a class will get me to work harder, but I won't be working smarter and I will be sacrificing other parts of my education to stress about that one class. I wish professors would work together to support students instead of declaring their class the most important and expecting students to put other courses on the backburner. I think this does a real disservice to students. The atmosphere in the CS department also leads many students to put academic success above well-being. Personally, I dealt with many family issues this semester and never felt like I could ask a professor for an extension or assistance because that would be deemed as failure or weakness. I think if professors worked together they could create a more supportive and uplifting atmosphere for students that would lead to better outcomes for learning. Although this answer is already long-winded, I thought I would provide this example to illustrate what I mean: When I took CMSC216 with Nelson I experienced a medical issue that prevented me from sleeping or going to class for almost 2 weeks. I didn't tell any of my professors about this or even get a doctor's note. I just tried to power through all my classes. That plan didn't work out very well for me, and more work was piling up than I could handle. I went to Nelson and told him what was going on. Before I could even ask for an extension he told me to take care of my medical issue and get back to him when it was fixed and we would figure out a new due date for the assignment together. His support went a long way towards making me feel less overwhelmed and allowing me to focus on recovery before academics. I wish more professors advocated this type of support/culture at the start of the semester that puts students first and grades second. I would also like to note that this is the first time in my 4 years I have been asked a question remotely like this. Everyone asks for feedback on their course at the end of the semester, but nobody really asks students about how they feel about their experience as a whole.
• My laziness. (If that doesn't count, how difficult it is to find places to collaborate in a group on campus)
• Classes don't teach how to work in industry. Most of the materials learned in 400 level classes will probably never be used again unless doing research. Most people that get a generic software engineering role at a large company will never write C code in 2019 much less assembly.
• This isn't applicable to CMSC435, but I always despised CS office hours- the room was always so crowded, and you usually had to wait for a long time to get help. It made me not inclined to ask for help, which in turn hurt my grade. I'm not sure how to remedy this other than getting more rooms and more TA's. Or perhaps there should be more group projects to enable collaboration. As far as I remember I only had one group project in all of my CS classes before CMSC435.
• Not having enough time during the week to do everything I want to. Primarily because I work 4 days a week during the afternoon, and have classes on the days that I don't work. Sunday is pretty much my only actualy full free day, which I use to get homework and other assignments done.
• Myself mostly, but only in terms of communicating. I get in my own head about communicating and trying to make sure I let everyone speak and express their thoughts, but I take too much time in listening that I don't spend enough time speaking myself. This is also only in terms of group projects. In terms of purely myself, I find it hard to motivate myself to dive into anything I'm not interested in. I do it in a lot of my classes that don't interest me. If I'm not interested than I don't want to do it and I simply don't do it. This is a horrible attitude to have in school and I recognize it.
• Lost of motivation and interest in the subject at hand.
• I think that the class size and the amount of CS classes that someone can sign-up for in one semester is the most limiting. Being a computer engineering major, I have had both very small classes in the engineering school and very large classes in the computer science department. I find that I am often more engaged in the smaller class sizes and feel more comfortable asking questions: overall, the learning environment is much more comfortable. Hopefully this gets addressed with the computer science program being a limited enrollment program, but the effects might not be seen for a couple of years.
• lack of clear objectives in tasks.
• Operating Systems.
• I've never really had a rapport with any professors in my 4 years here at UMD. The large class size make it difficult and it always seemed intimidating to talk to professors. In 435 was the only time I directly interacted and talked to a professor face to face.
• Lack of Collaboration. I think that in the 'real world' Software Engineers are constantly collaborating. Here at UM, collaboration is pretty much viewed as illegal. I get that its academic dishonesty and what not, but I think UM should have more classes where they encourage this collaboration, more classes like CMSC435 where you can work to engineer and product, not just code.
• Honestly this is pretty similar to my answer above. I think what gets in my way the most is not having confidence in my choices but feeling like I need to make some choice soon, or else risk not getting any work done before it's too late. I like for there to be SOME set of guidelines to start me in the right direction.
• Most professors don't feel approachable to me
• Having to balance work load between multiple classes and work from a job. That's something very specific to me because of the timings that work picked up along with the sometimes short deadlines that we set for ourselves for various parts of the project. It was mostly unlucky but I think if we simply worked harder during the "free-er" periods then that could have been avoided. But at the end of the day, trying to balance class, work, and a social life makes it very difficult to do well in class.
• One thing that obstructs me from performing my best work is vagueness with regards to expectations. When what is expected from students with regards to programming projects ect. Is made explicitly clear, I do great work. When the requirements for a project are more open-ended, it's difficult to figure out what to do and to produce a product that is exceptional. It's also very hard to get started on something, when you don't know what that something is supposed to be.
• Me not knowing where/how to start or set up my code base to work in. I have found that once I actually get started most CS work usually flows for me, but I am often lost or confused in how to construct the appropriate environment since this is usually not specified during class time. Generally, I think I have not had too much problem with CS work at Maryland, other than the very rare project which is more hair pulling than actually writing anything or making any meaningful progress (ex 216 Herman filesystem project or 417 Agrawala routing project).
• I wasn't confident in myself whether I want to or could become a developer. At some point in college, I got used to "getting a C is good for degree" attitude. But this class gives me hope that I can be a developer if I really believe in myself and put in enough effort.
• Well, as one of the few ECE students in this class it's a bit different but I would say in general, me. I prevent myself from doing better. I wouldn't blame it on anyone (or anything) else.
• My own procrastination. Seriously, I'd probably have a GPA at least a half point higher if I'd just bothered to start projects earlier when I was an underclassman.
• I want to be a software engineer and I like the applications of computer science. But here is mostly focused on theory which kind of bores me to tears. Obviously you need some theory, but it feels like too much for someone like me. In my internships I felt pretty unprepared for the real world. Knowing how to do an inductive proof or implement bubble or memorizing the different Android classes is not really helpful in industry.
• Sometimes I didn't know what was expected of me given an assignment because of either unclear descriptions or lack of evaluation metric (e.g. public tests) to see how well I did.
• Grades. It's something that's unavoidable, but the fact that grades and a good GPA are so important makes it hard for me to dive deep into a subject I'm truly interested about. I've done research with professors on the side in areas I'm passionate about, but I also want to perform well in my other classes. In CS classes, this focus on grades and measurables has adverse affects on the curriculum (teacher side) as well as the performance (student side). Professors want projects that are easy to grade and easy to measure, so we have cookie cutter projects. This then limits students' creativity and ability to think through a design problem and implement it.
• For most of my computer science classes, I have put more of an emphasis on getting a program working rather than fully understanding the topic because I feel pressed by the deadline and want to avoid getting a bad grade. Because of this, I either end up not getting the program working fully because there are details that I forget or later in the semester, not fully knowing the material puts me at a disadvantage. I feel like if I set more time aside to work on CS, I could create better quality work and more organized projects.
• My other classes. While this probably can't be changed at all, I found a lot of times, I'd want to work on my project ahead of time, but I couldn't as I had other classes/assignments to prioritize with earlier deadlines.
• This also has to do with the engineering school, but for me the one thing is just the sheer amount of work (particularly this semester). I truly wish I could have put even more time into this project and engaged with you more, but with 18 credits of upper level classes I was very short on time.
• The number of credits I have to take each semester and the number of unrelated classes I have to take. What really annoys me is that I have to take certain Gen-Eds which aren't related to my major at all and take time away from focusing on one class.
• I personally get distracted fairly easily and I simply just want to finish the work and get the highest grade with the least amount of effort possible. This mentality created a high level of base competence, but getting each and every part of the program flawless was never the biggest priority for me. The distractions I have are also related to the other obligations that I put much of my time into such as sports (badminton and soccer) and videogames.
• professors not creating an atmosphere where they want their students to succeed. Some professors (not you) pride themselves on the class being hard rather than helping the students actually learn the material and know what to do with the information
• Group work. I have traditionally done all the work by myself, because I can attend to all the details better when I don't have group mates weighing me down. I like CS, and I like analyzing problems & solving them. I don't like having to explain the solution to someone else. This is not because group mates are ALWAYS a burden - it's just that at UMD, projects are usually sufficiently small such that it's easier to do it solo than to work collectively and debug someone else's code. I took this class because the project was sufficiently big that group mates are required, and because I need experience in that area.
• The stress of certain deadlines with projects even when starting them early got very stressful later on. During this semester, the 435 project felt like I could do a lot at my own pace.
• Being forced into particular subjects that I have absolutely zero interest in. I'm a web development guy, and there is one class at UMD dedicated to the subject. I'm pretty sure that class doesn't even exist any more. I personally have a pretty hard time motivating myself when I don't have a personal interest in the work.

4. The obstacles that prevent me from knowing what is expected of me in this degree program are:

• A guideline of what classes one should take should they want further exploration within a topic (besides cybersecurity).
• I always feel like I know what is expected of me within this degree program. Professors have consistently made clear what they individually expect of me.
• At a lot of points it was hard to determine if this was a software engineering program or a computer science program. It seemed like most students around me believe this is a software engineering program so they complained about theory and not having coding project or something similar. This I believe affects the way some professors teach. To keep students engaged they try to make sure that their is a connection to industry and that "real world skills are taught." I'm not against this per say but the implementation is usually sub par. Other than 435 and a couple projects in other classes the projects given by proffessors aren't designed to make you a good software engineer only to help you understand the concepts taught in class. I'm not arguing for making this major a SWE major. I just want their to be a clear understanding of if the goal of this program is to make me a software engineer or a computer scientist. I understand that most people just want to be SWE's (I'm one of them).
• I do wish their were more hands-on type of classes in CS program. CMSC435 is one obvious example. However, many classes are simply just theory courses that don't really contribute to what you'll encounter in the real world.
• I don't entirely understand this question, but I'm going to interpret 'you' as referring to Professor Purtilo. Mainly just incentive for teams with external clients to interact with the professor. We didn't get to know what exactly we could benefit from talking with you because this was the first time we'd interacted with a supervisor/spirit guide for a large and daunting project. It would be nice if you were able to advise us on some of the external clients in maybe a 10 minute or so meeting before going over to the clients. I learn best with examples, so if you'd shown me a very clear example of your concrete feedback and advice that pertains to my current project (or something similar), I would've had far more incentive to seek out your advice. What ended up happening was me, and my team, finding valuable advice from you at the critical review, which at that point we couldn't act on in-depth. If at the beginning of the semester you'd known that the client wanted to use a framework as constricting as Our-Sci and had possible suggestions for dealing with it or even alternative, we would've been able to get to more detailed work even quicker.
• As a finance student at UMD’s business school, I learn a lot about the curriculum through all the interactions I have within the community. I have a general idea of what to expect from a class since everything is in the same building and you’ll regularly see professors/students speak to one another about what they are doing. There are many events where you can learn about the professor’s research and just the convenience of having everything together in the same space goes a long way. On the other hand, for CS I think most students learn about a course online and likewise meet the professor for the first time in class. The new Iribe building will help alleviate these concerns as it will become easier for students to congregate for events and visit their professors.
• The first couple weeks I was a bit confused by the website blog. Unless you specifically told us to check the blog, I would not look at the blog at all, and ended up missing some information. Afterwards, I did check it every day. It could be nice to have an option to have the blog emailed to you if you want, whenever it is updated.
• An obstacle that prevents my from knowing what is expected from me is the large class sizes for CS classes here at UMD. Additionally, the unavailability of professors makes it hard for me to connect with other faculty members and to communicate my concerns.
• The projects are all for teaching purposes. I have had very few projects in this program that would translate to the real world. I know some of these projects are necessary to teach the concepts but I wish I had more real life projects. I'm sure I'll get enough real life projects when I start working.
• Like I mentioned in question 3, absentee professors make it so that I have no idea what the examinations are going to be like, how the class is structured, how grades will turn out, etc. This causes me to struggle in some classes because I do not know if I am doing well in a course.
• The size of the program and student count in the classes is very large and communication with professors is sometimes hard to achieve. It all feels very impersonal, at least the first half of the program. This has an obvious effect on my engagement and initiative levels sometimes. It also kind of establishes the precedent that professors aren't really readily available for discussion, so even when its much clearer in the higher level classes that this is not the case.
• When you get to upper level CS courses like this one, it's not clear what level of background knowledge you are expected to have. Based on the classes that are pre-requesites alone, we shouldn't know how to do many of the things that we were required to do. The thing with the CS program here is that its almost a requirement that you do stuff outside of your classes. This isn't necessarily a bad thing, but it sure doesn't help with te feelings of imposter syndrome.
• The obstacles the prevented me from knowing what is expected of me in this degree program was the lack of available mentors in the program. I understand we have our advisors, but it’s very hard to make an appointment with them. It would be a lot more helpful if there was anonymous advice place other than piazza that we could go to get help. I feel like there is just too many people on piazza to get meaningful feedback or have serious discussions.
• I realized around junior year that employers were expecting a large set of knowledge from me, but my curriculum left out many topics. For example, would a typical employer say that a computer engineering graduate should have knowledge of networking? I didn't take the networking elective, and I feel like I lack that knowledge. Nobody really ever talked to me about the elective options in the upper levels. I was given a link to the electives and told to pick some from each category. But I wish my advisor had talked about which ones are more standard vs specialized and what types of career each one would be associated with.
• I have had a good grasp of the expectations of this degree program for the most part.
• Not sure what this question even means.
• I wish I had more instruction as to how I can apply the knowledge that I'm learning towards a career. While I learned important fundamentals and theories in my CS classes, I hardly used any of that knowledge in any of my internships. I believe the curriculum could be tweaked, or more classes could be offered, to teach more modern things as new trends emerge (such as cloud, blockchain, etc.).
• (Not speaking of this class but,) Vague requirements for projects, or too specific requirements. I've noticed in a lot of projects I've had to do the specifications have always either been too vague, or too specific. Vague being bad because they don't specifiy how they want it to be done, even though they do want it to be done in some certain way, usually a way done in class, requiring a lot of personal questions about some aspects of it. And being too specific has made some of the projects extremely boring and uninteresting because it literally lays out every aspect and process that needs to be done, requiring absolutely no thinking on my side.
• Grading. In a lot of my computer science classes grading takes forever and in some I don't see grades until almost finals time, which isn't good. I can't fully assess my progress, how I'm doing, or the quality of my work if I don't receive feedback for the work I've done.
• The phrasing of these types of questions really confuses me about what I'm supposed to do.
• I find that it is often hard to communicate with the advising office since they are overloaded with students. Also, I know that for my advising it can be done through email. As a result, requirements can often get muddled between these communication channels. I think that every advising appointment should be a necessary in-person meeting. I also was not fully aware of the (new?) degree audit tool, U-Achieve, that can be accessed online. If the department advertised this tool more, or showed how to use it in the first advising appointment, then this could be helpful in setting expectations for the degree program.
• -conflicting understandings of what is expected of us -lack of explicit expectations -how that which is expected of us will be used in the real world
• UMD does not make the responsibility of a professor clear at times.
• The CS curriculum at UMD seems very broad which is great, but there is no established tracks that you can take besides the cybersecurity track, to specialize in something. Maybe some more guidance about classes you can take to strengthen your knowledge in certain fields would be helpful.
• Throughout my college career I really never questioned what was expected of me in this major. I know that I am here to get a great degree and to produce high quality work for the University and myself.
• My answer is then that I feel the class was focused too much on smaller planning based assignments and metrics and less on what was learned or the amount of effort and care that was put into the team or project. Yes, I did learn a lot about the importance of planning, however I felt like simple mistakes reflected much more poorly than they should have. Sometimes I would miss a peer review because I was devoting my entire Friday evening to working on the project, but this would just be reflected as missing points on a peer review, while the reward of my efforts, grade-wise, was much less direct. It could be a bit demoralizing at times, although I see the importance of learning these things now.
• I feel like I know what is expected of me for the program
• Frankly a lack of caring or a feeling of laziness. After a certain point, I just feel like it doesn't matter what's expected of me, I just care to get a degree and get out so I can go find a job. I think there isn't a huge amount of incentive to understand what is expected of us as individuals in this program unless there's something specific I'm looking for. Even then, I'd have to probably know what that is off the bat or I would just stop caring.
• I already had a pretty set idea about what's expected of you from the start of the class. I believed that as a professor, you were required to lecture us about Software Engineering and grade our projects because this is what most other professors did. However, your role as our 'spirit guide' was very different as you provided us with advice and resources on how to complete our product and achieve Software Development.
• I believe I know what is expected of me, at least in terms of specific classes.
• I feel CS courseworks here at UMD are disconnected. Some of the things I learned in one class were never seen and mentioned again in the rest of the college career. I also wish to see more group projects that build things from scratch, because I actually learned the most from those activities. Group projects also resembles the real world more. That being said, individual projects are still necessary. I personally just think the way they are set up now make it harder to prevent cheating.
• I suppose there's no over-arching principle that the CS program seems to teach. Software engineering definitely taught valuable lessons about practical coding in teams though.
• The fact that CS advisors are about as useful as cardboard cutouts. They are no help, do not know any classes outside of the department, which wouldn't be a problem but when the university is already unclear about it's GEN ED requirments, it's very frusturating to have an advisor tell that they also don't know what the scholarship in practice requirement means. They are also incapbable of providing assistance in choosing classes, if you show up to them not knowing which classes you want to take, instead of ADVISING you, they simply admonish you for not picking them ahead of time and then just pick random classes and tell you to send an email when you figure out what you want. Advising meetings are also extemely useless and obtuse. Not only do you need permission to take any CMSC class on the schedule, but they block your account from scheduling any class without a meeting. Why? As established previously, it's not like they know anything about the rest of the classes offered here, and if need to get permission from them to take any of the CMSC courses, why block my account so I can't schedule my GEN ED's/Electives/Classes for my other major? I've never had an advising meeting take longer than 5 minutes, and they never actually say anything that can't be covered in a half decent FAQ.
• I think I know more or less what is expected of me. I mostly just memorize stuff to regurgitate on exams, but I know that that is what is expected of me. I'm a little confused what this question is asking to be honest. The requirements for the computer science major are pretty clearly laid out and so I go through the motions that are required of me.
• I am in the Computer Engineering program, and the curriculum is pretty set in stone. But I would imagine Computer Science majors might be confused about the upper level concentrations and how those courses contribute value to their degree. I also heard horror stories of advising screwing people over such that they had to take an additional semester to get the degree.
• This was the first time I worked on a large team for a software engineering project. I had worked on group projects in the past as a member of QUEST, but the level of involvement and the team dynamics are completely different. I suspect that for many people, they are thrust into a team environment where no one has team management experience, and it can seem hopeless. This was definitely the case for me, and as a result, I felt like I was juggling multiple things at once: how to build team camaraderie, how to develop a good design spec, how to get everyone on board with a good idea without shutting other ideas down, and how to please the professor at the end of the day, because it is a class. Sometimes, these goals conflicted with each other, which made it difficult for me to parse what was expected of me. I knew the goal of the class, or for you, was to create good software engineers. Software engineers have a lot of responsibilities, but because I was ultimately in a capstone class, I felt the need to fulfill my responsibilities as a student first and a software engineer second. This class is one of the few classes that blurs the lines between an encapsulated college experience and a real world work experience. For some courses, the line is more explicit - for this course, I felt it was more ambiguous, and this was the main obstacle that prevented me from knowing what was expected of me.
• I think the introductory curriculum that we have to take for the CS degree (132, 216, 330) creates an obstacle since it does not focus on topics that we did this semester, like design. A unique part of the course that I liked was how the skills and topics we learned are more applicable to the workplace rather than simply "getting something to work" in the intro level courses. In hindsight, I wish I took advantage of the oppportunity to schedule a meeting during the semester to just casually discuss things like software engineering in general that we did not cover in class.
• There is a lot of text in the syllabus, and it takes a long time to completely understand everything. I think a more organized way to read the syllabus would be helpful, because often times, I would read a section, and then realize that it wasn't quite relevant just yet, and that we would get to that section in the future.
• I found the advising to not be the greatest (again this has more to do with the engineering school). Almost all of my advising appointments consisted of just me telling them what classes I wanted to take, and them making sure it was possible and and then approving me. This being said, I believe the expectations of this degree are available if you go looking for them.
• One obstacle is the varying level of experience for students in the major. Coming into CMSC435, I was only familiar with Java and a little bit of Node.js, and I soon realized that everyone in the class had backgrounds which were very, very different from mine. I think that as a professor, it would be difficult to task projects to students when their skills might not necessarily match up to what you planned. Another obstacle is that application is not heavily enforced at UMD. Even in a class like CMSC425 - Game Programming, most of the class and most of the final grade is dependent on learning the theory of games. Although knowing theory is good, not applying the theory could be even worse because one would be unable to actually put the knowledge into practice. I can say that for some classes, like CMSC351, I only studied the theory so I could get a good grade in the class. However, I don't remember much from that class and can't apply any of the things I "should" have learned from it. Therefore, it might be expected that I know certain things from a class that are considered basic, but when I'm not encouraged to apply my knowledge in that class I'm less inclined to retain it.Please be as specific as possible in answering the following.
• Since each person taking 435 has come from various backgrounds in terms of internship experience as well as class experience, it is difficult for me to know what you believe the average student should know. Without the knowledge of the level of software design knowledge for each student, it will be difficult for the requirements for you as a teacher to be set in stone. If the requirements cannot be made in a concrete manner, not only will I, but the department itself will have a hard time knowing what should be expected for the professor. Along with that, I have not gone to office hours much to learn more about what is expected. If I were more outgoing, I would have been in office hours engaging in conversations about these expectations.
• Resources are readily available but not really brought to our attention, leaving me and other students unaware of their presence.
• There are none? The CS "graduation requirements" page is really clear, and anybody in CS owns a computer & goes to campus, so they can always access the "graduation requirements" page almost whenever they want.
• Not knowing about the kinds of path I could go on at the beginning of the degree. Such as working dev ops or backend development, or becoming a full stack developer was never an appart option. I only knew about coding specific projects and had no connection to outside industry untill internships and this class.
• Don't think there's anything, honestly. Everyone knows that CS is a hard major and that you're expected to put in far more work than the majority of your peers. Did I know that coming in? Probably not but I learned it pretty fast.