fixed ordering and other minor changes

5 files changed, 22 insertions, 26 deletions

diff --git a/content/1_Intro/Practicing.mdx b/content/1_Intro/Practicing.mdx
index 806c39c..38c0190 100644
--- a/content/1_Intro/Practicing.mdx
+++ b/content/1_Intro/Practicing.mdx
@@ -29,10 +29,7 @@ My personal opinion is that it is okay to give up early when solving CP problems
 Sometimes I spend as little as 15-20 minutes on a problem before reading the editorial
 or at least glancing at solution code. Other times I may spend significantly longer.
 
-CP editorials generally aren't the best (with the exception of USACO editorials,
-which are pretty good) so I often spend a lot of time trying to understand the
-solution even after "giving up" and reading the editorial. I think it's good
-enough to implement the code without having the editorial open.
+CP editorials generally aren't the best (with the exception of USACO editorials, which are pretty good) so I often spend a lot of time trying to understand the solution even after "giving up" and reading the editorial. I think it's good enough to implement the code without having the editorial open.
 
 My justification for why I think it's okay to give up so early is as follows:
 
@@ -47,8 +44,7 @@ My justification for why I think it's okay to give up so early is as follows:
   you read the editorial so now you do, then you've learned a lot more.
   - In other words, reading editorials is a _good_ thing, not a bad thing!
 
-Overall, I would just say to "give up" when you feel like giving up, whether that's
-in five hours or in 15 minutes :)
+Overall, I would just say to "give up" when you feel like giving up, whether that's in five hours or in 15 minutes :)
 
 ## Siyong Huang
 
@@ -88,14 +84,18 @@ Read the editorial when you feel like you've stopped making progress; that could
 
 I follow three guidelines (from most important to least important)
 
-1. Having fun, just doing whatever you feel like doing
-2. Spend about the same amount of time that you would be able to during a real contest
-3. Whether you are making progress or not
+1. Having fun, just doing whatever you feel like doing.
+2. Spend about the same amount of time that you would be able to during a real contest.
+3. Whether you are making progress or not.
 
 ## Eric Wei
 
 I think the most important thing regarding practicing is to try to get something out of every problem, whether it's a new algorithm or idea, an implementation trick that can help in the future, or just a bug you hopefully won't mess up in the future. That being said, editorials are more useful once you've been stuck for a while; I think the exploration that happens from being a little stuck is often instructive (and good practice for contests, when it's your only option). But at some point the problem's more frustrating than helpful, and sometime before this is probably the right time to take a hint or read the editorial.
 
+## Michael Cao
+
+Do hard problems, and try to learn something from them. If you read the editorial, think about how you would arrive at the solution if you were to solve it again. Also, it's important to implement every problem you read the editorial of. Most importantly, don't burn yourself out, or you'll just be worse off in the end because your practice isn't efficent.
+
 ## Additional
 
 <Resources>
diff --git a/content/2_Bronze/Ad_Hoc.mdx b/content/2_Bronze/Ad_Hoc.mdx
index 611a714..c7429f6 100644
--- a/content/2_Bronze/Ad_Hoc.mdx
+++ b/content/2_Bronze/Ad_Hoc.mdx
@@ -28,7 +28,7 @@ Any problem that doesn't fall under any well-defined category can be labelled as
 
 These tips are helpful in solving Ad Hoc problems. However, in the end, the best way to get better at Ad Hoc problems (or any type of problem) is to do a lot of them. Try to solve as many practice problems below as you can, and click the solution sketch tab if you can't figure the solution out.
 
-<!-- If anyone disagrees with any of the tips / ideas presented in the blogs below, just let me know and you can remove it if you want. I think they're quite interesting, though I haven't tried it out myself. -->
+<!-- If anyone disagrees with any of the tips / ideas presented in the blogs below, just let me know. I think they're quite interesting, though I haven't tried it out myself. -->
 
 <Resources>
   <Resource source="ZLE" title="The Art of Thinking" url="https://kauntaofficial.github.io/the-art-of-thinking">blog with more tips</Resource>
diff --git a/content/4_Gold/BFS.mdx b/content/4_Gold/BFS.mdx
index deae5d0..ab4ab5f 100644
--- a/content/4_Gold/BFS.mdx
+++ b/content/4_Gold/BFS.mdx
@@ -199,7 +199,8 @@ Don't forget that once Bessie reaches the goal, she will ignore further commands
 
 </Warning>
 
-(Ben - equivalent to existing editorial)
+<!-- (Ben - equivalent to existing editorial) -->
+
 <!-- You can change it, but keep the section on making modifications to graphs before. Maybe replace with a problem w/o a good editorial? -->
 
 
diff --git a/content/4_Gold/DP.mdx b/content/4_Gold/DP.mdx
index fca485f..70db325 100644
--- a/content/4_Gold/DP.mdx
+++ b/content/4_Gold/DP.mdx
@@ -51,22 +51,16 @@ export const problems = {
     ],
 }
 
-**Dynamic Programming** (DP) is an important algorithmic technique in competitive programming that appears at all levels of competition. 
+**Dynamic Programming** (DP) is an important algorithmic technique in Competitive Programming from the gold division to competitions like the International Olympiad of Informatics. By breaking down the full task into sub-problems, DP avoids the redundant computations of brute force solutions.
 
-<IncompleteSection>
+Although it is not too difficult to grasp the general ideas behind DP, the technique can be used in a diverse range of problems and is a must-know idea for competitors in the USACO gold division.
 
-What do you mean by "all levels"? Certainly doesn't appear in silver ...
+<IncompleteSection>
 
 </IncompleteSection>
 
-By breaking down the full task into sub-problems, DP avoids the redundant computations of brute force solutions.
-
-Although it is not too difficult to grasp the general ideas behind DP, the technique can be used in a diverse range of problems and is a must-know idea for competitors in the USACO gold division.
-
 ## Introductory Resources
 
-Let's begin by reading some resources covering the basics of Dynamic Programming and introducing classical problems, or Dynamic Programming problems which are well known. <Asterisk> However, classical doesn't necessarily mean common. Since so many competitors know about these problems, problemsetters rarely set direct applications of them. </Asterisk>
-
 <Resources>
   <Resource source="CPH" title="7 - DP" starred>Great introduction that covers most classical problems. Mentions memoization.</Resource>
   <Resource source="TC" title="DP from Novice to Advanced" url="dynamic-programming-from-novice-to-advanced">great for all skill levels</Resource>
@@ -75,8 +69,6 @@ Let's begin by reading some resources covering the basics of Dynamic Programming
   <Resource source="PAPS" title="9 - DP">starts with DAGs, which are covered in "Topological Sort"</Resource>
 </Resources>
 
-Practice makes perfect. Start by doing some problems. Each topic starts with direct applications of the classical problems, and then some interesting variations and USACO problems which utilize the ideas. Solutions for most problems (excluding USACO) can be found on Chapter 7 of CPH.
-
 <Info title="Pro Tip">
 
 Sometimes it's a good idea to write a slower polynomial-time solution and then optimize it to the desired complexity (say, write $O(N^2)$ first and then speed it up to $O(N)$).
@@ -89,19 +81,23 @@ These are easier USACO problems which use DP, and don't require many optimizatio
 
 <Problems problems={problems.usacoEasy} />
 
-## Knapsack
+## Classical Problems
+
+Get familiar with some classical problems, or Dynamic Programming problems which are well known. <Asterisk> However, classical doesn't necessarily mean common. Since so many competitors know about these problems, problemsetters rarely set direct applications of them. </Asterisk> Solutions for most of these problems can be found in Chapter 7 of CPH.
+
+### Knapsack
 
 Common variations on Knapsack, followed by more challenging problems which feature variations on the state and additional algorithms.
 
 <Problems problems={problems.knapsack} />
 
-## Paths in a Grid (and related)
+### Paths in a Grid (and related)
 
 Interesting applications of "number of paths on a grid," some of which don't directly present a grid in the problem, but can be modelled as one. <Asterisk> Such as Longest Common Subsequence. </Asterisk> 
 
 <Problems problems={problems.pathsGrid} />
 
-## Longest Increasing Subsequence
+### Longest Increasing Subsequence
 
 Some of the problems in this section don't initially look like Longest Increasing Subsequence, but it ends up being the solution. <Asterisk> This can happen a lot, which is why it's a good idea to not focus on one topic unless you have a full solution</Asterisk>
 
diff --git a/content/ordering.ts b/content/ordering.ts
index 8127c31..4a4732b 100644
--- a/content/ordering.ts
+++ b/content/ordering.ts
@@ -78,7 +78,6 @@ const MODULE_ORDERING: {[key in SectionID]: Chapter[]} = {
       name: "Complete Search",
       items: [
         "complete-search",
-        "gen-perm",
       ]
     },
     {