While it is true code pilot is quite amazing and can produce some very decent snippets, if the exercice you give is specific enought (using a special database schema, file format, or API), with objectives that are not common (ask the user specific questions, and draw conclusions out of it or react to events), then it cannot produce a fully working program. I use code pilot regularly now, and it does speed up my work, but I can't do anything with it without understanding the problem at hand.
There is nothing wrong with the student assemblings and fixing parts of code that exist. Doing that requires understanding those parts, how they interacts and what you can do with them. It's not killing tests. Plus as professionals, we all do that anyway. Heck, I learned doing that. I'm paid doing that.
However, there is something wrong with academic exercices that I see in the wild. Things that are very abstracts, requiring way more than programming knowledge, or stuff that are asked out of context completely. Students are both understimulated, and given too hard bites to chew. It's a terrible way to learn, and to be tested IMO.
Tests nowaday don't tests for knowledge, they test either for compliance, or act as a filter instead of a feedback loop. This is not education.
In fact, I've yet to see school IT course that I didn't find deeply flawed, and I completely understand the students for cheating at them to that they can suffer as little as possible. They are not given a chance to prove themself or progress, they are not respected. They are forced fed junk and asked to spit it back all shiny.
I remember when I was a student, and I went to 11 different schools because of my twisted life. They all sucked. And I say that as I spent half my student life at the top of my class grade ladder.
As I moved as well, I experienced three different Canadian universities' Computer Science Program.
There was only one professor and course that I still remember 20 years later: CS408, Software Engineering, Professor Wortman, UofToronto.
Class project was in four phases, cumulative (basic functionality for the application in phase 1, progressively additional functionality in other phases, frequently strongly interacting with previous phase code).
Here's the kicker: After each phase, you had to swap your code with another team. So you had to pick up somebody else's code, figure it out, and then build up on it.
Few of us that had real-world working experience loved the course and flourished in it. This is what we are training for! This is what programming is like! You are taking real code and building a real thing with it!
About 250 other students signed a petition to the Dean on how this is unfair and awful and they will not put up with it. They were just too used to / spoiled by 16 years of 5 assignments per semester with abstract, entirely separate questions of 1.a), 1.b), 1.c), etc.
All I could think of - if you did not like this course, you are about to not enjoy next 4-5 decades of your life :D
Other than this one course, I can say that I'm a prolific, enthusiastic, life-long learner, and my university experience was the absolute dumps - it was far less about learning, and far more about bureaucratic hoops and artificial constraints and restrictions. I was top of the class in some hard courses (generative compilers etc), mid-pack in the some of meh courses, but in retrospective, my life opened up when I was done with academia and could work and learn in the 'real world'.
> Here's the kicker: After each phase, you had to swap your code with another team. So you had to pick up somebody else's code, figure it out, and then build up on it.
This is hilarious and is a good example of how sw engineering works in the real world. Love it.
There are a few issues with this kind of assignment.
The first issue is that it's really hell on the TAs with all of the administrative work needed to do the swapping between phases. Software engineering is already one of the more annoying classes to TA, and this makes it even less palatable.
The bigger issue is that, on the basis of fairness, you grade in later phases is very heavily dependent on factors that are outside of your control. If you get someone's code who just didn't complete the assignment--that is probably going to happen once a semester--you are going to be at a disadvantage. Even if there is an option to appeal to the TAs and get the unacceptable code base replaced with an acceptable one, that's still likely to be a few days' worth of work lost learning the codebase, discovering its incompleteness, and now you have to start over again.
I'll also point out that it's not exactly real-world experience. It is extremely rare that someone will be dumped on a codebase without a prior author remaining on to help them ramp up on the code.
I would expect that code you get from Stage N-1 is functional across a range of tests that are agreed upon upfront.
For the fairness aspect, I would also let students pick any Stage N-1 that is not their previous N-1. That would also teach em that not all is created equal (and probably identify approaches / ideas that they can incorporate in their work)
That is exactly what happened. You got 1% extra mark if somebody picked your code.
Seemed trivial at the beginning of semester,right?
...did I mention my team had previous real life experience?
We put extrnsive code and documentation and FAQs online (this was like 99 or 2001 don't remember, but we'll before Github etc) , and committed to 7 day support of our code base. We got 18 out of 22 picks after phase 1.
Of course competition was much stiffer further phases, but that too was like 3 valuable real world lessons learned for everybody!
Yeah, that statement was the only thing that stuck out to me in an, otherwise, pretty good writeup that I mostly agree with.
The only times I can think of where the previous author was able to help was either during onboarding (where you are expected to be given smaller-scope tasks with the context of that code being predefined for you) or during work on certain specific singular projects as a team.
But at any large big tech company, you are probably gonna be jumping around more than a few different codebases (more often than not, large and being worked on for years), even if you work on a singular team/product. And most of the time, you are expected to figure as much as possible on your own, only reaching out to the people when you get stuck or encounter a specific issue. Other than that, you are expected to be able to build at least a janky proof of concept with as little help as possible.
Most of the time, the help I sharply needed was rather targeted and not really related to the code itself overall. It would be something that is kind of extremely difficult to guess on your own without it being explicitly told (aside from docs/code comments), things like "everything looks fine, but I get stuck at this auth step, what's wrong there?" - "oh yeah, you gotta auth as a part of this specific group, so you need to be added to this security group in this config file".
I am not trying to say that i am some genius and can get the structure and overall mental model of how a codebase works all on my own easily, only with the specific "gotchas" (like the ones mentioned in a paragraph above) giving me issues. Not at all. The only way I can mentally get a structure of the codebase and how the whole system works and operates (even as a rough/simplified model) is by looking at the design docs/documentation (very helpful, but far from sufficient on its own, more like a supplementary material of variable quality) and, most importantly, making small code changes and debugging the code using breakpoints to see how it all flows and where. Imo, understanding code through debugging and reading a lot into the code is an irreplaceable step for understanding a section of any significantly-sized codebase.
I had a similar software engineering course experience to the one above with a lot of things out of my control.
I got an A. By being humble reflective and proactive, showing the instructor that I was looking for solutions to the problem and giving an appropriate amount of time and effort to the class.
I think you could remove a lot of your fairness and logistical concerns by at stage N choosing one solution and everyone group has to start from there.
Now for pedagogical purposes it might be that the professor chooses the best solution or a substantially worse solution.
There might be some concern that this unfairly advantages one group over the others but it’s not completely clear to me that it does.
Thanks for the note and perspective. Some clarifications:
1. As noted, each team got to review and pick the code they would take after each phase as long as it's not your own. I remember drawing a graph of picked code lines and it was fascinating, evolution / survival of fittest at work. But it wasn't something one didn't have control of.
2. I don't know why it would make TA work either better or worse, we may not be fully understanding each other. You have 22 programs to put through a standardized test suite based on formal requirements all teams had to code to. It was far easier to grade than any other assignment I ever had.
3. I guess different people have different real world experience. All of COTS/ERP and a lot of enterprise applications are somebody else's code. Millions of lines of somebody else's code. So that's the norm in my life. YMMV :)
> It is extremely rare that someone will be dumped on a codebase without a prior author remaining on to help them ramp up on the code.
The way this is more likely to work out IRL is that the last person who actually understood the design - not just the what's, but the why's - had long since moved on, and the "prior author" that you have access to can, at best, tell you where the dragons are.
I don’t know the size of your university projects, or the speed you worked at, but most of my university projects could be understood in a day. The coding part was by far the most time intensive thing at the time.
it's not rare at all for previous authors to just disappear. do you know what the turnover is at large companies??
reading the code is not the issue though, we also lose context. WHY was it done that way? was it a product decision, due to time constraints, or technical complexity? that should be documented but often isn't
My software engineering teacher did something similar. We had a giant group project that had to be worked on by the whole class. He split the class into 5 groups of 5, and we divided the work by group, and groups had to work together to integrate with each other.
Hats off to your prof. This is such a brilliant idea for how to teach, anchored in a solid reflection of what “doing the job” is like day-to-day outside the academic context.
Github Copilot won't give students anything they couldn't already google.
It seems to be a natural part of aging, to start to complain about education and kids these days because it's not the same as when we were in school.
I try not to do that, because I never forgot how my parents generation said the exact same about us when we were in school, and I guarantee my grandparents generation complained when my parents were in school.
There is nothing wrong with the student assemblings and fixing parts of code that exist. Doing that requires understanding those parts, how they interacts and what you can do with them. It's not killing tests. Plus as professionals, we all do that anyway. Heck, I learned doing that. I'm paid doing that.
However, there is something wrong with academic exercices that I see in the wild. Things that are very abstracts, requiring way more than programming knowledge, or stuff that are asked out of context completely. Students are both understimulated, and given too hard bites to chew. It's a terrible way to learn, and to be tested IMO.
Tests nowaday don't tests for knowledge, they test either for compliance, or act as a filter instead of a feedback loop. This is not education.
In fact, I've yet to see school IT course that I didn't find deeply flawed, and I completely understand the students for cheating at them to that they can suffer as little as possible. They are not given a chance to prove themself or progress, they are not respected. They are forced fed junk and asked to spit it back all shiny.
I remember when I was a student, and I went to 11 different schools because of my twisted life. They all sucked. And I say that as I spent half my student life at the top of my class grade ladder.
I regret having cheated so rarely now.