This is a rundown of the things you should have in your toolkit -- doesn't matter whether you call yourself a software engineer, programmer, developer, code monkey, etc.

Editor

You must have an excellent editor. It should slice, dice, puree and mince, all with minimal effort. Seriously, it should have support for searching across files, "tags" (jumping to the definition of an identifier), ideally provide tooltips for function calls while you're writing, automatic template generation, and pushbutton compilation that can step you through the list of compile errors, if any.

Pick a good editor, and become an expert at using it. It's worth the investment.

Toolchain (Compiler)

I can't really say compiler any more, since many of the languages we're using aren't compiled in the traditional sense. So instead I'll call this the toolchain. For your chosen language, you need to choose the most appropriate toolchain. It may sometimes seem like you don't have much choice: there's only one python, right? Wrong. You have the choice of targeting different platforms (CPython, Jython or IronPython), and also of choosing the version you'll use. You may need to choose an older version so that you can match what's installed on your hosting provider. You may even need to keep around multiple versions — maybe you're a library writer and need to ensure portability across various versions.

Things that are part of your toolchain: compiler or interpreter and runtime. In other words, whatever it takes to make the software run on your customers' computer.

Version Control

AKA VC, software configuration management (SCM), source control. This is a tool that keeps track of the various versions of your software and allows you to work effectively with other engineers. There are a number of different VC tools, with a wide variety of features, complexity and costs.

If you haven't used VC before, take a look at subversion. It's free (open source), widely used, easy to install and use, and stable. There are other tools that may have better technical merits, especially for certain environments, but I think subversion is the best place to start from an ease-of-learning perspective.

Build

For your software to have value for your customers, you need to be able to convert program text into executable software. If your software is a one-file script, maybe all you need to do is publish it to your website. In this is the case, you're allowed a pass on having a build tool, but you should still consider an automated solution.

If you have to deliver something more complex, an automated build tool is required.

Even if you're just publishing a handful of scripts to your website as a tar or zip file, you still need to perform the following: gather the scripts, tar them, name the tarball something sensible, and upload. Do this by hand, and eventually you will skip a step and your customers will end up downloading an unusable mess.

At the opposite extreme, you may have hundreds of files that need to be compiled into a handful of libraries and then linked into an executable. You may have dozens of dependencies on external libraries. Translations to other natural languages. All of this needs to be portable across a dozen platforms.

This is why "make" was invented, and why other tools with similar goals continue to evolve to solve these complex problems. Ant, Maven, Scons, an endless parade of Make variants, etc. Pick the build tool that best works with your toolchain and specific situation.

Review

You need a way to review your work. If you're working alone, it may be enough to simply review your work in your editor — though I'd recommend at least printing it out. For whatever reason, it seems harder / less effective to review a work product in the medium that produced it. A better alternative may be to use the view / diff functionality in your VC tool.

If you're working with others, it will be helpful to install a code review tool that helps package your work product, distribute it to your peers for review, and manage feedback.

Test

Some languages come with support for unit test built in — python includes it in the standard library. You can find a handful of different libraries for c++, and for seemingly any other programming language known to man.

Your testing needs may also require a framework like selenium, which allows automated testing in a web browser.

If you're doing embedded software, you're probably going to have to jump through a bunch of hoops to automate your testing. Unfortunately, you'll have to figure out how big the hoops are, how many you need, how far off the ground they need to be, whether they should be electrified, and then you'll have to build them yourself. Annoying, but very much worth it in the end.

Continuous Integration / Automated Build

Again: if you're working alone you can skip this, though I still think it's useful. To be clear, "continuous integration" is more than a tool. It's a way of life. However, this post is about your toolkit, and CI is a very useful category of tool. There are a number of different CI tools available, each with a slightly different focus and set of features. Pick the tool that has the features you need, connect it to your VC system, and enjoy the automation.

Lint

For those of you who aren't familiar, lint is an old-school tool for finding potential trouble spots in C code. There are many tools available for C and other programming languages that help to sniff out trouble spots in code. Some tools can even spot design anti-patterns. C has lint. Python has pylint. Coverity Prevent is a commercial tool (expensive) that can find deep bugs in C, C++ and Java.

I don't want to advocate sloppy programming practices: you shouldn't need to run lint on your code. But if there's a tool available that can effectively remove defects from my software, I'm going to use it.

("Effective" defined to mean costing less to remove defects than some alternative, which is often either system testing or "customer testing". Before you go spending tons of money on an expensive lint, are you doing code reviews? This is an extremely cost effective practice. Spend your time and money there first.)

I'll continue this in another post. Meanwhile, what's in your toolkit? Favorites from the categories above? Categories of software tools that you want to make sure I don't miss?