Any specific reason why $HOME is not good for a git repo in this specific case ? AFAICT, the repo is tracking only what is mentioned in the .gitignore.
As for symlinks, heh, yes I do know they are not silly and actually extremely useful and yes I know how to use them. I simply think they are silly for managing dotfiles. If your intent is to version your dotfiles and have different 'profiles' across your systems, using the tools at hand -- well, in theory you can write a bunch of script to create the symlinks and 'manage' them as well -- but I just find /that/ silly.
erm, firstly, by silly symlinks I meant in the context of managing dotfiles. A lot of exiting tools do that and IMHO, it is silly. Of course in yours it might make perfect sense. Secondly, erm -- git submodules are nasty and dangerous ? ...for managing vim files ? How am I to use pathogen (or all the hipsters to use oh-my-<whatever>)). I didn't say this is what you use on your production servers. This is how I manage my dotfiles on my personal boxes and find it easier to use than any specific purpose tool.
I get into these modes every once in a while, now that I have been a IT guy [1] for 12+ years. Here are a few suggestions that might be worth thinking about. Of course you are not me, so YMMV
a. Get a new hobby. I have realized that having an out-of-work hobby helps your work life immensely. I don't mean a hobby that you'd go to only when bored or on the weekends, nor something 'easy' -- so listening to music, or watching movies or reading a book don't qualify for what I am recommending. It has to have a steep learning curve if you want to get a high enough level of satisfaction from the process that it improves your overall sense of well being. Learning to draw/sketch, learning to play a musical instrument or juggle or scuba dive would qualify.
b. Teach. The easiest way to get into this is get involved in your local User groups and share what you already know. Do it for free. I assure you this too will indirectly have a phenomenal affect on your work life. Also checkout http://software-carpentry.org/contrib/training.html ...which leads me neatly to my next point...
c. Challenge yourself and get involved in a writing software for a completely different domain. I see way too many software engineers limiting themselves to writing code and creating products that are consumed by other software engineers. That gets boring after a while. Write code (or quite your job and join a firm that writes code) for scientific research (think physics, phrama, genetics ...etc) or for automotive companies or for hospitals ...basically move out of the domain where software is the central/critical component (eg: web or software solution providers ...you know what I mean ?)
d. Just take a break. I don't mean a long sabbatical. Just a break. You don't even need to do something special with your break, ie: you don't need to travel to exotic locations -- you can just take a break to seriously pursue (a) above.
Hope this helps,
cheers,
[1] translation: I've held positions in pretty much every aspect of delivering software - userspace programming, systems-level programming, web dev, Level 2 & 3 support, system administration and ^devops^ (whatever that is)
heh, you bet ! When I read the article, I was like FFS ! You've got to be kidding me ! Is this really on the NY-effing-times ! ...but then I read the comments ...ah well, first world ignorance of ^low-tech^ solutions. Next thing you know somebody would be 'discovering' water is good to fight dehydration ! :)
I do not claim to know much about the condition, nor can claim to understand what it might be for you. However, trying to put myself in your shoes, in whatever manner possible, I can think of a few things:
a. Get in touch with people with similar problems and learn from their experiences.
As I read this, I remembered the story I read not too long ago:
Now, although the situation is not quite the same, only slightly similar (in terms of loss of memory), it serves as an example. Social networks work excellent as a support group in situations such as these. Not only does it help to learn from people out there who are dealing with the same issue, but also technically speaking -- reusing existing resources is the most optimal and efficient way to (re)build something - be it software or one's life :)
b. Decide on a longer term objective first. A couple of examples:
* You probably are in an unique position to think about how to use technology to help people who are affected by the problems you are facing. Does that appeal to you ? If it does, can you think of a way to use technology as a means to build a platform/app/resource ...etc ?
* If not that, try to answer, what would you like to do ? What, in your definition is a 'software developer' -- do you want to get back to exactly what you were doing earlier ? Or do you want to explore technologies that you probably never worked on before ? ...and why ?
c. When you've got a rough idea of a longer term objective, you shall hopefully know what are the short-to-mid term goals you'd have to achieve in terms of the necessary skills. Write them out. Prioritize and then get cracking.
I know it is easy for me to say it and although I don't suffer from amnesia, every once in a while I try to 'brush up' skills that I don't use in my daily work (read: C :) ) and I suspect that I do. So, I share (at least) a bit of your frustration -- exactly as you said -- "I’ll probably be rolling my eyes at how simple some things are but also getting stuck on relatively basic things
until they click again."
...though, I do not think there is another way to approach (re)learning.
d. Do you have access to any of your own code ? ie: code you have written from scratch yourself (as opposed to collaborated on). I would imagine re-reading/re-implementing bits of that might help. I say this because, experience has led me to believe that every programmer has a very individual 'coding style'. Much like prose, coders tend to express themselves in a manner that can be identified as their writing. From choice of variable names, to control flow. Relearning the technologies you knew might be easier if you did it with your own code.
e. Understand that university education will only help you gain a certain level of self-confidence in your abilities. To actually learn anything, you have to 'do'. So github might serve you better than coursera.
f. As far as employment is concerned, that is a different question than the 're-learning' process -- others have suggested options and I do not have any opinion to offer there except that putting your code out there (eg: on github) as well as progress (eg: a blog) might help.
As for symlinks, heh, yes I do know they are not silly and actually extremely useful and yes I know how to use them. I simply think they are silly for managing dotfiles. If your intent is to version your dotfiles and have different 'profiles' across your systems, using the tools at hand -- well, in theory you can write a bunch of script to create the symlinks and 'manage' them as well -- but I just find /that/ silly.