Waterloo Cs 135 Assignments For Kids

Last updated May 2014

Introduction

My life has changed substantially since I started university, and most of the change is due to the Software Engineering co-op program at the University of Waterloo.  This page is intended to document these changes and the experiences I've had getting my degree.

My parents have always had to work hard for a living.  Manual labour in frigid -30C (-22F) conditions is something my father is very familiar with.  I consider myself very fortunate that it's unlikely I'll ever have to do manual labour to make a living again.

When I was a kid, my parents started a business selling railroad ties.  Railroads would periodically replace older railroad ties as part of their regular maintenance, and contractors would bid to clean up the old railroad ties.  Many were busted and worthless, but some were ideal for re-purposing in retaining walls.  We would always win the small contracts because other contractors would simply pick out all the good ties and leave a huge mess, while we would bring rakes and shovels and pick up every last particulate until the ground was clean.  This would typically entail a full work day after a 4 hour drive (in both directions) to the middle of nowhere.  At the end of the day, we'd all be dirty and climb into a ton truck that didn't have any leg room for the middle passenger.  Whenever my father needed to shift gears, I would have to lift my legs up, otherwise the stick shift would hit them.

The work I do has changed since then.  I just got my software engineering degree, and I finished my last work term at Amazon Inc. working on Amazon Redshift.


This was what I did just before coming to university, and I would probably still be doing it if I didn't get accepted.


This is a skidder, and I used it to pull trees out of the forest.


I grew up in New Brunswick, Canada.  The exact place I'm from has no population statistic associated with it.  If you Google for it, you will find a different place in New Brunswick that just happens to have the same name.  The nearest town is a 15 minute drive away and has a population of about 4000.  The nearest city is about an hour away.


This is the same ice storm that took out the power in Toronto in winter 2013.







When I first applied to Waterloo, I was overly confident that I would get in since I already had a web site and a lot of coding experience.  It didn't feel good when I got a letter saying that my application was rejected.  My father insisted on calling the university to ask why I was rejected, but I told him not to.  He did it anyway, and that was probably the most important call of my life because I was put on a waiting list, and a couple months later, I got an email saying that I was offered admission contingent on good performance in some correspondence courses I was taking.  This is a picture of the 18 hour drive from my house to Waterloo.


Work-Term #1 ProductWiki

For my first work term I worked with Omar Ismail (co-founder of ProductWiki), who went on to also co-found Streak (YC S11).  I think I was really lucky to get a job at ProductWiki, because I actually got to write code there.  For a first co-op, many students didn't get jobs that involved coding, and a few didn't get jobs.  The ProductWiki team were also UW alumni, so they understood the significance of work term evaluations that students receive.  A bad evaluation will show up for every job that students applies for during their next 5 co-op rounds.  They gave me the highest evaluation of 'Outstanding', which set a precedent for me.  In the end, I got an outstanding from all of the 5 companies I worked for.  I don't have any work related pictures, but here are some photos I took around this period.

This was taken in the laurel creek conservation area, near where I lived at the time.





Velocity Residence

I spent 6 terms living in Velocity Residence, an entrepreneurial themed residence at UW.  I didn't create any million dollar startups while I was there, but I gained a much more mature perspective on business over the years.  I think everyone has an idea for a new social network, or a to-do app, and Velocity allows you to get that out of your system as a short term project, instead of being unfortunate enough to convince a VC to give you money for your terrible idea.  The pitch practice and networking opportunities are also very valuable.


notes.robertelder.ca

Starting about half-way through the first term, I started taking pictures of the blackboard notes instead of writing them down.  I never took notes in high school because my handwriting was so messy and slow.  I also found it difficult to listen to what the lecturer was saying while writing things down at the same time, so this was perfect for me.

I posted these notes on notes.robertelder.ca, a site I created to share the notes with members of my class.  This graph shows the number of page views per day to the Class of 2014 Software Engineering course notes site during the 2A term. Each number indicates the day a major exam took place.  Note the spike in page views the day before most exams.  There are 5731 pictures on notes.robertelder.ca

Most Popular Browser by Visitor

The sample consists almost exclusively of people in the SE 2014 class who visited the site in the 2A term. This data is based on individual visit, so it biased in 2 ways: First, toward the people who actually visit the site since not everyone uses it. Secondly, toward people who visit the site more.

Most Popular Operating System by Visitor

Visitor Repeats

Work-Term #2 Xtreme Labs

My second work term was in Toronto at Xtreme labs.  This was exciting because it was the first time I had ever visited a big city.  Xtreme labs has since been acquired by Pivotal Labs.






Work-Term #3 OANDA

On my third work term I lived closer to downtown Toronto.  I worked for OANDA, which was cool because I had opened a trading account with them almost as soon as I turned 19.  When I first opened the account and started learning about the FOREX markets, I never expected that one day I would actually work for a market maker.



On one cold fall morning, there were a bunch of tiny frozen mosquitoes on the steps to my apartment.



Dundas Square



6:00AM view of Toronto from Trinity Bellwoods Park.


One term I became so overloaded with school work that I stopped going to any of my classes and just did assignments in my room all day, every day.  On this particular day, I finished my combinatorics assignment at 5:30AM just as the sun was coming up, so I celebrated by going for a walk and taking some pictures of the sun rise.



Work-Term #4 NVIDIA

I did my fourth work term at NVIDIA.  It was my first big-name company, and it was a nice feeling to actually accomplish the pilgrimage of so many other software engineers who ultimately end up in silicon valley.

At NVIDIA, I re-wrote an internal web site that showed the results of the many thousands of unit tests for CUDA from a number of static pages, into one fully dynamic search tool.  This saved hours of time for the QA team and developers.  They are now able to bookmark a URL that shows only the test results that are relevant to them.  I also made it possible to re-run unit tests directly from the test result page.


I had a lot of trouble finding a place to live, and I ended up renting a bedroom in a family's house for $1000 a month (which was a very good price).  The catch was that I now had a 10km bike ride to work every day from San Jose to Santa Clara.  I ended up moving to two more places in search of a place that was closer to work.  Taking the bus would have required a 2 hour commute and one transfer.  This place is not friendly to people who don't have cars.


I eventually moved closer to work, but I still had to cross this road on my bicycle every day.


I found a glitch in the matrix.  This is located here.


The first week end after I arrived in California, I biked up Sierra Road.  These pictures don't really do justice for the feeling you get looking out over the rolling green hills that seem to stretch on forever.











One day in Subway, a man in a tie dye shirt who looked kind of like a wizard started a conversation with me.  He told me about how he never used to be religious, but after he had chickenpox around the age of 40, he starting seeing signs from god.  He saw visions of angels and now spreads the message to everyone that the most important thing in the world is love by creating artwork that represents the angels he sees.  He gave me this picture.


This is a picture of me with Jen-Hsun Huang, the CEO of NVIDIA in his back yard.  If I could have this photo taken again I would have shaved and got a haircut but I guess I'll have to live with this one.


The CEO invited all the interns over to his house for the evening.  I won't post the pictures here out of respect for his privacy, but I can say that he's doing well and his car can go very fast.


The time during which I visited Jen-Hsun's house crystallized my impression of the valley.  After we were done enjoying the hospitality of someone who's net worth was hundreds of millions of dollars the bus took us back to NVIDIA.  I then got on my bicycle and biked home in the dark to the place I was staying.  I slept on a bunk bed in a room with 5 other people, in a house that had more people than I could count.  The owner of the property also lived there, and he slept on the couch so the extra bed could be rented out for increased cash flow.  One of the individuals who lived there was an entrepreneur from Spain.  He usually wasn't there because he worked 14 hour days.  He didn't even come home a couple times.  He talked about the deals he was making worth hundreds of thousands of dollars, and he still slept on the bunk bed across from me.  There was also a Japanese girl who was doing immigration research for the Japanese Government, and a variety of similarly ambitious people.  I was invited to a Chinese food outing once, and by chance found out that the person sitting next to me had founded 9gag.com.  This was a truly inspiring place full of people willing to invest all their energy into making it big, and many of them actually do.



San Francisco

It doesn't seem like a good idea to build houses like this in a major earthquake zone.


I would be afraid my car would flip over.


Umm...


Of course.


I didn't realize it at the time, but this guy is legit.


Caltrain station.


The free market at work.




Moffett Federal Airfield



Hangar One


Alcatraz Federal Penitentiary





Work-Term #5 Amazon Inc.

At Amazon I worked on an AWS product called Redshift during the period when it first launched.  Amazon was the first company I worked for that, I felt, had scalable software development practices.  It was my first experience working with such a large and complex distributed system.

During this term, I worked on internal tools that were used by the ops team to perform maintenance more quickly and safely.  I actually coded up some solutions that were from interview questions I had received in the past.

The view from my apartment in downtown Seattle.  I was very happy that I didn't have to bike to work this time.




Taken from Victor Steinbrueck Park


View of work from the apartment.


View of the apartment from work.





CS452 - Real Time Programming

CS452 - Real Time Programming, is a course unlike any other.   Attending lectures is completely optional.  There is absolutely no content to study for, and the final exam is 26.5 hours long.  It is also my favourite course.  During the first lecture, the professor declared: "You're all here because you're a little bit weird, and I'm a little bit weird too."  After one week, half of the class had dropped the course.

In the words of some people, CS452 has a reputation of being the 'hardest course at Waterloo'.  It belongs to a group of advanced technical electives known informally as 'the big three' that are infamous for being so time consuming.  The QNX operating system traces its roots back to this course.

The entire course centers around a project where each group of two students build a real-time OS kernel from scratch with no debugger, and no starter code other than a busy-wait printf function and a boot loader.  It is standard to not use memory protection because it takes too much time to configure.  The kernel runs a set of user tasks that operate a model train set in response to real-time information derived from sensors on the track.  The communication with the train set runs at 2400 baud so it takes about 61 milliseconds to ask all of the sensors for data about the train's possible location.  This makes it particularly challenging because a train can move about 3 centimeters in that time.  A successful project needs to be able to ask where a train is and successfully flip track switches before the train moves over them or collides with another train.


The first thing I did was write an assert function.  When I was a kid, I used to watch Shining Time Station, so I made the assertion failures as obvious as possible by printing and ASCII-art representation of Thomas the Tank Engine.


The trains tend to speed up and slow down depending on how warm they are, and how polished the track is.


Communication with the train controller must be reverse-engineered from old BASIC code.


Each sensor on the track remembers whether it has been pushed forward or backward since the last time it was polled, but only if it's not broken.


The switches on the track must be separately activated and de-activated in two different commands.  If you turn it off in less than 150 milliseconds you won't actually move the switch because the solenoid needs power for some time before it actually moves (I believe this is due to power factor). If you turn it off after 500 milliseconds you risk physically damaging the hardware by burning out the solenoid.  It is routine for many of the switches and sensors to be broken, and your project is expected to handle this smoothly.


I found it difficult to attend all of my classes.


In this photo I was trying to get preemptive context switching to work when an assertion failure fired in one of the tasks.  At this time I wasn't disabling interrupts on the assertion failure condition so the kernel would context switch out periodically while it was printing the message for the assertion failure.  I had put a debug message of "iii" in the interrupt handler, and the result was some very esoteric humor.


Our UI which showed the state of all sensors and switches.  Many of the sensors would stick on, which would cause the model to think the train was in a completely different place on the track.  This would typically cause the trains to crash.


The cross-compiled code is downloaded to a TS-7200 board attached to a peripheral on the main computers in the lab.  Every student in the course becomes very familiar with this button.


Work-Term #6 Amazon Inc. (2nd)

I returned to Amazon to work on Redshift again.  I had originally decided to intern at a different company for each term, but the product was interesting enough to come back to.

This term I took over a partially-complete project and drove it to production for customers to use.  The project was event notifications for Redshift.

My new apartment.  No direct view of work, but still pretty close.


The view from my huge living room windows overlooked a community center that homeless people slept behind sometimes.  It was a strange juxtaposition given the fact that my corporate housing provided more than what I needed, and gave me a comfortable 7th floor view of people who had nothing.


Sunrise from my apartment.


Sunset from the office.


I was able to get a blurry photo of Jeff Bezos.



Deionized electrolyte water.


Veni Vidi Vici


Final Grades

I never failed a class, but I came close a few times.  I also ended up doing an extra course in my last term due to some graduation requirements that, I would argue, were not clear enough.

Grades Ordered by Mark

96SE 490Design Project 1
90SE 390Design Project Planning
90SE 491Design Project 2
88SE 101Introduction to Methods of Software Engineering
88SE 464Software Design and Architectures
84ECE 455Embedded Software
83MATH 119Calculus 2 for Engineering
83SE 350Operating Systems
83STV 205Cybernetics and Society
82CS 137Programming Principles
81MATH 115Linear Algebra for Engineering
81CS 348Introduction to Database Management
80CS 458Computer Security and Privacy
78CS 138Functional Programming and Data Abstraction
77PHIL 145Critical Thinking
77SOC 101Introduction to Sociology
76MATH 117Calculus 1 for Engineering
76PSYCH 101Introductory Psychology
76ENGL 210FGenres of Business Communication
76CS 445Software Requirements
76CS 454Distributed Systems
75MSCI 261Engineering Economics: Financial Management for Engineers
75CS 246Object-Oriented Software Development
75CS 240Data Structures and Data Management
75SE 465Software Testing and Quality Assurance
74MATH 135Algebra for Honours Mathematics
73ECE 358Computer Networks
73CS 452Real-time Programming
72CHE 102Chemistry for Engineers
71ECE 126Introduction to Electrostatics, Magnetism and Electronics
69SE 380Introduction to Feedback Control
65ECE 222Digital Computers
65BIOL 130Introductory Cell Biology
65CS 349User Interfaces
61CS 241Foundations of Sequential Programs
60MATH 213Advanced Mathematics for Software Engineers
60CS 343Concurrent and Parallel Programming
60CS 341Algorithms
59BIOL 140Fundamentals of Microbiology
58SE 141Digital Circuits and Systems
56BIOL 273Principles of Human Physiology 1
55PHYS 115Mechanics
53STAT 206Statistics for Software Engineering
53MATH 239Introduction to Combinatorics
52SE 212Logic and Computation

To be completely honest, some of the marks seemed completely random.  I would often expect a mark that was +/- 20% in the wrong direction.  For example, in ECE 455 I got my 6th highest mark of university.  I thought I was going to fail the course because I skipped most of the classes to get eye surgery or to attend one of my other courses that was scheduled at the same time.  In CS 343, my 8th lowest mark, we worked with a language called micro C++.  I found a bug with the compiler that resulted in a segmentation fault on a certain rare race condition.  I was even able to create a test case that would trigger the fault in under a couple seconds (I think it wasn't synchronizing the exit of threads correctly).  I showed the prof and he confirmed that it was definitely a bug in micro C++, and that he wasn't going to fix it.

Distribution of Marks

Interviews

I don't know how many job interviews I've done, but I put it around 50-80.  I did Jobmine 5 times, and I had 24 interviews one term.  Doing all these interviews was stressful, especially since they happen during midterm week, but it really boosted my confidence at interviewing for jobs.  It also made me good at interview questions, since the same ones generally start appearing over and over.

It also gave me an opinion on how to interview a job candidate well, and what kind of questions you should or should not ask.  This is an endlessly debated topic, but I really feel one place where interviewers get it wrong is on asking people to write code.  It is extremely rare for a software developer to write code that gets contributed toward the end product.  If all software developers did was write code, then modern windows could be written by 1,000 developers in about about four months[1]. Instead, Microsoft has 43,629 engineers[2] and no shortage of work for them.  What software developers spend most of their time doing is typically 1) communicating and 2) re-writing code that doesn't work.  This re-writing typically occurs because of inadequate or improper communication related to the requirements, but can also be caused by errors introduced due to lack of CS fundamentals or simple mistakes.

I will start by discussing how the interview process seems to focus on the errors introduced by a lack of CS fundamentals and make some claims:

Claim 1:  If you want sustainable software you shouldn't hire people who can write code, you should hire people who can debug code.

There are several reasons why I feel this claim is justified:

  • If you can write fairly good code the first time, you may or may not be skilled at debugging the remaining flaws.  If you are very good at debugging, then you can definitely improve your code to whatever level is required, even if you don't get it the first time.  If you're good enough at debugging, you can take an empty file and debug that into whatever software product you need.  On the other hand, I've seen some very smart developers who, when faced with a monolithic project they didn't write, just throw their hands up and say 'I have no idea what to do. It should just work!'.  Even worse, some people operate by the axiom of 'If you've traced the problem down this far, you're doing something wrong.'  The idea that you could tack down a problem in a third-party library is complete unthinkable to them.
  • If the end goal of your product is to have bug-free code then, I will claim, that people who can debug code strictly dominate people who can write code.  If you hire the best and the brightest who always get things 99.99% right the first time you're going to have pretty good software, right?  People who are used to getting it right the first time may have never needed to develop the skills required to go the extra 0.01%, but 99.99% is basically perfect isn't it?  If your system is made of 100,000 components, all of which work 99.99% of the time, then your system is going to about 0.0045% of the time[3].
  • If the goal of the interview is to find a candidate that has deep knowledge of data structures and algorithms, then you will not be guaranteed this by getting them to write code.  The algorithms used for many interview questions can be easily memorized and revised immediately before the interview.  On the other hand, if the interviewee can identify and fix a novel bug in an existing algorithm during an interview, then they are a lot more likely to have a fundamental understanding.  This is because isolating an error state, in the pedantic software engineering sense of the term 'error', means to find a case in the program where the desired program state is different from the observed program state.  In order to know what the desired program state is, you must understand the algorithm.
  • You can quickly and quantifiably verify that the interviewee got the correct solution.  If you give a candidate some code that's broken and ask them to fix it or even just to find a minimal test case that clearly demonstrates the error, then you can easily say that they got the right answer, possibly by a unit test.  You also don't have to spend time watching them write out the function prototypes.  Let's be honest, if you're about to interview someone and ask them a binary search tree question, you're probably going to make sure you brush up on BST delete, insert etc. just before the interview yourself.  Spotting bugs in complex algorithms is notoriously difficult even for the interviewer.  I even remember a few cases where after an interview I went home to think about the question more, and I realized that the solution I presented in the interview had errors, but the interviewer still claimed that it was correct.
  • If you ask the right questions the information density of the interview can be much higher.  Interviews are usually only about an hour, which isn't much time to get to know someone.  Typically, you'll only get asked two or three big programming questions, and the interviewer will only begin to develop a picture of the depth of your knowledge after you've been writing code for a few minutes.  Here are some questions that are time-efficient debugging related questions that I think would give you an idea of how the candidate thinks in under a minute:
    • "Your co-worker recently made some changes to a linked-list delete routine.  Now every time we search the linked-list for something after doing a deletion, the computer just hangs.  What do you think happened, and how would you debug this?  What's it likely doing when it hangs?"
    • "Everybody knows that hash table insertion is O(1), so I wrote myself a custom hash table implementation. For the hash function, I just use the first 4 bytes of the thing I want to insert so the hash function is super fast.  Why is it so slow when I insert URLs?"
  • Software developers spend very little time actually writing code, they spend most of their time debugging code that should already work.  Why not just cut to the chase and evaluate the performance of the employee on what they will actually be doing when they come work for you?

Claim 2:  If you only want throw-away software fast, then you can just hire people who write code.

There is another side of the argument that is more sympathetic to the business needs of programming, instead of the more academic desire for perfection:

  • In a business you don't need software that works perfectly, you need something that works 99.99% now, instead of 80% now and 100% if you just wait another two weeks.  I'm definitely guilty of taking a bit too much time on some projects to try and make them more maintainable for other developers.  The truth is, it's really difficult to decide whether you should invest the effort in making things maintainable in the future.  Depending on how the project goes you might be missing out on huge business opportunities by not getting an MVP out there faster.  Us software developers are also extremely expensive, so once the product approaches 100% complete, the return on investment of spending developer time decreases rapidly.  On the other hand, you might be creating a not-so-great design decision that is used by not only your company, but one that must be supported forever by everyone. One example I'm thinking of is the master boot record.[4]
  • You're going to have to think harder to set up the interview.  Asking someone to write out a linked list implementation is a lot easier than writing one yourself, putting a bug in it, and writing a unit test for it.  Interviewees commonly share questions too, so you're going to have to have enough diversity in your questions to prevent them from sharing exact answers.

Claim 3:  If you want the best of both worlds, then create teams where some members write almost perfect code the first time, and some members can debug code fast regardless of how perfect their first solution is.

I believe the best approach, especially if you run a large organization, would be a hybrid one:  Hire some people who are really good at quickly writing code that is mostly correct, and some people who are really good at quickly debugging code.  If you put these people on the same team, you get the best of both worlds.  By virtue of their differing views on how to best solve problems, it may be difficult for these individuals to see the perspective of the other, so good inter-personal skills will be especially important.

In the extreme case if there is no cross-pollination between these two intellectual types, you'll either end up with software that is unnecessarily late and higher quality than necessary, or software that looks perfect now but causes a slow accumulation of technical debt.  The latter case is a less obvious and more severe problem since the effect is disconnected temporally from the cause.  I believe this is why there is traditionally so much emphasis on being able to write code fast in interviews.

 When I was in California, I met an engineer who described a dichotomy that has stuck with me.  He said that the way a stereotypical mathematician learns to program is take a book on programming, read the entire thing, then write their program without looking back at the book.  The way an engineer learns to program is by taking the book, throwing it in the garbage, then taking something they know already works and slowly tinkering with it until it becomes the program they want.  Although the label engineering/mathematician isn't really relevant here, I do feel that this idea is relevant for defining two ends of a spectrum for describing how people solve problems.  Some people algebraically arrive at a solution that is almost perfect, but if they're wrong they find it difficult to orient themselves in the direction of improvement.  Other people use something closer to fixed-point iteration, continually using feedback to clumsily get closer to the right answer.  If you'll stick with me on these extremely lose associations, you might enjoy reading about the idea of how analysts and algebraists eat their corn.  You'll probably notice that of the two algorithms for solving problems I just described, one is from analysis, and one is from algebra.

Communication

Finally, one of the attributes of a potential employee that I think is the most overlooked is their ability to communicate and interact with others.  For at least a few of my interviews, I would walk in, and the interviewer would say "OK, let's get right to it. So we've got a binary search tree...".  No "Hi, how are you?" or any kind of small talk at all.  I don't think it makes sense to spend a lot of time asking someone how their day was, but if you hire this person they're probably going to be giving presentations, conducting meetings or talking to customers etc.  Two or three minutes of well-targeted small talk questions also give you a great idea of the kind of habits this person has.  Do you have any side projects you're working on?  Do you enjoy what you're studying?

Some people have personalities that are particularly poisonous to your organization.  People who consistently talk down to co-workers, or try to call out the inferiority of work that other people have done to assert themselves on higher ground are among these types. An email stating "Hey, can you stop breaking the build?  You're putting us way behind. Thanks." is sure to contribute less to group productivity than "Hi, I noticed the build <link to build> is red, and the last commit is related to XYZ you worked on.  Can you help me fix it? Thanks,Firstname Lastname".  If you match one of these poisonous people with a reasonable person, work will still get done, but you're going to damage employee loyalty.  If you put two poisonous people together, you might even end up getting negative work done as they will continually battle it out for the higher ground by purposely not communicating so the other person will screw up.  And they will, and it will always be the fault of the other person so nobody will improve.

In an interview, there is a clear social hierarchy.  The interviewer is at the top, and the interviewee is at the bottom.  If you want to give the person a chance to show that they might be poisonous for your organization, you could think about disrupting that hierarchy.  Instead of sitting across a table from, side beside them and work with them.  After all, this is the way its going to be when they come work for you, isn't it?  They'll spend a huge amount of time communicating with team members to solve problems, not solving problems by themselves while others watch.  If you're working with an interviewee to solve a problem, and you say something stupid, does the interviewee try to make you feel bad about it?  If they do that to an interviewer, they'll probably be even worse to people on their team.

Conclusion

On the day of my last exam I had $5,039.22 in the bank.  I have no debt and I'm waiting on an income tax refund from the government.  In the early days I borrowed a few thousand dollars from my parents, but I was able to pay for almost all of my tuition with my own money from co-ops.  This is a huge deal because my understanding is that people at other universities end up with $100,000 in debt after they graduate.  Before I started university I didn't really realize how big of a difference the co-op program would make.  Having no debt is really awesome!

I've spoken highly of my experiences in many aspects, but it's not all fun and games.  The social experience at UW isn't exactly the greatest.  Partially, this is my own fault since many people are able to manage the high work load and having a social life at the same time, but I'm not able to do this.  Ever since second year I started focusing more on school because I didn't want to fail a term and set myself back.  Since the work load is high enough that its never possible to 'finish' your assignments, I ended up working on school pretty much all the time.  I was never able to determine exactly how much effort was necessary to 'just get by', and with the threat of the guillotine over my head all the time, I spent more and more time on school, until the last term when I ended up with 7 courses.

The fact that it's necessary to move every 4 months is a mixed blessing.  It's great to have so much diversity, but finding a place to live every 4 months can be a pain.  It's also difficult to put roots anywhere and get a good stable social circle going.

Elon Musk commented that he didn't go to Waterloo because there weren't many girls on campus.  I can say that there are girls on campus, but very few of them go to my classes.  In my graduating class there were 5 girls and 78 guys.  In some of my electives there were no girls.  In the work force there were generally less girls than in my classes.  I believe this trend is changing because I've been told that the lower year software engineering classes have a ratio that is closer to 50/50.

The last 5 years have been the most significant of my life.  The experiences I've had due to the co-op program have probably been the most impactful on me.  I've been able to realize that the world is so much bigger than I thought before.  I have also had the opportunity to be influenced by so many successful entrepreneurs, and great thinkers.  For the first time in my life I was able to meet other people who shared a passion for knowledge as great as mine.  Most of my friends have gone off to work at Google, Amazon, Facebook and all the other big companies.  I really look forward to seeing where they end up.

To be continued...

Sign up for when I write part 2, if you're interested:

Part 2 is now available here.

References

[1]  The point of the argument is to consider how long it takes to write software if it were just a matter of typing the characters.  I have made the assumption that modern windows is about 100,000,000 lines of code.  If it takes about 20 seconds to write out one line of code (this should be more than enough time for the average line), then with 7 hour work days it's going to take (100,000,000 * 20) / (60*60*7) = 79365 person days to finish.  Thus, with 1,000 developers it would take about 79 days.  The assumption that time taken for work scales linearly with the number of workers is justified since the thesis of this argument states that all developers do is write code, which is a solitary act that is independent of the total number of workers.  With 20 work days per month, that's about 4 months.

[2]   https://www.microsoft.com/en-us/news/inside_ms.aspx#EmploymentInfo Accessed May 12, 2014

[3] If all 100,000 components need to work at the same time, and each of them works 99.99% of the time, then 0.9999^100000 = 0.00004537723 = 0.0045%

[4] Master boot records still use CHS addressing, which doesn't make much sense for SSDs and flash devices.  There is also lots of fancy magic you need to do in order to support large disks or have more than 4 partitions.

I wrote the last exam (GER 101) of my first year at Waterloo two days ago. I was busy moving out or rez yesterday, and I just got some of my 1B marks on Quest. Thought I should write a blog post to wrap up my first year at UW. It was pretty lit: met a bunch of cool kids, joined a handful of clubs, played intramurals, pulled an (almost) all-nighter, got smashed twice, and had tons of fun in (some of) my classes while studying my butt off in the process.

RCH (left) is my favorite building, because it’s always empty late at night (I’m looking at you, QNC), and I can enjoy a few hours of solitary studying time there every day.

The transition from high school to university was easier and smoother than I thought. Before coming to university, I heard a lot of scary things about the workload in first year, especially many MATH 135 horror stories. But everything turned out fine, thankfully. And I honestly really like the campus. There is something I like about the campus being enclosed by Ring Road and constantly patrolled by geese. It’s not as big and nice as UBC, but it feels intimate.

The university residence I picked (UWP) was not that nice though. The room is really small and the walls aren’t soundproof. There was also a pretty serious ant infection in our unit, which was really annoying. But living on campus in first year was definitely worth it! Because there are so many co-op sequences in Math and Engineering, some of us will eventually be off-stream (i.e. I will be on co-op while some friends will have a study term, and vice versa), and first year is really (sadly) our only chance to meet people from all sequences.

1A

I am not gonna lie, I was pretty pumped after the ceremony!

As a frequent lurker on /r/uwaterloo even before I got accepted into UW, I thought I had a pretty good idea of what my first semester would be like. But you have to actually experience it to know what it’s really like. Almost lost my voice during Orientation Week from constantly screaming, laughing, and cheering. Exploring campus and bantering about baseball with people in my orientation group were great.

I still remember on the first day of classes I woke up an hour before my first lecture and wore a black Waterloo hoodie feeling like a smarty. After my first midterm, I finally realized that I am not in high school anymore. I also learned that sprinting from MC to PAS in 10 minutes is not fun, and that employer info sessions are where I get free sunglasses, keychains, and T-shirts (JK people actually go there for the free food).

I played in the intramural slo-pitch league and in my first game, struck out with the bases loaded (2-4 for the day though). For some weird reason, I started a habit of working on my CS assignments on Friday night till 3 in the morning in Grand Commons, and waking up at 3pm the next day still feeling exhausted. I went to Mr. Paninos for real and really loved their beef noodles, and then proceeded to eat there for the rest of the week. NOT a good idea. I feel like throwing up whenever I see a Panino meme on Reddit now. I tried out almost all the restaurants in the plaza (RIP Panda King I will miss you forever), and fell in love with the $1.99 BK nuggets. I felt like a total noob.

I worked really hard this term. Got the wake-up call after my first midterm, started doing assignments the day they were assigned and reading relevant materials the day before class. So I managed to get decent grades, but I think I should’ve gone out more and tried to meet more people.

MATH 135

I can say that I thoroughly enjoyed this course. Did pretty well, and getting 98% on my second-ever university exam was an amazing feeling. Had to Work through hard proof assignment questions like there’s no tomorrow though. I was really keen and sat in the first row every single class. That’s my philosophy: always sit in the front. Proving something like there are infinite number of primes and whether 263+3315 is divisble by 7 were definitely highlights of this course as well. The prof, Ian, was awesome and made the class very enjoyable for me. The final was not hard and similar to the sample final they gave us. Carmen Bruni’s final exam Twitch stream on MATH 135 was the icing on the cake.

MATH 137

Mike Eden literally taught this course in sarcasm. Hilarious prof. I already learned derivatives and integrations back in high school so this course is mostly review, but this course was still pretty interesting. I like how Eden asked us to never forget to write “By Limit Laws”, but then promptly forgot it himself while doing examples. Midterm was unexpectedly hard, but the final was alright.

CS 135

I didn’t really enjoy coding in Racket (a dialect of Scheme) until after the second midterm. But boy, foldr and lambdas are love. Functional programming is something truly special and amazing, I have to say. When recursion becomes your second nature, you will really appreciate its elegance. The assignments are really wordy though, and don’t even get me started on lambda tracing. It’s just so tedious. Dr Racket became a meme on the CS 135 Facebook group, and Dave Tompkins (a.k.a Quest God, Dancin’ DJ Dave) achieved celebrity status for his dank CS jokes.

ENGL 109

A fairly standard communication course. Apparently starting from this year (Fall 2015) all Math and CS kids have to take two communication courses before they graduate, which I think is a good idea. This course is mostly essay writing (we wrote 3 major essays over the term, and some smaller written exercises), and the prof was very enthusiastic about teaching. I really liked the technical report assignment, where I got to talk about the differences between objected-oriented and functional programming using layperson’s terms.

ECON 101

Oh the fabled “ultimate bird course”. Its honestly not that birdy, you still need to put in the effort to read the study guide and do the multiple choice questions in order to do well on exams. But yes, it’s mostly rote memoriztaion, though some concepts like game theory are very interesting. I think it did teach me some economic literacy.

1B

I felt a lot relaxed and confident after my 1A term, so I signed up for 6 courses this term. It was definitely more work than I anticipated, but it was worth it. I met a lot of people in the UWCLEC Russian Club and had tons of fun. We would all bring food and drinks to the Russian tutor’s place in UWP and have small potlucks basically.

MATH 136

MEME 136! MATH 136 will always be a part of me: Yongqiang “Yeezus” Zhao, the definition of a basis (“Whaaaat, is the definition of a baaaasis?” “A linearly independent spanning set!” “Wow, that was beautiful!”), “plug into a matrix and row reduce”, Wolfram Alpha, and Dan Wolczuk (a.k.a Dr Dan).

I even compiled a “MATH 136 in a nutshell” (basically all the catchphrases we use while proving theorems):

  • “It is intuitively obvious that…”
  • “Clearly/Obviously”
  • “Immediately true by inspection, as required. ∎”
  • “Without loss of generality (WLOG Moite)”
  • “Similarly, same argument applies”
  • “By the System-Rank Theorem”
  • “Trivial” you know what’s trivial? c1 = c2 = c3 = … = cn = 0 as n approaches infinity

Oh fun times. Linear algebra gets extremely abstract sometimes, but in the end everything made sense.

MATH 138

I also made a “MATH 138 in a nutshell”:

  • “Eventually, for large n, an/bn < 1” Hand-wavvvvvy
  • “Counterexample: let an = 1/n, bn = 1/n, cn = 1/n…”
  • “Upper bound of error, by Taylor’s Inequality is above 9001, since 9001 >= (0.0001)^5*(1/e)^6/6!” Yo you gotta have le equal sign bruh
  • “It diverges since it is the harmonic series” Jordy Hams be like first published in 1962
  • “It converges since it is the alternating harmonic series”
  • “By IBP/Ratio Test/Limit Comparison Test”
  • “(2n-1)(2n-3)…(5)(3)(1) for n from 0 to infinity”
  • “DO NOT EVALUATE THE INTEGRAL” PRAISE THE LORD
  • “DO NOT USE L’HOPITAL’S RULE” U WOT M8
  • “Use the washer/disk method”
  • “Include all initial conditions”
  • “1+½^2+⅓^2+… = pi2/6” (TRIGGERED)
  • “It is a telescoping series…”
  • RATIO TEST RETURNS 1 and LIMIT COMPARISON TEST RETURNS INFINITY -> TURBOTRIGGERED

Calculus 2: basically a continuation of MATH 137 (Calculus 1). Lots of sequences, series, and Taylor polynomials, mixed with some easy proofs. Probably my last calculus class in undergrad, if I choose not to take upper year Statistics courses.

CS 136

Fairly easy intro course to C. Definitely not as fun as CS 135 to be honest. We learned some basic data structures (Arrays, binary trees, linked lists etc.), algorithms (Quicksort, mergesort), and the C memory model. Assignments were pretty boring and tedious, and memory leaks caused me some trouble. The Russian Club afterparties would sometimes turn into code parties (awks). Only fun stuff I remember about this course is that my prof was basically constanly bashing the slides for poor style and code quality.

ENGL 119

ENGL 119 wasn’t interesting at all. Did learn some useful presentation techniques and aspects of technical writing, but it was so disorganized. Second mandatory communication course. Now I think about it, I should’ve sticked it out and kept Public Speaking.

GER 101

Pretty chill class. Prof was chill. Kinda felt like a high school French class. The video project was awesome. We had to move two monitors back and forth for three straight days, and we didn’t have a tripod or anything fancy to film it properly, but it was worth it. I feel that I could’ve learned more German from this class (I really liked the in-class activities). Midterm and final were both very short and easy.

STAT 230

My favorite course this term by far. Really enjoyed learning all the random variable distributions and argument counting techniques. This course made me interested in data science, analytics, and just statistics in general. Diana is a great prof, and we made the negative binomial distribution into a meme. The final was way harder than I anticipated, but still managed a decent overall mark.

One thought on “Waterloo Cs 135 Assignments For Kids

Leave a Reply

Your email address will not be published. Required fields are marked *