The path from birth to death is filled with choices about where to work and what kind of work to do. Sometimes the world is nice enough to allow us some input. These days, developers have a lot more say in their employment, thanks to rising demand for their services.
Whether you're an independent contractor or a cubicle loyalist with a wandering eye, programming want ads abound, each stirring its own set of questions about how best to steer your career. For some, this is entirely new territory, having fallen into employment with computers simply as a means to scratch an itch.
[ Beware the 7 myths of programming, and verse yourself in the 10 hard truths developers must accept. | Learn how to work smarter, not harder with InfoWorld's roundup of all the tips and trends programmers need to know in the Developers' Survival Guide. Download the PDF today! | Keep up on key application development insights with the Developer World newsletter. ]
The following nine concerns are central to charting your career path. Some target the résumé. Others offer opportunities for career growth in themselves. Then there are questions of how to navigate unfortunate employment issues particular to IT. Thinking about your answers to these questions is more than a way of preparing for when someone comes to ask them. It is the first step in making the most of your interests and skills.
Will certification give you an edge?
A common dilemma facing career-minded developers is how much attention to pay to certification. After all, employers always want to determine if you really know what you claim to know, and tech companies are always stepping forward with certificate programs to help them.
The programs are aimed at teaching a given technology, then testing your competence with what was taught. They focus on practical solutions, not theoretical conundrums like most university courses. Thus, they appeal to companies looking to vet candidates in their ability to deliver real-world solutions.
The key question for developers, though, is whether there's any real demand for a particular certificate. Most cutting-edge technologies are too new to be testable, so employers look for other evidence of ability. The real market for certification will always be in bedrock tools like running an Oracle database or maintaining a fleet of Microsoft boxes. Companies that depend on Oracle or Microsoft will usually pay extra for people who've already demonstrated a skill. When your certification and the employer's needs align, everyone is happy.
But developers need to choose carefully. Preparing for exams takes a fair amount of time, and the questions often test trivial knowledge -- the kind usually provided by automatic tools built into today's powerful editors. I've taken several exams about the Java stack and thought to myself: Knowing that fact is Eclipse's job, not mine.
Certificates often have a limited window of usefulness as well. Being an expert on Windows XP was great 10 years ago, but it won't help much today -- unless the company is sticking with XP until the bitter end. You can often find yourself getting certified in versions 1.0, 1.1, 1.2 of a product.
What is the true value of a computer science degree?
If it's hard to discern whether a professional certificate for a particular technology is worth earning, it's almost impossible to decide whether to invest in traditional collegiate degrees. All it takes is one look at leaders like Steve Jobs, Michael Dell, Bill Gates, or Mark Zuckerberg to know that a bachelor's degree is not a prerequisite for changing the world.
But traditions die hard. Some companies simply insist on a bachelor's or even a master's degree because it's an easy way to cut their pile of résumés, or offers a measure of some intangible quality like a deep interest and versatility in working with computers. Whatever the reason, a significant number of people continue to believe that a sheepskin is essential, so developers with an eye on the want ads encounter the dilemma to stock up on diplomas time and again.
[ Want to cash in on your IT experiences? InfoWorld is looking for stories of an amazing or amusing IT adventure, lesson learned, or tales from the trenches. Send your story to email@example.com. If we publish it, we'll keep you anonymous and send you a $50 American Express gift cheque. ]
The practical value of a collegiate degree is controversial. Some find the typical university curriculum too focused on theoretical questions about algorithms to be a meaningful benchmark in the workplace. The professors are more interested in wondering whether the running time can be predicted with a polynomial or an exponential function.
Others believe that this abstract understanding of algorithms and data structures is essential for doing a good job with new challenges. Languages come and go, but a deep understanding lasts until we retire.
Should you specialize or go broad when it comes to programming languages?
A good developer can program in any language because the languages are all just if-then-else statements wrapped together with clever features for reusability. But every developer ends up having a favorite language with a set of idioms and common constructs that are burned into the brain.
But the newer languages are often seductive. Not only do they solve the problems that have been driving us nuts about older languages, but no one has managed to articulate the new aggravations they offer.
Employers are often as torn as developers when it comes to committing to a new language. On one hand, they love the promise that a new programming language will sweep away old problems, but they're also prudent to be skeptical of fads. A technology commitment could span decades, and they must choose wisely to avoid being shackled with a onetime flashy langauge that no one knows any more.
For developers, the best position is often to obtain expertise in a language with exploding demand. Before the iPhone came out, Objective-C was a fading language used to write native applications for the Mac. Then things changed and demand for Objective-C soared. The gamble for every developer is whether the new FooBar language is going to fade away or explode.
Should you contribute to open source projects?
The classic stereotype of open source projects is that they're put together by unkempt purists who turn up their nose at anything to do with money. This stereotype is quickly fading as people are learning that experience with major open source projects can be a valuable calling card and even a career unto itself.
The most obvious advantage to working on an open source project is that you can share your code with a potential employer. There are no nondisclosure agreements or proprietary restrictions that keep you from sending out a pointer to your corner of the project and saying, "I wrote that." Anyone can look at it. If you've achieved committer status, it shows you work well enough with others and know how to contribute to an ongoing project. Those are valuable skills that many programmers never develop.
Some of the most popular open source projects are now part of enterprise stacks, so companies are increasingly looking for developers who are part of the community built around the open source projects on which their stack depends. One manager at a major server company told me he couldn't afford to hire Linus Torvalds, but he needed Linux expertise. He watched the Linux project and hired people who knew Linus Torvalds. If the email lists showed an interaction between Torvalds and the developer, the manager picked up the phone.
Many open source projects require support, and providing this can be a side job that leads to a full-time career. Companies often find it much cheaper to adopt an open source technology and hire a few support consultants to make it all work, rather than go proprietary.
Savvy programmers are also investing early in open source projects by contributing code. They can work on cutting-edge open source projects on the side just because they're cool. If the project turns into the next Hadoop, Lucene, or Linux, they'll be able to turn that experimentation into a job and, quite possibly, a long-lasting career.
How do you work around ageism?
What does every tech recruiter want? An unmarried 21-year-old new graduate of a top computer science institution ready to work long hours and create great things. What about a 22-year-old with a year of experience? Uh. Maybe. Perhaps. Are there any 21-year-olds available?
One of the great, often unspoken, rules of the programming world is that managers have very narrow ideas of the right age for a job. It's not that managers want to discriminate, and it's not that humans want to change as they get older -- but they do. So everyone clings to stereotypes even if they're against the law.
This is often most obvious in the hypercompetitive world of tech startups, where the attitude is like the NBA. If you got stuck finishing your degree, you're obviously not special enough. This world prizes people who spend long hours doing obsessive things. They like youth, and it's not uncommon to hear venture capitalists toss aside anyone who's not a younger 20-something.
The good news for programmers is that some employers favor older, more mature people who've learned a thing or two about working well with others. These aren't the slick jobs in the startup world that get all the press, but they are often well-paying and satisfying.
The savviest programmers learn to size themselves up against the competition. Some jobs are targeted at insanely dedicated people who will stay up all night coding, and older programmers with new families shouldn't bother to compete for them. Others require experienced creatures, and young "rock star" developers shouldn't try to talk their way into jobs with bosses who want stable, not blazing and amazing.
How much does location matter?
If you're young and willing to pack everything you own into the back of your car and move on, the only thing that's important about the location of a job is whether you like the burrito place next door. Good food and pleasant surroundings is all that matters.
But where to seek your next job becomes a trickier question when you can't pack up your car in 10 minutes. If you have a family or another reason that makes a nomadic coding life difficult to impossible, you have to think about the long-term stability of a region before committing to a new employer.
Many programmers in Silicon Valley move successfully from startup to startup. If one doesn't work out, there's another being formed this minute. There's plenty of work in different firms, and that makes it easy to find new challenges, as we're taught to say.
This may be the major reason that some firms have trouble attracting talent to regions where there's only one dominant player. If you move to Oregon or Washington and the job doesn't work out, you could be moving again.
Can you choose a niche to avoid the offshoring ax?
Lately many programmers have begun to specialize in particular layers. Some are user interface geniuses who specialize in making the user experience simultaneously simple and powerful. Others understand sharding and big data.
The growth potential of a career in a certain layer of the stack should always be considered, in particular in relation to its vulnerability to offshoring. Some suggest that user interfaces are culture-dependent, thereby insulating user interface jockeys from offshoring pressure. Others think it's better to pick the next big wave like big data warehouses because a rising tide lifts all boats.
While change is a constant in IT, it may not be practical to jump on every wave. If you have terrible aesthetic judgment, you shouldn't try to be a user interface rock star. Nor does it make much sense to try to sell yourself as a big data genius if you find a statistics textbook to be confusing. There are limits to how much you can steer your career, but there are ways to play a new wave to your strengths -- and to make yourself immune to offshoring.
Should you strike out on your own?
An increasingly common career dilemma is whether to stay full-time or switch to being a contractor. Many companies, especially the bigger ones, are happy to work with independent contractors because it simplifies their long-term planning, allowing them to take on projects without raising the ire of executives who sit around talking about head count.
The biggest practical difference is figuring out health insurance and pension benefits. An independent contractor usually handles them on their own. Some find it to be a pain, but others like the continuity they get by keeping the same independent health insurance or pension plan when they switch contracts.
Another big difference is in what you like to do. Regular employees are often curators and caretakers who are responsible for keeping everything running. Contractors are usually builders and problem solvers who are brought in as needed. Those aren't absolute rules, but for the most part, those who stick around get saddled with maintenance.