24: The CLI Projects

You have learned a very "baby" version of C++ that is just enough to start using it to make things. You could theoretically use the C++ you know to create almost anything, but there's many nice (and terrible) features in C++ that you'll want to learn later to boost your power. For now, what you have is good enough to start practicing your programming skills.

Programming is a creative activity much like painting or writing in that the more you do it the better you get at it. Learning syntax and memorizing facts won't teach you this, only actually using what you learn to create software will teach you how to use what you learned to create software. Seems stupid to say, but there's plenty of "programmers" who think programming is only about memorizing facts and learning concepts. There's other "programmers" who think programming is only about hacking out garbage unreadable code without any understanding. What you want to do is both understanding and application. Learn everything you can, then apply what you learn to become better than both of those "programmers."

This section is all about making you create as much working software as possible. There's an idea I learned from from art. "You have 500 terrible paintings inside you." The only way to get better at painting (and almost everything) is to do it until you stop sucking at it. Generally the best way to do that is to create many small projects that have a beginning, middle, and end to the project. This teaches you the two most important things about creating anything:

1. The start is usually the hardest part. Just getting started can seem impossible, and many times you'll sit there staring at the screen feeling dumb because you have no idea what to do first. By forcing yourself to bang out tons of small projects you become better at getting to a first version of your idea. You also start to devise tools and schemes to cut down the time between idea and first bit of code. For example, I typically have little "starter projects" that I clone to get started rather than recreate every project from scratch.
2. The end is also the hardest part. This depends on the person, but there's tons of programmers who don't know how to finalize a project. I use the term "programmer done" where a programmer thinks that their code compiling is enough to claim the code is finished. The reality is compilation is only a minimal first step in the process of creating a finished work. After that you have to refine it, clean it up, possibly rewrite it, create tests, and document it. Even if it's only for you, having documentation is incredibly helpful for future you who doesn't remember anything.

Your goal in this module is to create as many small projects that are as complete as you can make them. I'll be presenting utilities that are available as command line tools in Unix and somewhat in Windows. You are not trying to be original at all. You're only making copies and trying to make them as complete as possible to practice getting started, applying your skills, and finishing a project off.

A Beginner Programming Process

Everyone has a process, even if they claim they don't. Usually if they claim to not have a process they think it makes them smarter or more creative, but it only shows that they lack self-reflection and are unable to think about who they are and how they work. Also, if you just film them working for a few hours you'll see they repeat the same patterns over and over which is a process.

The problem we have is you are a beginner, so you most likely don't have a process. If you did have a process it's most likely not very effective because, well, you're a beginner. You have no idea what you're doing. To solve this problem I'm going to give you a process to follow. It should work to get you through these projects, and if you keep making more you can start to adapt this process and explore what works for you.

The purpose of a process is not to make amazing code every time. A process is more about reducing the probability of failure. You use a process to reduce failure points so that you can focus on more important things. The idea is if you follow the process then your chance of success is higher.

I should also mention that this isn't everyone's process, but generally people have similar ways of working (even if they deny it). This process is simply the one that I've seen work best for beginners who have no idea what to do next.

• Coming soon...need to see what I wrote in other courses.

Usually Don't Do These 10 Things

I mean like 10 or something should be good enough.

Don't think, "How can I follow the rules." Think, "What can I get away with?"

I'm giving you a list of things to avoid, not rules you must follow at all costs. Don't take these to be some set of rules that make you a good or bad programmer. They're only things that I see beginners doing that thwart their ability to learn. As you get more advanced you'll probably break all of these "rules-not-rules," but you'll know why you're breaking them. It's also important that you not try to force other people to do these. Finally, the worst mindset to have is, "I'm going to get in trouble if I break a rule!" That's the creativity killer. The best mindset to have is, "What can I get away with?" Programming is a weird activity because we have a lot of rules enforced by the compiler, but we're also trying to push those rules to make our ideas a reality. Think of it as a game to see how far you can bend the rules and still make it work.

Don't type a ton then run it once.

If you type a ton of code, and compile it once, then you'll have tons of errors. If you do this, don't say, "I'll never be a programmer!!!!" Say, "Oh, I should try that again but type a little at a time." Programming's great because if you make a massive mistake you can simply delete everything and try again. I delete stuff all the time when it's not working. The reason you do this is so the compiler can tell you early why your code is broken. It's easier to fix a few lines of code at a time. It's very difficult to fix 100 lines of absolute trash.

Don't stare at the code hoping to see the answer.

Print, print, print! Sometimes I'll read the code and think about what's going on, but I'm not just reading it. I'm running it in my head and thinking through possible causes. You are probably not at that level so you need to use print debugging (or a debugger) to see what's going on. As you get better you can read the code, but usually it's faster to start debugging and analyzing the code while it's running to figure out what's wrong.

Don't think you have to memorize everything.

A common misunderstanding is that programmers memorize everything before starting a project, then create all of their code without every looking anything up. Bullshit. Not only is this not true at all, but it's an incredibly anti-intellectual belief that people shouldn't research and use references. The foundation of modern humanity is reading, researching, and references. It's definitely not memory because if that were true we'd have only one world war and everyone would remember how terrible that was and never do it again. Humans suck at memory, and that's why we constantly use references. Feel free to look every single thing up, over and over, and as you do you'll start to remember it and won't need to look it up as often.

Don't think that you need the answers before starting.

Similarily, you don't need to have an answer to the problem before touching the keyboard. Programming is a highly interactive activity and no matter how you prepare you'll run into things you didn't anticipate and have to work around. One of the best things about programming is the act of writing code about something also teaches you about that subject. That means if you don't know everything about the topic then creating a piece of software will teach you about it. Do some research, learn what you can, and start writing the code when you have a reasonable understanding. As you code you will run into things you don't understand, at which point you do more research and improve your understanding. This interaction results in a deeper understanding of the problem than if you simply read a bunch of books about it.

Don't think you only have one chance to get it right.

Programmers have a concept called a "spike." A spike is a trash first version that hits all the main unknowns, but isn't feature complete. It's a throw away version that teaches you what you need for the next version. You are totally allowed to do the same, and it might help you get past the start if you keep telling yourself, "This is just a trash experiment." You are also totally allowed to try something, realize it will not work, and throw it away and start again. The best thing about programming is that you can always try again. It's an imperfect and impermanent medium. Embrace it.

Don't think that knowing a lot of facts makes you a good programmer.

There's a class of programmer who think that knowing a lot is the same as being capable. Knowing many facts could make you better, since programming is an intellectual activity that relies on information about the language to work effectively. However, no amount of memorization will write the code. At some point you have to actually type the code in and get it to work, and usually all your fancy book lernin' falls to pieces when faced with the reality of real problems. If you ever doubt this go get any programming textbook and look for, "This is left as an exercise for the reader." That's Professor Speak for, "I have no idea how to do this or explain it," because they've never actually sat down and done it. Usually you see this when they're deleting things from trees.

Don't fall into the trap of excessive studying to avoid creating.

Another trap programmers fall into is studying endlessly to avoid the fear of failure that creativity bring. Creating something is always messy and risky. What you do may not work. It may receive criticism. You may realize you're not nearly as good as you think you are. The way many programmers avoid facing this fear is to memorize a bunch of facts about the language. They'll then claim their memorization is exactly the same as being able to use it. You'll typically find these people living in the "code review system" at companies, writing comments on other people's code but never actually making their own. You'll find them in chat communities pontificating on other people's skill without a single project you can view to confirm their supposed "genius." They'll also sit around, doing nothing, waiting to be discovered for this, "genius." But you'll never see them actually demonstrate this supposed vast trove of knowledge by actually doing anything with it. The way you avoid this trap is to focus on making as many small projects as you can, and being honest with their quality. Just remember to only critique your work after your done, not while you're making it.

Don't have unrealistic expectations of your skill.

If you ever say, "I'll never be a great programmer like Zed!" Then you're right, not with that attitude. It took me decades to get good and I'm still learning. The only way you'll improve is if you focus on competing with yourself. Don't say, "I'll never be as good as that famous programmer who's been programming since the dawn of computing." Ask yourself, "Did I do better on this than last time?" If not then ask, "Ok, what can I do to improve?" You should also be asking, "Did I have fun?" Programming is brutal, so try to have fun with it. That's probably more important than pushing for some weird extreme arbitrary efficiency. Finally, most of the programmers you think are gods are probably not nearly as good as you think they are because programming is difficult. We all kind of suck at it, I just suck at it less than you do.

Don't think you need to be efficient.

Sometimes you'll run into someone who will claim that you need X technology or Y language to really boost your efficiency. The first problem with this attitude is that efficiency comes more from good simple decisions in your programming and less from tools. This is because programming is a long game, and if you're using a tool to bang out mountains of trash then in 6 months you'll be buried extremely efficient trash. If you take your time and learn to craft simple solutions that are maintainable then you'll be more efficient on average over time. The other problem with this is it's a very Corporate Manager attitude. Managers are mostly trained in a style of business that treats programming like factory work. In factory work squeezing 2% efficiency out of the guy who punches rivets in a door can actually boost your revenue. Programming is not a factory job. It's a creative discipline that requires thought and coordination with others. Demanding that people produce quickly in a creative disciplines means they produce mountains of garbage that reduce your revenue. In fact, if management really wanted to boost efficiency they'd do things that improve the inputs to the creative process like...forcing Product Managers to actually describe features with more than a one-liner ticket in Jira.

Finding Documentation

The primary source for documentation is cppreference.com. It has tons of great information about everything you could ever want to know about C and C++. The problem is, it has tons of information about everything you could never need to know about C and C++.

The best way to trim this information down is to look up things as you work through these exercises, and then "follow the rabbit hole." When visit a page like std::vector you can read about std::vector, type in the example, and then click any of the linked pages, study that one, type in the example, and repeat this process for hours.

When you do this, try to come back to your project and incorporate what you learn to help you understand it in the context of your work.

You can also use Google to search for answers, and the AI results (which are probably not AI results at all) will generally give you a good overview with good enough code samples. The trick is to never copy paste the code. Never copy-past any code while you're learning. Always type it in, get it to work, change it, and then break it. This will teach you what the code is doing. Combine this with researching the code's contents on cppreference.com and you'll learn a ton.

You can also ask any of the other AI tools out there but once again do not copy-paste. You should also assume that these AI tools can hallucinate APIs. It's rare these, and people who use them say it's more likely when you "push the AI too hard" but just assume that any AI tool is trying to please you, so it will make things up to keep you happy. Also, keep in mind that I don't actively use AI tools so I may be totally wrong here. Still, in general, I wouldn't blindly trust any code.

Getting Help

If you need help you can email me at help@learncodethehardway.com, but that may take me a while to respond. You can also go to help.learncodethehardway.com and ask a question. I will usually answer those daily, and asking your question there helps other people who might have a similar question. Finally, there is also a chat you can join to chat with other people. I try to be there when I can, so drop in, ask if I'm there and I'll help.

Finally, I stream a few times a day on twitch.tv/zedashaw. I'm usually there at 10PM and some time during the day. You can always stop by there, ask me a question, and then I can usually demonstrate an answer to you on the spot. Be sure to @ZedAShaw so I see it.

Mix it Up

There's two ways you can approach this module:

1. Start at the beginning and do your best on each project.
2. Go back to the projects that interest you and push them as far as you can.
3. Implement many other tools and create some of your own until you feel confident in this style of programming.

You theoretically could do this for many months or even years. You would slowly begin to add new C++ features as you discovered them, learn a ton about systems programming and how to create projects, and gain quite a lot of skill.

For some people this is incredibly boring, so another way to approach Module 2 is:

1. Do about 2-3 projects to understand the process.
2. Start mixing Module 3 exercises into your studies.
3. Do a project from Module 2, then study an exercise in Module 3.
4. Take what you learn from Module 3 and apply it to the project you just did.
5. When you're done you'll have completed both modules and can continue from there.

This process will most likely complete both modules slower, but it'd be less monotonous and most likely more interesting. It'd also be more challenging because you'd probably feel unsure of yourself the entire time, but when you're done you can always go back and redo Module 2 to really test your skills.

Either way you approach it, the point of Module 2 is to get you started in making little command line utilities to build confidence and skill in your C++. Take your time, learn what you can, and if you get bored, mix it up.

Creating a Starter Project

To make things easier you'll want to create a "starter project." This will be a directory that has a single main.cpp and everything you need to compile it. You use this project by copying it to a new directory then changing the files to use the name of your project. You can most likely use one starter for this whole module, but you should practice using your starter and make one whole project for each exercise.

To create a starter project do this:

1. Instructions coming soon...