Bruce Eckel just posted a blog post about how to get in to a career in computing. He starts by posing the question "should I learn C++ or Java?" and throughout the post indicates how thoroughly irrelevant that question is to a successful computing career.

It's a great article overall, but based upon my experience, I think this statement Bruce makes in his post rings truest.

"When the Internet was first booming, all you had to do was spend some time learning HTML and you could get a job and earn some pretty good money. When things turned down, however, it rapidly becomes clear that there is a hierarchy of desirable skills, and the HTML programmers (like the laborers and sheet rockers) go first, while the highly-skilled code smiths and carpenters are retained.

What I'm trying to say here is that you don't want to go into this business unless you are ready to commit to lifelong learning. Sometimes it seems like programming is a well-paying, reliable job -- but the only way you can make sure of this is if you are always making yourself more valuable."

He also lists the output of a seminar where participants highlighted qualities in ideal job candidates for software developers.

"There is no right answer ... and always a better way. Show and discuss your code, without emotional attachment. You are not your code."

I've worked with a lot of different programmers in my career, and I've found that the best ones had these two qualities Bruce describes in common: a commitment to lifelong learning and emotional separation from their code.

The guys I worked with who had not committed themselves to lifelong learning typically fell in to the category of people who learned a language because programming jobs in that language were hot at the time they got in. If these are your motivations for becoming a programmer, I have very simple advice for you: choose another career.

People who learn one hot language just to get a job mostly find themselves ten or more years later as one-trick ponies on outdated software platforms. Since they have no real interest in learning anything else, there's a huge degree of insecurity associated with learning anything new, which has a direct impact on how they react to ideas to improve their trade. This is easy to spot; instead of welcoming alternative approaches for their merits and engaging in debate, these guys are the ones who will dig their heels in against change and do everything they can to maintain the status quo, regardless of whether or not the solutions are meeting the needs of the end users/software requirements. This is a one-way ticket to a dead-end career.

I like to consider myself in the other camp, which is programmers who embrace the lifelong learning process. However, I also try to be realistic about my ability to stay in this camp for the long term; there are trade-offs to both career choices.

To be clear, I love writing software more than anything else about my work, but I also enjoy the occasional breaks from the "grind" when my management responsibilities take center stage. In short, writing high-quality software requires a ton of focus and discipline, and unless you take constant pleasure in this you will find yourself hating your job. When you hear about engineers getting burned out, it's usually due to being forced to stay in a focused state for an extended period of time. Both (a) the need to constantly change your methods and approaches, and (b) to learn entirely new languages to produce the best solutions and leave your old skills behind require a huge commitment both personally and professionally. Case in point, after ten years in the field, I'll be learning Groovy from one of the guys on my team next week since we determined that the Grails platform will be the best thing to support our web service endpoints.

While I don't know when (if ever) I will get burned out, I could definitely see myself leaving coding behind one day in the future. I'd still be involved with software, but I would replace coding with more managerial responsibilities, perhaps focusing more on software team management or product management needs. If that day ever comes, I think I'll always be a tinkerer; after all, if you love programming, that love stays with you forever. I learned last week that my periodontist used to be a UNIX programmer before he got burned out, and he still messes around with coding on the weekends.

I had a chance to get out of coding earlier in my career, when I took on a senior management position. It's a lot easier to manage software than to produce it as your personal output, and in a different company I probably would have stayed with the management role. However, the company I worked for was not a technology company, and this meant that I spent more time managing the concerns of the business than the development of their software. Since my passion is ultimately for software, I just didn't care about my career continuing in that direction. I've since made the switch to work in the tech sector, and can now honestly say that if I was given the choice between a career developing software in the non-tech sector and switching careers, I would switch careers. So, even if I end up in a primarily managerial role in the future, it will be for a tech company.

In closing, my advice for budding software engineers is this.

1) Know that you love software before you commit to it. You'll know when you take your first pseudocode class: a clear division forms between the people who get it and the people who don't. If you're in the "don't" section, choose another career.

2) If you don't like teaching yourself new things, the skills you learn today will be irrelevant in less than a decade. Accept the commitment to learn throughout your career as a coder, or accept your eventual fate as a has-been.

3) College degrees matter less than hands-on knowledge and time spent at the keyboard. I outpaced my entire class in college because I bought my own programming books that deviated from the coursework, and as a result I learned things they were not teaching in school.

4) College degrees still matter. There was a lot of stuff I missed in my two-year AS degree at a community college that I ended up learning either through experience, or by rubbing shoulders with colleagues with four-year CS degrees. If you can't make it through four years of school, make sure you pick up a book on programming algorithms and learn the classics before you hit the workforce.

5) Early on, decide if you want to focus on application development or software engineering. Application development deals with making user interfaces, interfacing different systems together, solving business process problems, and exposing applications to the outside world (i.e. web services and other remoting techniques). Software engineering deals with creation of utilities and processes that support information processing, tends to be more math intensive, requires a lower-level understanding of the trade, and rarely deals with the systems that expose the software to an end user. There are core differences in these two disciplines and 100 shades in between, so figure out what you like.

6) Once you know what you want to do, seek a job that puts you in an apprenticeship role with an actual person as your mentor. Companies that support co-op programs and allow you to learn from a mentor while contributing to a team produce the best engineers. If you find that you are plugged in to a position like a cog in a big machine, and have "ivory tower" designers/architects handing out instructions without teaching you the "why", find another job.

7) If you decide to program software for a company whose core business is not technology, know that in most of these companies the quality of the software is not important, and your role in the organization is considered expendable. In these companies, IT is usually the first department to get cut when things go south, and you will sometimes be forced to make crippling compromises in the quality of your applications to meet short-term business needs. That being said, you will often get the opportunity to directly impact the work of people who you see regularly and share in the success of the businesses your software supports, so there are tangible rewards to this avenue.

8) If you decide to program software for a company that sells their technology, they tend to treat their engineers better than corporate IT shops, and cut their engineering staff last when things get bad. On the flip side, in tech companies there is a lot more pressure to produce and meet deadlines; if the software doesn't get produced, there is nothing to sell, and the company goes under. You will also be less connected to the people who use your software since they often don't work for the same company.

9) The languages you can program in do not define your capabilities as an engineer, but they do determine how easy it is to achieve the goals you are tasked with. A language like C++ produces the highest-performance software, but becomes riddled with complexity when you want to use it to produce user interfaces or deal with cross-platform applications. Languages like Java and C# are great for producing applications, but can't match the raw speed of C++. Almost all the GUI toolkits are a pain in the ass, but are a necessary evil to produce end-user applications (if you can't stand pushing pixels around all day, don't become an application developer). Dynamic languages are more flexible and easier to make mistakes with; compiled languages tend to be faster and more precise, but can sometimes make you feel like you are wearing handcuffs. My recommendation would be to learn C, plus either Java/C#, at least one web-development UI language (Flex, XHTML + JavaScript, etc.), and at least one dynamic language; you will learn things from each that make your mastery of the others more complete. They will also help you learn what your preferences are, and help you decide what you want to specialize in.

These thoughts are obviously just my own experiences, but hopefully you will find them useful if you are considering getting in to the field. Whatever you decide, if you love programming in school or as a hobby I can assure you that you will also love it as a job. I wake up every morning and can't wait to get to work to fire up my IDE and knock out some more code.