We wrote the code with a pencil, on coding sheets. The team leader checked it, and once it was deemed OK, we could type it in on a terminal.
It was a horrible language. The article speaks of code that "reads like a novel"; I swear I never read COBOL code that was easy to read. The problem was that COBOL doesn't lend itself to expressing structure. Combined with the fact that we were under commercial pressure to ship code, we shipped a lot of spaghetti code.
The idea that COBOL code is "easy to maintain" is nonsense. Any non-trivial COBOL program that is easy to read and maintain is going to be harder to write than an equivalent program in (say) Pascal, PL1 or ALGOL.
I worked for Burroughs; one of the super-powers of the Burroughs systems was hardware BCD arithmetic. It allowed a COBOL programmer to declare numeric variables with any specified number of decimal digits, and perform arithmetic on them with exact precision, easily. This is necessary when handling currencies, for example. Also, a hex dump of a BCD variable is precisely it's decimal value - BCD made it easy to debug.
It is said that COBOL is unsuited to systems programming. This is true; but it's not impossible. I was lucky enough to be sent on an "advanced COBOL course", in which I learned that the Burroughs COBOL compiler had seven passes; and that you could stop it during the later passes, and edit the intermediate code, before resuming the remaining passes. This meant that you could do things like access registers and IO ports. It blew my mind (but I never made use of those learnings!)
For many years, I denied that I had ever learned COBOL, for fear of being marked-down as an old fogey. Now I'm retired, I am an old fogey, and I don't give a tinker's cuss.