1. The team engagement practices that were both used by my team and useful to the project were:
Having weekly face to face meeting and doing a show and tell during that meeting worked really well for us. Looking back at the semester, I can see a direct correlation with this and progress that was being made. It also helped all of us stay updated with what was happening during the semester and see what we needed to do in the upcoming week.
Throughout the semester our team used Discord to keep in contact. We would keep each other updated about various deadlines, client meetings, and agendas. Here we would also take polls to get an understanding of who can and can't show up to a meeting in person and decide from there if it'd be best to move it online. During our first meeting, we also brought pizza for the team to share which I think was a great way to break the ice.
We used three meetings a week plus our group chat to maintain engagement. The group chat was active every weekday since our group leader was always sending good morning texts of tasks for the week/day.
The hackathon style meetings were the most effective practice by far. We were able to communicate needs and issues and get a lot done. This boosted overall productivity.
Not just learning to work with one another but actually getting to know my team members was crucial to the success of our project. I can confidently say that we actually like each other and that everything we did together was fun. We had our more semi-professional moments, but above all we worked well because when we did work, we liked it.
Using a discord server to communicate and interact with each other was good. Seeing each other as friends and not just coworkers helped to improve communication as well.
Definitely getting pizza the first time solidified team chemistry between everyone that showed up. Having in person meetings every Tuesday was also good. At the very beginning we went over goals for the class and personal/technical strengths and weaknesses and I think that broke down barriers as well. Also, joking around in the group chat and in person made things more personal. I sent out a text every weekday morning outlining things scheduled for the day and doubling down on things that needed to get done. In the beginning I asked everyone to like the message so that I knew everyone was on the same page, and I think having everyone do a simple thing together that was visible for the whole group encouraged participation as well.
We mainly got pizza for every hackathon we had. And we had quite a few hackathons, around 6 maybe. It also helped us get close because We'd spend time talking about things not even related to the project since its late at night. XXX and I are both from India, and we both live in the same area at UMD. So after the hackathons, we would walk back and talk about things in our life, and similarities we had in our lives.
In-person and virtual meetings, accompanied by in-depth notes were team engagement practices that were useful for our team success. We all communicated constantly and kept each other accountable. We were all eager to help each other and fill in the gaps where necessary. We all understood the level of responsibility and accountability that would be required to carry out a successful project and we respected each other's time and built a strong trust amongst the group.
Having regular meetings in person with the team was very useful, and helped us be organized. Also, buying food on the first meeting was a good icebreaker.
We had meetings three times a week. For every meeting, our group leader (XXX) would make everyone list out what they completed since we last met and what we were expected to do moving forward. This really help keep our team on schedule to complete our product. Another important thing that our group leader did was messaging the group chat daily in order to keep everyone up to date. We also went out for pizza a couple of times (without pineapple ofc).
Constant contact on discord meant everyone is always tied into the tasks at hand, regardless if it is 2:00pm, 2:00am, 5 minutes before a client meeting, during meetings, and admittedly during class. I can't imagine how a project like this would have worked before the internet, because we would've had team members missing in action often. In-person meetings in IRB facilitated an ease of communication we wouldn't have been able to get any other way. Seeing everyone's face at the meetings meant that lacking engagement is easily noticed, and embarrassing enough to correct itself most of the time since we naturally all felt a personal responsibility to the team's efforts in this project. Going around the table and everyone giving specific updates of what they have been working on, their accomplishements over the past few hours, and what they plan to continue working on was a great tool for engagement because we relied on each other to motivate ourselves.
Pair programming on some features is something we started doing at the beginning, but it quickly fell apart for most features except quizzes and routes. I learned that pair programming is a skill to practice and improve on, not just a strategy to make things instantly easier.
We spent a lot of time talking outside the project. We also talked on the way back from class. Me, XXX, and YYY even played video games together on a couple of occasions. This helped us to get to know each other and allowed us to put trust into one another. Because of this I very much consider these 3 my friends, not just group members.
I believe the team engagement practices such as going over the IDPs were useful as it got a conversation started, however putting them on a spreadsheet and talking about our strengths brought out the weakness in using the IDPs. Not everyone was on board with their predetermined strengths and usually the conversation would just steer towards ignoring them and moving on. This could work but would need to be reimagined to be more fun and engaging and less survey and bureaucratic.
The best team engagement exercise I experienced over the entire semester was not a spreadsheet activity, or mandatory deadlines, or constant reminders. The best team engagement happened with my scrimmage 3 team when all of us spent the most time together and were fully engaged working with the problem. We also had a lot in common which helped with banter which in turn helped in engagement.
Setting deadlines and being up front with my team members was great advice and helped me be active and engaging with my team. Trying to enforce deadlines and communicating to work around these with my team was definitely a big part of my learning experience in this course.
(1) Weekly meetings with clients, Purtilo, and with just the team. (2) Using Discord as our main way to communicate. - Easy to ping specific people and to search for old messages - Has voice chat/screen share - Allows you to easily send/view files
Our team chose in the very beginning to schedule out two weekly stand ups. The agenda for these were loose but having these scheduled meetings were critical. They served as pseudo-deadlines and allowed us to easily keep track of different teamates progress. Additionally, it was a great place to get group assignments done. We would not have completed the project without having these scheduled. Everyone has varying busy schedlues that change alot while in college. Giving concreate times in advance is essential. Likewise, we blocked a day and time early with our client that would serve as our meeting time. Although we didnt meet every week, it made it very easy for us to meet on a whim these days, and towards the end of the project we met almost every week on this.
Additionally, in the beginning I created a team backgroud document where teammates entered useful information about the project. This included languages and libraries that they knew, classes that they had taken that would be useful to the project. And any other informatoin that may be useful for the team to here. I believe that this helped make out teaming assignments easier as we were able to start off out first meeting with some good footing
Our first team meeting, we got pizza and drinks to serve as an ice breaker (Thanks XXX!). It was a great way to build community within the team and start off on good terms. I wish we would have done it more often, but we often got to business quickly in our meetings.
Frequent weekly meetings, presenting the work that we did and then meeting one on one afterwards to discuss specifics
We really focused on communication and bonding. I felt like those were integral to a great product. We were great at effective communication of progress and task assignment and made sure to meet outside of class as a group so we could not be burdened as such.
Over the course of the semester, we had a variety of ways to maintain engagement. On Sundays and Wednesdays, we had team meetings to sync and discuss progress and in-motion tasks. On Wednesdays at 7 PM, we had a meeting with our clients to update them on the week's progress, and discuss plans for the following week. Additionally, we met with Professor Purtilo on Friday mornings.
We had pizza at our first team meeting that helped us get off to a good start. We did not do much after our first meeting to keep up engagement outside of biweekly meetings.
Regular meetings to know where everyone is at and what to work on.
We generally met in person multiple times a week, and added onto that by meeting online in discord multiple times a week. We would keep each other up to date on what we were working on through these meetings.
Team Standups. Every week we would get together in one of the conference rooms on the fifth floor of Iribe and go over the agenda for that week. We would discuss what class work we needed to finish, stuff that Purtilo assigns to ensure that we understand what makes good software engineers as well as good team members. The team is then updated about client requests whom will often have their needs changed and discussion about how to accommodate those changes are held so that they could be implemented at the next possible build. After those are handled, we then would dive into team member updates about the stuff they have been working on. This ranges from risks that they are trying to mitigate, obstacles that they need to overcome for implementation, what they have managed to build, and any bugs that they found or have been reported during acceptance testing by a third party. Everything that was discussed in these meetings were recorded in a meeting minutes document so that any member of the team can revisit as well as creating a defined
These standups gave the group guidance and structure in designing and developing our product and I cannot see us being able to do without it.
Client Meetings. As the people who have a need and lack a product to solve that, consistent updates and communication with our client allowed us to be able to quickly make modifications to the product before it became too expensive to change. We would plan a meeting with a client either in person or through zoom to discuss about the design of the product. These meetings allow for a vision to form about how the product should function during the design phase and directs the team in their building/implementation of their work. What is not immediately obvious is that the client themselves is a resource for the product. Specifically a channel to gain resources. Purtilo is able to give teams a VM and sagely guidance when you are designing your product, however that is limiting especially when your product requires a subject matter expert outside the software engineering/cs field. This is where the client comes in. They can give the data you need for implementation, predictions on how a specific demographic may react, as well as any other resource they have access to. Our client was most helpful in acquiring outside knowledge and data in our own product.
Communication. If you don’t work with your team, you don’t have a team at all. We used discord as our platform of choice to communicate any details and updates that did not require a team stand up. Messaging was fast and instant, and it was easy for team members to discuss anything related to the product.
Weekly in-person meetings, with food. This was really helpful for getting us all in the same room. Also doing hackathons and working together with eachother is a very good way to keep everyone on the same page. Do this.
Regular zoom meetings and group activities outside work reminded of what we were working on constantly and encouraged us to get along.
The main engagement practice was probably meeting in person as we were able to talk and joke around while also getting work done. Meeting in-person was a great way to bond as a team and make deeper connections than just being a generic group project. By having these deeper connections we were able to work more cohesively as a team and able to communicate better when it was needed.
2. If I could make ONE change to CMSC435 to make it a great class, it would be:
Honestly, I think that the course is well thought out. The ticketing system, mentoring tips, spirit guide meetings, etc help a lot in making sure that everyone in the team is contributing. By working on course projects I feel like I have learned a lot about software engineering, and got confidence that I will be able to perform well on other software engineering teams in the tech industry. If I had to still suggest a change, it would be to have more software engineering classes that you can take before this class.
This is a tough one to answer as the class is already incredible. I greatly appreciated the availabilty you had for us and the prompt responses you'd give when emailed. A brief discussion about pros and cons of various popular frameworks prior to the start of projects would have been a good addition to the course as it would allow those who have little experience of real-world tech stack to make a more informed decision when it came to choosing how to proceed with the project.
One change I would make to CMSC435 is to provide mored detail on Scrimmage2 of what is expected in the documentation of what we were going to create for Scrimmage3. The "do the right thing" phrase is not sufficient to think to cover so much detail on documentation if we are just beginning the class and do not know anything about the software engineering process and documentation.
I'd say offering a template on how ticketing should be. Overall the class was great, I feel more confident in my ability to work on projects that solve real world issues. Not just following commands, but the ability to actually think and use problem solving.
I truly understand the value and the lessons that we have all learned by creating our own working format and pace, such as setting up a weekly meeting or daily standup with our group and having to create a manageable schedule. That being said, I think there was some wasted time that could have been utilized if there was some sort of suggested schedule or format that was only followed for the first week of two. After that it should definitely be up to the teams to figure out how to deal with that ambiguity.
Either starting the project earlier or finishing it later.
I wish the slides were posted so I could review some of the concepts the Professor talked about. I never took notes because I found I was more engaged looking at the Professor and asking questions while thinking critically on what was being lectured on. I think it also would have been nice to do some organized "getting to know you" games with our groups during class when we were first assigned.
As much as you did send out emails detailing expectations for the course as early as once we registered, more transparency of the time commitment that'd be required per week would've been appreciated. I understood the magnitude of the group project that we'd be working on, and I was very excited for that, but I didn't expect that to also require weekly meetings with you and our clients, respectively, that would take up a considerable chunk of the week, that of which I, quite frankly, didn't always have the time for. I felt that my semester weekly schedule, all of a sudden, booked up significantly once our group formed about a month into the semester, and maybe if we had formed our groups earlier, the time commitment would've hit me less badly. I understand the impact that the scrimmages have, but I think we could've done just as well with one fewer scrimmage.
More clearer expectations for the scrimmages. E.g., for the paper we wrote for the scrimmage activity, it would be good to have clearer expectations for the level of detail of the paper.
It would be great if there was some more resources regarding front-end technology. Most of the classes here at UMD don't really cover front-end stuff and it's a bit difficult for someone to start learning by themselves. So having some resources would definitely help.
More instruction on how to deal with clients. Of course, its an impossible task to educate students on ideal social skills, but if we would have had more guidance on how to deal with common types of clients for these projects and how their approach may differ from industry clients, I feel that we would have been able to make a stronger product. I've never worked with a client before, and it has ended up being a lot different from working for a teacher or professor who makes it clear what they expect and gives you all you might need to accomplish the task.
For example, our client (Dr. XXX) kept adding features and changing her mind from the first meeting. While this is inevitable to some degree, the changes were still coming in full force a few days before the final delivery. Also, our data was given to us incomplete, missing entire columns in the schema, and imageless. From the start, we had to make sure the data could be easily expanded and cleaned up, which could have been avoided if we asked for better data from them early, or compromised by promising less functionality of the app since it took so much time to set up the data.
Id maybe consider having the students do tickets in the scrimmage to see who was serious about doing them and who was putting in the most effort to help with assign groups
I would change how teams are formed and add a scheduling element. Having a team with similar interests or one that is social will automatically perform better than one trying too hard with scheduled meetings and crazy work schedules. The project teams felt more forced as many had drastically different schedules and availability. I believe having the ability to spend more time together with each other would be highly beneficial as it allows us to learn about each other, have some banter, get to share hobbies and more. For example, I only got to learn that XXX and YYY liked formula 1 in the last three weeks when we could have talked about it all semester. We only had Sunday as a collective to hold a team meeting. Other meetings usually ended up online due to availability and scheduling reasons. I would love to have spent more time with them socially and get to know them beyond the surface level.
Maybe have less time devoted to the scrimmages and more towards the semester long project. I feel as if the scrimmages were helpful, but the main project was as well and it would've been nice to have some more time to polish our product. Also I felt like among the work of other classes, advice deadlines were often forgotten about. I think maybe a reminder system may be helpful, but I think this could also be due to my forgetfulness.
Less time spent on the scrimmages to allow for more time for the main project I wouldve loved to hear from more people in the insustry! The couple of times that guests / alumni were brought in was very informative. Those experiences arent something that you get in any other class, and having more of that in this class wouldve been amazing. Additionally, if we could have another day like alumni day, after the CDR where we could sit with Alumni (prefereably with experience in the industry / sector/ technology of our projects) for a longer period of time, Im sure that would be extermely beneficial to the projects
Having more time to work during class, despite our frequent meetings, it was very hard to find time to meet due to the fact that I work, am also taking other classes, and have other obligations as well. We are all avaiable during the class time, so having more of that to meet would have been helpful.
Maybe a wider variety of clients/options of projects or more resources for each aspect like front end design or back end database setup.
I would make the slides shared in class accessible via svn or some other mechanism. It would be really helpful to be able to revisit some of these points shared in class after they are presented on.
Increase the numnber of credits students get for taking the course
Maybe a slightly simpler/smaller project. I feel like it was only barely done because we had very intelligent people, many sleepless nights, and hard workers. I also wish there were more benchmarks because similar to how it's hard to work on projects that have no deadline until the end of the semester (soft deadlines), it's very hard to work on it throughout the semester.
Maybe have all the projects be built from the ground up instead of having them use existing services already. Though that's a bit of a personal thing as I like working with both the backend and frontend, and my project was specifically frontend.
Purtilo Pizza fund or some forced bonding exercise. In my experience when it comes to students who take CMSC435 (or CS/CE students in general) they may not come in with the strongest social skills or know how to work in a group. In a class all about collaborative work, not knowing how to effectively communicate what you want to say or being able to work with a peer is a death sentence. The projects you are assigned to are pretty much impossible to do alone, and very much requires everyone doing their best to make a meaningful contribution. So at the beginning of the semester it is essentially sink or swim in learning to not only collaborate with peers, but being comfortable with the social dynamics in a team. The scrimmages help with creating teams with the best potential in compatibility, but that is only middling if that potential is not actually realized. A simple group bonding exercise would make teams quickly comfortable with one another which means that they can hit the ground running when it comes to the design process of the product.
I suggested a small pizza party during our first standup to christen our first interaction with one another. You should be that person as well.
Make it longer. It should really span semesters. I know this isn't possible for administration reasons but maybe things will change and this will become possible some day.
Other than that, I would've liked more resources to make sure everyone had the knowledge they needed to use the tech this class relies on. Maybe just a couple video tutorials online on how to set up SSH, TortoiseSVN, and maybe even one on setting up a LAMP stack server that you could point people with no experience to for the first scrimmages.
Availability of slides would be an improvement, as I felt we were incentivized to come to class by team time and quizzes anyway so it wouldn't hurt attendance and would let me revisit information later to actually process it instead of just getting the one chance.
This was a hard question to answer as compared to other courses, CMSC435 was the smoothest. If I had to make one change it would probably be to have a way to be notified when the course blog was updated. There were a few times where I would find out about an assignment from my team discord, so having notifications to when something was uploaded would be helpful.
3. The one thing that most gets in the way of me doing my best work in CS (CE) here at UM is:
Personally, I think that specialized CE course offering was limited and computer hardware and architecure classes were more designed for EE and not CE (there are some alternative CMSC courses on the same topics as the EE courses, but I cannot take them as a CE major since credit is only granted for the EE version). I mainly picked CE because I wanted to get into low level systems programming. cmsc216 and enee447 (operating systems, I wanted to take the cmsc version but due to scheduling conflicts, I had to take the enee version) were great courses for what I wanted to do in future. Throughout my undergrad, I only had 1 class where we did C programming, and 0 C++ programming based classes. I only know C++ because of studying it on my own and using it for some independent projects. So I feel like there should be more specialized courses for low level programming in the CE curriculum.
I also think that class scheduling is also tough, there were class conflicts and I was not able to take some of the classes I wanted to take. However, there is not a lot that can be done to solve that issue other than having more sections and seats.
Honestly, it would have to be other classes. As much as I want to devote all my time to this class and put in the best effort that I possibly could, I had other obligations for other classes which forced me to divide my time up as equally as possible.
The one thing that most gets in the way of me doing my best work in CS is having to take two CS classes a semester. This was the second semester out of all of them where I did not have to take two CS classes concurrently. This semester, it actually felt like I had time to learn about the class and gain the key takeaways from this class. Most of these CS courses here at UMD are like weed-out courses. They don't focus to much on scoring and grades, maybe even trivial stuff like memorizing how to program certain programs without compilers. Unlike CMSC 435 they don't focus on the learning and academic success of the students. Their is only a select few classes I took at UMD that actually focused on my learning rather than my grades. Unfortunately myself, I believe. I’ve learned far too late into the game how best to play it and I feel that there are opportunities that have passed me by. Computer Science is broad and I needed to narrow my focus, then make it my specialty. This field is constantly evolving and it’s important to stay well ahead of the curve. However, I just don’t like the direction that we’re headed.
Course work that feels disconnected from learning. I found that most of the time I studied to do well on exams and not to actually learn the content. More projects and less exams would go a long way.
Probably not having done certain things, so getting nervous to try them. For example, research. Research in physic is (as I've come to find out) very different than that in computer science, so I had preconceived notions of how to go about doing things that were just not accurate. Also, computer science does have a pervasive feel of elitism. If you're not actively friends with someone in computer science in a class, it feels like you're competing with them. This is not how it feels in the physics degree.
Gatekeeping is definitely present in computer science.
Lack of professor and TA engagement oftentimes gets in the way of me doing my best work in CS at UMD. Many of my classes struggle with TA office hours availability and Piazza response time, which leads to confusion on assignments without enough time to clarify certain questions. As for CMSC435, you do an unbelievable job of making sure all your students are prepared and aware of the task at hand and are ALWAYS available for your students' needs.
All the other classes that I need to take. E.g., taking a bunch of gen ed classes.
Myself tbh. Sometimes there are some things that are out of my control, but I feel like I could've probably done better if I just allocated enough time to do my work.
A general lack of orientation on computer science has gotten in my way the most. In 131, they tell you download this whatchamacallit, and start coding, and eventually you're just expected to know what an IDE is and why its necessary. In 216, learning how to navigate a command line and ssh connection seem to be major point of the class, yet they practically spoonfeed students the exact commands to run. In 330, you're expected to start using git to clone and pull and push a little bit, but you are again spoonfed the steps. You don't learn what bash is, they just tell you "do this...". You don't learn what a branch is, what a merge is, how to install anything, etc. And then one day after you can explain the in's and out's of an ocaml lexer parser interpreter, then they expect you to just know what bash is, and have filled in all the gaps in the education that have came before. Now, the greatest challenges I've been facing as a senior here have been slowly filling in the gaps of the things we skipped through in the cirriculum.
Concisely, the biggest thing that gets in the way of me doing my work in CS here at UM is jumping the gun on learning exciting programming before learning what a computer is and how to use it.
The four-level courses outside CS are fine but if want to take more cs courses this is not an option. I am taking history rn which isn't very useful and would rather spend this time learning more or doing more in the CS field.
There is a theme here. CS and CE majors are usually very stressed and highly antisocial beyond their own little circles they formed on day one. Having a bunch of stressed and overworked antisocial people in every class can get very boring and negatively affects my personal motivation to do well in a class. As a talkative person I need that constant interaction and exchange of ideas. Although my team was good at being social in person, outside of class it did seem like some of them were stressed and overworked by other classes and club commitments.
The amount of time I have to dedicate towards that class/assignment and the access to correct and usable knowledge. Often times I find myself learning loads of material on my own since lectures or slides are not well made enough for me to apply the knowledge. Although this class has a very different structure and self-instruction was inevtiable, time constraints limited me from putting my best work into this project and being as best a team member as I could've been.
Other classes that are not CS related and that take up a lot of my time. Having interesting things to work on.
This class was so easy and enjoyable to work on because I WANTED to work on this project every day. It wasnt a random fibanocci project in a another new langauge. It was intersting, informative, and fun. Way back in 131 and 132 every once and a while projects like blackjack or the tetris games would be intersteing and fun to work on. But all of the other projects are a laborous and boring to work on
Not having enough time to do everything. More generally, I do a lot of things and it becomes difficult to keep track when things inevitably spike in difficulty.
The structure of the courses or the order they are taken in. I feel like some of the lower level courses, especially in EE, need to be revamped to be less centered on heavy theory and have some more hands on work that suddenly starts to pop up in higher level courses, I understand that theory is the foundation that projects are built on but they need to go hand in hand for an effective education.
The significant overlap in timetables. Obviously every class takes place in the same ~15 week block, but this has the unfortunate effect of busy periods overlapping quite significantly, especially in CS, causing a lot of hectic, last-minute work.
I often feel pigeonholed into a certain career path when taking CS courses at UMD which demotivates me as I am pursuing a degree in CS for differnt reasosn than most students.
Professors/unfair exams/unrelated content in lectures to exams, impossible classes, extremely smart people that make me feel dumb.
Stress and large amounts of work piling up in the same week due to heavy course loads.
Schedule. If you are a CS student, you have to juggle a lot of difficult classes if you want to make an impact with your degree. There is a lot of projects to do, tests to take, as well as other classes outside the major that are required for graduation. Then you also have to take in consideration that you also may be applying/actively working at internships which will take up a significant amount of your time as well. Dividing your attention across these classes, especially non-CS ones makes it difficult to wholly focus on your CS work.
Stress and Disabilities. Sometimes there are things outside of your control that impact the way you work and go about your day to day life. For CS in particular, it is very taxing cognitively and requires some technical creativity to do some of the projects. As such stress and disabilities can severely impact the study and the work that you do. Although there are some accommodations, there are certain parts in the study of CS that cannot be accommodated for, so you just ask for your professor's understanding and have to roll with it.
Myself. I'm not good at leaving my shell to get the help I need. Even if the help exists and is easy to get oftentimes I don't search it out, which has hurt me in the past.
I think the most frustrating thing I've encountered is when instructors aren't transparent, specifically in regards to where to find information necessary for the class, deadlines, and grading timelines.
Mismatched expectations between professors and TAs. I have noticed in the past that when I go to office hours of TAs there have been instances where the TAs do/give me advice different from the professor and that makes me even more confused. There have also been times where the TAs could not help me and the professor would say to ask the TAs and I would be stuck in the middle.
4. The obstacles that prevent me from knowing what is expected of me in my degree program are:
I genuinely thought hard about this and there are no other obstacles that I can think of other than the ones I mention in my response to question 3.
I think overall I am well informed of what is expected of me in my degree program. The university gives students a list of classes that they must choose from in order to graduate and the descriptions of those classes are usually well defined on Testudo.
I don't really know now what is expected of me in my degree program. I feel like the main expectation is get your degree by taking the classes that you need/want to in order to get your degree. I guess then it would be instructors or advisors not relaying these expectations if there are more than this.
Figuring out which courses will actually help with what I want to pursue. They say we must choose from a list of classes, but they don't guarantee that we will gain important skills and experience.
The disconnect from the real world or at least from what we anticipate the real world to be. Most classes really are just making a little project and chucking it over the wall, as was aptly put in class. There are no stakes other than a grade and nothing feels worth getting invested in - there is no value to extract from them except purely as an exercise.
For CE, its the ability to choose your upper level classes. There are certain 4XX classes that have required 3XX classes. When we're asked to choose the 3XX we don't consider what 400 level that unlocks. It makes it so that when it comes time to choose 4XX, you feel locked in a choice you didn't know you made.
I don't think there are obstacles. I meet fairly regularly with my advisor, run degree audits, and organize my schedule to get things done. I would say I'm pretty on top of things and know what I need to complete to graduate.
Along those lines, there are many times where TAs and professors don't distribute material and information in a timely manner, including grading assignments. Oftentimes, assignments are graded without a time to improve for the next assignment.
A lack of information about professional practices. There are just one or two classes related to software engineering.
Again the answer is probably myself. I can't really blame anyone because I know I could've asked for help.
Freshman and sophomore year they basically tell you exactly which classes to take if you want to graduate, and it seemed the vast majority of people took 330 & 351 together Spring of sophomore year. By then, you have likely already done Math240/241 decided by flipping a coin thus determining your career path from your specialization options now.
When registration rolls around towards the end of sophomore year, you are faced with a choice of which classes to strategically take, and the last thing you want to do is listen to a Basket Weaving major from South Harmon Institute of Tech (a CMSC advisor) on which classes to take. "Whatever interests you" is the worst advice to give to students striving for employment and graduate education after their stay at UM. I just know there is some hidden guide to registering for classes and optimizing your track to graduation which quiet little pockets of students have, and I feel like an outsider going on the website and rolling the dice to get whatever CMSC-4XX classes I can get my hands on and hoping I don't accidentally sign up for 2 classes which should really be 12 credits each.
The biggest obstacle is that in this highly sensitive battle of me vs the degree requirements, the difference betwen making these few years packed with 18hr days and these few years being packed with some little coding here and there and hanging out at the fraternity house the rest of the time is simply the luck of the draw. My advisor doesn't even know what wifi is, or linux, and she is thus not a great resource to guide me to graduate successfully. Hard work beat luck in my case and I ended up navigating the cirrculum well enough.
I would re-list my response from 3 here but also lack of class like 435 it's hard to know what an actual job is like or an actual project is like.
The major obstacles that prevented me from knowing where I would go in CE have been bad professors. It's as simple as that, ask any EE or CE student and they will tell a similar story. Although there have been great classes in both CS and CE, there were a fair share of bad ones. By having unenthusiastic professors with lazy teaching, ruined my interests in higher level computer engineering classes as I often felt like I didn't learn a lot. If I had more engagement back then I would have been more interested in exploring different areas of the field. This isn't to say that all professors are bad, our spirit guide is a perfect example of someone who is enthusiastic and pushes me to explore different aspects of computer science. My interest in learning about linux and software development practices drastically increased after Professor Purtilo's lectures and conversations. They sounded boring to me before but now my entire YouTube feed is filled with explainer videos and off topic computer science projects. I've also started my own project with one of my friends because of the material I learned in this class.
I'm not entirely sure how to answer this question, but I think it is hard to know what is expected of me without knowing what a class entails prior to covering the material. For example when I was registering for this class, I didn't know what to expect besides group work. During the class's instruction is became more and more clear what my role was in the class and what was expected from me as a student. Some classes seem very disorganized unlike this one. For example I am currently taking a class where the material covered in class is far more difficult than the material on exams and quizzes, so it becomes unclear what is expected of me to know at times.
Courses with vague instructions for homework and projects
There are not many obstacles in this regard. I belive UMD's audit system does a great job of laying out degree expectations I cane easily refer to and see all of my degree expectations
Unclear requirements. This was less of a problem in CMNS, but as a double major, ARHUs requirements can be vague and impossible to figure out without scheduling an appointment with an advisor. I dont think CMNS (at least CS) has that issue to the same degree however.
My own lack of interest. As a CE major, the courses in both CS and EE which I personally found interesting were, such as this one, cmsc420, couple enee498k (lab in electric car design) and a few others were ones I was successful in but wasn't so good at courses I did not find interesting or enjoy attending. It does have to do in some part with course material and the approach the instructor takes.
N/A - It is pretty clear what instructors expect w.r.t. coursework, and it's also pretty clear what the department expects as well in terms of meeting requirements.
An assumption of prior knoweledge. Many students posses a knoweldge base in technology that I do not have that puts me at a disadvantage when taking CS courses and increases the learning curve at the beginning of each semester.
Impossible classes that expect you to do bad and curve
Information isn't always easily accessible, or made obvious at all times. I generally have to go talk to my advisor specifically about certain things if I have questions
I am not quite sure what the expectation is being defined here. If it is about what it takes to graduate with a CS degree, then a simple visit to the undergraduate major requirements, or a visit with your academic advisor should clarify things.
If it's about work ethic or a caricature of what a CS student should look like then that question is more interesting.
What is a CS degree? I think a lot of people studying for a CS degree are aspiring to be a software engineer. And who can blame them? Work-life balance, salary, and general happiness are all qualities of a desirable occupation and a CS degree is probably the best way to attain it.
However the problem is that Computer Science is more of a theoretical major rather than an applicative one. Think of it like a degree for pure math but only related to computers and computing. A lot of classes offered at UMD follow this theoretical study, and only a very few are actually applicable to the software engineering discipline. I think that most people studying this field have this misconception and no one has bothered to clarify it since employers only look for people with CS degrees and UMD is incentivised to retain CS Majors (as it is one of the most popular degrees offered here).
I know what is expected of me. The degree audit site did a good job of showing me what I needed and didn't need, and I ran it each semester. Other than that I feel that the gen-ed requirements were a little hard to understand. Maybe instead of having weird acronyms like FSOC or FSMA they could just be called MATH and COMMUNICATION. Just a thought.
There should some requirements just for the basic industry technologies, as I agree learning how to code is the priority over learning specific technologies, but most of my team not knowing how to use git when we started was concerning and most of the tech I use at my job I didn't learn in school.
Lack of detail in the degree requirements. There are many documents I had to go through to figure out exactly my graduation plan would be and even then I had to wait a few days to meet with my advisor to figure out exactly what my final plan would be.
5. The best way to predict when students will be compatible members of a successful team is:
I think you answered it yourself in our final class :). I strongly believe that if someone is willing to show up and 'give a damn' they will be compatible with most of the teams no matter what. Of course, they need to have some technical knowledge needed for the project, but most students who have made it to senior year in college would have that. In my opinion, willingness to be there for your team is what matters more at that point.
I think the best way to predict compatibility amongst team members would be to compare each member's strengths and weaknesses and what they're good at/what they're not so good at, and pair them up with others who balance out those downfalls. That way, not only will they be able to learn from each other, but there will always be someone on the team that will be able to lead others in the right direction on a specific task.
The best way to predict when students are compatible members of a successful team is their activity. If they are active in the group chat, showing up to meetings and class, and being attentive in our meetings and class is a significant trait that will show up in their contributions to the success of the group. It shows they care about the success of themself so they will want to have success in the group they are in.
Their communication. If they are not communicating their issues or what they are working on it will just cause disorganization. You cannot have a successful team if not everyone is on the same page. You would also need some form of leadership. Now that doesn't mean have someone giving orders, but someone who can help facilitate a good flow between members.
If they possess a wide variety of strengths. One thing we noticed pretty early on is that we all (supposedly) had similar strengths, which I believe left us weak in some areas. I would also say that we really cannot be the judge of compatible team members given that we had to vote three whole people off the island. That was truly the best move for us and I don’t think I would have enjoyed this class at all if I was constantly having to manage them, which proves that sometimes things change and some people just don’t go together.
It's hard from a professor's perspective but from a student perspective having a group that shares the same sense of humor. From a professor perspective, ensuring that each group knows how to do the same things is important. If only a handful know how to do what the project asks, it creates animosity.
How engaged they are in the first week and how willing they are to pick up difficult tasks. I would say the majority of my group was pretty active (or as active as can be reasonably expected) the first week once I started getting things going and organized meetings. Also, seeking people out and giving them work tends to make sure they're engaged. Not everyone will be proactive and take on work, but I think most people will get things done once it's been directly assigned as a responsibility to them.
As you mentioned in class today, caring is the most important attribute. Most students have equal knowledge of technical computer programming skills and ability to use their foundation to research and expand their knowledge of existing softwares. It's a matter of putting equally committed students together that make a successful team. If everyone cares about putting in the work to deliver a successful product, then it will come.
When the students are all communicative with each other. Also, the scrimmages because it shows how students cooperate with team members.
How much they walk the talk tbh. When we first started working together, one of our team members was very active in our group meetings. But despite his active participation, it kind of felt like he was just repeating the most generic stuff over and over again. And lo and behold, towards the second half of the semester, he was rarely present for our group meetings and was also hard to reach. It also didn't help that he didn't have much to contribute for the project, but he still messed it up at the end despite having weeks to finish it. It also didn't help that he was unable join the group for pizza and always talked about how busy he was (as if we didn't have our own stuff going on)
When the team members share a similar passion for the project and a desire to succeed, then they naturally succeed. When some players want to put hours and hours a day into the project, and some players want to check off the minimum requirements and watch tv, the less engaged team members are going to end up having nothing left to do by the time they get around to it. When everyone on the team is excited to work on the project, and wants to get a jump on it from the very first day, then they all end up doing more work anyways.
Interestingly, in the opposite case when the whole group is disengaged and doesn't really care, it tends to go pretty well. The work is divided evenly and pushing off responsibility to everyone else means everyone else is pushing off responsibility onto you. I've been in both kinds of groups and I think the engaged group is a better experience. The worst case which I have experienced as well is the group of lazybones with one star player. In that, the star player ends up doing just about everything. That project ended up being good, but it was a terrible experience and I disliked the rest of that group.
When they say there going to do somethig they actually do it. Also very effective commincation. If a person tells me they cant work on it till last minute bu they still do it there still a good teammember since they commincated everything. What drives me nuts with other group projects ive been in and pre split was when you ask if someone can do something or help out with something and you get no repsonce till its way to late. Also if there quick to help out.
This is a hard one. I've already touched on scheduling and spending time together but compatibility isn't always obvious. I think a group's leadership is going to determine compatibility. This is a lesson I learned the hard way this semester. In our initial team charter we ignored the team roles portion due to a majority decision on making decisions collectively and asking each other based on roles we assign later on. The problem with this was that we never assigned a leader and the leadership would naturally shift between whoever was most active that week or whatever effort was being led or the subgroup they were a part of. In hindsight this was a horrible idea. I should have been more proactive in this decision and taken control. Over the last few weeks, I have learned that if there is no authority figure, people will not live up to their deadlines or simply fail to show up at times.
The best example I have of a leader creating compatibility is from my time as an ENES100 TA. We had a graduate TA who was super knowledgeable and friendly but he had great leadership qualities. He held weekly meetings with a tell all and a bonding game. Most of the TAs ~10-15 would show up to these meetings despite their busy schedules because the meetings were fun! He would get the work done in the first half and the games in the second. It was great bonding time and it was some of the best time I had as a TA. Identifying that kind of leader and putting one on each team would be my solution to predicting compatibility.
Likely their ability to collaborate and be open with there teammates. I tried to be as open with my team whenever it was appropriate about my life like family matters or other schoolwork obligations and my teammates were also open about it as well. I think this led to a healthy and fairly successful team environment. These are the main aspects I beleive make a good teammate.
Engagement. The best teammates are the ones that care the most, and a quick way to gauge this is through their engagement
Theres a couple ways of telling this, many of which we use in this class, such as clifton stengths,previous work experience, and classes taken. But the best way is through trial and error. The scrimamges in the beginning of the year are the easiest tell-tale sign of a sucesful team. If members cannot handle the quick hitting scrimmages or cannot work well in small groups of 2-4, they will never be successful in larger team, longer term projects. From my personal scrimamge experience, from the first meeting I was able to tell who I was going to be able / want to work with on my team
If they have things in common outside of CS
How active a participant they are. If they are participating in discussions and such, they have a personal interest in seeing the project through.
Just seeing how much people show up and at least participate in the smallest sense. It's not a perfect gauge, because some people are just more reserved or quiet, but most people who will be good group members are often vocal or at least participative and play their parts well.
Based on their response when someone messes up. Those who belive in similar principles of how to respond when someone messes up wil often succeed when working on a team together.
How they communicate and how much they care about the project.
If they hold similar interests and have similar working styles.
The best way to predict which members will actually be compatible is their personality and work ethic.
People have their strengths and weaknesses. If we have a diverse group of personalities, everyone’s strength can cover another’s weakness when it comes to meaningful contribution to work. If we have a group with similar personalities, those weaknesses are exacerbated and the group may find it difficult to work together or even make contributions.
Work ethic is especially important. Simply having someone not doing any work compared to the rest of the group members can be draining for morale. This can lead to group conflict and tense dynamic between members which would not be productive for work at all. The same can be said for over achievers as well. People who find someone essentially doing the work themselves or taking up the work other people are doing can earn resentment from other members.
I think a willingness to be open-minded and accept that you can be wrong sometimes can go a long way with someone integrating into a group. Being willing to listen to other people as well as being able to take criticism would allow someone to grow and become a better fit for the team.
Whether or not they laugh at the silly memes I post in the discord. This is the only metric that matters. Being part of the planning process and coming to the in-person meetings is also probably a good predictor of how invested in the project they are, and by extension how successful the team will be.
I think initiative is the most important aspect of compatibility, and one could probably glean this from resumes - do they have personal projects, participation in extracurriculars, etc?
To have icebreakers in alternating groups to see which people seem to click well. Also, another way would be to have a buffer time of like a week where groups can test and see if they are compatible through various team building excersises (kind of like the scrimmages), this way in case a group is not compatible they have time to change expectations before diving straight into a project.