Everyone's been nervous for months, watching the market numbers, the stock prices, the declining sales figures. In the IT department, it's not uncommon to see programmers with one window open on code, the second on the app the code's supposed to generate ... and the third on a steady stream of plummeting financial indexes and bad news about the economy. Then, about two in the afternoon, your project manager taps you on the shoulder - special meeting in ten minutes. When you stand up from your cubicle and look around, you notice that there are several security types idling in the hallway ... and you know, instinctively, what that meeting's going to be about.
The message is usually the same - sales have dropped precipitously, management's cutting back everywhere they can. The project you're working on is important - you knew it was important when you signed on for it six months ago, but it's completion is still a few months out, and they haven't even ramped up marketing for it.
It's an all too common scenario, one that is happening more and more frequently as the economy continues its decline. The tightness of credit, the decline in disposable income and the uncertainty about the future all contribute to an environment where job losses are becoming far more frequent, even in supposedly safe areas like high tech.
There are, however, a number of things that you can do both before and after getting that pink slip to ease the transition into a new opportunity, especially if you're in IT. How to handle losing a job is something that a lot of employment agencies (and unemployment agencies) for that matter, special in, but its also worth keeping in mind that the way that you deal with jobs is a lot like the job market itself - it evolves over time, and what may have worked earlier may not be as applicable in this day and age.
Thus, the first steps towards becoming gainfully unemployed is to keep the following in mind:
Keep Your Radar Active
One of the things that distinguishes tech people from non-tech people is that they are unusually good in seeing and properly interpreting patterns. Assuming you're doing your own job well (and for the purposes of this article, this is a key assumption) what you're going to find is that there are obvious patterns (and some not so obvious patterns) that layoffs may be imminent. Deadlines get shortened or features get cut on products in the development queue that were otherwise on schedule. You find that even though you may need more hires (or contractors) you don't get them. In-house perks are steadily cut, non-essential expenses are minimized, training is reduced or eliminated altogether.
In general, you should always keep one ear open to news that pertains to your industry and the company that you're working for. It's also worth watching to see how transparent your company is via blogs and related community activities that come out of the company - in general, when the economic situation tightens, so does the level of news orchestration coming out of the company as well, including tightening up on who can blog.
Keep in mind that most layoffs are intended to be strategic for the company, not necessarily for IT. When times are tight, the costs involved in marketing and distributing new technologies are high enough that they may represent a negative cash outflow at least at first, and consequently may be tabled ... even when the projects themselves are close to complete.
If reasonable development methodologies were followed (at least so the thinking goes), such projects can be shelved for a while until the economic climate gets better, then picked up where they were left off. Note that the reality is usually somewhat different ... software projects, like food, usually have a distinct sell-by date before they become stale, but unless you're the CTO for a company and can make that argument, new projects usually tend to get terminated before existing ones do.
Understand as well that in most layoffs, the people making the decisions are not usually themselves technologists. Most programmers will admit that there is a world of difference between a novice programmer with one year of experience and a senior programmer with more than a dozen, but when it comes down to reducing head count, seniority (at least in IT) can work against you, as your salary will likely be in line with your experience, and as such makes a far more tempting target for cost conscious managers.
Build Your Networks
Your personal networks are analogous to a savings account - the more that you invest into them, the more likely that when you need that support, you'll have it.
This is the first major recession to occur since the explosion of formal social networks sites such as Facebook, LinkedIn, MySpace and a host of others, and as such it also may serve as the first significant test of the value of such networks. These networks should not, in and of themselves, be seen as your social networks, but rather should serve the role of a web-based Rolodex, a way of keeping track of the people you know and from them finding the people that you could potentially reach out to if things get problematic.
Keep in mind that among the people that make up your network are those people that you work with. Building networks in that case also means building bridges to those people most likely to give you recommendations in the future. That's why it is very important when layoffs do come that you do not burn those bridges on the way out - performing petty acts of vandalism or giving your supervisor the bird on the way out the door won't do you a lot of good (no matter how satisfying) when you find you need that supervisor's recommendation for your next job.
However, beyond that, your networks are also likely to consist of business associates that you have worked with, business clients, open source project participants, standards committees and so forth - even your own employees if you are a manager. It's not unknown for a person to find themselves applying for a job where a previous employee may actually be a potential contact in to a company you want to get into.
Know Your Options Ahead of Time
Take some time to talk to your personnel department if you are with a company and find out what the company policies are with regards to layoffs. Note that layoffs may fall into a different category than termination with cause - with specific mandated requirements that a company needs to follow in order to comply with federal regulations.
Insurance is probably the first issue you should ascertain - if layoffs occur, what happens to your current health insurance. If you work for a company with twenty or more employees, you should be eligible for COBRA (the Consolidated Omnibus Budget Reconcilation Act), which lets you keep your existing plan for up to six months, though you become responsible for paying the balance of the premium that your employer was carrying. Note that while COBRA is expensive compared to having full time health insurance while employed, it is considerably cheaper than trying to find an individual insurance plan, and in many cases can be extended depending upon circumstances.
Going without insurance is an option as well, but it's a risky one. All it takes is one accident or serious illness and you will not only be less likely to find a now job while recuperating, but you will also be facing mounting medical bills that can get severely burdensome quickly.
If a company is going through hard times, it may choose to offer voluntary severance packages, in which you get what amounts to a bonus for choosing to leave. For IT professionals who may not be heavily invested in the company to begin with, this should be an option you should consider seriously - companies at this stage may face involuntary terminations or even bankruptcy in the not too distance future, where you will likely find that any severance package is bare-bones or even non-existent ... more than a few employees (including this writer) have shown up to work only to find a notice on the door that the company has folded and that bankruptcy claims will be handled in order of size. What's more, by accepting such packages, you may find yourself in a better situation if the company does recover and is interested in hiring you back in the first place.
Severance packages are typically based upon time in service and your current salary, and can often provide you with several months of additional income. However, it is also worth understanding that this is essentially a buy-off, in order to avoid the possibility of lawsuits against the company and that having done so you may lose seniority for pensions or time towards vestment in options by accepting it. For older workers, this may prove to be unacceptable, though there is a dark underside to this as well - the spectre of agism in IT (see Understand Where You Are In Your Career, later in this article).
One final thing you should check up on is the status of 401K and related retirement funds. When you shift from one job to another it is very easy to lose track of retirement funds, especially if they were initially set up by the company, and knowing the status of funds also makes it easier to turn them over into new investment vehicles when you do find a new job (or set up a company for yourself).
Preparing the Home Front
There are additionally preparations that you can and should be making at home, regardless of whether you have benefits and potential severance pay coming. One of the key things you can do to protect yourself is keep an active savings account going, something that is relatively liquid even if it doesn't necessarily return a lot in interest (now is not the time to search for yield!). Your options will be much broader if you have recourses to keep yourself afloat during these times - if you don't you become too dependent upon having to take the next job that is offered, regardless of whether it is in fact a good fit for you.
Assume additionally that at least for a short period of time you may very need some form of workspace - either in your home or in a separate "work center". This is a place that you can use for either looking for work (at least initially much of this search will be electronic) or for establishing your own business, but you will need somewhere that is both relatively secure and interruption free. Note also that while the temptation to set up an office in the local coffee establishment may be overwhelming, buying $5 coffee while looking for a job may not be the most brilliant ideas.
Finally, if you have a family at home, do not keep them in the dark about what's going on, nor don't forget to add them in your own calculations about what's needed financial ... and understand that unemployment of at least one wage earner does not necessarily mean either that you have a lot more time to spend with them (though you should take the opportunity as it presents itself) or at the same time that children in particular may very well internalize the fear that any economic uncertainty brings with it. Be especially aware of this last point - children often have difficulty in handling such fear, and will need much more assurance from you and your spouse during this time that things are working out.
When the Axe Falls
Your project manager's boss has taken the floor now, and the news is worse than you expected. They're shutting down the project, and letting everyone go. When the economy gets better we might rehire you but we can't make any promises. There's a severance package, here's info about health care, blah blah ... sorry about this, and better luck next time.
You get back to your computer, and you notice that the system has been locked down. Management's taking no chances that a disgruntled programmer will try to wreak havoc on the way out the door. There's a box on the chair for your few belongings, and as you start putting your books and keepsakes into the box you see that one of the security guards is keeping half an eye on you as well. Soon you join a steady stream of others heading out the door, each looking stunned, one or two barely holding back tears. You've just been pink-slipped, and things are going to get crazy.
As you head away from your ... former ... workplace, you're going to feel strong emotions - rage, despondency, giddiness, fear. No one is immune from that - it's the brain's natural reaction to a serious shock, and no matter how irrational, you're going to be messed up until you can safely defuse that initial emotion.
One of the best things you can do at this stage is take a personal vacation. Yes, money may be tight and your future may be uncertain, but this is more necessary for your sanity at this stage than anything else you could be doing. Take a road trip or a hike in the woods, if it's a stress reliever go shopping (though not in excess), buy some notebooks and work on a novel. Get away from the computer - you'll have more than enough time there, but at this stage you need to disconnect for a little bit. You should plan a few days to perhaps a week, but not much beyond that - your goal is to calm down, ground yourself and move beyond anger or sadness to a state of contemplation.
Jobs are relationships. You invest time, energy, your personal social status, money and your ideas into it. Any time you break off a relationship, your mind and body need to adjust to the new reality before becoming productive again, and all too often you run into people who go from bad job to bad job because they react from fear, not forethought and planning.
Determine What You Want To Do
The most natural tendency in the world when losing a job is to want to seek a new job that was just like the old one, even if you hated. We are creatures of habit, and because the last job that you were in was the one that you most likely were most current in your skills, knew best, and in general had the clearest mental castles from, finding something just like it - "but with a better boss" - is perfectly natural.
It's also most likely the least effective strategy that you can have. Consider this: your company just laid off a large number of people because they had decided that the approach they were taking was not cost effective, especially in an increasingly tight and competitive market. While its not likely that your particular skill-set (or even a given computer language or technology) was at fault here, it is likely that other companies in that same space - potential hirers - are also facing the same pressures.
In other words, seeking the same job elsewhere may be risking a higher than normal chance to find yourself back on the streets in six months or less. Thus, while looking for a similar job should in fact be a strategy in getting back on your feet, it shouldn't be the only one.
Indeed, your best strategy is to strategize at this point - take some time determining what your goals are, and tailoring your job search to meet those goals. Where you are (or at least perceive yourself to be) in your career should be a big first step in ascertaining those goals.
While programmers don't in general see themselves in the trades there are some concepts that carry over from those fields. Most developers will fit into apprentice, journey-level, or master categories, and if your goals include staying in the IT field, then you should ask yourself honestly how far along you are in such an assessment.
An apprentice is someone who is still learning the tools of the trade, still trying to determine the best working patterns and methodologies. Most apprentices in the IT field are those people with between zero and three years of work experience in the field. The best strategy for most apprentices is to target jobs that will let them take the groundwork of experience they already have and build on it in other areas - a Ruby programmer becoming proficient in PHP or Python, a testing engineer learning more about application development, a web designer spending some time learning how to write AJAX code. The nice thing about being an apprentice is that your options are the broadest - you need more experience, and if the job lasts six months, then its simply an opportunity to learn yet another set of skills.
Apprentices, additionally, are often highly desired by startup software companies because they can be trained more readily, they are usually willing to put in a lot of overtime and extra effort, and (unfortunately) because they are the least expensive option. This means that for apprentice-level programmers, going to startups is a logical next step, and even when times are tight, startups often flourish because they represent the least expensive overall way of getting companies going (and if they fail, the overall impact on others will be relatively minimal).
Similarly, if gaining experience is a key goal, this is also the best stage to work in "consulting services" - I.e., work with placement agencies (it is not the best time to be an independent consultant, however). Placement agencies are generally most interested in filling positions with people who are less concerned about stability and more concerned about getting that experience and training. The placement agencies themselves would prefer that they had people with more experience, but because of the overhead that they frequently charge its typically much more likely that they will be picking up those people in the two to five year experience range (upper-level apprentice to newer journeyman).
Journey-level programmers make up the bulk of programmers in the field. These people overall have established a primary area of competency, and are working to become better known in the field. Most journey level developers have between four and ten years in the field, and these are generally the most stable workers - they stay within a single language (or will jump only to relatively similar languages), they often gain specializations in one particular domain (security systems, knowledge management systems or web application development, for instance), and are often the ones most likely to be programming mentors or project managers (and are often the ones found in positions calling for senior software engineers).
The strategy for journey-level programmers, consequently, is somewhat different than for the apprentice. At this stage in your career, what you're aiming for is stability - you want an employer that can let you continue to develop in your areas of specialization with minimal disruptions to your own career. Of course, this means that pink slip moments are considerably more devastating to journey-level developers than to any other.
In this particular situation, journey-level programmers should look upon this time as an opportunity to retire obsolete skills in favor of new ones (a journey-level programmer facing a new language will become much more skilled with that language that an apprentice will in the same period of time), to move into adjacent skill fields (a skilled web application developer may want to get into financial services - admittedly, perhaps not just right now - or messaging systems), to concentrate more upon the architectural aspects of their skills in order to understand how to build larger, more complex systems, or to become more oriented towards project management.
Indeed, one of the biggest dangers that journey-level programmers face is complacency in the face of changing technologies. More than a few journey-level developers become proficient on one language or system and when that technology becomes obsolete, so too do their jobs. Many developers then spend a lot of time looking for increasingly rare jobs in that technology rather than examining whether they would be better off using these skills to springboard into new areas.
Senior journeyman programmers also are much more likely to go into independent consulting or to be part of a team to start a new company. Such developers are essentially picking up management skills, keeping in mind that IT management usually bears only a casual relationship to management in other parts of business. In the trades, these are often called master tradesman - in part because such tradesmen are usually the owners of their own businesses. Indeed, for a senior journey-level programmer, losing a job is often the impetus for finally taking the leap and starting your own business, or at least take a senior management position in a midsize to large organization - senior architects, program managers, CTOs or CIOs.
Master developers in that sense need to be thinking strategically about their own goals - moving from a CTO position to a software developer position seldom makes sense, but jumping from CTO of a small firm to a senior architect position in a larger one makes a great deal of sense.
There is an alternate track here, though, one that doesn't necessarily exist in the trades. The researcher is an expert in a fairly broad range of technologies who has not otherwise chosen to enter into management (at least not through traditional channels). In general the researcher is someone who has spent more than a decade as a developer or architect, and has chosen to concentrate on improving the technology in some way.
Researchers frequently are the ones to write computer languages, to establish industry standards, to write books and papers on new technologies, set curriculum guidelines for educational programs and certification requirements and to shape the direction of programming methodologies. In general, research tracks and management tracks tend to be considered more or less equivalent, at least in IT, and it is not uncommon for researchers to be former entrepreneurs or for entrepreneurs to go back into research.
In most cases, if you are a researcher, one critical goal is to move to arenas that will let you extend your research. In times of layoffs, researchers often take this opportunity to write books or become involved in standards processes - usually given the very tight networks involved there, it is a relatively simple process finding other organizations willing to continue to sponsor your research, especially if your work is considered seminal in the field.
This is also a good time to take your research and move into a more entrepreneurial role. Many of the most successful startups took place when a key researcher decided to commercialize his or her work, since such research typically is intended to solve a currently insurmountable problem.
Migrating Out of IT
For a fair number of people, software development may be in fact only a way-point towards some other profession. While the shift to management may seem like just such a migration, its actually fairly rare for an IT professional to migrate to a senior non-IT management position unless the company involved is itself a highly technology oriented one.
Apprentice programmers who shift to other areas usually have the broadest choice, though typically such jobs still may have technology related aspects to them. Software or hardware sales are a frequent area for younger programmers in particular to move to, as the potential for reward tends to be higher than for programming, and people with technical competency often have an advantage in being able to sell this technology to others. On the other hand, such sales positions are also perhaps even more vulnerable in a downturn than programming itself is.
Working for a consulting company may also expose you to other careers that may not necessarily be programming per se but that may appeal more to you than writing code does. Hardware developers may end up making the jump to general industrial engineering, database developers may move into analytics or information management, content management specialists may end up working in general publishing or library systems. Financial services developers may become more focused on algorithmic development and the more mathematical side of the field, or in actuarial science. People working with standards may find contract law, intellectual property law or related legal fields more intriguing. People working on sales systems may find accounting is a natural jump out of IT.
The key here is recognizing that IT intersects a lot of different potential employment arenas, and that simply because you are not writing code does not mean that a given job in a field that you like is out of bounds. This becomes increasingly true as programming systems shift away from the hard-core software developer and instead becomes more generalized - is a sales manager who writes a sales management tool using an AJAX toolkit a programmer? Yes, but that's not his or her primary focus. Over time what this has meant is that people in tomorrow's (today's?) economy are expected to have some programming expertise regardless of the profession that they are in.
Going Back to School
When times get bad, schools get full. This is a simple reality - people recognize that sometimes they need the advanced degree, additional courses or just the research time that they are not going to get when punching a time clock.
As with choosing to go back into work, going back to school should be taken as a strategic decision. Simply choosing to finish a Bachelors degree or working towards a Masters or PhD because there aren't any jobs at the moment is not necessarily the wisest decision. Again, establishing goals and objectives here can make a big difference when planning whether to go back to school.
If you do not have at least a Bachelors degree, going back and getting one is probably a good idea at any stage in your career, but choose the degree based upon your interests, not upon what you think will pay the most. Especially if you have three or four years (or more) of experience in the field, getting a computer science degree is not longer necessarily a critical requirement, and indeed, if your area of interest lies elsewhere (such as economics) then you should take the opportunity to become more conversant with the "vertical" that you're interested in rather than upon CS principles themselves.
Getting a Masters or PhD is a somewhat different matter. In most states and provinces, if you want to teach at the college level (something which can become very important both from a network building and an understanding level) you generally need at least a Masters degree. In this case, you should focus that degree so that it both reflects your skillset and your long term goals - a pure Computer Engineering degree doesn't make much sense if you happen to be interested in knowledge management but an Information Sciences degree does. If you're interested in systems and architecture, a degree in economics, systems theory or mathematics can prove quite useful. If you're increasingly interested in moving into a management role, an MBA or related degree is probably not a bad idea.
While many of the key "researchers" in the IT field do not have a PhD, most of them do have at least a Masters degree. A PhD does open access into academia, but it's also a prerequisite for the research arms of larger corporations and governmental agencies.
The challenge of working towards advanced degrees in a tight economic environment can be daunting, however. Research budgets tend to be attractive items to cut when economic conditions go bad, and it becomes harder to justify providing educational opportunities as perks when companies aren't sure they have the money to make payroll. Moreover, demand tends to go up for education in hard times, which means that schools become more competitive.
Typically what that means is that if you do choose to go to school, understand that it is a full time commitment that will force you to reduce your standard of living, and possibly to go into debt. The best course of action in this situation is to plan early (even before you lose the job, if at all possible), find a way to balance a need for income with the time and energy you need to commit to the enterprise, and to research options and even interview graduate school advisors before making that commitment.
Certifications represent an alternative path to education, though after twenty years of certifications being offered in given technologies by various vendors, there is still comparatively little independent evidence that certifications offer a significant differentiating factor for hiring by employers. As the expense of taking these certifications will more than likely come out of your pocket rather than an employer's, you should weigh going after such certification carefully.
Establish Strategies for Achieving Your Goals
Once you have decided your direction and the goals you want to achieve in the long term, the next challenge is to implement these. One way of thinking about this process is to envision applying agile development methodologies to the task of achieving your goals.
The biggest challenge that most people face when job hunting is that they set their goals to be too large and monolithic. "I have to get a job" may be a goal, but there is nothing there that indicates how in fact you will achieve that goal, what the job will be, or even why you need to get the job in the first place. Instead, you can use an iterative process to break down the goal into more easily achievable tasks:
State your goal clearly, concisely, and with a demonstrable target
Identify those tasks that need to be completed in order to achieve the tasks
Clearly identify the completion criteria for a task before moving onto the next task.
Focus on each task until it is completed.
At the end of each task, re-evaluate your goals based upon your current state.
Repeat until the final goal is achieved.
Stating your goal. "I wish to get a job as an XML specialist working with XQuery in order to gain more experience in XML based content management systems."
Identifying your tasks. "To do this, I will need to find companies that are currently working with XML content management systems, I need to ascertain their needs and determine if there are ways to communicate with a champion there, I need to create a resume that showcases my talents specifically for these companies, I need to get my resume in front of the right people, I need to identify and contact references that will speak to my skill and authority, and I need to prepare for an interview."
Identify the completion criteria for the task. I'll consider this task complete when I have identified twenty companies in the space, their contact information, the types of products they work with, they available positions, and those people in my network that may get me a potential "in" to the company.
Focus on each task at hand. To find XML companies, I researched in places such as O'Reilly and the XML Cover Pages in order to determine the companies in this space, including how to contact them, what positions they have advertised, and who may be considered to be experts that work for these companies that I could potential contact.
Evaluate Your Goals. After having completed this analysis, I've found eight companies that have positions worth following up on initially, another five that may have something worth following up on later but that don't have any immediate requirements, and the remaining seven that I've disqualified for various factors. I will now move to the next stage and put together a resume for the companies in my list, because this looks like a viable approach.
By keeping focused on both the broader goals and the more tactical tasks, you can often circumvent those "recommended" strategies that are often less than useless for actually finding a job.
Avoid the Resume Trap
The Job Mill Industry was one of the earliest web success stories, but increasingly these companies, that provide job listings for millions of jobs every year, are becoming something of a cautionary tale about the dangers of automation in society.
Before web job boards, finding a job came down to searching the want-ads in newspapers. Typically, this meant that for any given job, an HR director might get anywhere from no resumes to perhaps a couple hundred, depending upon the scope of the job. Yet with the rise of Internet job board and the ease of creating and responding to such job postings, the same job listing may potentially get thousands of resume submissions. This means that increasingly HR is responding by creating filters that will eliminate any resumes that don't fit specifically into their needs, often dropping potentially good candidates that don't have precisely the required buzzword in favor of inferior candidates who do (there's a lot of similarity between search engine optimization and resume optimization - both are involved with otherwise gaming the computer systems).
A resume is an important part of any job hunt, but it is no longer effective in getting a foot in the door. There your better course of action is typically playing on connections and promoting yourself.
One strategy that tends to work well is to place your resume up in a place where you're likely to get some traffic, such as in a blog you write or posting resumes to mailing lists (though check out the etiquette involved there first - some mailing lists specifically forbid posting resumes or job listings, while others may have a separate job mailing list for this. However, having your resume online in general is a good strategy - it's possible that it may get picked up in search engines or otherwise linked, and as such may be stumbled upon by recruiters (this holds especially well for journey-level developers and above).
That's not to say that the job boards are useless ... far from it. One useful strategy when working with job boards is to take advantage of their RSS feeds (most boards now have them). In many cases you can perform keyword searches to specify only those jobs that satisfy a given criteria, then you can use various programmatic techniques to filter out from those feeds ones that may be in your area, may be in your salary range or otherwise are attractive. You can also do additional profiling of those feeds to get an idea which skills or technologies are in demand right now (some handy scripts to do just that will be posted soon in this channel).
Make Employers Come to You
One of the things that many job-hunters lose sight of is that the purpose of a resume is to help promote you as a possible employee or contractor. However, overall it is not the most effective such promotion tool - if your resume is too sparse, then it can actually work against you, no matter how skilled you are, and if its too rich, it can similarly prove too exhaustive a read - and that's assuming it gets past the electronic gate guards in HR.
For the job hunter, perhaps the best advice is the same one that young assistant professors are told - to survive in academia, you must either publish or perish. If you haven't begun one yet, start a blog, right now, focusing on technical issues, your philosophy of work, innovative things that have caught your eye. This serves three purposes. First it provides you with a log of your own work and thinking, something that's often easy to misplace over time, especially if you move from job to job. It makes it possible for a potential employer to evaluate your thinking processes and to get a better feel for how you would approach a certain challenge. Finally, good blogs tend to get picked up by other bloggers, and this in turn makes it more likely that an employer may stumble upon you and contact you out of the blue.
A short aside on that - not all jobs are advertised. Many times, employers may be thinking about staffing up but haven't yet reached the stage where they have specific requirements. This is in fact the ideal time for many developers to come on board, because often the project is malleable enough at that stage that its implementation can be shaped by the programmers that are there, whereas most advertised positions occur either because the project is far enough along that requirements have hardened or because someone dropped out or was fired and they need to fill that hole quickly.
Social Network sites like LinkedIn can promote you too, though keep in mind that such sites can also become oversaturated. Your presence on LinkedIn or FaceBook is your profile page, and you should take the time to make sure that this particular presence reflects positively upon you. FaceBook, for instance, has a powerful API for customization, but it also tends to have a certain amount of trivialities that can work against you in a corporate environment - having pictures up on your wall of you passed out after a beer party is not going to necessarily go over well with a potential employer.
Finally, while it can be an expensive strategy, presenting at conferences, putting together webcasts and speaking to user groups can be a very effective way of getting your name in front of people, especially if you let it be known that you are available for employment and make your resources available from these presentations. Placing presentations up on YouTube or similar video hosting (or Power Point presentations up on scribd.com or the like) can again increase your exposure, while at the same time educating people about critical technology, and what's more, these types of promotion are generally free or available at very low cost.
Participate in Open Source and Open Standards
Such strategies do work, but they also take time to put together and even longer for people to react. While it's possible that you may manage to land something almost immediately, the reality is that it may take weeks or even months before something solid shows up.
For that reason alone (and there are many others) you may also think about either getting involved in or even initiating an open source project. This doesn't necessarily mean powering up Linux and starting to write C++ applications, but instead should be looked at as creating the applications that you'd like to create, but that you were otherwise prohibited from doing because it didn't fit into the corporate mission. Most programmers have at least a couple of these projects in the work at any time ... by publishing them via open source you gain the advantage of setting up a development team without necessarily needing to support that team financially.
Open source development will keep your skills fresh, and will often give you a chance to experiment with new technologies that you were unable to work with otherwise. They let you communicate with others of a similar mindset, which can keep you focused on programming rather than getting lost surfing the web, and often produce workable products that may be the foundation that you can commercialize.
Additionally, open source programming is a lot like blogging - it attracts people who need these technologies, it opens up opportunities for consulting, and it may very well lead you into a job at some point. This is part of the reason why being a developer is usually not as devastating as most other professions - when you don't have a formal job, you can concentrate on your informal job that may in turn develop into something more comprehensive.
Open Standards development is a little bit different, but not that profoundly so. Especially for research oriented developers, open standards provides a means by which you can help establish key specifications that may be used by other developers.
Indeed, it's perhaps not unsurprising that most of the work on standardizing key elements of web technologies occurred at times when business was slow and many of the standardizing engineers were themselves between jobs. During these periods, there's less likelihood that political resistance will emerge from companies that are seeking that such standards favor their own product sets, and it also means that people have more time to think about standards' working drafts, build examples and otherwise prove concept.
Getting involved in either of these activities typically involves contacting the chair or lead developer for the project, and being willing to roll up your sleeves and work. Sourceforge or Google Code both host a large number of open source projects, and your best course of action is to search each by keyword in order to find something that looks worth supporting - research, download, explore, and analyze the projects in question, then figure out what you can do to help best.
Start Your Own Company
The bulk of all software companies in existence today were started when economic times were bad, either in the economy at large or in the tech sector specifically. This is not as odd as it may sound at first hearing. When times are bad, the driving factor in the creation of companies usually tends to be boredom ... the founders are sitting around the table at a bar or are chatting online and one brings up the idea of putting together a company. Roles are usually loosely defined, people don't necessarily take things seriously, the challenge is just getting the project up and running. Niches that may have been filled by other businesses are failing (opening up that space), people have time to reflect on how to use existing technology in novel ways, and people have just been let go and are looking for something to do.
Eventually, the product gels, and other people begin to use the product. Orders begin to come in, as well as opportunities for consulting. The project provides enough traction to keep people active, and the company begins to generate revenue, then eventually profits. By the time the economy begins to thaw, the company in question has already established itself in the niche, key people have either chosen to lead or have gone on to other projects, and the company can focus on building market-share rather than in trying to develop a product. What's more the ethic involved with the company is one where work is encouraged. Investors may come into the business at this point, but typically their role is reduced from seeding the project to providing the capital necessary to market and promote the products.
Thus, these companies usually have a very definite advantage in the marketplace. Contrast this with companies that are formed at the height of a tech boom. These are often investor-led rather than developer-led - people are looking for a good return on their investment, so bring what they see as killer ideas to the table. You get tech incubators, trying to shelter fragile companies while they grow, but frankly they are fragile for the most part because they just don't have a solid business model. Labor is more expensive (it always is at the top of the market, when technical talent is in highest demand, even for fairly mediocre quality).
Additionally, companies begun near the top of a technical market typically tend to be awash in cash, and as such control of the purse becomes a much higher concern than development of the technology. There's a strong imperative to show profits (and quickly), meaning that several of the crucial factors in research driven development - repeated trial and error, the role of serendipity, the open exchange of ideas, time to find the right balance in talent levels - are either limited or missing outright.
This is not all to say that starting up a new company in the headwinds of an economic downturn are easier. Money will be tight, and the possibilities of failure are perhaps more enhanced at this stage even for a startup than they are at the height (though failure will usually occur much earlier in the process than for late cycle startups). Moreover, as with going back to school, you will likely have to have a fair amount of income to survive on while trying to get the business off the ground (six months is recommended). Given the current credit crunch, this also means that starting new businesses with loans becomes harder to achieve, and it is very much likely that this particular regime will hold sway for some time.
As with everything else, this environment is going to weed out the half-baked business plans and easily replicated technologies very quickly. What this implies in the long term is that you will see far fewer startups make it past the six month point, but those that do will likely have the staying power.
Your Next Job Has No Name Yet
If you are older than forty five, things look somewhat more grim for you than they do for younger programmers. Most senior programmers have had between ten and thirty years of experience beyond college, and are as likely as not to have advanced degrees. Older programming technologies are fading fairly rapidly - COBOL, for instance, had its last heydays in the Millennium Clock Crisis leading up to 2000, and has been in fairly rapid decline ever since.
Older programmers are also often the most easily trimmed - they are closer to retirement, which means that if they reach the point of getting a pension they will be on the books for years. While a good programmer with twenty years of experience can work circles around someone who's had only a few years, they also tend to make nearly double what an apprentice programmer can, so especially in penny-pinching companies its hard to make this point clear to cost-cutters who see the number of lines of code being produced, not the sophistication of that code.
At the same time, unemployment can be devastating to a programmer who's invested fifteen to twenty years in the same company and is suddenly out on the streets with skills that are at best for technologies in decline and at worst obsolete. Given that most people in this position you have already established families, have mortgages and otherwise have a great deal invested in stability, having to find a new job in such a market can be nearly impossible.
However, one of the facets that such senior programmers do bring with them is experience, and it is precisely this experience that may be most critically needed in the next decade. All too often, when people seek new job opportunities, what they are looking for are those jobs that are closest to their most recent jobs - and that are similar to the jobs that they saw around them in years past.
This is perfectly understandable of course - most of us are creatures of habit - yet the biggest challenges that are faced today are not how best to build a new Internet e-commerce site or better router. Programmers solve problems, and most of these problems have been solved, many times and in many ways. What isn't being solved are bigger problems, social problems that do not necessarily have large salaries attached but that in the long run are ultimately far more important.
The educational system in the United States (and to a certain extent worldwide) is in shambles, a victim of government cutbacks, poor planning, political vindictiveness and ossification of both policies and personnel. The question of teaching and training the next generation needs to be solved in an intelligent matter, not just with better computer programs but also with more participation in the educational process by the people most qualified to teach the next generation how to use the technologies and methodologies that will form the cornerstones of their own lives.
The physical infrastructures throughout much of the "industrial" world have been collapsing through overuse and underinvestment, and again technologists are probably better positioned than most to figure out how to replace the current infrastructure with new ways of thinking about moving people and things around, new ways of making work possible, new ways of structuring our cities and towns that are more in keeping with twenty-first century mores and values than early twentieth.
The financial system is collapsing, and it is hear in particular that programmers and technologists could help rebuild the financial system in a way that provides the maximum amount of benefit to the largest number of people, while reducing the systematic risk inherent in any financial system. In a way, technology was used as a vehicle for "gaming" the system for a narrow number of power brokers, now we need to discover ways of putting that technology in place to insure that the abuses of the past are no longer possible (abuses of the future are a different matter, but another role of technologists is to read into the future to try to at least set bounds on what those abuses could be).
The power infrastructure is fragile and definitely inadequate for present day needs, let along future needs, and without significant work not only in developing new power technologies but the intelligence for those technologies to work more effectively in concert, we'll be facing an increasingly unreliable, unstable network for any new technological development.
The effects of climate change are increasing the stresses on our society, especially as it become more high tech, and as such we need to modernize our approaches not only to weather prediction but also to building communities that are more resistant to these stresses, mechanisms to better handle both evacuation systems and our response mechanisms after such events, and perhaps ultimately figure out ways to diminish the more serious factors contributing to climate change.
Finally, information technologies need to address the ravage of famine, corruption, disease, not just in areas that have traditionally suffered from these stressors but also far more locally, as resources become ever more stretched. We cannot necessarily count on market forces and big money to help solve these problems, but not addressing these problems will be far worse in the long term.
Thus, what all of us are facing is not a shortage of jobs that need to be done - if anything, the need for skilled, talented engineers and developers of all stripes is perhaps even more pressing now than it was a decade ago or more, but we all need to understand that the jobs that need to be done are ones that don't necessarily pay well, at least not initially, and in many cases the jobs require the other skills that trained technologists have - the ability to plan, to organize, to analyze ... the ability to communicate, teach and yes, entertain ... the ability to identify problems and recommend solutions, then to turn these recommendations into reality. That doesn't necessarily come with a job title and a six figure salary, but ultimately it will be these jobs that will be most important in the coming decade.
Thus, as you are planning your next steps in the face of looming unemployment, understand that your next job may not necessarily exist yet as an occupational category, and will in many ways need to be as entrepreneurial as any thing you have done to date. The difference is that at the end of the day, it's also a job that ultimately will mean more not only to you but in the long run to your children and grandchildren. That ultimately is what makes what we do in technology meaningful.