Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SPD Improvements for Thought #11

Open
starlightromero opened this issue May 11, 2021 · 5 comments
Open

SPD Improvements for Thought #11

starlightromero opened this issue May 11, 2021 · 5 comments

Comments

@starlightromero
Copy link

After taking SPD 1.41 this term where we practice technical and behavioral interviewing as well as focus on outcomes, I have come to see SPD in a new light. Before proceeding further, let me say I deeply appreciated the focus on preparing students for the real world. SPD to me is not "Software Product Development". It is more of a "we don't know where else to put this course but it is valuable to all students so let's put it here" course. Yes, SPD does cover some software product development topics such as agile vs waterfall, the sprint process, and user interviews, but SPD is much more than that. Depending on the class, it can focus on interviewing, team building, conflict resolution, email etiquette, and more. Studying where Make School has come from, it seems likely that SPD is an old remnant (much like our vestigial tails), from the period when Make School acted less like a school and more like a product development program. It has adapted and changed over the years to align more with Make School's new goals, however there come certain drawbacks to making small improvements over the alternative of rethinking what SPD can and should be.

I see SPD as a blend between Outcomes Preparation, Product Development, Team Building, and much more. Instead of "Software Product Development" I see it as "Product and Professional Development", PPD. The benefit of this new approach means that PPD can be fit to teach the things we know and love as well as core theory, which is currently lacking in the curriculum, in addition practical skills. Theory such as the OSI model, HTTP (1.0, 1.1, 2, 3), TLS, and NAT. Practical skills such as terminal commands, scripts, and contributing to open source projects. With this new theory and practical skills students will be able to better understand the underlying architecture and protocol that governs the way the internet operates. The practical skills will help improve students day to day operations and push them to integrate into the continuously changing software landscape for both learning and networking purposed.

This implementation will not come easy. Some classes such as SPD 1.2 which spends a whole semester on Bootstrap may be better delivered in a few classes leaving extra space for new topics. I encourage this to be an open conversation on the pros and cons of SPD and how this can be improved to fit the current goals of Make School and the industry in order to serve students better.

@sidneyarcidiacono
Copy link
Contributor

Thoughts:

  1. I think that there is potential for SPD to support our Outcomes support should it focus on the base level of product knowledge engineers should have, but also primarily professional development and outcomes (networking, email etiquette, resume writing, how to showcase a portfolio, interview skills, etc.).
  2. I definitely agree with the statement that SPD feels like a vestigial appendage - and with the new Entrepreneurship (ENT) courses, I'm curious where SPD fits. I would most definitely support an overhaul of this 'track' with student feedback in mind that indicates a need for more technical interview practice, resume support, networking practice, etc.
  3. "Software Product Development" almost feels like a misnomer for the current direction of this course track - and I know that SPD has been a point of contention among students for a while. I know that SPD 1.41, for example, is the result of students asking for more practice with technical interviewing, and would definitely support a renaming of this track as well as an overhaul of the course material to better re-focus on Make School's current goals for students.
  4. Theoretical knowledge is definitely something lacking at Make School, and something that I feel would greatly benefit students to learn (even insofar as it provides them the language through which to communicate technical competencies in interview or networking settings). However, I could almost see the OSI model, HTTP (1.0, 1.1, 2, 3), TLS and NAT becoming a part of foundational WEB courses, rather than this "new SPD" concept. I'm interested to hear if others have thoughts on this placement?

Thoughts on Implementation

  1. One of the largest challenges I forsee with this conversation is the "who does this work?" question. With the understanding that our Curriculum Developers already have a lot of continuous feedback to integrate into courses with the goal of making Make School better, who would take this on? I think that this is a large organizational conversation, but think that solutions can be found should there be enough support of this overhaul.
  2. Consistency in delivery - this is an issue with SPD already, and would potentially continue to be an issue. Depending on what instructor you have for SPD, your experience can be very different than another student in the same course (SPD 1.41, for example). Ideally, any new curriculum would be written with robustness in mind, so that it can operate effectively regardless of delivery. This is a slightly "hand waving" comment, but again, with more backing, can be considered more specifically as this conversation develops. I'm simply putting this here for consideration at this time.

@starlightromero
Copy link
Author

starlightromero commented May 11, 2021

@sidneyarcidiacono

However, I could almost see the OSI model, HTTP (1.0, 1.1, 2, 3), TLS and NAT becoming a part of foundational WEB courses, rather than this "new SPD" concept.

I support statement 4 on The more theoretical aspects being better fit into a foundational WEB course. This would be best after students learn the basics of programming and have some knowledge of BEW, perhaps a post WEB 1.1 course. However with more foundational courses how does that effect the students' schedule? Do they simply take less electives?

If the theoretical aspects are moved into a foundational WEB course and SPD (PPD) is allowed to have laser-beam focus on Product and Professional Development then one aspect I could foresee is more resources for networking. Perhaps a web-scrapped and/or student contributed calendar in which events such as DockerCon2021 are added for networking and learning purposes. It's hard for me to fully image what SPD/PPD should/could be without having taken all the courses and judging how effective they are. I'd very much like to get some senior input on SPD.

One of the largest challenges I forsee with this conversation is the "who does this work?" question. With the understanding that our Curriculum Developers already have a lot of continuous feedback to integrate into courses with the goal of making Make School better, who would take this on? I think that this is a large organizational conversation, but think that solutions can be found should there be enough support of this overhaul.

As far as implementation, there is much to do and not enough hands to do it. I think in this situation (and this may be getting into a much bigger topic) it is important to plan. For instance (in a non-linear structure) if we are at point A and headed to point X (in regards to curriculum improvements, etc) but it would be better instead if we went to point Y then our efforts of getting to point X are in some sense wasted. In other words, have we slowed down and thought about the direction curriculum is going before implementing more improvements and using resources? Just some food for thought.

@atleastzero
Copy link

I don't have a great deal of insight on what kind of change this would need, but in my perspective having 9 required SPD courses makes some of them inevitably feel like fluff. In fact, when I have to explain SPD to people outside of Make School, I call it "homeroom but for college" - suffice to say I agree with the above comments that it can feel vestigial. I can see the value in some concepts that are maybe less technical and less practical and still not fitting into the category of something like CS or ENT being required for everyone. However, as Starlight said, we have an entire class dedicated to Bootstrap.

On the subject of SPD 1.2 - I can easily defend this class for my needs. I'm in the BEW track, and when I dabble outside of that subject, it's, for the most part, with frontend technologies. This being said, I'm not the strongest in creating aesthetically pleasing visuals and learning some basics, and being provided a structure to approach the topic was a great experience.... for me. I don't think everyone needs this class though. Plenty of people come to Make School with UI/UX backgrounds already. Others may dedicate all their time to DS or pure BEW and to mandate these students be graded on things like applying color theory seems a little insane to me. It just doesn't seem like an essential part of an Applied Computer Science program to me.

On the subject of having both SPD 1.41 and SPD 2.41 - I withdrew from all of my technicals last year in term 4 and have what, as far as I can tell, is the unique experience of taking these classes concurrently. These classes seem incredibly similar. I appreciate Make School's efforts in the realm of Outcomes. I can see how important it is to the school that students are job-ready. While this is a huge draw for many, I don't think it makes sense to make everyone learn the same networking and interviewing skills twice. Shifting the focus to SPD 2.41 alone, here's why. First of all, the work in this class depends on a) whether or not you've already landed a full-time software engineering job and b) who is teaching the class. Without going into too much detail, as Sid pointed out, within the same course, you can have vastly different experiences based on the instructor you have. The work required for students seems to differ greatly based on what instructor you've been (randomly?) assigned. Beyond this, why have different requirements for students that have landed a job unless it's clear that some students don't need the class. Students that have a full-time job, to my knowledge, haven't even been required to actually attend class, at all. To me, it's clear that this class, which seems like mostly a repeat anyway, should be optional, or at least have the potential to be waived.

I haven't taken SPD 1.5 yet, so I don't feel comfortable commenting on it.

What Would I Do Differently

Beyond the comments I've made, I'm sure there are other ways to consolidate the essential SPD material into fewer required classes. That being said, I don't think the other material is unimportant - just not relevant to everyone. I believe this material would be better serving students as electives.

Mixed Feelings

Theoretical knowledge is definitely something lacking at Make School, and something that I feel would greatly benefit students to learn

I agree with Sid's comment to an extent. I previously attended two other schools as a Software Engineering major. At Embry-Riddle, we used a lot of hardware-level technologies and it wasn't something I did much of on my own. I felt competent in applying my learning to real-world problems although I'd admittedly have lacked in personal projects if I'd stayed on that track. At ASU online we pretty much only learned theory. I probably still know way too many random features of Java that I may never use because we never did anything worthwhile with them.

Make School changed so much for me. Although I don't currently have a lot of projects that I'm wildly proud of, I know I have the ability to build Actual Things for Actual People. I don't think I even knew what an API was before coming here. I didn't have a GitHub before coming here either. I also never interned before Make School. I feel so much more connected with the developer world because of the Make School community (although, for me, the in-person experience was key in this).

THAT BEING SAID, I also never would've learned what a UML diagram was if I didn't go to ASU and I wouldn't have known about Hardware Description Languages if it weren't for Embry-Riddle. In some job markets, those things matter.

I'll finish by saying that there are things where Sid's comment seems like a no-brainer if Make School were to make some changes. I've been pushing for an elective Operating Systems class since I got here. This is one class I could understand adding and making mandatory because Applied Computer Science is still Computer Science after all.

@starlightromero
Copy link
Author

starlightromero commented May 11, 2021

@atleastzero

I don't think everyone needs this class though. Plenty of people come to Make School with UI/UX backgrounds already. Others may dedicate all their time to DS or pure BEW and to mandate these students be graded on things like applying color theory seems a little insane to me. It just doesn't seem like an essential part of an Applied Computer Science program to me.

Beyond the comments I've made, I'm sure there are other ways to consolidate the essential SPD material into fewer required classes. That being said, I don't think the other material is unimportant - just not relevant to everyone. I believe this material would be better serving students as electives.

What are some of the topics or SPD classes you feel were necessary and benefited the majority of people?

On the subject of having both SPD 1.41 and SPD 2.41

I didn't realize there was also a SPD 2.41. I'm assuming since SPD 1.41 is new that 2.41 is also a new class. It does seem weird that the subject/core topics would need to be taught twice. Students, after learning, should be able to apply the skills afterward.

Beyond this, why have different requirements for students that have landed a job unless it's clear that some students don't need the class. Students that have a full-time job, to my knowledge, haven't even been required to actually attend class, at all. To me, it's clear that this class, which seems like mostly a repeat anyway, should be optional, or at least have the potential to be waived.

With all of what you said I will reiterate and say it definitely does feel vestigial - a filler of space which was needed since things were not as thought through as they could have been. I'll restate my comment above in a slightly different way by saying I greatly appreciate the curriculum team and the work they do to improve bugs, old syntax, and more. However, how much pull does curriculum have to change things at a larger scale? Do they work with other teams/people to make sure we are not just improving what is already existing but actively analyzing what the requirements are that need to be fulfilled for student success.

I probably still know way too many random features of Java that I may never use because we never did anything worthwhile with them.

I've been pushing for an elective Operating Systems class since I got here. This is one class I could understand adding and making mandatory because Applied Computer Science is still Computer Science after all.

I 100% agree. Students do not need to be experts in these more theoretical or low-level subjects but at least have a basic understanding in order to have an overview of how the system works as a whole. I think context could help students, especially struggling students, to see the relevance of what they are learning and how it ties into a bigger picture. As opposed to your niche Java knowledge which is very specific, the theory I'd advocate for is (like you said) OS and other overviews of similar topics.

@Hydrochlorick
Copy link

Hydrochlorick commented Jul 14, 2021

Critique of SPD has continued to be something that we hear from students via word of mouth, and came up more than a few times in the Term 4 feedback forms.

I think I vaguely recall hearing @ogjaylowe and maybe @dfmorse23 were working on it? Is there a way to get any insight on the development of these ideas (and maybe opportunities to provide feedback before they go live)? Especially the general sense of what SPD should “be".

I know there’s plenty of folks that think SPD1.41 turned out great, but would have been better suited to be held earlier in the year. And while I understand Megan’s perspective in regards to SPD1.2 (The bootstrap one), I haven’t encountered many who share that appreciation for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants