5 ms·

The one bad habit you learn from coding in school is you take a project and then throw it away. So speed does count when it comes to finishing an assignment so

The one bad habit you learn from coding in school is you take a project and then throw it away. So speed does count when it comes to finishing an assignment so you can goof off, go party, etc. And then you never see it again, so who cares if the code sucks as long as it produces the outcome you want. What you don't learn in school is how to write maintainable code. This is a much different style of writing code, and much more valuable once you go out in the "Real World". I'm not sure if there are CS programs out that start with a small project and then force the students to make massive changes to that project throughout the course of the year, but to me there is immense value to that. Even better would be if they had CS101, CS201, CS301 and the students taking CS201 would be forced to dig up their project from CS101 and work on that, CS301 would work on the code from CS201, etc. It's eye-opening how much you forget about your code after a few weeks, so it would drive home the notion of commenting, writing easily readable code, etc.

RyanMcGreal 12y ago
It occurs to me, reading your comment, that an interesting exercise for a software development school program would be to assign a project for first-year students; then, in second year, assign the students to take the same project from the previous year and modify it.
- dyeje 12y ago
  I actually discussed this idea with professors at my university, but the general consensus was that it was too ambitious/complicated to work into the current system.
- Terr_ 12y ago
  One problem with that is that you tend to penalize students who didn't do well the first time, and you also make it more difficult to grade because it's not an independent measurement of their progress in a particular class.
  - clay_to_n 12y ago
    Agreed. I feel like the biggest problem with these sorts of assignments for students is that most students are still learning to program - so by the time you "add on" to your first assignment, a lot of them will want/need to re-write it.
    - RyanMcGreal 12y ago
      That's kind of the point: the assignment is to take an existing codebase (probably a crappy one), figure it out (who remembers what they were thinking a year ago?), and add to it without breaking it.
      - Terr_ 12y ago
        So then you give every student the same existing codebase (along with the same set of requirements), and as a bonus this helps them learn and adapt something written by a different person. Saying: "Use the same thing you worked on last quarter" dooms everyone who made wrong foundational choices with their old project to spend most of their time "fighting the last war".
        zo1 12y ago
        "Saying: "Use the same thing you worked on last quarter" dooms everyone who made wrong foundational choices with their old project to spend most of their time "fighting the last war"." Not unless you told them before they started the previous year's project that it'll be used further along the line. I'd just make it one really long subject that spans 3/4 years.
elektronjunge 12y ago
I had a couple classes like that, usually it was more at the semester boundary. E.g. my intro to compilers classes involved writing a compiler for a c-subset. The advanced compilers class built on that compiler by adding optimizations and such. My intro to systems class had a project that was to write a shell. My operating systems class had a project to add job management and pipes to the shell from the systems class. I really liked those projects you felt like you had something pretty substantial when you were done.
loudmax 12y ago
Even more challenging would be to maintain somebody else's code. Say, at the start of an assignment, each student is randomly assigned a code base from the previous project (we could restrict this set to only include code bases that met the grade). New requirements that weren't a part of the previous project are introduced every time this happens. If the students are being graded on a curve so they're competing against one another, this would be downright diabolical.
- geebee 12y ago
  I'm embarrassed to say that I went 15 years before I really learned to work with "other people's code". That's partly because I came to programming as a math/industrial engineering student, where I was really writing code to solve problems and get answers rather than a sustainable, usable product. Even once I started writing code for users, it was generally pretty experimental and research-y, so I usually got a green field project. In the past few years, I've worked repeatedly with existing code bases to extend or modify functionality (or just fix problems), and it has been an amazing learning experience. Not all of the code has been good, much of it has been questionable. But the process of understanding someone else's code, figuring out how to change it, balancing the harm of forking vs the benefit of improving, dealing with pull requests and merges… there are a number of skills you will only learn from years in this kind of environment. One huge challenge here is when you don't work in an organization that understands software. People aren't knowledgeable about software are often impressed with green field programmers "jim wrote the whole thing". Truth is, understanding a different code base and getting to the point where you can improve it and contribute back to it is (at least in my experience) far more challenging than just writing something from scratch. It seems that most people who write software are already well aware of this, but it can be a hard sell outside (in fact, you may even find that people seriously question your progress - a green field app there's something nifty and new to demo even day, with existing code bases, there's a lot of confusion and investigation - and it can be very dispiriting to spend days stubbornly trying to understand and diagnose a feature, finally solve it, and realize that the team is disappointed with your progress). However, the good software teams appear to be well aware of the challenges, and it's an essential learning experience.
- jeffreyrogers 12y ago
sanderjd 12y ago
A really great addition to any CS curriculum would be a long-running projects course that runs the full four years so that you get experience in managing architecture, growth, and maintenance, instead of just building. Lots of students do that by attaching themselves to open source projects or working internships, which is great, but it's not (as far as I know) an official major part of any curriculum I've heard about.
- V-2 12y ago
  A single four year project would be a little harsh... once you realize what you've done wrong, you'd be to too deep in it to amend your ways anymore. Give them a chance to start from scratch a few times...
  - Linell 12y ago
    A rewrite could always be an option, if it's finished on time. Setting a reasonable pace with the project could be tricky, but I think it would be very beneficial.
  - mattgreenrocks 12y ago
    Most of the time, you should be building an initial version and throwing it away anyway. Internet time does not justify poor program design.
  - sanderjd 12y ago
    Realizing what you've done wrong and feeling the pain of figuring out how to amend it is the whole point of the exercise. Maybe the right way to amend it is to rewrite the whole thing, but that may or may not be the best choice, depending on what else you want to get done. Just like the real world!
- kalid 12y ago
  For Prof. Larry Peterson's networking class, we had to build up a web server over the course of a semester. You built IP, and used that library to build TCP, and then served files over your TCP connection. It was the first time I realized that bugs in earlier assignments don't magically disappear, and changed my thinking dramatically.
grecy 12y ago
> I'm not sure if there are CS programs out that start with a small project and then force the students to make massive changes to that project throughout the course of the year I studied Software Engineering at Swinburne University in Melbourne Australia, and we did exactly that. One subject was "Software Maintenance Project" where we took an existing code-base we didn't write (a front-end for laTex for our year, the CVS code base for the next year students) and continually made changes to it. Halfway through the course we had to deal with changing requirements. We were graded on the quality of our code and how well it fit the existing style etc., not how fast we did it. We also did a full-year final year project with 16 of us where we created a BIG code base from scratch. We decided to use an iterative approach (our choice) and so over the year we ran 6 iterations continually building on what we'd already done. We also did awesome courses like "Personal Software Process" to teach us discipline in how we personally approach writing code. EDIT: Sometimes I post to HN "hire/resume" threads about my hire-ability and how I personally think I'm "better" than the average person who studied CS because of things like the above. Normally everyone disagrees and says as long as I can code, it doesn't matter that I studied Software Engineering and am a certified Engineer. It's for reasons like the above I still personally feel I'm stronger than the average CS grad.
- ramidarigaz 12y ago
  That sounds like a seriously awesome course. I wish my school would do that...
- mattgreenrocks 12y ago
  FYI, you are stronger than the average grad. People get pretty defensive when it comes to skills; nobody wants to believe they're below average if they're frequenting this site. My one piece of advice: keep studying and practicing making beautiful software, in and out. Be careful who you take technical advice from; the industry right now is flush with cash, and thus there is a huge incentive to talk more than produce. Projects are often killed as quickly as they're started, causing people not to practice program design.
fragmede 12y ago
6.170 at MIT attempted to be a 'real-life' coding lab class, while teaching OO concepts. First you're given an assignment; eg, write a simple physics engine that simulates a pool table, and you're graded on your implementation of this. Next a curve-ball is thrown that you're not supposed to know before hand. Eg. Add gravity and turn it into pinball. (Apparently, it's no longer taught in Java, but a quick glance says the curriculum hasn't fundamentally changed - it's a 'real-world' coding lab - now with git!)
jsolson 12y ago
My undergraduate program at Georgia Tech attempted to do this in CS2335 (Software Practicum). That I recall, our first project was an IM client/server, our second was a client/sever game involving programmable automatons, and our third project was a hybrid of Space War-Asteroids-Trader-Lander-Pirates. You had the option of building them all completely separately, but you were strongly encouraged to re-use code form earlier revisions, particular for the client-server bits. The class also included labs on Subversion, although nothing on the notion of things like code review. I could imagine teaching the course today with Github and requiring (or at least awarding some credit for) good use of Pull Requests, meaningful code review, etc. Sadly it looks like the course no longer exists; I have no idea what replaced it.
- poikniok 12y ago
  CS2340 replaced it. It is a java project course, working in groups of 4-5 people. In my opinion, and that of many others, it is very useless.

RyanMcGreal 12y ago

It occurs to me, reading your comment, that an interesting exercise for a software development school program would be to assign a project for first-year students; then, in second year, assign the students to take the same project from the previous year and modify it.

dyeje 12y ago
I actually discussed this idea with professors at my university, but the general consensus was that it was too ambitious/complicated to work into the current system.
Terr_ 12y ago
One problem with that is that you tend to penalize students who didn't do well the first time, and you also make it more difficult to grade because it's not an independent measurement of their progress in a particular class.
- clay_to_n 12y ago
  Agreed. I feel like the biggest problem with these sorts of assignments for students is that most students are still learning to program - so by the time you "add on" to your first assignment, a lot of them will want/need to re-write it.
  - RyanMcGreal 12y ago
    That's kind of the point: the assignment is to take an existing codebase (probably a crappy one), figure it out (who remembers what they were thinking a year ago?), and add to it without breaking it.
    - Terr_ 12y ago
      So then you give every student the same existing codebase (along with the same set of requirements), and as a bonus this helps them learn and adapt something written by a different person. Saying: "Use the same thing you worked on last quarter" dooms everyone who made wrong foundational choices with their old project to spend most of their time "fighting the last war".
      - zo1 12y ago
        "Saying: "Use the same thing you worked on last quarter" dooms everyone who made wrong foundational choices with their old project to spend most of their time "fighting the last war"." Not unless you told them before they started the previous year's project that it'll be used further along the line. I'd just make it one really long subject that spans 3/4 years.

elektronjunge 12y ago

I had a couple classes like that, usually it was more at the semester boundary. E.g. my intro to compilers classes involved writing a compiler for a c-subset. The advanced compilers class built on that compiler by adding optimizations and such. My intro to systems class had a project that was to write a shell. My operating systems class had a project to add job management and pipes to the shell from the systems class. I really liked those projects you felt like you had something pretty substantial when you were done.

loudmax 12y ago

Even more challenging would be to maintain somebody else's code. Say, at the start of an assignment, each student is randomly assigned a code base from the previous project (we could restrict this set to only include code bases that met the grade). New requirements that weren't a part of the previous project are introduced every time this happens. If the students are being graded on a curve so they're competing against one another, this would be downright diabolical.

geebee 12y ago
I'm embarrassed to say that I went 15 years before I really learned to work with "other people's code". That's partly because I came to programming as a math/industrial engineering student, where I was really writing code to solve problems and get answers rather than a sustainable, usable product. Even once I started writing code for users, it was generally pretty experimental and research-y, so I usually got a green field project. In the past few years, I've worked repeatedly with existing code bases to extend or modify functionality (or just fix problems), and it has been an amazing learning experience. Not all of the code has been good, much of it has been questionable. But the process of understanding someone else's code, figuring out how to change it, balancing the harm of forking vs the benefit of improving, dealing with pull requests and merges… there are a number of skills you will only learn from years in this kind of environment. One huge challenge here is when you don't work in an organization that understands software. People aren't knowledgeable about software are often impressed with green field programmers "jim wrote the whole thing". Truth is, understanding a different code base and getting to the point where you can improve it and contribute back to it is (at least in my experience) far more challenging than just writing something from scratch. It seems that most people who write software are already well aware of this, but it can be a hard sell outside (in fact, you may even find that people seriously question your progress - a green field app there's something nifty and new to demo even day, with existing code bases, there's a lot of confusion and investigation - and it can be very dispiriting to spend days stubbornly trying to understand and diagnose a feature, finally solve it, and realize that the team is disappointed with your progress). However, the good software teams appear to be well aware of the challenges, and it's an essential learning experience.
jeffreyrogers 12y ago

sanderjd 12y ago

A really great addition to any CS curriculum would be a long-running projects course that runs the full four years so that you get experience in managing architecture, growth, and maintenance, instead of just building. Lots of students do that by attaching themselves to open source projects or working internships, which is great, but it's not (as far as I know) an official major part of any curriculum I've heard about.

V-2 12y ago
A single four year project would be a little harsh... once you realize what you've done wrong, you'd be to too deep in it to amend your ways anymore. Give them a chance to start from scratch a few times...
- Linell 12y ago
  A rewrite could always be an option, if it's finished on time. Setting a reasonable pace with the project could be tricky, but I think it would be very beneficial.
- mattgreenrocks 12y ago
  Most of the time, you should be building an initial version and throwing it away anyway. Internet time does not justify poor program design.
- sanderjd 12y ago
  Realizing what you've done wrong and feeling the pain of figuring out how to amend it is the whole point of the exercise. Maybe the right way to amend it is to rewrite the whole thing, but that may or may not be the best choice, depending on what else you want to get done. Just like the real world!
kalid 12y ago
For Prof. Larry Peterson's networking class, we had to build up a web server over the course of a semester. You built IP, and used that library to build TCP, and then served files over your TCP connection. It was the first time I realized that bugs in earlier assignments don't magically disappear, and changed my thinking dramatically.

grecy 12y ago

> I'm not sure if there are CS programs out that start with a small project and then force the students to make massive changes to that project throughout the course of the year I studied Software Engineering at Swinburne University in Melbourne Australia, and we did exactly that. One subject was "Software Maintenance Project" where we took an existing code-base we didn't write (a front-end for laTex for our year, the CVS code base for the next year students) and continually made changes to it. Halfway through the course we had to deal with changing requirements. We were graded on the quality of our code and how well it fit the existing style etc., not how fast we did it. We also did a full-year final year project with 16 of us where we created a BIG code base from scratch. We decided to use an iterative approach (our choice) and so over the year we ran 6 iterations continually building on what we'd already done. We also did awesome courses like "Personal Software Process" to teach us discipline in how we personally approach writing code. EDIT: Sometimes I post to HN "hire/resume" threads about my hire-ability and how I personally think I'm "better" than the average person who studied CS because of things like the above. Normally everyone disagrees and says as long as I can code, it doesn't matter that I studied Software Engineering and am a certified Engineer. It's for reasons like the above I still personally feel I'm stronger than the average CS grad.

ramidarigaz 12y ago
That sounds like a seriously awesome course. I wish my school would do that...
mattgreenrocks 12y ago
FYI, you are stronger than the average grad. People get pretty defensive when it comes to skills; nobody wants to believe they're below average if they're frequenting this site. My one piece of advice: keep studying and practicing making beautiful software, in and out. Be careful who you take technical advice from; the industry right now is flush with cash, and thus there is a huge incentive to talk more than produce. Projects are often killed as quickly as they're started, causing people not to practice program design.

fragmede 12y ago

6.170 at MIT attempted to be a 'real-life' coding lab class, while teaching OO concepts. First you're given an assignment; eg, write a simple physics engine that simulates a pool table, and you're graded on your implementation of this. Next a curve-ball is thrown that you're not supposed to know before hand. Eg. Add gravity and turn it into pinball. (Apparently, it's no longer taught in Java, but a quick glance says the curriculum hasn't fundamentally changed - it's a 'real-world' coding lab - now with git!)

jsolson 12y ago

My undergraduate program at Georgia Tech attempted to do this in CS2335 (Software Practicum). That I recall, our first project was an IM client/server, our second was a client/sever game involving programmable automatons, and our third project was a hybrid of Space War-Asteroids-Trader-Lander-Pirates. You had the option of building them all completely separately, but you were strongly encouraged to re-use code form earlier revisions, particular for the client-server bits. The class also included labs on Subversion, although nothing on the notion of things like code review. I could imagine teaching the course today with Github and requiring (or at least awarding some credit for) good use of Pull Requests, meaningful code review, etc. Sadly it looks like the course no longer exists; I have no idea what replaced it.

poikniok 12y ago
CS2340 replaced it. It is a java project course, working in groups of 4-5 people. In my opinion, and that of many others, it is very useless.