Mosh is an excellent teacher and we are all blessed to have benefited from his courses. But there is something that happens in the software development process that is not covered in his courses. It’s often overlooked. That is the requirements and design process.
It’s always fun to start coding a new project. But before you start coding, spend a little time planning what you will code. Sure, the requirements may drift, you’ll refactor your concept as much as you refactor your code. But start with a plan. It can be a very short plan, but you do need a plan. Maybe just a short readme file to keep you on track.
Objective - What is the application supposed to do.
Functional Requirements - What are the details of what goes in and comes out of the program. What features are required. A list of features. A list of rules. Whatever it is that will determine if the solution is successful or incomplete. This will look very different for a game than for a business app.
Technical Requirements - If you need to write certain tests or use specific hardware or software. Do you need a certain database? Do you have certain security concerns? Hosting? Consider what objects you might need. What database tables you might need.
Now you are ready to code.
In Mosh’s courses, he spends a lot of time in advance preparing the applications he is going to teach you to build. He thinks about the design and features and what order to present them to us. That makes it look like he just jumps right in and starts coding. But trust me, he’s thought a lot about the design and features in advance. Of course, with more experience this process can go rather quickly.
This is one of the reasons I suggest to everyone to try doing some leetcode.com exercises. Those problems are designed to force you to think about what you are doing before you do it. Like a good chess puzzle, the answer is not that obvious. Knowing the mechanics of programming (language and syntax) is the starting point. Being able to design an application and develop solutions to challenges that arise - that’s the real work of a programmer.
Jerry
5 Likes
Thank you for taking your time to write this Jerry! 
1 Like
I like your posts, these are super beneficial. Thank you.
1 Like
Great post, thanks Jerry! I’m getting to the point now that I need to think more about this to get my own projects off the ground and (scary as it might be) try to do some leetcode.
Leetcode is pretty scary. First, try the beginner’s guide. The beginner’s guide took me 5 hours, but was it worth it? Absolutely yes! My brain got to use its full power. You will be getting pen and paper and writing every step-down, and then you will go research for the parts you need. Although the data structures and algorithms course is not needed to learn, the algorithms are super helpful to learn. 
One thing Jerry taught me is to always break it down before solving the thing. Try your absolute best to solve the problems, it is okay if you can’t solve them, there are a thousand more problems you can “redeem” yourself with. Those failed problems will help you solve the next problem. 
Very exciting to hear your experience there. It’s definitely a challenge to solve these problems. But very rewarding as well. Glad to hear you are inspired.
Jerry
1 Like
What do you mean by ‘list of rules’?
I’ve used your post to create a template planning sheet for myself and your post was a good starting point.
Let’s say you wanted to build a mortgage calculator. It would have a set of specifications covering what type of data you need to read, what type of forms and reports you need to display. In my mind, features is about what it needs to do. A list of rules is basically the restrictions you need to check and/or enforce. Perhaps a set of rules covering data encryption policy, password policy, or whatever else.
It is very important that you think about hackers, employee theft of information, or whatever else. These can be really crazy. For example, I wrote a time clock application for the airline. I added a rule that if anyone changes the time on the server by more than 1 hour, an alert would be sent to some people. It turns out that I caught a major fraud violation because a supervisor was moving the clock forward and back and adding punch-in and punch-out records, then splitting the money with the staff members he was punching in.
Rules can cover other things such as governing where updates must be recorded or duplicated. Like in banking, you might want to send a transaction to three places.
Features are benefits. Rules are restrictions. Simply put.
1 Like