In large companies I've worked for
It's currently just me and two minions. And we have to do Perl, JavaScript, TypeScript, HTML, Template-Toolkit, C/XS (only me), bash scripts and some other stuff. I'm understaffed, overworked and i absolutely love it. We move fast, solve "impossible" problems every week, and the product is becoming sleeker, faster and more capable before our very eyes.
Tackling a big development project with a tiny team on a tiny budget (and less pay) seems daunting, especially for people from that magic silicon valley place on the other side of the pond. But we have no bureaucracy to speak of, except a coding style guide, a weekly meeting and a simple prioritized todo list. If we need to change something currently in development, we just talk to each other for a couple of minutes and have a working prototype by the end of the week.
I've worked in big companies before. Yes, you have way more resources at your disposal, you have a bigger team to pull ideas from. But it usually takes ages to get anything decided. And it takes ages to get the request to buy a required hardware approved and even longer for the relevant department to decide on the seller with the best price.
I like working for small companies a lot more. If we decide to change (=improve) some graphical element over coffee, i can just open Gimp and have the fix ready on our test/demo server in a couple of minutes. If i need another(¹) thermal printer, i can go to the next office, get quick approval from the boss and have our company secretary buy it online with next-business-day delivery.
What is the company's succession plan if you decide to leave for greener pastures?
I train my coworkers to the best of my abilities. The code is as maintainable as i'm able to design it. I have strict code guidelines that make it somewhat easy for developers used to other languages to understand my Perl code. Everything i do is maintained in source code repos, including and and all database design changes. There is (basic) documentation. There are at least two people with admin permissions on every of our systems.
Generally, I'm a fan of chromatic's emphasis on maintainability over "readability"
Yes. But at least in my personal experience, many people who take over maintenance of software have less experience. In the past, it always helped to keep the language used fairly simple(²). Using an explicit for loop over an array (doing operations step-by-step) is often easier to understand than trying to parse some complex "write-only" map() call. If i have to do something complex and less readable (for example, for performance reasons), i always provide an explanation in the comments, in some cases even accompanied by a commented out step-by-step "easy code" example.
(¹) I'm the printing specialist, too, writing Perl "drivers" for (mostly) point-of-sales invoice printers. My desk currently sports 3 desktop thermal printers, a bluetooth thermal printer and an A4 laserprinter. Oh, and a point-of-sales terminal with integrated thermal printer. (At home, i also have an old industrial thermo-transfer label printer as well as an USB P-Touch printer i've written code for). So if you ever need something printed, i probably have the required equipment within arms length.
(²) Think Randall Munroe's "Thing Explainer"