jlc
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.
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.
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.
The Soul of a New Machine by Tracy Kidder
A Supposedly Fun Thing I'll Never Do Again by D.F. Wallace
Speak, Memory by Vladimir Nabokov
Anything by John McPhee
Edit: formatting
I hope I'm missing something, but I don't seem to be able to find it in its entirety, and its DVD is also sold out.
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.
Good luck!
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.
Good luck.
EDIT: formatting
It has been around a long while now, is in use around the world, and should at least make a good starting point for further customization.
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.
I'd say give it a go.
I'd say take a look at some of the code in the standard library and in some other packages you've used before, then read this:
http://jcalderone.livejournal.com/39794.html
Then just go for it.
Even my beloved Commodore 64 is long gone, but I haven't been able to part with the Amiga. Not saying this is a good thing. Just saying.
http://www.amazon.com/UNIX-System-Administration-Handbook-3r...
EDIT: FWIW, I think most bike paths are a travesty. You're better off out in the traffic where people can at least see you. Make them choose to run you over.