Makefile for make is really useful when you build a program from several translation units (i.e. several
*.cc files which are
#include-ing some other header files) which are linked together (it is not very useful for a single source file tiny program). It organizes the various compilation steps of the translation units (and avoid running useless compilations again). See also this answer to a related question.
During the debugging phase, compile with all warnings and debug info (e.g.
gcc -Wall -Wextra -g for C code compiled by GCC...) and learn how to use your debugger, e.g. GDB and memory leak detectors like valgrind.... Be scared of undefined behavior. With a recent GCC 5 compiler (at end of 2015), you may also want to use (occasionally) various
-fsanitize= debugging options. Have some good testing procedures. For production and benchmarking, ask for compiler optimizations (e.g. add
-march=native -O2 to your GCC compiler flags). For C++11 code, replace
g++ -std=c++11; in your GNU
CFLAGS variables for C and
CXXFLAGS for C++.
As soon as you are writing some not-tiny program in C or C++ (e.g. more than ten thousand lines of source code), you'll want to organize it in several translation units (at least to avoiding very long build times while working on it, and preferably to group together related code or features). Notice that with C++ the usual included header files are themselves quite big, so having tiny translation units slows the overall build process.
The size, organization, name, and purpose of a translation unit (i.e. of a
bar.cc file) is a matter of habits and conventional. Some people prefer having many tiny files (of a few dozen lines). I like having source files of several thousand lines. The recent version of GCC compiler, and the recent Linux kernel have dozens of human-written C or C++ source files bigger than ten thousand lines. Both are quite large software (many millions of source lines)
Then, you could build such a program using some other builder (like omake or scons, etc...), or even using a shell script (BTW, the GNU make distribution contains a shell script to build it on systems without any
But yes, I believe you should learn GNU make (and you may even want to take advantage of recent GNU make features, e.g. Guile scriptability). Here is an example of
Makefile, and another one.
Notice that for historical reasons the tab character is significant for
make, so you need a specific mode in your editor.
In many cases, e.g. for configuration reasons, the
Makefile is generated (e.g. with autoconf or cmake).
You should look into the source code of several free software programs (e.g. GNU make itself! See also sourceforge, github, etc... to find some) and try building them. That would teach you a lot.
So you don't need
make (or some other builder) yet, just because your programs are very tiny. As soon as they will grow, you'll need some building process. Notice that large programs (a web browser, an optimizing compiler, an OS kernel) have often many millions lines of source code organized in at least hundreds of translation units, and often have some generated C/C++ code (by some script in awk, python, guile, etc..., or a specialized program itself coded in C++, or an external generator like ANTLR or gperf) for application-specific metaprogramming or aspect-oriented programming purposes.
PS. Some other programming languages (Ocaml, Haskell, Go, SML, ...) know about modules and have very different builders.