1. The team engagement practices that were both used by my team and useful to the project were:
First, we tried our best to make a prototype before the Greenlight. It was a terrible prototype but it gave us a realistic guess on things like cost and design that helped to guide us for the rest of the semester. However, the number one thing was meetings! We had twice weekly IN PERSON meetings where we discussed necessarily planning or did development based on our plans for that week. In preparation for these meetings we met with the client on Zoom essentially every weekend. And then we did weekly (except a couple weeks) in person 5-15 hr sprints at a member's house when development time was really needed. Doing these things in person really helped accountability and progress.
Discord was a very useful tool, we also connected with our client every other week, or when required over zoom. Other practices was task sharing together in person or over discord voice and assign each task to each person in different sprints on Trello. We had a discord channel for work-updates where we shared out updates with the team or blockers to work on. We had one in-person meeting on Tuesdays, but when most people couldn't make it, we rescheduled to another day or just met on discord. One big thing for us was communication. We talked about what issue we had, even when someone had to send a client message we all proof read it and gave the go ahead.
The most useful team engagement practices were regular meetings, shared internal deadlines, written notes, frequent check ins, and using GitLab issues and merge requests to track work. The team meetings helped us talk through blockers and decide what needed to be done next. Written notes were especially useful because they helped keep track of professor, client, and mentor feedback. Internal deadlines also helped when they were respected because the official deadlines were too late to wait for.
Another useful practice was having certain people lead communication with the client and mentor so that feedback did not get lost. Demo rehearsals and group planning before major presentations also helped because they forced us to understand the full project and not just our own assigned part. The most useful practice overall was when people communicated early about what they were doing and what they needed help with.
Discord. We had channels set up for specific topics like a work log (where people would post what they were currently working on), green light proposal, CDR, expo poster. Being able to make jokes, talk outside of the project (which we had the undeniably hardest one) led to a totally cohesive team. Our client was also VERY available, and we saw him every week, which led to some level of accountability by not wanting to embarrass ourselves with a lack of progress week-by-week. Purtilo likes to say if you've got vodka shooters on your timeline before you fail, you will. Keep the shooters 'til after delivery.
We tried a few things including a spreadsheet/Trello board, attempt at daily progress report for each member, and discord communication. While these things were mostly helpful, by far the most useful practice we used was a weekly group other than the client meeting. This 90 minute period could be used for whatever we needed to do, whether that was taking a step back and looking at our progress, figuring out a way forward, or just a 90 minute work session.
peer reviews were useful in tracking how each team member was performing week to week
Pitching our project in front of the class and demoing our project. Both these practices encouraged us to implement new features to our project on a weekly basis and ensure that we actually understand our project enough to be able to explain it to others, which is a valuable skill in the real world.
We relied on a combination of Discord, iMessage, G**gle Drive, and a mix of inperson and virtual meetings. Discord was our main place for us to share updates, ask questions, and make a quick call. We used an iMessage group chat at the start but didn't use it as much unless we needed a fast response. G**gle drive was very useful for shared resources and we had a mix of inperson and virtual meetings. From the start we planned on having around 2 inperson meetings per week and use the opportunity to work together or for in person code reviews, but as the semester progressed (particularly after cdr), we barely met in person asides after classes on tuesday and thursday which affected our progress a lot.
We met twice weekly. In person is necessary in my opinion. Also, we had a Discord where we communicated CONSTANTLY. We had channels for each week, each of our subteams, and each major assignment. We also messaged any time we were working on something and when we pushed our changes. Communication is the most important thing.
Having consistent communication via Discord. We had a channel for daily work check-ins that were extremely helpful, and we also had each other’s numbers to send urgent messages. We usually just utilized pinging specific people when necessary.
We also made good use of tracking documents when we had papers due, splitting up each section and marking its status; this was most helpful during final delivery.
We held two meetings each week with each other and one meeting a week with our client. This ensured that we all were consistently on the same page and we knew how to proceed with the project throughout. Additionally, major development sprints were done in-person on weekends over (usually) 9-12 hours to maximize the amount of communication and collaboration. This type of communication and ability to quickly clear confusion and learn our next steps were a very important reason we were able to deliver a successful product. We also communicated with each other on Discord in between meetings and sprints where we could keep each other accountable for upcoming assignments, tasking, deadlines, etc.
Consistently making tickets on the website, active Discord and iMessage group chat, repository updates automatically showing up in Discord, frequent in-person meetings (up to 3x a week), ClickUp, GitLab
Have lots and lots of meetings with your team. Once a week is not enough, also reach out to team members who are not so active in the project.
Weekly meetings. We met once for 1.5-2 hours in person each week. Towards the end of the semester, we also had online calls on Mondays & Fridays for around 15-20 minutes as check-ins.
Communicate on Discord. Having some sort of communication method that allows separation of chats based on topic was extremely useful for project work, and having your main communication method on PC as well as mobile is great for not interrupting your workflow. Also try to have your team socialize and talk about non-project things. Try to get a meal outside of project meetings sometimes: it really helps to have a team that can get along outside the class.
Consistent in-person meetings are integral to success, because virtual discussions can never match the same level of productivity. Regular check-ins are also important, and "standups" whenever possible help keep everyone on the same page. Using some method to track tasks for everyone is important, whether it be Trello, Jira, or a simple spreadsheet (what we resorted to after a while).
For the scrimmages at least, I found the Gallup surveys to be really insightful. We all really resonated with our results and I noticed we began to identify with these characteristics and lean into them as a consequence. We now have an inside joke where we call each other nicknames based on the Gallup personality categories. We probably only felt comfortable doing this because we were already friends, though.
We held two in-person meetings per week, which ensured that everyone was actively involved with the project and team members could help each other if needed. We also arranged four all-day "sprints" on Saturdays that accelerated our progress when we felt we were at risk of lagging. We communicated in a Discord group in between meetings.
Our team benefited a lot from having frequent in person meetings. It started out with just the team meeting in person twice a week. These meetings were always much more productive and we were all able to get a feel for where we were at with the project and our own personal tasks. Quick sync-ups were alright but the in person meetings let us bond and at the same time get much more work done and if you needed to ask someone a question they were 2 ft from you. These in person meetings then switched over to incorporating our client. After doing this I saw an extremely noticeable uptick in how much we were getting done. This was due to our client being able to tell us specifically what he wants changed and then we could take notes and easily know exactly what he expects. Emails were working but the in person meetings really brought out what (client) wanted us to get done. This greatly sped up how many bugs and features we were rolling out and it got us from (client) being shaky on buying a new server to host our product to (client) having full confidence in us and wanting to go ahead and buy us a server to run the product. These meetings also served as a way to see how much value (client) was getting from our product. We saw him using our product to publish some new transcripts and even saving himself time every morning on manually doing certain things. This made us extremely proud of ourselves and motivated us to keep moving at a faster pace.
Number ONE BY FAR IS Constant communication. Since that was the thing we lacked a lot when first starting this project. We even had you to intervine during winter break and suggested to us to have more frequent meetings. In which we did and was able to catch up to the rest of the class.
We made sure to always hit our quota of atleast 2 meetings per week, even if they had to be online. It was extremely important that we knew what our expectations were for the upcoming week. This means that each person knows what is expected of them by the end of the week, and it'll be reported as done, or we will discuss potential blockers that stop them from achieving their goal.
TRELLO. Trello was vital to keeping our project organized, by lists of tasks that needed to get done. Trello lets you assign tasks too, so this let us constantly see what tasks were who's responsibility.
Weekly standup meetings within our group, as well as weekly meetings with the client. The intra-team meetings helped us keep each other on track, listing what we've gotten done and what we planned to do for the rest of the day/week. The client meetings helped us stay on track with the client's specific goals and desires for the system.
regular check-ins and dividing tasks based on people's strengths. Our team also benefited from being honest about progress instead of waiting until the last minute to say something was not finished. When we actually communicated early, it was much easier to adjust the workload and avoid confusion.
The biggest one for my team will be the 2 team meetings and one client meeting every week each with an avg of 2hrs each. this put us in a situation where we saw each other for 5 days straight every week. this practice helped keep the team in check, we could always bring up any ideas we had in person literally the next days without having to wait. meeting everyday also helped us to move a lot quicker, we were able to find out what worked and what didn't work pretty early on in terms of implementation strategy or a feature.
our weekly client meeting also helped us speed up the rate we iterated on the product we never spent too long going in the wrong direction it kept us really efficient in terms of the hours we spend on development.
Meeting both in person and online, with emphasis that in person meetings were the most productive and easiest in terms of communicating with each other. Also, we kept a trello board in the beginning ,which was nice when we used it, but it was left behind not too long in development. Additionally, we would have a daily check-in channel on discord that would keep people accountable and knowledgable of each other's work and progress.
Our team found plenty of success this semester due to our high volume communication. When making our charter we agreed that meeting in-person and frequently was a must-have if we wanted to build a quality product and do well in this course. The professor also mentioned that having in-person meetings with clients was very beneficial if possible. We had a client meeting once a week and it was extremely helpful for us to understand the problem, make adjustments to our product, and add new features. I would highly recommend meeting with clients frequently in person. Additionally our team met two other times per week in-person and communicated daily on discord. Find your channel of communication, meet in person, get to know your teammates beyond a surface level and you'll succeed.
Weekly client meetings (every Wednesday) for demo and feedback, daily sync-ups (in person or Zoom) to track blockers, and using tickets to manage sprint goals.
The polls while did not take that much time did not really seem to really be substantial. I feel like it was just a quick statistic that didn't really stick after it was flashed to us for like a minute in class. I think peer mentoring while was not bad could perhaps work in a different format like a discussion, which would be more effective.
2. If I could make ONE change to CMSC435 to make it a great class, it would be:
I would add stronger team accountability earlier in the semester, along with better team matching at the start. Peer reviews at the end are helpful, but by then a lot of the damage is already done if some people are not contributing enough. I think the class would be much better if there were earlier individual contribution checks tied to actual commits, merge requests, documentation work, meeting participation, and teammate feedback.
I also think team matching should consider project preference more seriously, similar to engineering capstones. Students should have more say in the type of project they work on because motivation matters a lot. When someone is placed on a project they care about, they are more likely to put in effort, learn the system deeply, and take ownership. Technical strengths, communication habits, and leadership style matter too, but project interest and commitment level should be a major part of team formation.
A strong project becomes much harder when only a few people care deeply about the outcome while others are mainly trying to pass the class. Stronger accountability and better project-based team matching would help students who are putting in a lot of effort not feel like they are being pulled down by less active teammates. It would also push everyone to take ownership earlier instead of waiting until the final weeks. If this change were added, I think the class would feel more fair, teams would be more compatible, and projects would perform better overall.
While I understand the point of the scrimmages, they were largely just annoying. The team formation was very inefficient. I got placed on an incredible team and an amazing project, so maybe they were useful for Dr. Purtilo, but largely an annoyance for those in my team I asked about it. To make a tangible difference, I believe Purtilo should make instructions but clearly state that 'Hey, you should probably ask questions, and not make assumptions". It would provide the benefit of the scrimmages, while still giving room for people who weren't going to engage to get placed in their appropriate teams.
My one complaint in this entire class is scrimmage 3. It felt far too vague, and everyone scoring around a 70% that I've talked to no matter the group is somewhat proof of that. It felt like it was set up for failure to make sure we were engaged with the rest of the course, but that seems to be affecting the wrong group of students. The ones who care about their grades are likely to care more about the class regardless, but the ones who just want to pass won't care too much about that.
Less research projects and more industry projects
The projects people work on. I think the project each person is placed in could be better and male the class better for them. I know there is no guarantee and this class emulates the real world where you can really start anywhere with zero knowledge of that industry you're working in or the tech stack, but seeking a better measurement of students interests in projects and putting them in something close to that might influence their perception for the class. For me, I wish I had the opportunity to work on another project.
Be a little more clear about the textbook and what chapters are being covered in class, especially if future classes will have more consistent quizzes. We didn't have many quizzes so the textbook didn't feel too relevant this semester, but for semesters where there will be more consistent schedule for quizzes, students should know which textbook chapters the lecture is covering so they can review appropriately.
This should definitely be a two semseter course so you have time to get grounded in the principles.
Give the earlier assignments less weight. No one has experienced a class like this at UMD, and I think there should be more leniency as we dust off the cobwebs.
Having more build time. This semester was unique since we had a week off for snow, but it caused timelines to shift. My team accounted for not working during spring break which turned out to be a mistake since that left us with only 3 weeks of build-only time. I think that spring break should be time for a true break and that it shouldn’t be counted in the given 4 weeks of build time.
I believe this class was well run, and I understand that the reason for ambiguity is to test who is willing to learn and ask, versus who is not. However, the beginning of the semester did feel pretty cryptic in terms of how our performance would actually impact our team assignments (e.g. learning that nobody got above 80 on scrimmage 3). My one advice would be to keep ambiguity, but provide some more clarity into your decision making system, as it give us some light in the dark so to speak.
More consistency of workload and complexity between all of the projects, especially if grading for all projects is on the same scale. Of course, I am biased because my team put in the most hours every week (which, the numbers may be inflated for some members as we realized we all had different criteria for what counts as project time), but there did seem to be some disparity between projects. However, that higher complexity definitely helped us develop our skills a lot more than a simpler project would and I only hope that every student who takes this class can develop those skills.
One change that I would make is to provide one specific textbook to read and assigned chapters to read every week.
Make tickets graded on a weekly basis, like peer mentoring is. If you do one, you get the grade. If you don't, 0. I forgot to do tickets occasionally, and this would ensure I didn't do that.
I think that having more social time to talk with people in the class would help make it even better. At the beginning of the semester at least, it would be nice for class to have some organized activity to help people interact with each other and get to know names and who everyone else is.
Facilitate more inter-group discussion, perhaps with a class forum. Talking with other groups when we got the chance was always very insightful, but these were usually chance encounters. I believe that even more direct interaction (not Decidio) would be very valuable.
I'm not sure if this is a good idea or not, but I think it might be nice if we had more say on which project we ended up on. I loved my team and had a great semester, but I think I would have preferred to be on a project that was a bit more rigorous. Maybe you could give everyone the chance to make a ranked voting style list of the projects they would like to work on, and then take that into account with their engagement scores to make your decisions. I just had an absurd idea of making public rankings of student engagement available and having students compete for first pick of the projects. That would create a horribly competitive environment and would never fly in an actual class, but it would be really funny to watch. I would watch a reality show about that.
I believe that there should be a lengthier disucssion of good version control practices. While we covered aspects of SVN and basic practices on what to include/exclude from repositories, I would have appreciated some guidance on more complex repository management that we would likely need for our capstone projects, such as coordinating repository usage with other team members.
I would add more alumni days. Whether it be just meeting them and networking or showing off our project. The first alumni day was such a great help to my team. The alums were able to suggest multiple tools and libraries we could use and one of them even led us to using the LaBSE model for our semantic scoring system. On top of providing helpful tips it was amazing to see successful alumni who could give us valuable tips to guide us in the next steps of our lives being our careers. Networking is very important now a days and if even one student is able to get a job from an alumni I think that would be a huge success.
I would add more ungraded exercises to lecture. The material that Dr. Purtilo went over was super VALUABLE and I plan on using much of his advice for the rest of my career as a software dev; however, there were some days where I found myself getting distracted during the lecture itself because I was either thinking about the project or just your ears shut off after a while. I think some ungraded exercises or even just calling on people more often would help (this was more common in the first few weeks but then kind of decreased).
More time for student to meet everyone else (especially before making groups). A lot of the time it seems like everyone was sticking with their group. So I didn't really meet anyone else thats not in my group.
I would make some of the lectures into team exercises. Or even just parts of some lectures. It could be 15-20 minutes dedicated to having each team discuss a list of introspective questions. They could be questions like "Does everybody know what is expected of them?", or "How would you describe the project velocity? What improvements could be made to go higher?". I do not believe it is the Professor's responsibility to hand-hold us through figuring out our team dynamics. However, I do believe a couple forced discussions could be a great benefit to each team, and even the course as a whole.
I would moreso change the curriculum, either adding more of the software engineering principles to introductory courses, or adding a 300 level course as an introduction to these principles and ideas. I think they would go a long way in our overall preparation as CS majors across campus, as well as for this specific course
I would make the project expectations and grading criteria clearer from the beginning. Since the class depends a lot on teamwork and long-term project progress, it would help if each phase had very specific examples of what a strong submission looks like. That would make the class feel less like guessing what is expected and more like learning how to improve the project step by step.
Have students choose the project they want to work on. I don't know how that would work in practice but it is the biggest change I could think of.
Adjusting the weights of grades. I find it crazy that the scrimmages are worth so much of our grade. They are very important for forming quality teams yes, but their impact on grades should be less. We have much less time and knowledge while working on scrimmage 3 for example which is worth 10% of our grade. This 10% is EQUAL to the final delivery which we spend the entire semester working towards. 1-2 weeks at the beginning of the semester of being naive should not be the same weight of our grade as the most work-intensive project of our college careers. Great class otherwise and nothing I would change. The challenge was super beneficial for my growth, but this one thing irks me.
I would suggest using ELMS calendar for important deadlines. That would save a lot of efforts. Attention, worries, concerns, and stamina to adapt to new tools are also invisible costs.
I would say that perhaps having more check up assignments might be more helpful since it could really help all the teams gauge the status of things, not just in terms of progress, but also how to better move forward in working together.
3. The one thing that most gets in the way of me doing my best work in CS (CE) here at UM is:
For me it was balancing multiple technical classes with work and other commitments. Also a tradeoff of trying to deeply understand the material rather than chasing grades. I think I would have done better if I would didn't have to commute and stayed on campus.
The biggest thing that gets in the way of me doing my best work in CS at UM is the lack of real building opportunities earlier in the program. A lot of classes teach important theory, but there are not enough chances to work on meaningful real projects, research, or partnerships with companies where students can build something that feels close to industry or real-world use.
I think students would benefit from more project-based opportunities where they can work with real clients, labs, startups, companies, or campus departments. CMSC435 was valuable because it gave that kind of experience, but I wish there were more opportunities like this before senior-level courses. It would help students build stronger portfolios, learn professional tools earlier, and understand what real software development looks like outside of homework assignments.
Another issue is cost and advising. UM is expensive, and sometimes it feels like students have to figure out too much on their own even after paying a lot to be here. Advising can also be frustrating because it is not always clear, practical, or personalized enough. Better advising, clearer pathways, and more real project opportunities would make it much easier for students to do their best work.
The lack of community. It feels very isolating to just go to class, do my work, do my exams, go home. I don't know if this is a Gen-Z thing but I fear we don't really make small talk anymore and that is kind of sad. In CMSC351, there was a very active Groupme, and people would organize study groups, lament their exams, etc. This course provided community in the major that I had not had since 351. Honestly, if I didn't have that, I wouldn't have spent the nearly 250 hours I did to complete this project successfully.
My own motivation. I am not the biggest fan of classes and school, but I do it because it is useful. One thing I appreciate about this class is that is the most (and maybe only) practical course I have taken in this university.
Exams in other classes
Professors who are unable to effectively teach others about a subject. Every class I've struggled in at UMD was the result of a professor having a poor teaching ability, thus forcing me to learn the class on my own. Of course, this doesn't refer to Purtilo, he is an amazing teacher.
Having too many classes at once, especially when they have midterms, projects, deliverables due around the same time.
Myself. In my experience, you can get by in many CS courses by not going to class and looking over slides.
My own fear that it won't be enough in the end. And other commitments that I have
Myself. I tend to procrastinate or not do assignments as soon as possible, since most classes boil down to "read slides and do the homework", which demotivates me specifically as that style of teaching does not work the best for me, however I must be adaptable to what I get.
Fluff "projects" or work that is not very relevant to where the job market is going. I believe theoretical classes are important, but the non-theoretical ones should not use antiquated practices and actually prepare students for how to code, which also means embracing AI. For example, many of my job interviews have started to ask me how I use GenAI tools in my classes and projects, and it is essential the school gives us the preparation needed to successfully answer questions like that. There are other things that seem to get in the way of actually learning program, and I think exams that test things like syntax or history (within reason) are not a good use of time. More flexibility in projects would be nice too, more relevant in other classes but I think students should be allowed to build whatever they want for things like final projects (and even normal projects) as long as it meets the criteria of what the class is trying to teach.
Group projects always have members who arent as dedicated to the work as you.
Procrastination/ADHD. Find what works for you to improve it sooner rather than later.
Some of the lecturers here are just not good at making their content understandable. I usually have to put a significant amount of time outside of lecture to figure out the content, only to figure out that a lot of the details I was confused on were not too complicated. My concern is not that I find content difficult (it should be in higher level courses), but that a lot of the content really shouldn't be hard but ends up getting difficult to follow through the way it's taught.
Focus on shallow assignments and exams in lieu of true learning and understanding. Getting an A in a class doesn't mean anything about true mastery of most classes.
Honestly one of the biggest things that gets in my way is not being able to collaborate with other students on the projects. I work best in a collaborative environment and I really enjoy talking through problems with other people, but it's forbidden at UMD and very strictly enforced. As far as I know, Montgomery College didn't have that policy, or at least no one told me about it if it existed. It helps me become a better programmer to have to explain my thought process to other people and bug fix together. I also think people would be less quick to turn to AI for advice if they were allowed to talk to other students and collaborate to learn and work through difficult problems. Also it might help some chronically online people to develop better social skills. There aren't enough TA office hours for this, especially not for the upper level courses (There are a good amount for the lower level classes at least).
I wish that more CS courses covered "practical" skills with coding and software. Typical CS courses taught me high-level concepts, but I was always left confused as to how to demonstrate that knowledge in the real-world. During the few times that courses wanted a practical skill (like managing a repository with a partner), I felt like I had been thrown into deep water and relied on more experienced classmates to fill in my gaps. CMSC435 answered many of my questions about the "process" of making programs. Also, the crowd size at many UMD CS events has limited my ability to learn from and utilize them.
The biggest obstacle is being able to balance the large workloads across multiple technical classes. I often have multiple large projects, labs and exams all in the same week. This leads me to never being able to solely focus on one class or subject matter. This led me to feel like I really didn't learn anything and I was just trying to learn as much as I can for a grade or for an exam. This led me to having a very lackluster experience in many of my classes and sometimes I felt like I was just being milked by the college for money rather than actually being prepped for my future career. This was even more apparent after I had only 1 summer of being an intern. Over that one summer I learned 10x as much as I had in my entire college career. I was internalizing and actually learning things rather than just being forced to because I was being graded on it. I was able to enjoy work due to this and it sort of made me resent my college experience when it came to classes and school work. 435 was the only class I ever took that made me feel like I was actually learning/internalizing the material from the class and I feel like many other classes should be like that but they simply weren't. I don't know why this problem is what it is but it was definitely disappointing to feel like this especially after how much I have spent on going to college.
Oh I could go on for hours and hours about this one but I try my best to sum up. Because we are a research institution most classes place an emphasis on theory and mathematics. For example, in both 320, 421, 422, and other classes we learned about and did week long projects on K-means, a very simple topic. It is good to understand these things but then myself and others often lack experience for what interviewers are looking for and what we will need on the job (especially in the soft-skills department).Because of this it has essentially become necessary to supplement your college curriculum with internships, hackathons, co-ops, personal projects, etc. 435 Actually taught me a lot of these missing things I believe it to now be the most valuable class available in the UMD CS curriculum at this point.
Can't think of one but if I had to put something I would say is class work/ schedules. The thing is that I work best in-person with my team members but the thing is that most/ all of the time my team members have scheduling conflict. So we always had zoom meeting and not in-person ones.
I often have a lack of motivation in most classes. Many 400 level courses have a lack of framing towards Industry practice, or industry skills. UMD often teaches the theory behind concepts, and even their history. But we never know how this will be used in industry, or what jobs/fields these classes and languages correspond to. For example, when taking a course on programming proofs, I had literally no idea why the language, Dafny, or any of the software in the class would be used in the real world. This leads to a lack of motivation, because I can't see the overall purpose of what I'm learning. I am motivated to do my best work when I believe that it is an opportunity for growth.
The disjoint between some course expectations and what we learned in previous courses served as my primary roadblock throughout my attendance at UMD. The primary examples that come to mind are with this course, never seeing a lot of the software engineering workflows/approaches, the lack of group projects throughout introductory courses, as well as the technology gap between classes, e.g. self teaching technologies we are expected to know.
balancing the workload across multiple hard technical classes at the same time. In CS/CE, many assignments are not just do the homework; they require debugging, researching, testing, and sometimes spending hours stuck on one issue. When several classes have projects, exams, and deadlines in the same week, it becomes hard to give each assignment the time and focus it deserves. I feel like I often have to choose between doing something really well and just getting everything submitted on time.
Honestly it my actual job outside of campus, that probably the biggest limitation for me personally. i work a full time job outside of school so most weeks i am putting in over 40 plus hours which limits the amount of focus i was able to give to doing school work regardless i made it work, might have taken some late nights but i made it work. a way i would do this better if i could start over would be to manage my time better and try to squeeze out as much productivity out of everyday as much as i could to reduce the need for the late nights.
Maybe lack of guidance. Even the already available resources at this University only help to a certain extent. Like said in class, more technical guidance would be appreciated.
My social life. This is not me boasting, but I have build up many relationships over my 4 years here including in a fraternity, two club sports, a girlfriend, and much more. I had to sacrifice so much time with these groups which was unfortunate, yet still needed to take time away from the capstone to ensure they remained strong. I just found it hard to juggle so much stuff all at once, but at least I improved my time management and procrastination which were lacking before.
Lack of a comprehensive view of the knowledge we are going to obtain when taking the first year courses. As a result, some students still only understand those CS courses as coding courses for the first several semesters. A comprehensive look at the architecture of the knowledge in CS as a first year CS student will help.
I think the few things that get in the way of my work is either issues with communication (so miscommunicated expectations) and I guess life when you get thrown curveballs and other commitments that you didn't expect showing up.
4. The obstacles that prevent me from knowing what is expected of me in my degree program are:
I think taking other classes like CMSC435 that samples real world practices before even taking CMSC435, would have made the class better to get used to. However, I thin the CE department advisors do a good job arranging the classes I have to take towards my degree, and I can disagree if I feel drawn to another course.
One obstacle is that degree expectations are sometimes spread across different places, such as major requirements, concentration rules, prerequisite rules, advising pages, course syllabi, and unofficial advice from other students. It can be hard to know what is officially required versus what is just recommended.
Another obstacle is that some requirements feel unclear or unnecessary from a student perspective. For example, having to take one 400 level credit outside of the major can feel like an extra requirement that does not meaningfully support my CS path, but still adds time, scheduling stress, and cost. When requirements like that are not clearly explained, it can feel like students are being pushed to take more classes and pay more money without a strong academic reason.
The program also does not always make it clear what practical skills students are expected to already know before upper level classes. For example, tools like Git, GitLab, testing, project structure, and deployment are very important, but students can reach a major project class with very different levels of experience. A clearer roadmap of both course requirements and expected technical skills would help students know what they should prepare for earlier.
Nothing, the degree track has been in my head since the first time I looked at it. I wish there were more application based courses like this, not just loads of theory.
Advising. I asked if I could meet with my advisor in person as I had multiple questions and wanted to have a conversation and was met with "I don't do in person meetings. Write your questions in an email". This, of course, resulted in a long back and forth email chain in what could have been a 5 minute meeting.
Lack of information of the exact purpose of certain CS courses in the long-term. The description of courses online isn't always helpful and representative of the course itself, and also requires you to know that the course exists in the first place for you to actually search it up. There should be a way for you to input the specific CS skills/experience you may be interested in (Java, making games, ios, cyber, etc) and a list of courses associated with those interests should appear for you to look through.
For the general track, it gets a bit vague knowing what classes you should ideally take for a path forward. There isn't that much guidance and it's basically just take 5 classes from 3 areas and nothing else.
There is no direction. There is a lot of incentive to just take the easiest classes with the easiest professors. Not the best for career preparation.
I personally think everything is pretty accessible
The advising. It is really difficult asking advising for advice on careers, paths, future classes, or anything related to computer science. While it is true that someone else should not decide your path for you, it also has to be true that we, as students, get advice and engage in discussions about the Current market or future paths from people who have experienced the field and have chosen to advise future members of the field. It feels like they are only there to repeat what I can find on websites or my degree audit.
Hard to reach advisors that don't provide useful information anyways and information being scattered across outdated websites and canvas pages. I've been disillusioned with this school's computer science program (or at least the logistical side of things) ever since my freshman fall where my advisor told me that I should take multivariable calculus to fulfill my 200 level math course, even though linear algebra was a prereq to the 400 level classes I wanted to take. I added my math major so I wouldn't feel like I wasted credits, time, and effort in taking that class. I have learned so much more about classes from my peers than the advising department, and half of my emails when I do try and get information get ignored or take weeks to get a response. The most important information is stuff you have to find out yourself. If it was not clear, I have some strong opinions on the state of CS advising, and I also think that the class registration process is stupid and inefficient.
I only talked to advisors a couple of times in my four years here. I dont know an advisor would help me or how I can find resources on my own. Not enough classes provide practical experience. 435 being the only class that comes close to this is very inadequate.
If anything, my own lack of motivation towards seeking out information.
Advising here is bad. The advisors seem to be overwhelmed with students so they cannot give serious individual attention to students. Communication is usually relatively slow and I do not really consider them a reliable resource for getting you on track. Figuring out the requirements on your own usually invites mistakes or misunderstandings, which invites serious consequences for your college career.
Non-technical advisors who aren't very clear about the relevant field (compared to Math, for example) aren't able to give truly helpful advice outside of the basic bureaucratic things.
My original advisor has been my biggest obstacle in this area since coming to UMD. Not only did he not know anything about computer science, he didn't even know basic facts about which classes I needed to graduate. Because of him I've taken multiple very difficult classes I didn't need for my degree which has lowered my GPA and my goodwill towards the advising program in general. I had no idea what I was doing when I transferred here and the lack of any sort of guidance left me lost and disillusioned and wishing I could go back to community college. After two years at UMD I finally feel at home here, but for a good while I hated everything to do with this school and wanted to drop out. The transition was really hard for me and I didn't have any support at all, neither academically nor with that transition. I really wish we had some place we could go in the CS department to get class and career advice from someone who is familiar with the field. Initially I was choosing my upper level classes based on a whim because I had no frame of reference of which ones were rigorous or good fundamental courses. Right now I know exactly which classes I want to take, but that was only because I bring that up in conversation with every CS major I meet to gather as much data as possible on class difficulty, usefulness, how organized the professor is, class structure, ect. That was actually how I ended up in this class. It has a really good reputation and was number one on my list of classes I wanted to take before I graduated. I'm happy to say it did not disappoint.
My original advisor quit last semester, and this semester I have an absolutely incredible advisor. She's sat down with me multiple times this semester for over an hour at a time to go over my academic plan and talk about the pros and cons of taking different classes, doing research, getting everything set up for grad school, ect. I'm pretty sure she's new here, but she's so knowledgeable on all the inner workings of the department and helped me find a couple administrative loopholes already to deal with some issues I've been having. My old advisor had me on the wrong plan for grad school, and she helped me completely change my plan to make it work. He had told me I could apply in the spring and attend grad school in the fall, which is completely false. My current advisor helped me work it all out and I decided to stay an extra semester and shift around a bunch of classes so that they would double count for grad credits. She actually may be the reason I am employed right now. I saw her at the spring career fair and told her about a company I had an amazing conversation with and really liked. After they hired me, she told me that she had gone up to them after I left and gave me a glowing review. So perhaps not the entire advising department is bad, maybe it was just that one guy. Still, I think we would all benefit from someone to talk to about career issues who has knowledge about the field. With the state of the job market right now, many of us are very scared and don't have anyone to turn to for advise.
As of now, I don't fully know the connection between "what CS majors are taught in class" and "what hard skills employers expect of CS applicants." I would have preferred more general advice for succeeding in the field from professors, like in 435. Additionally, CS can have a competitive culture where I am unsure of how "good" I need to be to succeed. I have decent grades, but how much do I need beyond that for a decent change at finding a job?
One obstacle is how the CE program is built at UMD. I feel like I never had my own major I feel like it was just a double major between CS and Electrical engineering. I would jump class to class and there would be very little in common between the classes. One second I was learning about functional programming languages then the next I was learning about signals. There was no cohesion between the classes and I often felt like I was learning material I simply didn't need. Another obstacle is that anything I learned about internship prep, interview prep or industry expectations came from talking to people older than me or people who had experience with those things. Not once (until 435) was I ever told what would be expected of me or what I should expect in my future career during college. It sometimes felt like students were just forced to independently figure out how to connect our coursework to real career preparation and what we were expected to know leaving college.
So I don't think I encountered too many obstacles other than you just have to be ready to figure everything out yourself. There are too many kids that professors, advisors, etc don't have time to teach you how to set things up. However, this in itself is also a benefit because it made me very self sufficient. In general, I dont think there are that many obstacles of "knowing" what's expected for the degree. Instead, I think there are many obstacles to actually achieving it, and knowing what will be expected of you in how to get and during a job (some of which i discussed in the previous question).
Myself to be complete honest. I have very bad imposter syndrone and that tends to effect my mental state quite alot. It something that happened during the start of college and I can't shake it off.
I am not sure what is expected of me in my degree program, because there is no semblance of a general guide to success. There is a lot of course variety, which I am grateful for. But I have no idea what practices I am expected to know by the time I graduate. Many of the earlier concepts, like memory management and functional programming, can be dropped and never touched again unless you choose a direct sequel to the class. Many industry standard skills, like version control, and ticket logging, are nowhere to be found except a select class or two. I am not sure what I am expected to know by the end of my degree, other than to have a general sense of what programming is.
Very similar to my point on question 3, but expanding a bit. The biggest obstacle for me, specifically regarding my knowledge of my expectations here at UMD, was primarily the lack of a clear path through the curriculum, and guidence through that path, or lack thereof. There are of course plenty of materials online, like the 4 year plans, and meetings with advisors, but I found that the different tracks through the major, such as machine learning, data science (my track), etc. did not have enough guidence around what they were for (assuming I didn't know about the topics coming in), what jobs they would lead to, and so on.
unclear requirements, different expectations from different professors, and not always knowing which skills matter most outside of individual classes. Sometimes degree requirements explain what courses to take, but they do not always explain what level of ability students should have by each point in the program. It can also be confusing when one class assumes knowledge that another class did not really cover deeply.
The school's advising is not technical and can't really help me pick classes based on what i want to do in the future if its not part of the pre selected tracks, i.e if i wanted to focus on cloud engineering as a CS student an advisor won't be able to help with that. i would have to really on word of mouth and class descriptions which won't tell the whole story about the class.
Unclear communication / lack of guidance as stated in the previous question.
The department class structures. I have felt like every class up to this point was just to go through the motions. I would walk to class, sit, maybe pay attention because I was uninterested and didn't see the relevance or the teacher wasn't entertaining at lecturing, talk to nobody, and leave. Then I would just do my assignments, get my grade and move on...for 4 years. I only made 1 friend from my classes to this point which I blame partially on myself but also on the course structure in CS. I certainly was not too motivated to find friends as I viewed classes like a mindless job and had pre-established friend and support groups. Most classes though have individual based work which doesn't force you to work in a team and meet new people, which is a required skill for the real world and fun. This was the first class where I felt like my education was actually worth the cost and I'm shocked the entire department isn't rallying behind this structure.
Introduction of elective courses use very fancy words so that it is hard to get what I should expect in enrolling in this course. Most of the time I only register for courses that seem to be important for job hunting / easy to get good grades according to other students' feedback. However, those might not be the things that would help me succeed in the most efficient way.
The obstacles that prevent me from knowing what is expected would probably be distractions that show up in your life like mentioned in the previous answer.
5. The best way to predict when students will be compatible members of a successful team is:
A good way is to measure each members passion for software engineering. Do they just want to pass they class or are they interesting in learning? Do they want to be accountable for a particular role, and even communicate when they are stuck and need help, rather than trying to fix it all and end up taking time and not getting anything done.
The best way to predict team compatibility is to look at how students talk about work, not only what technical skills they list. The way someone speaks about a project, their tone, their previous experience, and their willingness to help others says a lot about how they will act on a team.
I think a good team member is someone who shows ownership, communicates respectfully, volunteers when help is needed, and does not treat the work like it is someone else’s problem. Previous project experience can help, but attitude matters just as much. A student who is willing to learn, support teammates, and step up when needed can be more valuable than someone who has strong technical skills but does not communicate well or does not care about the team.
Engagement. Speaking up. Really, just any effort shown to match the rest of the team. Some of us had obligations outside of class and were able to verbalize that to the rest of the team. Even so, everyone still put in maximum effort and didn't slack off. Nobody was left holding the bag. If you think to yourself, I'd share a foxhole with this guy (or gal), you will have a successful project. Anything less, and you are doomed to not deliver a successful project.
I think being easy to work with is far better than being technically strong but difficult to work with. That could be in terms of personality, communication, or existing friendship.
Their level of experience as well as what classes they are currently taking. People with high workloads will be difficult on any team.
By comparing their personalities and finding students with personalities that compliment each other. Students who want to be the leader that tells everyone what to do are most likely going to struggle to work together, for example. The individual skills of each student are not as important in a successful team, as skills can be learned and improved very quickly over time, while personality is not something that changes so easily.
Shared work ethic and commitment level is very important. You could be friends with your teammates, you guys can vibe and all, but if you don't have a similar work ethic there'll be friction between the team when things get rocky.
How much effort they put in. A lazy team member will not fit in well with people who try.
If they can establish steady communication and if they can laugh together about something other than school work
If every person is humble enough to admit what they don't know, and help each other learn new things.
Honestly, what made my team the most compatible was that we were all generally social, easy-going, had a sense of humor, and shared interests. This way, our team meetings were more enjoyable and felt way less like doing classwork, even though we were still getting stuff done we were also building relations with each other. Now, personalities are hard to predict and doubly so because people are much different in class. I think the current way that temperaments are determined is good, and it seemed to have worked for our team. I think a lot of it is just the eye test, things you can tell by the way that someone acts, talks, or even passively exists. To properly answer the question, I think the best way to predict when students will work well together is when they have similar attitudes about how they approach their work and how they approach life in general.
How fast are they able to respond to a message by a team member. Communication and meeting frequency makes a successful team.
Communication and Contribution. Even if not actively working on something, how willing are students willing to communicate regarding working on things, making time or effort commitments, and sticking to them when the time comes.
The dedication of students to their work is a good sign if they will be compatible. If a team is all dedicated to delivering a high-quality project, then that's a good sign that they will put the effort in to work together. Certainly, when there are people in a team who aren't putting in as much effort to the project, there will be discontent and the rest of the team will be held back. Of course, it is also important that the team members can get along with each other outside of class. At the very least, they should be able to work together without drama but being able to be friends is a definite plus to teamwork.
The ability to communicate well and establish relationships that aren't just "collaborators". Being friends isn't enough to guarantee success either, but good communication and a shared ego is invaluable for the project to succeed.
Honestly, I think the engagement metrics are pretty spot on. A lot of team conflict arises from people not putting in the effort they should and other members having to pick up the slack. Even on our team, there was a bit of conflict about effort. Everyone was putting in a lot of work, we didn't have issues with that, but we did disagree sometimes about which features to add and how much effort that would take. I've had some arguments with other members of our team where I thought we should add some feature that would improve the product, but some of them thought it would take too much time and wasn't strictly necessary (even though it would have improved the product).
Early team dynamics (in the first week) are likely emblematic of what is to come. Pay attention to issues that arise early on and agree on fixes, otherwise people will develop habits that are harder to break. Check for level of active participation, frequency of miscommunication/delayed communication, and ability to calmly resolve disagreements.
The best predictor is whether team members are reliable communicators or not. They need to consistently contribute to the projects progress over time rather than waiting until the last minute when all their team members are waiting for their part to be done. I think technical skills is important but teams really start to struggle more based on bad communication, lack of responsibility or lopsided effort being put in. When you have some people putting in a lot of effort and others who just aren't matching that it causes a disconnect inside of the team and leads to resentment amongst the members of the team. When you have a team that is regularly attending the meetings, communicating their challenges with their task early and responding to all the messages to them they are much more likely to succeed. The compatibility of the team members is just so much better when the members have similar expectations regarding the effort they want to put in, specific deadlines and the overall project quality.
I had a very positive experience with my team. Dr. Purtilo tends to group you based on shared experience with the project scope and, more importantly, similar levels of motivation/dedication/engagement as a human. I would mostly consider myself on the higher side of dedication/motivation and I was teamed with others who were very motivated and dedicated. Therefore, we were very compatible as a team. I'm not saying this is the best way to predict compatibility and it certainly has it's share of downsides (eg its nice if you're on the nice team and bad if you're on the bad team, and also some potential considerations about privilege/outside circumstances), BUT it worked for me which is all I can say; and I'm grateful and proud of the experience I had.
Their ability to connect with others. I feel like it doesn't matter how good you are, if you don't work on getting to know your peers then you will just make your life harder.
The best way to predict compatibility is to look at the friction generated when trying to plan and accomplish tasks. I believe that compatibility is not the most important metric for success. I believe that leadership, planning, and ambition are all more important. However, compatibility is an additional force that is important for carrying teams to the finish-line. Low team compatibility will generate high friction. "High friction" looks like having trouble planning meetings, disagreements, lack of honest communication, and a hard time getting people motivated. If people are compatibile but have no leading and planning skills, they will have a pleasant time in each other's company but won't be successful.
The best way is to test communication between the groupmates. Admittedly, this would not be able to happen fully until at least some form of premptive groups are made, but seeing how well group members communicate within the team, as well as outside of it with instructors, clients, etc. really puts onto display how well students will work together. I think using the mini groups for the 3 scrimmages was a great test of this, testing how well we could work together. The groupmates that were hard to get a hold of typically either did not contribute adequately, or worked on their own and the group faced conflicts of some sort trying to merge the work.
not just to look at technical skill, but to look at communication style, reliability, work habits, and expectations for the project. A successful team needs people who respond on time, are honest about what they can do, and are willing to help solve problems instead of avoiding them. I think a short survey before forming teams could help, asking about availability, preferred roles, coding experience, communication habits, and how seriously each person wants to approach the project.
I will say putting students that have taken similar classes, in a similar degree and similar level of work ethic is what worked my team. taking similar classes usually helps breaks the ice between team members to start a conversation.
I think the scrimmages, where we were thrown in to team settings was a good way to analyze team member performance and strengths/weaknesses.
How communicative they are. If you reach out to them and they respond quickly more often then not and with a thoughtful response, then you know they'rededicated. Doing the little things is also important as a team. Looking out for each other by pinging people on upcoming deadlines is HUGE because it shows you care for your teammates success. Thus building trust and making your relationship stronger.
More deliveries. With more explicit deadlines, teamwork is more likely to be filled with a sense of ritual.
I think analyzing communication and even personality compatibility is important, since to work well you have to get along well, tension among the team is definitely something that can hold back work, and having a team that supports each other and are comfortable with each other are better than teams that are not.