A number of a former anonymous students have graciously made advice available to current students. The advice is organized by topic:
This class boils down to teaching you the things relating to developing code that aren't the actual writing of code: thinking about code and the people who write it, very high level design of code, breaking code, testing code, managing code and the people who write it. You learn a lot, but if you're looking for a class that teaches you a programming concept and lets you run away and complete a project, this is not the class; rather, this class forces you to do all the best practices of developing code that aren't otherwise enforced in other courses in the curriculum. If you decide to take this class, you should approach it with the mentality of an engineer rather than a programmer, the distinction becomes clearer throughout the class.
This class is really worth what you put into it: if you are willing to spend the time and really do the readings and pay attention you will really learn a number of valuable skills and lessons for the post-college world.
Our advice to future students looking to take this class is to 1) attend all lectures if possible and 2) take them seriously. Although this class is probably the least "code intensive" ULCS class we’ve taken, it's by far the most useful. After two summers of both of us interning at large industry companies, we can honestly say that we now understand 100% of the things being said around the company. Let us explain, as CS interns, other employees talk to you as if you know and understand all the industry standards and sayings a software engineer should. And yes, while they do encourage you to ask questions about things you don't understand, let's be real you never feel comfortable asking them which leads to unsatisfying google explanations. After taking this course we can confidently say that we feel more prepared than ever to enter the SE industry. Honestly we believe this should be a mandatory course over EECS 496 and TC 497 because 481 does a better job at preparing you what to really expect then those two classes. This is not to say that all other EECS classes which involve programming topics such as web-dev, security, and so forth aren't great classes to take. It's more to show you that there are other things to consider other than your actual skill set as a developer when you graduate from the University of Michigan.
Connect the software engineering principles we learned in class to your past and future work experiences as a growing software engineer, and you'll be surprised at how applicable the lecture content in 481 will prove to be.
The majority of the material in this class is probably more relevant to working in industry than the majority of the material in the major. Brush your teeth.
Use this class as a way to gauge whether you will enjoy working as a software engineer in industry.
Understand that EECS 481 is about learning and will give you the skills to excel at interviews, so take your time to genuinely learn the material covered, speak with the staff about how you can use the information to improve your abilities personally, and enjoy your time!
Treat this course as an EECS class mixed with humanities: it requires a different kind of understanding of the material, and it might be the most practical EECS class offered because it requires you to learn the concepts and be able to apply them to real-world scenarios in software engineering.
Approach the class with an open mindset; if you enroll in the course expecting it to operate like every other EECS class with regular projects and such, you might be disappointed. However, everything you learn in EECS 481 is still very valuable for your future in the CS industry and is a breath of fresh air with respect to CS curriculum.
Understand that software development is a best-effort process in a field that your education doesn't often teach as best-effort.
Experience is the best teacher; take any opportunity you can to work with a "large" project before you have a job on the line!
Take this class seriously: the concepts you learn will be applicable to future jobs in software engineering or product management. I found myself breathing a sigh of relief after every lecture because I walked away knowing something I was too scared to ask colleagues about during internships.
Take every lecture of this course seriously because it will prepare you for industry better than any other EECS course.
I believe the class has done a great job explaining how programming is done in the real world. As a student I initially thought software engineering would be more about writing code but instead I have learned that it is more about reviewing code.
I started work as a PM at Microsoft in October ... Your requirements elicitation lecture is proving quite helpful at work!
Many of the lessons involved are applicable to real world coding beyond school.
This class is unique in that it is more about industry than academia, so take this chance to absorb some context surrounding the job that you will likely find yourself in after school.
This is a great class. The homeworks are released in the first week and you should do them as soon as you can (plays boss music: HW 6). It will make you feel better as you can go to class and actually appreciate what is being taught. Most of the readings are interesting if you must, just speed read.
This class teaches you about everything the other classes in CS don't really teach you about.
This class is as close to real-life development as you're going to get in college — if you want to be prepared, take it seriously.
Although this class doesn't involve much programming, Wes asks you to think and write critically, which I think are some of the most useful skills you can have.
Get ready for a lot of reading.
In order to get as much out of this course as possible, be prepared to do the readings for the course. Given you do the readings, this course is around or slightly above EECS 280 level workload.
Be very careful with time management; course starts "easy", and it's very easy to become too comfortable and eventually realize you put something off too long.
Have fun with this class. It's pretty stress free and all of the homeworks are very open ended which allows for a lot of creativity. You get as much out of the class as you put in, so just go for it. Also, do your readings!!!
Don't underestimate the workload; it is a very different flavor of workload than other EECS classes at umich and may not be as easily tackled as you expect.
The amount of work required for each homework can vary greatly, so start early on all of them.
Make sure you estimate your time correctly and start on the HW/readings early!
The course isn't that hard, you will get more out of it by doing more than the bare minimum.
In order to succeed in this class, you will have to actively apply the concepts you learn in lecture to the projects and properly plan your course of action when tackling how to debug extremely large codebases in a timely manner.
Do as many of the readings as possible while also attending each lecture; all of your learning will come from what the professor has to say and how well you attack each project/homework assignment.
This class really emphasizes learning the material rather than getting the right answer; for many of the open-ended problems if you demonstrate that you've learned from the experience but perhaps not give a "correct" answer, they will be happy.
Put in the effort to understand what you're learning in this class and why, don't just memorize it.
In order to take away any meaningful lessons from the class, you must be willing to engage — do the readings, ask questions on Piazza and in lecture, and understand that not all important EECS lessons revolve around lines of code.
This is not a coding course, but it will feel less "school-like" than any other course you've taken so far, so try to actually understand the course concepts.
Do the readings (and don't just skim them or read the abstracts)! I didn't realize how important they would be for the information they provide is almost mandatory for answering the test questions. I saw measurable, and significant improvement on them once I started doing the readings in the second half of the class.
My advice for this course as a whole is very simple: do the readings and do them thoroughly, go to class always, and start studying for the exams early. If you have trouble with the class or with an assignment, go get help early.
Use the course staff as a resource! This class provides you with the knowledge to sit through that first meeting and have an idea about what all that tech jargon means. Coincidently, last summer I kept a list of all of the vocabulary words that were used in meetings that I did not understand. The first word on my list: triage. On the first day of class, one of the first things Professor Weimer asked was: how many of you know what triaging is? The real-world can be scary, and it's important to take advantage of this class and the course staff by not being afraid to reach out and ask those questions that you may think are "dumb". (I believe this class should be mandatory because it prepares you for industry more than the required professionalism course: EECS 496).
Plan ahead and be prepared, like real life things in this class things don't always go as expected and planned and you want to be able to adapt quickly.
Start HW6 early! Like beginning of the semester early! You'll get much more out of it and it's a great talking point for interviews.
Come in with an open mind about what software engineering really means!
My main piece of advice for future students would be to make sure you consistently look at the class holistically. It's easy to lose track focusing on individual topics, and not realize how they all interact with each other.
Do the required readings, they are very helpful for understanding the course material.
There is nothing that can really prepare a student for this course. The closest thing for me was Rome300 as we had extensive reading assignments. What is needed for the class is an open mind and a strong work ethic.
Do the readings! D O T H E R E A D I N G S. Not skim, fully read.
Going to the lecture for this class is more important than in any other EECS class I've ever taken.
The instructor is full of experience in academia, the corporate world, and basically any spot of land that CS hits and although his lectures are already full of very useful insights and anecdotes, you can get more out of him by asking questions because that's where some of the best class discussion comes from. Ask more questions.
Read and go to lecture, seriously, you can spend so much less time working out of class if you just absorb everything that you can during lecture, plus the lectures for this class always finds a way to be entertaining.
Go to lecture, it's actually the best.
Go to lecture even if you don't think you'll pay attention; I was surprised by how much I absorbed even from semi-conscious presence.
Go to lecture and pay attention — the content is interesting, and it makes studying for the exams SO much easier!
Hearing the instructor talk about his experiences and tangentially related topics (things you can't get from the slides) for 3 hours a week is what I ultimately learned the most from when I think about my 481 experience.
Go to class no matter what. I found the topics in this class to be the most relevant to the work experience. Also found these topics to be the most interesting in all of my CS classes.
Don't bring your laptop to class (unless specifically instructed to do so); be present and ask many questions.
I would also attend lecture, and make sure to ask many questions during class.
Go to office hours or ask questions in piazza more often you normally would because this class has a lot of assignments and questions that are relatively more open-ended compared to most of the other EECS classes, and also because I'd say the instructors are pretty helpful with your questions and problems.
Make sure you actually read the assigned readings, they often help in understanding the lecture content.
I know it's hard, but try not to use your computer during lecture: I learned the most in lectures where I did not.
Even if you’ve never gone to a single class before because pretty much all lectures are recorded here, go to this one, because they are actually exciting and interesting.
In order to succeed in other aspects of the class separate from projects, do the assigned readings before every lecture and take notes as this is an excellent supplement to the lecture material and will make it easier for you to study for and succeed on the exam.
Make sure you complete the readings thoroughly and spend time studying them, because unlike any other EECS classes, you will be held to a very high standard of reading comprehension and the reading quizzes will be difficult.
Skimming the reading assignments is not sufficient for the reading quizzes, and they contain a lot of useful information for the exam.
Do a few of the optional readings and know them super well because they're easy extra credit points on the exam!
You can possibly save a lot of time studying if you constantly review the slides and take notes on the readings on your notebook.
Know that the exams aren't like other classes, in that they are more conceptual and require you to think in a broader context, which is honestly how most exams should be.
Paying attention and being engaged in class is the best way to prepare for the exam.
Start studying early for the exams, there is nothing you can put on your cheatsheet that will help you if you don't have a solid base of knowledge of the subjects taught in the classroom.
The exams in this class will be different than those that you take in most other EECS classes. Study with a group of three to four other people and talk about the big ideas behind each lecture. Try and create a latticework of concepts: understand how they all connect and interact with each other, and you'll do well.
It's really helpful to highlight the readings / take notes as you do them — that way you only ever have to read them fully once and when it's time to study for reading quizzes or look them over before an upcoming exam, you can just re-read the important parts.
Start early. Don't be scared to ask questions. Start early. Don't be scared to talk to professors/TAs/etc, they are literally there to help you. Start early.
Be sure to explain your reasoning and thought process in your reports — instructors are looking to see that you've understood and implemented course concepts!
I would find a good partner right from the get go.
Being comfortable with Linux and having a Linux partition on your computer is very helpful in this class, it makes installing and running the required tools far easier.
Often, the setup process is the hardest part of the projects so attend the discussion sections because they are super helpful for walking through how to get a project setup.
Since all the homework is more or less posted at the beginning of the course do it all immediately before your other classes ramp up.
Reading and understanding the source code is going to be one of, if not the hardest and time consuming parts of this project, so plan ahead and get familiar with source code as early as you can.
Be prepared to face a lot of frustration with stuff not working right
Start homework early to make sure you can get the tools to build/compile.
Don’t just do the homework to complete them, try to understand and learn from them.
Start early, you'll run into more bugs than you’d like since this isn’t your own codebase!
Most of the details for all assignments are posted on the course website at the beginning of the semester — start the assignments early and prevent the unnecessary stress of falling behind.
Really choose the project for HW6 carefully — choose a project that interests you, has an active community, and is friendly to developers of your skill level.
Take HW6 very seriously and start early; you will have the opportunity to learn a lot just from searching through open source projects, seeing the volume of issues, and examining how contributors interact with one another and key developers.
For HW6 try to find an open-source project that interests you rather than picking an "easy" project.
Rather than searching for a project in a language you are familiar with or an "easy" project to contribute to, search for a project with dedicated members that will actively chat with and mentor you no matter how small the issue.
I'm sure there are enough people suggesting you should really do the readings, so I'll go ahead and suggest that choosing the project you wish to contribute to for homework 6 is more important than you may initially assume; our project was great on the surface level, but when we inspected the underlying structure modifications became increasingly difficult and our report suffered from it.
Start Homework 6 as early as possible, read the spec very carefully, decide which project to contribute to early, and if you are unsure about anything, ask.
You can almost never spend too much time on RE and effort estimation as there will always be things that force you to deviate from your initial time plan.
Spend some time in part 6a attempting to do something of an implementation that way you don't commit to a project that is far outside of your abilities.
Start early and plan well. Choosing a reasonable task is extremely important for this assignment — don't bite off more than you can chew!
Definitely take advantage of Homework 6 and find a project that you know you can meaningfully contribute to based on your current skill set. All of the major themes of the course are evident through the final project.
Start early and pick something that can fit better into your report.
Don't be afraid to invest a lot of time to finding a open-source project that you are really interested in because in this project, you mostly get what you put into it.
Planning is the most important part of the software engineering process because it effectively concentrates a team's efforts by breaking down problems such that a team can construct a robust system.
Make sure you understand the complexity and level of scale of the open source project you are getting yourself involved with before you commit to it.
Choose an active project so that you can get help quickly and actually have a chance at getting your pull request accepted.
Because it is so difficult to correctly estimate how long a task will take, give yourself more time than you initially think is required so you can adjust accordingly.
For homework 6, be sure to plan for more time than you initially think because issues will come up.
Go above and beyond merely "meeting the requirements": find a project that you'd enjoy contributing to, give it your best effort, and see what you are truly capable of.
Don't be afraid to ask questions on github for HW6, even if your question is something like where certain code is located.
Remember that effort estimation is difficult, so you should account for certain portions of projects to take longer than expect so you can avoid last-second submissions.
Based on my experience with this homework, I would highly recommend that future students communicate with other collaborators/ owners to see if this was something that they could reasonably do within two weeks. Also, don’t be afraid to ask for help to get the program to run. That turned out to be my single biggest problem for this assignment. I feel like I could have done so much more if I got my selected program to actually work as intended within the first few days of the two weeks. Also, on a final note, try to pick an issue that involves a bug rather that implementing a feature. Most of the material we covered in lecture as well as home works involved finding bugs via manual and automated testing.
I would recommend that future students spend more time understanding the source code for the project they select for Homework 6 in the first part of the assignment. This will allow them to spend more time implementing their contributions to the open source project.
Before creating your timeline of work/deliverables, evaluate all your other external obligations (work, other classes, family events, etc.), otherwise you may be in deep when the deadline approaches, especially if you underestimate the amount of time something will take (this was more likely than I thought when dealing with concepts I had not experienced before e.g. mutation testing, delta debugging, git submissions).
Just because a project is accepting pull requests doesn't mean it is accepting the kind of changes you want to make.
Talk with the development community to see if anyone who has worked on a similar problem could help you out and save you time in reading documentation, project planning, and code design.
Start this project early and don’t be afraid to reach out to other users!
Pick a repository that looks interesting and is easy to run in a debugger.
For Homework 6, don't try to tackle too many issues as it's better to do one thing really well than lots of things moderately well.
My advice for this HW is to go beyond just looking at the issues you choose on Github when completing HW 6a. You should look at the issues and also try to understand where in the code base you will be making changes. This does not mean find the exact line(s), but more along the lines of find out which components are involved and where you might look further when actually trying to solve the issues. You should also reach out to the community before you submit hw 6a to see how helpful they might be.
For GUI projects in Homework 6, it's easy to locate relevant code for changes by looking for static text in the UI.
While working on the projects, think about ways in which you can expand the methods you are learning to other applications, such as your future job.
When contributing to open source projects, quickly comment on the issue that you would like to work on, stating as much (so that someone else doesn’t take it from you)!
I would recommend starting assignment 6 early. The assignment required more than 24 hours for me personally, so I was unable to gain the full experience I would have if I started a week earlier and spent more time working on commit changes.
No matter how carefully you plan your project, your estimates will be wrong, often by a lot; the sooner you accept this truth, the better.
Do not be afraid to ask the community of your project for help!