Skip to content

Building a great programming career

Ever since Jenny and I wrote Head First C#, I’ve gotten a lot of e-mail and questions from developers just starting their careers. (I think it has to do with the fact that our book has become one of the most popular ways to learn how to program in C#.) But there’s a big topic that we don’t cover in the book, a topic that a lot of our readers really want to know about: how to get a better development job once you’ve finished the book and feel pretty confident with C#.

We get this question every now and then on the book’s forum. And when it comes up, I usually point people to something I posted there earlier this year. I’ve gotten a lot of good feedback from people who were happy to see that advice. But I’ve been getting more e-mails from people who want a little more information. More and more people are looking to improve their job prospects, maybe because they’ve been reading headlines about the economy. So I wanted to delve a little deeper into managing your career in software development.

First things first. It sounds a little silly to state it outright, but it’s worth repeating: the most important thing that makes a good professional programmer stand out is his programming skill. Our readers already know this, because we said it in the intro:

There’s only one way to learn to program: writing a lot of code. And that’s what you’re going to do throughout this book. Coding is a skill, and the only way to get good at it is to practice.

That’s why we included a whole lot of programming puzzles and Lose Weight Exercises throughout the whole book – not just pen-and-paper puzzles, but actual programming problems that need to be solved by writing code. One thing that a lot of junior programmers don’t realize is that programming is about more than just coding. It’s about solving problems, sometimes really tough ones. Solving the kind of problems that you come across at work is a skill, one that improves with practice. And the only way to get practice is to find problems and solve them.

Obviously, Jenny and I think that Head First C# is a great way to get that practice. But it’s certainly not the only way. There are all sorts of projects that you can do. And if you don’t have a project that needs to be done, try thinking of one. That’s what I did back in 1994 or so, when I wanted to learn Perl and I also wanted to learn about these newfangled web servers that everyone was talking about. So I decided to give myself a project: write a simple web server in Perl. Doing lots of projects like that (sometimes for myself, sometimes for others) made me a better programmer, and doing lots of projects will make you one, too.

There’s another thing that I think really helps expand your programming horizons: learn more than one language. There are a lot of peculiarities specific to any one language. On the other hand, there are many general concepts that are common to entire classes of programming languages, or all languages in general. If you’ve only worked with one language, then it’s very hard to know what’s specific to the language you know.

So if you’re starting to feel comfortable as a C# programmer, I definitely recommend giving yourself a Java project; if you’re a Java programmer, do a little C# coding. The two languages are very similar, but you’ll learn a lot from the differences. But if you really want to push yourself and learn something valuable, move away from managed languages and try writing a little C or C++ code. Try picking up a functional language like LISP. Personally, I love assembly languages, and I’ve had a lot of fun learning about microcontrollers over the years. Simply taking a few days to learn enough about a new language to do a simple project can be a very valuable experience for a programming starting out a career. Plus, it gives you something to talk about in an interview!

Coding and problem solving aren’t the only skills a professional software developer needs. There’s another necessary skill, one that’s arguably just as important: working with a team. That’s something I’ve been thinking a lot about lately (since it’s the subject of our next book): what makes a good team, and what programming team members and leaders can do to work better and build better software. There are so many facets to working with project teams, from understanding and interacting with different personalities to finding and fixing roadblocks that keep the work from getting done. And while there are certainly some great books on project teams and teamwork, a lot of them probably won’t make all that much sense to someone who’s completely green.

This used to be a catch-22: you need experience on a software team to get a job working on one, but you can’t get a job working on a software team without experience. But there’s a solution to the problem now that wasn’t available when I was first starting out. There are plenty of open source projects looking for contributors, and even a new developer can make a valuable contribution.

Even if you just volunteer as a tester, or try your hand at fixing a few bugs, you’ll learn a lot about how people work together on software teams. In fact, you can learn a lot just by lurking in the forums and learning how the project is set up. What kind of version control system does it use? Can you figure out how to check out the code and get it to compile? Do they use a continuous integration system like CruiseControl to automatically do periodic builds? How do the team members review each others’ code?

Before you start working on an open source team, I highly recommend reading Karl Fogel’s excellent book, Producing Open Source Software. You can buy it from O’Reilly, but you can also read it for free on the book’s website. It will teach you a lot about both the mechanics and culture of open source teams. (A little disclosure: I was a technical reviewer for the book, and was really impressed with it when I read it.)

I originally meant this to be advice for people looking to start a programming career. But reading back over this, I think that veteran programmers could learn from it too. Of course, if you’re looking for a programming job, clearly there’s no substitute for actually putting years working as a professional developer. But doing these things can help push your career forward, even if you’re already partway through it.

2 Trackbacks/Pingbacks

  1. […] October 30, 2008 Building Better Software › Building a great programming career Posted by mhaden under software development   http://www.stellman-greene.com/2008/10/23/building-a-great-programming-career/ […]

  2. Thoughts on trust @ work « Tamarack Glen on Saturday, November 1, 2008 at 4:37 PM

    […] Thoughts on trust @ work 30 10 2008 http://www.estherderby.com/weblog/2008/10/what-trust-means-for-teams.html […]

Post a Comment

You must be logged in to post a comment.