Be sure to check InformIT for a new article every Wednesday. See more advice from other programmers here.
Most Frequently Used Programming Language:
I recently attended a panel with famed science fiction writer R. A. Salvatore. A young woman in a white tank top screen printed with the message "I ♥ NERDS" asked Mr. Salvatore what advice he had for new and aspiring writers.
"Quit, quit if you can," he said to a nervous uproar of laughter. He explained that if you can go long stretches without writing, if you can go about your life without stories bubbling up ready to be told, you should not be a writer. It reminded me of Rainer Maria Rilke's Letters to A Young Poet, a posthumously published correspondence between Rilke and a military cadet considering a writing career. In the first letter, Rilke advises the young cadet to not be distraught that editors are rejecting his work. Instead he suggests, like Salvatore, that one look inside, writing (or in our case programming) to feed that inferno that burns within.
Computer Science moves at the speed of light. It's not bad to have a specialty. But to complement that depth, you should have a breadth of knowledge in areas outside your comfort zone. This can allow you to adapt to the market as languages and frameworks come in and out of favor. I started my career as a Java Swing developer that hated web development. Now it is most of what I do. Quit learning and you will quickly find yourself on a perilous cliff unable to progress or descend.
Many companies use a coding exercise as some part of the interview process. While exercises aren't 100% predictive, they do convincingly gauge how applicants think on their feet. The more practice exercises you do, the more relaxed you will be in your interviews. Even with practice, you probably won't write flawless code, but you will be able to quickly recognize mistakes.
3. Read The Mythical Man-Month by Fred Brooks.
The book is a collection of essays on software engineering and project management. It should be required reading for all developers and managers. You might notice projects violating the rules presented by the book. In the best of cases, you will be able to change the course of the project in a positive manner, and in others, you will be powerless to do anything. But knowing is half the battle.