Hacker News Reader

> 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.

> 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.

what? I must be living a rare life.

Hahahaha. Most of the times the author has moved on a long time ago.

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.

Most of my major professional achievements involve jumping into code like this, and solving some problem anyhow.

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)

I love this idea. Maybe some extra credit if your Stage N-1 is the most popular choice?

This is brilliant.

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!

i mean... at 18 out of 22 you look at the teacher and say: look at me! I'm the teacher now!

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.

You could also choose two, which then ensures no team starts with their own work from the previous phase

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 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.

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

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 :)

> 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.

That behaviour by the students disgusts me.

It explains how we get the state of the profession we have these days.

Wow, your professor had an amazing idea! I wonder why isn't this strategy more common in college classes.

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.

> 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

Genius idea! Though if my professors did this, I may have been scared away from a career in programming

> After each phase, you had to swap your code with another team.

I'd expect that most students would just "rewrite" the code they received from the other team and replace it with their own.

I'm sure that various strategies for gaming the system were anticipated and prohibited.