There were two models available. One model's units all looked cleaner than those of the other, so I picked up one of those.
I bought a cable (RS-232?) and plugged it in. It worked great for command line stuff, but pine (the email client) and pico looked off, with some parts of the screen being drawn over others. I knew nothing about termcap/terminfo. This was before Google (and even before Altavista). I spent hours trying different things (perhaps I got some pointers from helpful folks on a newsgroup?) and managed to improve the situation, but it never worked flawlessly.
Looking back, what I was doing was a lot of random stuff without much understanding. I will probably never know whether what I was trying to do was impossible, or whether I failed just because I didn't know what I was doing and had no systematic approach to editing the termcap file.
With multiplatform, CI/CD, cloud, Docker, etc. I spend way more of my time in a terminal than I used to.
Terminfo is basically for smoothing over differences with terminal behaviors that aren't commonly used anymore. It only tells you there's a difference in capability. You still have to implement code to handle them which will never be invoked by anyone but a retro enthusiast plugging in obscure 70's hardware.
I generally have four or five xterms in use on my average Desktop.
A curses-based text interface is a good substitute for some graphical programs where an addressable cursor is required. It's certainly faster and more light-weight.
Programming for text-based programs also should involve the use of various options given in the terminfo, but most of us are lazy and only cater for one or two main cases. (Hiding behind curses/ncurses as those libraries do the thinking for us.)
Stepping through 40 years of organic development by a bunch of different groups whose decisions were based on the limitations of the time is just not gonna happen. But if you don't trying to understand where we ended up will drive you mad. You just pick some closed subset of behaviors / features that exist where your programs run and hope.
Don't give this stuff any more reverence than it deserves (which is none). Bob Barton  once said "Systems programmers are high priests of a low art."
You don't need to know all the incremental changes, unless the allure of becoming a historian and being able to recount all the developments in the space appeals to you. (Those who do not learn from history are condemned to repeat it.)
There is no mystery except the one you make for yourself.
Read books. https://man7.org/tlpi/ is a good place to start. Good luck!
There is also humility in just accepting that my curiosity is greater than my capacity and I'll never know much of anything about anything. I can pick a few things to go deep in but so far it hasn't needed to be terminals and that's not a moral failing.
CLI apps are probably the easiest applications that accept user input to make. Compared to GUI or web apps the amount of knowledge you need is almost trivial.
But they're all falsehoods that break down eventually and require an elder or time spent with the sacred texts to achieve enlightenment. Repeat the cycle and you get a senior dev in <something: webdev> whose skills are only kinda transferrable to <other thing: CLIs> and you must start your journey over again.
So you have arch mages in webdev who are a acolytes in systems and the only way they'll progress to is write a lot of bad code. I'll get there eventually but how long it takes is dependent on how many opportunities I get to cut my teeth on stuff that requires a more complete understanding.
It's safe to say that front-end development is now more complex than JEE...
I've only read the second cover to cover. Not as much there as you might think, the bulk was laid out in the 70s and 80s when most of an OS could fit in one person's brain.
Not much has been added since, basically extended color and a dozen or so sequences for hypertext links, etc.
I recommend these books. You could use a well-maintained terminal library or two in the meantime.
Every time I also think of just making a wrapper for it, but I never do.
I don't know anything about terraform, but I've written some applications where I intentionally don't automatically change the output (which in my case is usually bold text, I don't use colours much) because I expect no one will ever use the output for scripting . That's not "poor programming", it's a choice because there is no perfect solution that fits 100% of the cases.
I suspect that may probably be the best choice for terraform as well, but I never used it.
Imagine grep not working because in between the words that you are searching there is an escape code.
They are doing just fine. You can't expect them to learn 50 years of technical complexity in a few days and why there are so many different shells and how they behave differently.
edit: replaced debt by complexity
You don't really need to know anything about shells to write a CLI app, other than basic shell conventions (- for flags, things like that). You don't even need to know all that much about terminals, just some bare basics if you want to do colours or whatnot. All of this can be summarized in a page or two.
If you want to write a ncurses-like library: that's a different story. But then it's no longer a CLI app.
you can't just take the word "debt" to mean bad, then just throw it around for things you don't like, especially applied to things that take effort to learn, effort you have not and don't want to expend.
This works identically in all the shells (and even without a shell), and there is no "50 years years of techinical debt" (unless you mean the idea itself of in-band control codes)
print("stdout is a tty")
print("stdout is not a tty")
 There's an ioctl involved, and it can fail for other reasons than "fd is not terminal", however all the reason for the operation to fail are good reasons to not proceed with terminal specific behavior.
if (! try_thing())
if (! try_thing_again())
if (! try_thing_a_third_time())
I’m bookmarking this to come back and read through some of these resources.
If you’re interested in my own process, here are the video’s I recorded as I worked through this.
Part 1 - Building the command
Part 2 - Installing it on a Raspberry Pi
These are SRE type positions where strong systems knowledge and debugging skills are a requirement or at least a big plus.
If you're looking for strong diagnostic skills, then ask those questions geared to give you direct information as opposed to trying to weed it out from the answer to a vague high-level process description question. If the candidate has no idea why you're asking then any answer at all should be satisfactory.
And the open ended question is great because it allows candidate to showcase what they know. Have no idea how PTYs are allocated by kernel? No problem, you can talk how shells work.
Disclosure: I'm not an SRE
Things that do happen with some regularity like disk corruption should probably get focused on first.