NOAA and NIST have huge headquarters in Boulder, Co. Cutting these departments would affect Boulder in a *huge* way - much like GE's pull-out of Michael Moore's home town devastated that town.

You just applied logic to a situation that is best described as.....unlikely to occur? I was tempted to counter your logic with some more non-reality based logic and then I got confused.....

Take the offer, but then offer to your (now) former employee that you can help/consult/be available in the evenings or weekends for particularly difficult problems. Offer to do it for free and if they do value you, they might be willing to pay you for it. Your junior developers will be grateful but not as grateful as the owners.

    This has worked for me twice in the past. You don't burn bridges, and in fact strengthen relationships. You will probably find, as I did, that your period of working two jobs will last less than a month.

I graduated with a CS degree in 1994. I went directly into the C/C++ programming world and had a blast learning systems and writing code that was immediately put to use in large and small systems. I worked with embedded controllers. I wrote air traffic control system software. I did a little bit of everything and it was great.

One day after work, I went home and sat down to watch a movie and before I knew it, the end credits were rolling. I had been thinking about my code and my work for my job during the whole movie and was so preoccupied with it that I had missed the *entire* movie. I made a decision. My personal, non-work time is *my* time. I don't want to be 'working' when I'm at home and on the weekends (working means thinking about my code). I loved coding and coming up with solutions to problems that had never been made before, but enough was enough.

I switched (slowly) to IT. I started to do some system maintenance work and porting to other OS's along with my daily work. I maintained the code repository. I became the linux guru at the company. My next job was strictly IT-only. My new employer was happy to hire a guy who was a programmer to be his IT person. I lived in that role for a long and happy time. It was a research company and I had many opportunities to use my programming skills to make my IT work much less mundane.

The upside to this move was that I had more time to program on my own, in my spare time. IT is mostly mind-numbingly simple and can be forgotten about at 5pm when it's time to go home. You've fought all of the fires. Everyone else is going home. If the pager goes off, you handle the issue and go back to your life. I was satisfied and I had my peace and solitude in my personal-time back. I even started writing code and building websites for myself and my buddies which was a much more pleasant way to spend my off-hours. I loved it that if I was thinking about code in my off-hours, it was for my own projects and not someone else's projects.

I've stayed in IT for the last 17 years. I've stayed away from Windows (since it's mostly learning where to click) and kept mostly in the enterprise/startup/linux world where scripting is still a common task among IT people. I've used cfengine, puppet, chef and other tools to automate my tasks and nagios is a close friend. I've found that working for a startup, I have the opportunity to write more core-level scripts and even some programs (I still program in C or C++ once in a while) and get to help with the company with some serious tasks to keep my creative juices satisfied.

I market myself as a 50/50 kind of guy. SysAdmin and Programmer, although most of what I do during the day is IT and most of what I do in my spare time is programming. I love my current combination of tasks.

I don't know how much age discrimination will hurt me when I get to me 50+ years old. The age discrimination for IT people seems to be a pending doom for my line of work and I may have to go back to programming one of these days as a primary job some day, but I'm keeping my fingers crossed that I can continue to work as I have been.

Feel free to DM me through slashdot if you want to talk further. ( or @scumola on twitter )

http://beatport.com/ sells the original WAV files. They're a little more expensive than iTunes, but you get the raw data.

Can't we just outsource it? All our other intelligence is outsourced.

I live in Longmont, Co and there are a *ton* of harddrive companies around here. Many of them hire for embedded programmers (mostly C and C++). If you know Pascal, C is not a big jump away. Also, I used to work at a weather research facility and there are tons of scientists there that all write Fortran to do their weather modelling. You'd still be very useful in both of those fields. Search harddrive places and harddrive controller places - all very 'embedded programming' friendly.

The best advice that I can offer is:

* Use the best tool for the job (don't use SQL for everything, key/value DBs are better for *many* tasks)
* Index smartly (don't index on the whole string if needed, try just the first few chars sometimes)
* Make sure your indexes fit in memory
* Other than that, just log long-running queries and optimize those.

- Steve

How exactly are you supposed to know what *He* wants to do unless you have him try it out? Most kids are pretty open to all things interesting and fun. If you can make coding interesting and fun...there you go. If he doesn't like it after your best shot, after getting the best advice you can, then go try something else. While there is not much connection between playing games and coding, at least there is *A* connection. Better that than "Ooooh my kid likes WOW maybe he will end up being a Blacksmith"

I agree. Scripts and "patchwork" and "duct tape" is easier to maintain for an IT person than a huge program that may be more robust and more well though-out, but if something breaks in the large application, you need to re-design, and get the developer to change things, QA, deploy, etc ... With duct tape and scripts, an IT guy can make a quick change and be back up and running in no time. It's all about maintainability for me. If I can't get into the tool and get my hands dirty and mess around with it, it's a black box to me and unmaintainable. K.I.S.S. - keep things as simple as possible if you want to be able to maintain them. The more complexity that you introduce into an infrastructure the more documentation you need, the more people you need, and the slower your response will be to fix it when it breaks (and things *always* break).