This course prepares you for software engineering in the real world, whether as part of a job as a software engineer or as part of writing software in other contexts.
Block time in your calendar to attend the lectures every week, and do the in-lecture exercises to the best of your ability. Once a lecture is over, how comfortable you were with the in-lecture exercises should tell you how much time you need to spend on the remaining exercises. If a concept is still not clear, read the lecture notes.
The goal of exercises, both those during the lecture and those afterward, is to let you know how well you're mastering the concepts. The exercises also prepare you for the exams, which look and feel like an exercise set. Do not leave the exercises for the day before the exam, as you will need to spend more time studying, will remember less material, and it will be too late to practice concepts you're unfamiliar with.
Spend some time at the beginning of the course setting up your tools and trying out their full potential. For instance, you do not want to waste exam time setting up a compiler. You also do not want to spend time manually renaming variables when your IDE could do it for you. This also means double-checking that you do not have pending updates, that your laptop is charged, and so on before an exam. Investing time in your tools pays huge dividends.
Exams are open book, but you should not expect to have time to look up everything. Learn to identify the key parts in an assignment and complete as much as possible in the allotted time, rather than to come up with a "perfect" solution you do not have time to implement. This skill is crucial in the real world as well.
The hard, and interesting, parts about software engineering are related to solving problems. You have to balance competing interests to strike useful trade-offs, such as between reliability, performance, and development cost.
You must get used to the low-level details of software engineering, so that you can focus and think clearly about the hard parts. For instance, if you need to test a module, you want to spend your time thinking about what automated tests to write, not how to write these tests.
The only way to get used to low-level tasks is to practice. It's similar to learning a human language: after a while, you no longer need to explicitly think about conjugation or grammar, and you can start having interesting conversations thanks to the brain power that is freed up from performing low-level tasks.
This is what the exercises in this class are for. Each lecture is accompanied by an exercise set along with ideas on how to apply the course concepts in your own project. In particular, if after doing all of the exercises you still do not feel confident applying the concepts, you should try some of the suggested ideas on your own project, even if it is merely a project from another course.
In a real-world project, there is usually little guidance: you are given customer requirements, but are not told how to implement them. In addition, you often have to reuse code that only comes with vague documentation, and you have to learn how to use new frameworks and programming languages on your own.
While doing this, you need to go through documentation, tutorials, videos, and blog posts to learn "just enough" to get your job done. It is impractical to have a deep understanding of everything you use, even if you would like to. Furthermore, you need to collaborate with other software engineers, each with different strengths and weaknesses. Working in a team in a large project is a challenge.
There are many resources online that can help you overcome bugs or problems. Use them! Your favorite search engine can help you find solutions whenever your own thinking is not enough. Good software engineers reuse everything they can reuse, and only spend time inventing the things they cannot get "off the shelf". Spending days or months reinventing the wheel in order to solve a problem unrelated to the task at hand instead of reusing code is demotivating and inefficient.
In the course, in addition to public websites such as StackOverflow, you can ask for help on the course forum. While the course forum is more specific than other websites, the process of writing a question is similar.
To maximize the odds of getting a useful answer, you should help others help you using the following structure for your message:
- Summarize the context. What is your overall goal? Which versions of the relevant tools and libraries are you using?
- Summarize the problem. Are you encountering a specific error? Is there a specific task you need to do?
- Explain what you have tried already. Are there some common answers to similar problems that do not seem to work in your case? Did you try deleting caches, restarting programs, and so on?