1. The team engagement practices that were both used by my team and useful to the project were:
Demo dates were important for the shame factor alone. Not making significant progress between them was enough of an ego hit to motivate some serious coding. The CDR was a huge wakeup call and prompted some major changes to our design. The consequences of those changes were for both good and ill, but largely good.
Multiple weekly meetings. We met once a week on Monday for at least an hour to go over updates from the weekend, goals for the upcoming week, and other topics. We'd sometimes get food to make it more fun. We met on Tuesday's everyweek right before class with the professor to discuss updates and get his feedback. We met Thursday with the stakeholder to define specifications and show him updates. Meet regularly, the professor says it in class all the time but you're not gonna fail a software project by meeting with your team and stakeholder too often.
These were our regular meetings. We met othertimes as needed, up to every night.
Frequent team meetings online or in person, where we allocate a significant portion of our time discussing topics surrounding personal life, school work, and our experiences in the course so far. This allowed us to grow deeper bonds between members and get to know each other better, which cultivated a sense of responsibility and improved morale. The frequent personal contact also made it unlikely for any member to fall out of the loop or become too inactive. Active group chat on discord where we can consistently keep members updated outside of meetings. Within these chats the reaction function is often used as a way to acknowledge information or gather consensus.
Meeting every week in person. Meeting every week several times on discord. Reaching out to the customer to update them about our progress, and getting feedback from the customer, then using the feedback to refine our solution The Professor being available to us for issuing vm, issuing advice on how to use laravel, and many backedn issues.
Communicating through a Slack, and conducting group meetings through Zoom. Being able to have a designated app for team communication helped us separate our personal lives from this project and let us dial in on the project when needed. The zoom meetings were great for working on parts of the project together and was good for us to focus on completing a task.
One thing that my group and I did was that we met constantly, as Purtilo suggested. We had at least three weekly meetings. We had a general team meeting on Monday, where we discussed the weeks goals and any upcoming deadlines/assignments. We have a meeting with Purtilo on Tuesday, to give him updates on how the project was going, to ask any clarifying questions, and to get any wise sage advice from him. Then we had a meeting with Jayesh (our client) on Thursdays, where we discussed progress, showed new features and demoed prototypes, and got feedback. We had these meetings at a minimum each week, and it we were always on page with each other and we often had a lot of time to do team bonding and have fun as well. We also used Discord to stay in communication with each other, where we did daily reports on things we were doing and were planning to do, and we also used the Discord to generally talk about upcoming tasks, and plan any future meetings. These were all incredibly helpful, and we were able to diversify our roles and there wasn't much confusion about it.
Agile methodologies. Regular communication via slack, which I usually led to highlight what we needed week by week to meet deadlines. Here I would ask team members their availability for work sessions, when to schedule client/professor meetings, and what tasks need to be done or immediately assessed. We also used Jira to manage tickets and have these things written down for us to view in case new tasks needed to be picked up. Frequent communication via Discord (both in team server and between individual members) and meeting after every [other] class to discuss and brainstorm objectives.
The peer mentoring site, tickets and advice. It was really nice to see comments left by my teammates on a regular basis, sometimes I'd feel like I wasn't helping out the team enough but seeing their encouragement made me feel like my efforts were valuable.
Weekly meetings not only with each other, but also with Dr. Purtilo and our client. Getting constant feedback amongst ourselves and from two people with different persepectives on the project helped us consider the solution from all angles. Also recieving advice directly from the client who is going to use our product helped ensure we didn't overlook any component.
Another team engagement practice that worked was the amount of time we got food and spent time with each other. This happened more often as big deadlines approached, but we would order pizza or tacos and created shared music playlists while we worked. This helped bond the team, and was probably a big reason why we all liked each other and never had any fights.
Prototyping and design were probably the most useful for out project, and what we excelled at most. We did a lot of planning to decide on a product that would best meet Larry's goals and a lot of planning on the framework/backend for the site. This gave us a great stepping point for our design and initial development of the product.
Meeting regularly in class and afterwards was key in making sure that we moved forward as team and kept everyone on the same page. Frequent meetings made communication flow smoothly. There were times when our planning could have been better, and there were some miscommunications, but I think the team overall was very available and communication flowed well enough.
We met weekly, and everyone always came. All of our meeting were super consistent, which was helpful for making sure that everyone was on the same page and actually getting work done. Every week, we met on Monday from 7-8(or however late), every Tuesday at 11:15-11:45 a meeting with Professor Purtilo, and every Thursday from 5-6pm a meeting with the client. It's really easy to cancel some if it feels like you don't have updates or anything to talk about—but make it so you have something to talk about, and use the team time. Even if you're just sitting together and working, the consistency helps a lot.
We also used discord to communicate, and everyone was really responsive which helped. Especially in the beginning, we did daily check-ins which helped keep everyone accountable.
Having at least one of each of the following every week: Weekly Team Meeting, Weekly Team Meeting w Purtilo, Weekly Team Meeting w client. Also included "daily-check-ins" every morning to get the update on everyone's work per day. Helped us to stay on track with known bugs and repo organization.
Being able to swipe into and reserve IRB rooms and have a nice meeting space was super helpful in getting work done. Being able to have consistent in-person meetings was super valuable for productivity and team morale. The weekly professor meetings were helpful as well to get insight on obscure info that is actually pretty important to the class as well as being more comfortable interacting with the professor.
We made a discord channel to help communicate as a team. Before, the team was mainly using groupme, but I've learned that it's super important for everyone to either love/be willing to work with the communication platform you plan to use. When we were using groupme, the team did not communicate well and many people did not read the messages left in the chat, but once we changed to a platform that was more loved within our group, the engagement within the team exponentially increased. I think it's also super important to lay out clear guidelines with your team, so everyone works within their expectations of each other.
Meeting as a group regularly. It helped us stay focused on the project and getting work done every night we met for a couple hours at a time. I worked better when I was on a call with the team because it helped me stay focused and made the line of communication instant as I could ask questions and get answers immediately. Meeting with the client. He gave us useful feedback and asked for extra features. I wish we met with him more often, it would've made the product better. Meeting with the professor. Similarly, he gave great feedback and suggestions. We met more often in the beginning, but we should've kept meeting, it would've helped immensely.
Communicating frequently and effectively whenever we encountered any issues. We used a discord channel where we could message one another and hop on voice calls if we could not meet in person as a team.
The most useful engagement practices were using slack for communication,Zoom for meetings, Jira for writing tickets, and the peer mentoring site. Slack was the most useful as it is where all of the communication occurred outside of class and the occasional team meeting. There were a lot of times where the team needed to ask someone a question and slack was how we accomplished it. We also used that to alert the team members if a big change happened with the code or a deadline was coming up. I know I used it a couple of times to make announcements to the team about blog updates that are important that the rest of the team might not have seen yet. The second engagement practice was hosting Zoom meetings a couple of times a week with the team. These were great for having multiple members completing work on the project at the same time while being at our respective homes. We had members who lived across campus from each other so it would have been hard to get together late at night if something came up. We also used Zoom for coding sessions when deadlines were coming up. These were extremely helpful for making sure we had all hands on deck when important deadlines came up and we needed to grind out the rest of the work needed. Lastly, Zoom was helpful for hosting meetings with our client to get his feedback. Another helpful tool was Jira. This was used to create work tickets that needed to be completed. Everyone on the team got to see what other team members were doing and what needed to be completed. The last engagement practice that was helpful was the peer mentoring site. It allowed myself to get feedback from my team members on the work that I had done this week. It was helpful to see if the work I was doing was seen as productive. Overall, I was seen as a positive team member and contributor which is what I hoped to be.
Meetings during the week, whether online or in person, helped facilitate a culture of working hard amongst the team.
2. If I could make ONE change to CMSC435 to make it a great class, it would be:
I think the deadline for the proposal should be stricter than it was this semester. In the real world if you submit a proposal too late you're out of luck. This was less of an issue for our team and more something I noticed in other teams, but the lack of a hard deadline meant that teams were pushing into their development time and were rushed to release their product. I'm not sure if the deadline needs to be as strict as the CDR where it's a set date/time, but I think it was a little too loose this semester.
Greater clarity. The lack of any explicitly defined requirement for major assignments was initially pretty daunting. We weren’t given any direct instructions on how to complete our greenlight or CDR, and since we didn’t actually possess any professional experience it was difficult for us to figure out what we needed to have to earn a decent grade. Although I understand that the purpose is to encourage students to talk to the professor and actively try to get the information they need, it was nonetheless a very discouraging aspect of this course. Perhaps the professor could actively seek out teams and try to talk with them every once in a while to keep them somewhat more in the loop. Making students accustomed to these meetings could also encourage creator contact frequency between students and the professor.
Reduce the first week assignments weight. I cannot speak for other students, but I did not get into the course until after the first week of class. The first 4 classes had assignments weiging 12% of the entire grade. While the reason why it is that way is to weed out those that will not do the work, it also might defer most students from just giving up at the beginning, since we are all built differently. In this scenario, base on the financial difficulties I went through to get a umd degree in computer science, if I had signed up for this course at the beginning of my cmsc4xx course takings, I will have just dropped and went to take another course. Because every course cost money, and losing money is not something we all love doing since most students don't have a lot of money. However my goal was to understand the difference between software engineering and being a programemr or a coder. So I was willing to work with 88% of the grade left.
Quizzes too should be announced ahead of time. Honestly, sometimes I felt like there was some oracle deciding to place the idea of having a quiz in the professor's mind, on days when I am late for class or missed class because I worked overnight and slept too much.
A little more structure and directions on the proposal. We had to create so many iterations of the proposal since we did not know exactly what to fix when it was not approved for a green light. This resulted in our team losing one week of software development and came to haunt us at the end. Although I understand that this class is meant for us to figure out our own direction, some more tips of what you are looking for would be helpful for groups in the future.
I think the obvious answer that everyone would give is "more time for our project." And yes, more time would help. In fact, a lot of time would help. But that's not the point of the class, it's to be able to get a working product to solve a stakeholders problem in a limited amount of time, so that answer isn't really a good one. One thing that I wish that we had more of was exercises on actually acquiring a software engineering job. In our meetings with Purtilo we would often discuss on how to handle job interviews and navigate offers, and I wish that was something that was discussed in CMSC435. Usually, handling job offers and interviews is something that you have to learn on your own, but being able to learn it in a classroom setting would be very helpful.
1 page that contains all the deadlines and has all the templates/rubrics for everything that is graded.
Mandate each team to have regularized team meetings. The way my team worked it made it nearly impossible to have all of us at team meetings, since we could not agree on a meeting time for all of us. We did initially set recurring meetings of 9:30 Zoom MWF, but these were shorter meeting types since people did not have a lot of time for it, and thus work sessions could not be done during them. This meant a lot of our work sessions had to take place at night, when people were finally available to do work. This led to a lack of structure, and whether it be that some group members did not want to take the initiative to blot out time during the day, or would not follow through on commitment it made it hard to meet as a group. Perhaps this can be included in mandated professor meetings every week, which would also drive work pace.
Perhaps a little more input from students on which project team they'd like to be on. I understand that this can get complicated for the professor to manage but giving *some* weight to the students' preferences could drive up project engagement.
Give one or two more weeks for the full project. This is probably difficult because you gather many metrics in the first month, but I feel like another week would have given our team time to not be as stressed throughout the semester. The extra thanksgiving break did not help with this, and that was out of your control.
A second (small) change: A RSS feed for the blog!
I wish we could spend less time on the scrimmages. This might be specific to the scope of the Baxter project, but it would have been more useful to have more time working on the project. I understand the importance of the scrimamages and how you use it to form the teams, so I do not have an alternative to how to teach the scrimmage concepts while asigning the project groups quicker.
Helping more facilitation between group members. We had one group member that we could never get in communication with before he dropped, and we had another group member that became very difficult to get a hold of. I know this course is about developing communication, but I feel there is only so much one can do to try to get in communication with someone that isn't putting in the effort.
I think maybe we should be able to choose one person as the manager, so that way there is a person in the group that overlooks all activities and can make better decisions. (X) sort of filled that role for our group, but without any person as a designated leader, a diffusion of responsibility can sometimes take over the group. Also uploading the slides would be nice, they hold a lot of useful information.
The slide content. I enjoyed listening to you, and I think I would've gotten more value if I had specific best practices that I could take with me to industry. For example, acceptance tests: If I knew a best practice way to do that, I could've practiced it for the project and took that experience with me in industry. I like that the class is about doing, but having some of those concrete tools can be helpful.
Personality tests are bunk (in my opinion.) It's good to get people thinking about what their most effective role in a team would be, but dedicating as much in-class time to it as we did seems wasteful. I don't actually have a constructive replacement, mind you.
I would like to see a little more lab time in the beginning of when we get our groups. From what I remember, we got our groups and Thursdays continued to be more lecture based for a little while. Maybe make it a little easier to determine when things are due since sometimes they are kind of baked into the assignment description on the class blog. Other than that I really thought the class was well structured and great to be a part of.
Less walls of text if possible, and better communication on updates. Like sending out emails every blog update. (I know we can set the RSS feed to dump the stuff automatically, but having this set up already would be nice).
There should be a way to have more input on the type of project you want to work on for our final project. Since all of our projects were assigned, I feel like it's hard to grow passionate about the work you're doing, especially if it does not have coding concepts that are relevant to your interests.
Making the instructions for Scrimmage 2 and 3 better. Might've been just me, but I felt somewhat defeated from those early projects and took me a while to regain my footing in the main project.
I would have liked to have more structure for certain deliverables. I think providing a rubric would have helped the team streamline our process at certain moments. I understand the merit of having freedom to approach the challenges differently but sometimes the team felt as if we did not know if we were on the right track. On the other hand, when we had these issues we just contacted the professor to resolve them which was easy because you made yourself very availible.
One change would be to create teams where at least one team member has some form of experience for each part of the project. My team had little to no experience writing code in the javascript, html, and other user facing languages. There was a lot of time spent in documentation figuring out how to write the code necessary. It would have been nice to have a single team member who had substantial front end experience so we had a more solid foundation for the TIMELINE project, that had a focus on user interaction. Also maybe explain where teams could figure out how to include security into their projects if the team does not have experience with that.
Perhaps more room for error. I feel like I'm taking away the most from this class because I made errors, but those errors will cost me grades. Can't really speak until the class finishes, as only then will I see the totals of all the assignments and bonus points. Either more room for error academically, or more opportunities to make up for that error in the form of bonus points would make the experience more traditionally rewarding.
3. The one thing that most gets in the way of me doing my best work in CS (CE) here at UM is:
Lack of routine. An inconsistent sleep schedule alone has caused a tremendous amount of academic trouble for me.
The lack of organization and expectations in some of the upper level 400 classes (not at all including this class). I actually felt as if I learned the most in some of my lower level classes, i.e. 132, 216, and 330. I felt these classes were more demanding and in the case of 132 very realistic and applicable. As I got higher into classes past 330, I felt as if the management got worse.
For example when I took 433, I thought the content of the class was useful but because the class lacked TAs and everything was offloaded onto the professor, we had no exams and only 3 projects that were half baked. The lack of projects meant that while I learned the content, I didn't get the chance to apply it. I was also dissapointed with 335 which was too easy and elementary for a 300 level class. 451 was a great class and I would reccommend it. The content taught in 420 this semester was useful but again, the course wasn't that hard. Not that a course needs to be hard to be good, but the professor definetely could have fit more content in. I've felt this pattern across most of my 400 level classes, just a general lack of demand and content taught from upper level courses, at least the ones I've taken.
Rigidness. It was often very difficult to see the practical purpose of what we learned in the cs-classes and how they could be used in real world applications. This made it difficult to understand the importance of the subject or how to use it after the skills are acquired, which in turn both lowers the level of interest in class as well as the ability to take advantage of a course’s content after taking it.
Money. I had to work multiple jobs while taking classes at umd. A little money for my bills and expenses from my parents( or my ancestors) would have ease my studies. I always had to come up with impossible times to get projects done because sometimes working overnight, or in the afternoon took out the time to have fun in the projects and the course materials. The projects were a lot of fun, unfortunately I did not have enough time to savorate them the way I wanted to. However, there is a famous quote from Earl Nightingale, that I will paraphrase: "I am in one of two situations: Someone before me paid the price for me to have the life I have, or, I am paying the price for someone else after me to have the life I did not have." In both scenarios the price has to be paid. For some reason, it happens to be me at the moment, so get over it and move on.
Honestly for me, it is wanting to hang out with friends instead of studying. When it's warm out I love to golf and that gets in the way of me doing my best work sometimes, especially since golfing is such a time-consuming activity. The university does a good job of enabling students to focus on work on campus, but I do live off campus and making the trek to campus sometimes is too much of a burden. I feel like that can get in the way of me doing my best work, but as I've gotten older it has become less of a problem.
Probably my severe procrastination habit. One of the main reasons that I like working independently is because I can work at my own pace, and if that pace is saving an assignment to a couple days before its due? I'll get it done! I work very well under pressure and limited time, and this is usually how I do well in my classes. That's why I took this class, so I could learn how to more properly manage working on a huge project like this, especially when I'm working with other people who have different work habits. Sometimes during this project I slipped back into my own habits and delayed some of my tasks, but I couldn't do it for long and I had to pick myself up and plop myself in front of my computer so I could be a helpful teammate.
Motivation(myself), during semesters it goes up and down. Usually this affects how much work I get done for classes and how much do work I do outside of classes.
The lack of resources available in each course to succeed. The way that CMSC435 allowed for students to learn by trial of fire is unique to no other class, and I wish that other CS classes incorporated this concept. I think the nature of software engineering definately allows for more of this concept to be used, but other classes could have more hands on activites, instead of the same lecture -> quiz -> project -> exam cycle. Maybe I'm just tired of it.
Personal challenges with managing time. I had a particularly busy semester this fall, juggling new challenges such as moving and getting engaged, which made it increasingly difficult to commit the necessary time for "best work in CS (CE)".
A quality student-to-professor ratio. I understand that this is a state school, where CS is one of the most populated majors on campus. However, this was the first CS class I've had where the professor knows each students and pours effort into not only teaching them concepts of the course, but also the soft skills to give a more cohesive experience, with a greater level of personal learning.
I have a problem to over-extend myself. CS is a big time commitment by itself. In addition, I double major in music (super time-consuming) and am an active member in my fraternity. Managing acadmeic burnout and fatigue as the semester progresses is challenging, and often ends up in a decline in my engagement. I am fortunate to have a job loned up once I graduate, so without the stress that comes with career uncertainty, I tend to want to focus on my life passions, music and spending time with friends. I am not trying to say that is a valid excuse of why I can't put forth my best work, but I want to maximize my little remaining free time outside of industry on my passions. Academia also feels a little trivial after getting suubstantial experience in industry.
My interest in projects has usually been low to the point where I'm not excited to work on projects. This has made it so I only work to get things done by the deadline and not work to do my best work. I did really enjoy this product, though, as I always felt challenged and learned something new.
The professors are generally not engaged with the class. Of course, this applies broadly to UM and not to this class, where you are much more involved. But professors in general fail to motivate the students and engage them on a deeper level.
I think it's an inner battle. I think all of the work has been doable, but I feel like I'm not very technically competent. In reality, I could probably figure most things out, but I don't feel strong enough, where I want to market myself as a really good coder. I think it's kind of how women tend to think—like if we're not 100% certain or 100% good at things, we won't apply for the job or have the confidence and think we're good at it. It's always been hard for me to picture how I can go above and beyond in the software world, which is part of the reason why I shifted to product.
I think we also need way more team work. In the beginning, understanding the logic and learning how to code is important, but I would've enjoyed it more and probably produced better work if we had more team environments like this.
Not having more hands on classes. Classes are mostly individualized, especially in the beginning courses. Collaboration tools both socially in terms of how to communicate as well as the effect of costs in software should be more of a theme in the beginning AND how to collaborate with code including how git or svn type functionalities work and how they mesh together in a team scenario. This would not only be helpful for 435 but like as we start our careers.
Exams and projects often falling on the same dates even though the department could easily spread them out in some staggered fashion, at least for courses of the same level. Like a lot of students will take 250 and 216 at the same time, so why not have those exams happen a week apart
I did not have a lot of time to focus on my projects and coding skills because of other engagements I had with my other classes, work, and study programs. As such, it was difficult to put the amount of effort I wanted to into my major.
Time. The work stacks up quickly, whether it's from projects or exams. Those weeks become stressful and make it hard to get other work done. After those weeks, there's still little breathing room and it's hard to catch your breath once the semester initially picks up.
Not having access or requiring to jump through hurdles to attain some of the resources needed, as well as having most of my time being taken up by projects for CS classes.
The one thing that got in the way the most was trying to juggle my schoolwork and social life. I like to go and hang out with my friends on the weekend and not have to worry about homework. This in turn led to just saying I was done with a homework or project on friday and not trying to tweak it once I passed all of the tests so I could have free time on the weekend. This sometimes led me to be complacent in my work and not strive for the very best. I still made sure I put in a lot of time and effort, but I could have put in a little more. Honestly, I did not have this problem as much this semester.I put my work first which decreased my social life but in turn, I got the best grades I could. It sucked having to put in a lot of work on the weekends but I was making sure I was doing well in all of my classes.
Unrealistic expectations and costly time management decisions. I'll often assume that some feature or part of a CS project takes less time to take than it actually should. This often gets in my way, due to the inherent drawbacks of planning for something to take less time than it actually does. The bigger one I've found is actually investing my time poorly, where I'll devote time to a task with too high a risk or too low benefit. Hacking away at a problem without some semblance of strategy has held me back from being efficient in my CS projects, and I hope to get better at figuring out better strategies while still acknowledging the process of making design decisions while coding.
4. The obstacles that prevent me from knowing what is expected of me in my degree program are:
The resources are definitely out there, but it takes some digging to find them.
The lack of technically trained advisors. I felt as if I needed advice on the courses I should take I always turned to online resources or professors instead of advisors. I also ended up making a lot of these decisions on my own based on my career interests. I've felt as if the advisors weren't really able to answer questions that were beyond if I'm meeting my basic graduation requirements, and even then I once was told to just look at my degree audit and read it myself.
Lack of real-world exposure. It is difficult to come into contact with real professionals until a significant way into the program, which means for a large chunk of the program we had trouble understanding the set of skills that must be gained from our program. Furthermore, due to the variety of different computer science professions each demanding different skill sets, it is even harder to decide what we should learn during our time here at UMD.
CMSC435 was very well organized(Not syaing this because I took it. But in comparison to other courses. it was very well organized. ) For many other courses, I don't want to mention any course names here, they had lots of organization issues. Projects had bugs in them, instructions not clear enough. Some exam problems were not clear enough. I took CMSC451, and despite that I failed it, it was very well organized. I just was too busy working that I did not have enough time to study as much for it as was needed. Me saying CMSC451 was well organized is not synonym that I had an A, or that I will have an A in CMSC435.
I don't really feel like there are any obstacles that prevent me from knowing what is expected of me. I tend to check my degree audit multiple times throughout the semester, and I created a good 4-year plan when I was a freshman. I understand what I need to do in order to graduate in the spring, so I feel like there are any obstacles that get in the way of this.
I think going into my CS career I didn't have a clear vision of what I wanted to do. I took AP Computer Science A and was at the top of my class, and I really really liked working in Java and programming games and just programming in general. But when I dropped into University, I kind of just drifted along my classes, learning really cool things like programming and data structures and paradigms, but I didn't really apply myself outside of my classes, like applying to internships or joining clubs and stuff. I just kind of, did really well in my classes and not much else. I wish our advisors were more versed in the industry and could help guide us a little bit more, because I only really know what I wanted to do now, too late.
Unclear program structure. Especially for Computer Engineering, after taking the required classes, it is up to the student to choose out of a lot of options. Would be better if they showed certain routes or options based off interest in certain areas.
I honestly would have no way of knowing how to apply the things I learn in my classes to a real job. For example in my game theory class we go over the various concepts of payoff matrices as well as numerous searches but I have trouble figuring out how I will go about using a payoff matrix or Nash equillibrium in a real world setting.
Including the aforementioned obstacle of difficulty with time management, I believe that the main obstacles stem from the curriculum requirements that every person has to complete regardless of major.
For CS requirements, I believe it can be difficult to find what classes to take for pure software engineering. While I believe that the concepts learned in the classes (which are mostly theoretical) are valuable, classes like 435 make students apply the concepts in a practical setting. Students with practical experience have a much easier time applying for jobs and internships. Another missing aspect of most classes is collaboration. I have been asked in interviews if I have worked on any group CS projects, which I had to say no.
For general education classes, I felt like most were filler classes outside of the core requirements (English, Math, etc). An outlier in my opinion is professional writing. That class that taught me useful information that was beneficial beyond the scope of the class.
I think the lack of connection between industry and academia prevents me from getting the most out of my degree. We talked a lot in 435 about skills that employers will want to see, but this was the first time I had heard any of this. I am in my senior year, and I only happened to take this class by chance. I am very lucky to have found my own path in the security sector without help from the school. But I can imagine many scenarios where if I was not as fortunate, I could be struggling to find work. All I have really learned is how to code in different languages, but I think UMD wants to get more out of me as a soon-to-be-alum. However none of the class (besides this one) has given me those skills.
Not much. I usually know what is expected of me and try tomeet those expectations.
I think I know what is expected of me more or less in my degree program. I think problems in the program may lie in the expectations themselves, and what these expectations exclude and include.
Not having advisors is an atrocity. I should be able to receive guidance to someone who is dedicated to helping me succeed. I had to figure it out myself, and I tend to take a lot of initiative, and I can't imagine the struggle for students that are less sure of themselves. If I could've talked to someone about the classes and opportunities on campus, I would've gotten a lot more out of the degree. I could've curated the right classes for my interests and growth, and it also could've helped me make smarter internship choices sooner. I absolutely tried, but I didn't receive enough care from the department which was unfortunate, so I had to go about it in other ways.
The direction of the degree. I understand wanting to show everyone and get everyone skills in different areas of computer science. But even after choosing a track, you have more space to take more "off track" classes that may not actually be of that track. I would say the tracks are ill-defined in terms of the required courses.
Unhelpful / negligent / unqualified advisors
I think it is difficult to know what is expected from you as a CS major. I find myself unsure of many programming languages/concepts/platforms, and I grow worried that I do not know enough to prove myself a worthy programmer.
I didn't realize how broad CS was until I got here. I didn't really know what I wanted to do with my degree. Luckily, I was part of FIRE and that got me into data and data analytics. I wish there were more opportunities to figure out what we want to do before we get sent into the upper level courses. Since internships are such a big thing, it would be nice to experiment with some basics for SE, Data science, and other roles in our freshman and sophomore year before jumping into an intern role.
Communication from the department is not great in my opinion. I am subscribed to the CS newsletter but I feel it could be more engaging and informative.
A lot of the coursework is theory and the math behind computer science, but not a lot of classes show you have to apply that knowledge in coding. Over half of my upper level courses have been classes such as the theory behind machine learning, data structures, and other such classes. The majority of the focus was on the theory behind these topics, not necessarily how to implement them. There were a couple of coding projects but they were to take this data structure and write out the code for it, not necessarily how the data structure can be used for an actual product. That is the one part of my degree that I hoped got taught more. Also none of my classes have taught me what an API call was and how to implement them as that is one of the main basis for creating software applications. I had to learn that at my internship, not at college.
Nothing really. The CS department is fairly clear in explaining what is expected of my courseload wise. However, building myself up to be a good software developer, let alone engineer, proves to be difficult without more guidance in what coursework is helpful for which fields.
5. The best way to predict when students will be compatible members of a successful team is:
I think the current method (feedback from scrimmage groups) is about as good as things will get. If accessible to you, looking at their academic history might allow for creation of groups with a diverse overall skillset.
Commuication bar none. A close second is initiative and a willingness to learn. If people are strong communicators and able to efficiently and honestly communicate with their team members on challenges their facing, other life circumstances going on, etc. it makes it significantly easier to coordinate work. It eliminates the guess work of integrating work and trying to understand what is in progress and what isn't. It just generally removes any barriers that would otherwise inhibit efficient work.
Initaitve and willingness to learn are also important. It is impossible for someone to know everything a team will need going into a project, so being able to learn quickly and being willing to do so is really important. People who are reluctant to learn the skills necessary to be successful on their team will slow the team's entire progress.
One thing I wanted to add that's unrelated to the questions above. I like your saying "change is inevitable" but I think "change is expected" may better convey the idea. For me when I hear "change is inevitable" I think "the project's requirements are going to change and it's something we need to be ready to react to". For me it phrases it more as an inconvenience that we need to plan for. On the other hand "change is expected" conveys to me that "the project's requirements are going to change, and it's something we should take predictive action to make sure were building our product in a way that accomodates it". I think it's a little bit more of an optimistic way to look at it and makes change more of a welcomed event because it gives us the opportunity to leverage the predictive actions we took. Just a thought. Measure the students’ degree of communication and the sense of community between the students – teams that communicate frequently and willingly will be more homogenous and likely to be successful; measure the diversity of skill sets and personality within the team – a team with only one type of people would likely not see success, while a team with multifaceted abilities will be able to face challenges more effectively; measure the level of motivation and the sense of responsibility within the team, which is essential for the team to work efficiently and collectively.
Culturally diversified, and accepting differences in personalities. It also depends on the will to participate and give in their best.
This is a difficult question, because for me I know I am compatible with a team member if I can make a joke with them or have an enjoyable conversation about something other than work. But in general, I guess compatible team members can be determined based on characteristics of their personalities. It is also good to see if students have things in common that could help them relate to one another, creating a well-meshed team.
I think engagement is the best factor. If there are people who are very communicative, chatty, and engaged, that trumps everything else. Because everyone in the class are tech savvy, everyone has their own skills like front end, back end, theory, math, etc etc. But one thing in the class that not everyone has is engagement. Some people (like me) have gone through the CS degree, working alone (because that's what most Professors encourage, or require), and haven't really collaborated a lot on projects. Most students are expected to get their team communication skills from clubs and internships, but that's not a guaranteed for every person. If you have two software groups, one group who is tech-capable, nothing super special, but are very communicative and engaged, or a group of Microsoft/Google internship computer whizzes who say maybe 6 words a day, then the less tech capable, more engaged group is gonna do a lot better. Everyone on my team was not only very tech savvy and smart, but a lot were very engaged, social, and communicative. And that's what made us successful.
Nothing, you won't know it will work until they work after.
If they are able to follow through on what they say they will do. I think it is important that a team member is proactive and communicates well, but if they are unable to follow through on saying they will be at meetings, or finish certain tasks, and they don't by a certain time/don't communicate otherwise, they will be a bad team member.
Students' flexibility. One could say that "obviously everyone needs some level of knowledge to build something together 'successfully'", but I'd argue that even if that knowledge is lacking, it can be made up and supplemented if the individual team members have the flexibility to mold themselves according to the needs of the project/team. This flexibility is what Bruce Lee refers to in his famous quote: Be Water, My Friend. Empty your mind. Be formless, shapeless, like water. You put water into a cup, it becomes the cup. You put water into a bottle, it becomes the bottle. You put it into a teapot, it becomes the teapot. Now water can flow or it can crash. Be water, my friend.
How often and how fast they communicate. It can be hard to find overlap within a large group when everyone has different schedules. However, my group was very good about communicating conflicts and availability in general. I find that most people are accommodating so long as people explain their circumstances. This can be a hard metric to gather before making teams, and I imagine that people with more 'leadership-esc' experience would have an easier time understanding the importance of quality communication. The best way to predict when students will be compatible members of a team is when they share similar communication and work habits. Having similar communication habits makes a group able to mesh together quicker. People with similar communication habits also tend to share other characteristics, meaning they can work together quicker. They would not have to go throught the growing pains of learning how to interact with a new personality type.
On the first day are they trying to meet new people or are they talkative? Usually the best members of a team are the ones that are outgoing and talkative. I've found those are the best people to work with. They are good communicators and they stand their ground. They don't just listen to what people tell them to do, but rather work with others to develop the best product.
Overall communication at the beginning of the project. I think that if a group member is not able to communicate with the rest of the team, then it will be hard for them to get dialed into the project down the line. Hard-working members can get out of sync if they are not reachable by the team, while more slothful workers can be pushed if they are comfortable around the team and the team is comfortable with them.
I really liked the way you did it. How students deal with ambiguity is a good indicator and also the personalities on the team are really important. I've heard from many people that working on a team with people you enjoy working with is a lot more important than working on a cool project, and while this project was cool the best thing about it was the team and our dynamic. I like the personality test bit, I liked the ambiguous scenarios. I was even a little surprised, because some people that I didn't think I would get along with as well, I really enjoyed working with, and I loved that. The first thing I look for is the volunteering for tasks. If they seem eager for the project then I know that they would be communicative throughout and be passionate about its success. Obviously this isnt the end all, be all for whether they will make a good team member but I think it sets the tone in the beginning. Other than that, there is just good and consistent communication even if the thing they are communicating about is not necessarily successful or good. Being able to report bad things and not trying to hid them is a very key thing as well. Interests/hobbies outside of CS/CE. A higher likelihood of becoming friends means a higher likelihood of a successful team.
I think it is best to see how they interact as friends. Many of the problems that my team encountered was incompatible personality types. As such, it was very common that some disagreements and even arguments arose due to the starkly differing personalities. As such, I think it's super important to assign team members by the way they can be seen interacting with each other.
Communication and regular meetings. Due to our regular meetings, it became apparent which team members were dedicated to this project and which members didn't care as much. We would have meetings as late as 9/10pm into late into the night often since our schedules didn't work for meeting earlier, but ensured people that wanted to show up would.
Being able to communicate with each other effectively. Everyone is capable of doing their technical work but I think most issues stemmed from how effectively everyone was able to communicate with each other. Individually our team members were able to complete all our tasks, but we ran into the most problems when we had to migrate our contributions and make them work with each other.
I think the gallop questions were a relatively good instrument for determining if team members will be compatible. For the Timeline team, a lot of the guys were like minded in how they approached the project. We were all hard workers who tried to find ways to contribute to a successful project. I know personally that at the end, a lot of the changes needed to be made to the front end, which led to myself not personally needing to change a lot of code. Since I was not on the front end team, I could have just sat around and did nothing but instead, I found a way to contribute. I started to write out the final deliverables. By the time we finished up tweaking the code, the majority of the deliverables had been written by myself and other team members that were not fixing the code. This led the rest of the team to only have to add a paragraph or two to the final deliverable and review the document. It helped the group to get everything in on time. If I had not been willing to contribute to the project whenever I had free time, we might have not finished everything on time and lost points. I also think having a compatible team member is a willingness to find ways to be helpful when it looks like you finished your part. That's what helped my team be successful for our project.
I think the most useful thing would've been mapping students with similar schedules to each other. My team and I stalled at the beginning due to not being able to meet at a decent time. The trend stuck a bit throughout, as those who couldn't come to the first few meetings on time due to schedule conflicts ended up being less responsive when we switched to a weirder time that worked for all of us. Early meetings set a precedent it seems.