Yes; a monthly payment version is available at the checkout page.

1. Can you help me convince my employer to cover the course?

Of course! Around half of our past students have had the course reimbursed in full or in part. You can use this letter template to help convince your manager. Please reach out to [email protected] if you'd like advice or strategy beyond that convincing someone. In particular, if you're from a very large company, we can likely put you in touch with someone else at the company who has successfully had it reimbursed.

2. Will I be able to deduct the course from my taxes?

While we are not authorized to give tax advice, we can share that students in a few countries such as Germany have deducted the course from their taxes as professional-education expenses. Please contact us at [email protected] if you need extra documentation to claim the deduction. Always consult a tax professional before making any tax decisions.

3.  What is your tax ID?

Our tax ID is: 81-5159508

Yes! If you buy the full course and are not happy, we have a 14-day refund policy. Just shoot us an email at [email protected] . The only exception: if you purchase personalized feedback and submit exercises for feedback, then we will retain a portion of your payment proportional to the amount of work already done preparing your feedback.

Yes, these are available on request.  E-mail [email protected] with your answers to all homeworks, and we'll create your certificate.

Each unit has between 6-10 videos (plus video answers to all exercises).
4-8 readings and 2-4 exercises. 

Generally, if you have hit the point where you more frequently struggle with how to structure code than how to get something working, you are likely to benefit from this course. If you don't have ample experience working in large codebases, then you can still get amazing results, but you may have to work harder to understanding everything, or treat this material as something you keep coming back to. We actually used to turn away very junior engineers. Then we made a few exceptions, made sure they had the right expectations, and saw amazing outcomes.

Many parts of the course are very applicable to small or one-off programs. Certain aspects of code quality are important even in the smallest programs. For instance, a common trap when writing such programs is to write something very messy that works for the first batch of input, and then minutes later struggle to extend it to work on new cases seen in the next batch of input. The principles in this course will help you improve your code's robustness and readability in ways that will improve your quality of life even in the smallest projects.

We’re very strong believers in giving personalized feedback, as one of the best ways to learn. Many of the exercises are very open-ended, especially the design exercises, which have you sketching the design of an entire piece of software. For all of our exercises, we read your solution carefully, understand exactly how you are thinking about the problem, and tell you exactly what you need to improve your understanding and walk away with a strong grasp of the concept.

We also work very hard to make our feedback of the highest quality. We have a 20-page document on how to give better feedback, and Jimmy personally reviews every feedback for quality. Most feedbacks go through several revisions before being declared good enough for students. At time of writing, Nils and Jimmy are doing all the feedback themselves.

We've worked very hard to make the experience without personal feedback as good as possible. If we could help students without personal feedback learn as fast as those with, we'd tell you that — it's less work for us. In spite of that, nothing beats personal feedback.

There is a human tendency to think we understand a topic more than we do after listening to lectures. This is the illusion of explanatory depth. Even after attempting the exercises, you may still carry around several misunderstandings. Upon seeing a list of 10 common mistakes, it is only natural to interpret those mistakes through your current understanding and not realize when your answer is a mistake. Having an instructor say "If you look it your solution this way, it's an instance of mistake #3" cuts through all that.

Beyond that, some of the exercises are very open-ended, and, even after several hundred students, we still regularly see new answers unlike any previous submission. Also, some of the questions ask you to come up with your own example of a phenomenon, meaning that every answer is novel. For these questions, we provide lots of both valid and invalid examples, but nothing beats having an expert show you how to analyze your example through whatever lens we are trying to teach in that exercise.

Finally, in general, recognizing when code is bad takes a trained perception. This is not an intro programming class where you can run your code and see if it works. Bad code causes immediate problems of code being difficult to understand and fragile, and longer term problems of code being bloated and difficult to change. We aim to teach you how to look at code and instantly see these consequences as crisply as you've learned to recognize code with a syntax error. Until you get that perception yourself, it's helpful to have a trained eye coaching you.

The Advanced Software Design community is a place where talented engineers from all over the globe share ideas. On any given day, you'll find discussions buzzing about anything from how to convince a team to adopt better testing practices to when it's a good idea to use short variable names that take a lot of context to understand. You can bring in problems from work, find new job opportunities or recruit talented engineers, and get a global perspective on industry trends. On the whole, some alumni have called the community "a gift that keeps on giving."