The Third Bit

What Worked:
—————–
- randomly chosen teams
- responsibility
- points learned for interviewing
- exposure to different tools, projects, ideas, techniques
- learning how to demo, hold a meeting, speak in a meeting
- learning how to take criticism
- forcing students to be accountable and learn the importance of
keeping a project up-to-date for sake of those continuing the project
- demos- liked this for interviews
- exposure to meetings, interesting talks and people
- worth the travel from way west mississauga
- feedback on reports (and life)
- don’t change the jokes/stories, it made it interesting.
- quick responses to emails was very important. Even getting a
response is important. It becomes tiresome when there is a team member
who refuses to answer emails.

What Didn’t Work and what can be done differently:
—————
- overlap between both semesters
- demos - is there a better way to do this? I can’t think of one…
but maybe there is.
- 13 weeks is too short. I know, nothing can be done to fix this, but
I like complaining. Too much time is spent learning tools, rather than
being productive.
- communication between members needs to be reviewed. I think it
should be monitored like a work setting. Not to the point where people
are reprimanded for speaking out of line, but for accountability. Just
to have these conversations recorded. This was the reason I used the
mailing-list most of the time.
- status meetings should follow a standard agenda. Maybe if all team
members knew they were going to be asked something, they would be more
willing to finish their work on time or have a valid reason why it
isn’t. Status reports can be written beforehand to enforce this…?
- Documentation. I say this so much and probably don’t follow my own
advice enough. Enforce it with marks the same way coding is enforced.
It neeeeeeeee…eeeeds to be done and lacks in almost every project I
have ever worked on.
- more time learning about the real world and what to expect
- learn how to manage time and communicate with team members

By Lillian Angel on May 6, 2007

49X is finishing school for Software Professionals and it may be difficult to replicate that experience in a traditional class. The most valuable things I took away were the ones that would be hard to grade: How to conduct an efficient meeting, how to be less irritating, anecdotes from industry, presentation skills, etc. The actual programming was almost incident to the learning experience. I’m happy with that. It was a great course and I wish everyone could take it. But I think it’s different from Software Engineering—it’s more like learning about how a real team would work together in industry.

Here’s what I’d like to see for the new Software Engineering course(s):
* Design patterns—more depth.
* Architectural patterns—more depth.
* Tools: SVN, ORM, lint, debugger, memprof, Xcode, TextMate, OS X
* Style. How do you teach someone to take pride in their work?
* How to release and maintain software—web based and shrink wrapped.
* A non-toy project—something you can put on your CV: “Our group’s code is used in Tomcat”.

I don’t think many people can reasonably learn all of these things in two semesters. So why not have 4 Software Engineering classes? Not everyone wants to be a PhD and *no one* wants to call a Waterloo grad “boss”. Every semester we graduate students with half the skills needed to be a reasonable developer. Quick poll: how many of you have put that year of calculus to good use?

You want to know what to put in a Software Engineering class? Ask Google. Ask Microsoft. Ask RIM, or IBM, or Yahoo, or Amazon. Ask them what our grads are lacking. Ask them to describe their best new hires. Ask them what they teach newly hired developers. Call it “Google School of Code” or something. OK, now I’m just meandering.

By Miles Thibault on May 8, 2007

I’m not sure if my 49x experiences would help much to improve software engineering courses as my projects were more research based. I was a little concerned that with only a single term, it was difficult to come up with a project and get much done on it. The process was educational, but it might be best to have a little more initial direction.

As for the summer, I suppose the only thing I really missed out on was a teamwork type experience. Aside from that, and some initial bureaucratic troubles, things proceeded fairly smoothly.

I have not taken many software engineering courses (just 207), but in my experience I would have liked to see more motivation for the tools, which as a cocky first year student I shrugged off. It was only in later years that I came to recognize their usefulness. An argument can be made that such maturation is part of the educational experience but I thought I should throw it out there as food for thought

By Rick Valenzano on May 8, 2007

CSC49x was the meat that I was craving for that I felt wasn’t given to me on my PEY term - being able to do meaning/significant work with a team of random people. I’m sure there are a few other students who’ve went on PEY and felt like they did very little meaningful work and weren’t being fully utilized. I have to emphasize that not all students were treated like that but I’ve heard a few bad stories along those lines.

Things I’ve learned:

- Conflicts. This isn’t soley based on 49x, but it appears to be a reoccuring theme lately. When working with other people, there’s bound to be times where there will be conflicts, whether it is because of the clash of individuals’ ideas, expectations, work habits, miscommunication, whatever. In a regular classroom setting, I heard that student groups are allowed (and the A&S faculty permits?) to split and work on their own if problems cannot be resolved (someone please confirm this?). In a real project in the real world, it’s a little different and in my naive opinion (IMNO) people have to struggle through it or else the project may ultimately fall through and never complete, especially if the people in conflict are leads or managers. And even with people trying to cope with the situation (or pretend as if nothing happened), there probably will be a bad vibe in the air that is basically unhealthy and have an affect on productivity if is not dealt with properly. OK, so this part went a little longer than I thought but basically what I’m saying is that I’ve learned that we, as individuals, need to know how to deal and prepare for conflicts whenever they arise in an appropriate and healthy manner. I don’t know if this is a topic for CSC301/302, but I think it’s worthwhile getting some pointers as to how to deal with people and conflicts. Some readers here can relate.

- Demos. I never occured to me before 494, but after attending DemoCamp and doing a few demos, I personally feel that being able to present a demo of an app/project in a short amount of time in a compelling way is key to success for me. Not only will be a way for me to get a foot into the door, but I have a feeling I’m going to have to do it many more times for years to come so getting a lot of practice demoing now is good. Keep up with the demos.

Things that were valuable:
- Providing an insight and giving event info as to what’s going on in the community (ie. democamp) and encouraging students to go. I find that it’s valuable to know what events are happening in town so that aspiring developers, like myself, and students can have an oppurtunity to reach out, if they feel like, and get a different perspective on industry/workforce/life other than from a school setting. Students tend to get all caught up with school and assignments that we don’t bother looking out for these events and end up missing the chance. Altho DemoCamp’s content isn’t quite what I’m looking for, I’ve found other groups that have the same interests as I do and now I feel glad that I live in Toronto where there is A LOT of people with diverse interests.

And to answer Miles’ question about math: it depends on what you’re doing. If you’re mainly web-related stuff, you probably don’t need much math for that. But for me I did run into Linear Algebra a few times and I kinda wish I paid a little more attention in MAT223/4 back in the day, but that’s another story…

By Thuan on May 9, 2007

Most importantly I think the students should be encouraged if not made to work in the same room together, even if it’s a small amount of time each week. Classes are usually three hours a week, so I don’t think it would be too unreasonable to have the one hour status meeting and then two hours of group work. That time may be spent coding in complete silence, but if anything needs to be discussed than the group has a guaranteed time where everyone is present. Unfortunately about 90% (or maybe just 75% with a few bad experiences which make it seem like 90%) of the “teamwork” I did at U of T was really just divide and conquer - You take this section, I’ll take this section, we’ll compile it the day before and hope for the best. There was always someone who lived in Mississauga or our schedules just didn’t agree or the only time everyone could meet was 1am (true story, it was awful). I don’t think I really had a sense of teamwork until the third semester when I was working on the project alone. In that third semester there was a group of students in the same room for two and a half days a week which I was able to bounce Ideas of off and talk about the problems I was encountering. They may not have paid attention all the time but I found talking out loud helped to organize my thoughts.

As for tools and time management, perhaps a time tracking feature could be added to Dr. Project. I remember there being a lot of emphasis put on making estimates and improving our ability at estimating. I can now say from experience that watching my status bar go from green to red as my time goes over has helped me understand what I can accomplish in an hour and what I can’t.

What didn’t work? For me it was the presentations (If you remember I did rather miserable on both). Doing presentations is a good skill to learn, but for me, I picked topics irrelevant to both my work and interests. As a result I spent very little time preparing. I probably could have used some coaching to find a topic. Now I can think many things I would like to read up on and present, but at the time I was still fairly ignorant of what was out there and what I was interested in.

This next thought may be out of the 49x scope and really just stuff I wished I leaned in school, but maybe not as a few of the projects were web related. It would have been nice if U of T had an advanced web programming class. Looking at a simple server written in python is interesting, but it doesn’t translate when trying to install/configure/debug apache or tomcat for your 49x project.

Keep the jokes and the anecdotes, they really are the best lessons from 49x.

By Andrew Reynolds on May 23, 2007