And I'll throw in The Little Schemer and Understanding Computation. They come from a different direction than Code/nand2tetris. When I got that they all sort of meet in the middle, I found it mind-blowing.
LOL. I'm going to explain this for myself and then never look at this cursed thread again.
What is important is to clearly communicate the intent of code to the next developer (incl., yourself) who comes across it. Comments are one tool provided to do this. I write comments. I approve pull requests containing comments. But comments are not the only tool, and they're not the best one.
Now most of the time there's no particular difficulty establishing the intent of code. Sometimes, though, there's something weird, something that looks "wrong" but isn't. In those cases, I isolate the weird change using abstractions (at least a variable, but probably a function, a method, a class); I name it and any components well -- long, descriptive, using appropriate conventions; I put automated tests around it, which will fail if anyone changes it without understanding it, providing helpful and explicit error messages (where tools allow); and I write a developed, full explanation in a commit message (which IME will not be too hard to track down, if you've isolated the "weird" change using an abstraction).
That will almost always communicate the the intent. If it doesn't, I (reluctantly) comment it up.
Typically, it isn't digging. It's the last commit, maybe the one before it, and I have tools for doing this (e.g., magit, fugitive).
I don't notify anyone, nor do I need to. When I encounter a WTF moment, I look at the commit messages. When there's nothing there, I curse the last developer.
I guess it can be fun spelunking through commit messages, though, to see when the comment was added and if it still applies.
I love domino games. I used to play a lot of two-hand sniff (or muggins -- lots of variants). For me there's something aesthetically pleasing about games that use generic gaming equipment -- dominoes, cards, pawns, etc.
For what it's worth, I (software engineer, 49) got a better job when I was 47. I got a job that I thought would be better at 46, too. But it turned out I was wrong, so I tried again.
My take, based only on my own experience, so grain of salt and all that: I think a business's status as a "startup," "enterprise," etc. makes a poor proxy for what it's like to work there. The correlation isn't zero, but there are a lot of factors. It's not simple. At any rate, it's really hard to know what working for a company will be like from the outside. It's good to have your shopping list of nice-to-haves, and it's good to ask lots of questions and try to suss a company out. But be flexible.
I've had the best experience finding work through former co-workers, people I'd like to work with again. There's a better chance of getting hired, you will have some inside knowledge of the company (good and bad) from the beginning, and you know there's at least one other person there who cares.
I'd recommend starting your job hunt immediately. Put out feelers with people you know. Look at job descriptions. Send out resumes. Work on any skills that need learning or refreshing. (But don't let perfect be the enemy of the good w/r/t skills.) Worst case: you're already having some conversations with potential employers when the axe falls. Best case: you've got a fresh job with a better salary before the axe falls -- maybe, by leaving, you even save someone else's job.
Been there, almost exactly there, 15 years ago now.
0) If you are having suicidal thoughts, you should get medical attention. Even if you're not "truly" suicidal, depression/anxiety will rob you of the power you need to do things. So first things first.
1) Unless you're into building skyscrapers or bridges or something like that[1], you don't need anyone's permission to build stuff. Do it on your own time. Learn things. Have fun. Use it in the short term to give your life shape and meaning.
2) In the medium term, look for or make opportunities to use what you learn building stuff to make money. E.g., if by stuff you meant software, this could look like a skunkworks productivity booster app at the customer service job or a web app you make for a friend.
3) If you do 1 and 2 long enough; stay flexible, adjusting course as necessary; and don't let fear/complacency keep you from taking some chances now and again, you will eventually find that at some point you became a pro at building stuff (or perhaps at some related, but satisfying niche).
[1] If you're into buildings or bridges or somesuch, obviously you'll also need degrees/credentials, but steps 0-3 will still work.
One advantage of the job that you don't mention is that it might be a learning experience for you along a number of vectors. And one mitigating factor you don't mention is that the term of your employment need not be forever.
And I'll throw in The Little Schemer and Understanding Computation. They come from a different direction than Code/nand2tetris. When I got that they all sort of meet in the middle, I found it mind-blowing.