The program program is shellcode, so the first thing it does is set itself up with the state it needs. This includes clearing the direction flag, aligning the stack to 16 bytes, and figuring out where it is in memory (the call to 0xca both sticks an address on the stack and avoids some code described below). It then calls into a little subroutine (at 0xa) to read through the PEB → LoaderData → InMemoryOrderModuleList. The first entry is the entry for the main binary, from which it grabs the "FullDllName", does some sort of trivial hash on it, and compares it to a known value (presumably a check to see that it's running in a sane environment?) Then it largely skips the next entry (ntdll.dll) and goes to kernel32.dll, where it looks into the exports table to find what is presumably CreateProcessA (this is done using a similar hashing scheme, so the string is not directly present in the shellcode). There's a "calc.exe" string at the end of the code (perhaps you can spot it) and with that it has enough to pop a calc.

OTOH -e, depending on your shell, is either necessary (e.g. bash), or unnecessary but harmless (e.g. zsh) or insufficient (e.g. dash). If you want to print binary stuff portably, you need to use printf(1).

(Shameless plug: you can use https://github.com/jwilk/printfify to generate printf commands for binary files.)

In this case, base64 encoding is much more efficient:

  /EiD5PDowAAAAEFRQVBSUVZIMdJlSItSYEiLUhhIi1IgSItyUEgPt0pKTTHJSDHArDxhfAIs
  IEHByQ1BAcHi7VJBUUiLUiCLQjxIAdCLgIgAAABIhcB0Z0gB0FCLSBhEi0AgSQHQ41ZI/8lB
  izSISAHWTTHJSDHArEHByQ1BAcE44HXxTANMJAhFOdF12FhEi0AkSQHQZkGLDEhEi0AcSQHQ
  QYsEiEgB0EFYQVheWVpBWEFZQVpIg+wgQVL/4FhBWVpIixLpV////11IugEAAAAAAAAASI2N
  AQEAAEG6MYtvh//Vu/C1olZBuqaVvZ3/1UiDxCg8BnwKgPvgdQW7RxNyb2oAWUGJ2v/VY2Fs
  Yy5leGUA