I've been unemployed three times in the last 15 years. Once during the dot-com bust (on and off for almost a year). Then in 2008 (6 days right before my first daughter was born) for almost 4 months, and then just recently (end of the year 2013) for three months.

I cannot imagine how bad it is to be unemployed longer than that, and I consider myself lucky that it was just a few months. But even if it is a few months, as you said, it is stuff like COBRA and other eventualities that get you.

On my last unemployment event, when I tally the amount of salary lost + expenses that I must pay no matter what (COBRA, children medical bills, food, housing), that pretty much tallied up to a $30K loss. My wife and I were very well prepared financially in terms of savings. But no matter what, $30K are $30K. It hurts.

Being out of work can pretty much amount to losing between $8K to $10K a month if we really analyze the situation. 12 months out of work is not unrealistic, regardless of talent, so I shiver to think at the very concept.

And the worst thing is that unemployment can (and will come) regardless of performance. In the job I lost at the end of 2013, it was just someone in accounting that cancelled projects at the closing of the year. Nothing to do with performance.

Shit happens, even in software, even if we have mad skills. Good thing that I learned my lesson during the dot-com bubble.

I've been living by a formula: expect to be unemployed one-to-two months for every year of continuous employment, and plan for it.

Now, I'm planning to bump it to two-to-three months per every year of continuous employment. The older we get the more that we have to bump that ratio, specially if we decide to remain technical as opposed to transition into management.

I downloaded the study by Chef (which amounted to a 3-page PDF), and there was no breakdown of the sample population by age, race/ethnic make-up, gender, marital status, location, degree and primary/secondary software skills. So, one has to wonder how much of a self-selection bias took place in this so-called study.

For instance, I cannot see a way by which a sample population of single men in their late 20s working as developers (or founders) at start-ups in Silicon Valley will respond the questionnaire in a manner comparable to, say, a mixed gender sample population of developers in their mid-30s or 40s working at established companies out of, say, Austin.

Also, regarding age, someone starting up today should not find it impossible to become, literally, a millionaire as in "having earned a million" by the time of retirement. To effectively be a millionaire - meaning having net assets worth a million or more (at current purchasing power) counting inflation, that is another thing.

The thing that made me scratch my head the most is that 2/3 of the sampled population believed their profession to be recession-proof. That strikes me as naivete (or stupidity) of youth/inexperience/arrogance.

The software industry is not recession-proof. It is recession-resilient for those who actively cultivate their professional network.

But recession-proof? Not. A. Chance.

Either this study is seriously affected by the Dunning-Krugger Effect, or it is an exercise in intellectual self-pleasure, or somehow Chef managed to sample a population composed by truly elite multi-discipline engineers, owners of very hard-to-get skills (like building software for radar systems or something.)

Sounds like parenting as always. Statements like X today is horrible imply that X was better before. Most of those statements are rather subjective, praising to some fabled (and false) good old days. Pretty stupid statements, but oh man, do they make a fine soap box!

How did we go from building blocks for 2-year old kids to standard lego blocks? You know there is a difference, do you? If not, please STFU. Just to help you and those who sadly do not know the difference:

• * Building blocks (suitable for toddlers):
  • - Like this: http://www.target.com/p/b-one-...
  • - Or like this (which I use for my 1.5 year old daughter) : http://www.target.com/p/mega-b...
• * Standard Lego Blocks:
  • - Like these: http://upload.wikimedia.org/wi...

TFA is not claiming that. You are claiming that it does, though.

Anecdotes and conjecture are valid form of preliminary evidence with which to request further scrutiny of something.

Also, from personal anecdote (feel free to dismiss because ZOMFG anecdote!) kids at that early stage require specific stimulus to develop hand fine grained motor skills. Playing with sand, clay or building blocks (not standard lego blocks, but building blocks for toddlers) help do that.

Going into the (ZOMG!) anecdote: One of my nephews had a learning disability co-related to not developing hand fine motor skills, some type of proprioception problem related to ADHD/Asperger/Autism. He simply could not hold a pen without it falling off his fingers. Good fortune it was detected on time, and was put on specific corrective therapy to develop not just finger strength but the necessary coordination to do what he needed to do with his hands during that state of his body/mind development.

Feel free to dismiss this as you wish. Whatever gets your intellectual kicks.

With that said, I'm not against kids using technology. I was delightfully fascinated when I saw my older daughter (now 5) using my smart phone at the age of 2, and I'm fascinated how my youngest one (1.5 year old) fiddled her way into unlocking my phone (despite it being locked with a swipe-shape lock.)

But I keep my daughters away from technology if that precludes them from the other type of tactile-proprioceptive activities that have been developed over time to assist in their development: finger painting, puzzles, blocks, sculpting with silly putty, running around.

All those things are fun, but they are not just for fun. They have an evolutionary purpose.

There is a reason why kids play with soil instinctively. It is not just curiosity. It is the child mind and body instinctively seeking activities that trigger learning and development.

Replying to myself since we have no way to edit our previous posts - I would add that languages of the BASIC and XBase families (in particular VB and FoxPro) are/were more general purpose than either C/C++ or Java despite running in more restricted sets of hardware platforms.

Most modern Wirth-style languages posses syntax-level compiler directives to specify the calling convention. Heck, most modern languages either have such a capability, or an intermediary wrapper or stub generator to do that type of bridging. </itisasolvedproblem>

Uh, you are conflating "general purpose" with "platform availability". C runs in far more platforms than, say, Java, but, from professional experience as a C/C++ and Java programmer, I would not call C more of a general purpose language in the same way I would do so with Java.

Stop it. You are making too much sense.

Obviously yes. But also, and this is a very Japanese thing, to ensure people know how to build shit. From my short experience with Japanese culture, these people are not afraid to automate the crap out of things, but are afraid to lose what the government (and the nation) considers core competencies, from manufacturing to cultivation of rice. It is enshrined in their government's policies and in their ethos. I am not making this up.

It is breaking news for most of us in the US, managers and otherwise. The implications of that last statement of mine are not pretty for our culture </weareabunchofludditeswithourheadsupourasses>

I know!!(10+1) ;)

Correct, sort of. There is the concept of running away from intellectual property (say, you work on Coca-Cola, and you run away with patented/secret drink recipes and formulas, and go work with PepsiCo or make your own company. This is obviously stealing IP property. Non-compete agreements do nothing of the sort to prevent this, and there are already Federal and State laws to deal with such situations.

Similar laws and situations arise when, for example, a employee at, say, an insurance company, takes contact information on the company's clients, and leaves to make a competing company, using company-owned client information to poach those clients. That is unethical (and possibly unlawful). An ideal non-compete should be aimed at preventing that.

Sadly, non-compete agreements have a greater, nefarious scope: Non-compete agreements are of a complete different sort - you work at an insurance company and you leave to create your own. Then your former company comes to sue you out of work, forbidding you from establishing your own company in the same metropolitan area/county (or state!).

This is the type of non-compete agreements that should be illegal, or at the very least be time-limited (say, 6 months) instead of being open-ended. And these are not limited to tech companies mind you.

Names and locations omitted for obvious reasons:I know of a person who was a professional dancer in his country of origin, came to the US and continued training (and working) at a local dance school.

Being the young, inexperienced foreigner that he was, he signed a non-compete. When it was time to finish his training, he decided to open up his own school on a different area of the metropolitan area he and his former school/employer resided.

Long story short: school tried to sue the living crap out of him, that he could not open up a "competing" school in the whole multi-county metropolitan area. He was being pretty much forced into a situation of forced unemployment vs change careers vs get-out-of-dodge.

Ah, America, land of the free, home of the brave... and ridiculous lawsuits, where enough money can buy you the power to shake up young, starting entrepreneurs.

Fortunately, a lawyer was able to advise him well, and a judge pretty much ruled that the dance company was in effect trying to force the young man into unemployment. Although the young man signed the NC agreement, the judge ruled that the agreement was unreasonable and illegal.

Banning such types of NC agreements explicitly is a good thing; it will stop harassing entrepreneours and former employees; and it will free judges from having to deal with such ridiculous cases

This is a solution looking for a problem. Or more precisely, you are looking for an excuse to use a piece of technology or paradigm. Don't get me wrong, your systems requirements might indeed be best served using a NoSQL solution, but what exactly has your analysis shown regarding this?

Scaling is not just a technical feature (NoSQL, SQL, Jedi mind-meld tricks). Scaling is a function of your architecture. You can NoSQL the shit out of your solution, but if your software and system architecture is not scalable, then having NoSQL will mean chicken poop as solutions go.

If you want simple, put a simple RDBMs schema (a properly normalized that) in place, and have your code use a simple, technology-agnostic persistence layer that maps your domain-level artifacts to database artifacts. If you ever had to replace the back-end, then you can do so with minimal changes to the API that domain-level artifacts use to persist themselves with the persistence layer.

Design your domain solution around domain-specific artifacts. Persistence technology is typically a low-level design/implementation detail, an important one obviously (and a critical one for some classes of systems).

But for what you are describing, the choice shouldn't even be coming into the picture without first having an architectural notion of your solution.

In addition to Option Explicit. Friends indeed. But to the OP's behalf, Option Explicit is relatively new (2005 I think). There is still a lot of VB code out there that predates that feature.

But even then I think one should not need to rely on such things.

I used to be a QuickBasic and VB programmer back in Pre-(Internet)-Cambian times (and, oh, the horrror, PickBasic with numeric goto statements). We guarded ourselves (or I least I did) by using strict coding conventions and Hungarian notation on variable names and function names indicating the return values.

To a similar degree I did the same when I shifted from VB to FoxBase/FoxPro/VFP (what a nice product it was for its time). Anyways, it was obviously impossible to guarantee a type-mixing mistake would not occur, but software written this way tended to be very reliable and sufficiently type-safe.

Done this way, type mistakes were easy to spot by just looking at the code. At the end of the day, as Joel Spolsky once wrote, it is about making wrong code look wrong.

Hahaha, bingo.