wandercoding.com

I was reading Jeff Atwood’s post on Programming: Love It or Leave It which was derived from a Joel Spolsky forum entry. This got me thinking about some of the responses and some of my own experiences. I’ve mostly worked on products as opposed to IT departments. As Joel points out in one of his responses, “[you're] going to get more out of computer careers if [you] work in a product company.” This is because products tend to be longer life projects, tend to suffer less from budget cuts than internal IT projects, and mostly because they involve more design and creativity components as you have to try to appeal to customers who don’t have to buy from you. In a product company, you’re more likely going to have to produce software for sale as opposed to maintaining databases, hardware, or software, or another of hundreds of mundane tasks.

There are so many possibilities in the computer programming world. When I talk to people about what they’re looking for in their next job, I point out that there are many different possibilities. Small product start-ups, small companies with established products, large product companies, web-site companies, web-site design and consulting companies, large and small embedded software companies, IT service companies, non-software companies with IT departments, universities with research programming needs and IT needs, and many, many more.

Each one of these places offers different kinds of work. Some people have said that there is a shift in programming going on today. My friends who work for a large software product company spend a good amount of their time designing code for people in China to write. They get software back that may or may not work well and may not be up to par. Then they have to either request changes or fix it themselves. They tell me that it would be easier and more efficient to simply write the code themselves. Either way, this is what’s happening at that company and they don’t believe it’s going to change any time soon.

If you don’t like what you’re doing there are several choices. Do something entirely different and quit programming. This is the extreme approach. Alternatively, find a different kind of company or software. Your experience is transferable, but you may have to convince potential employers of this. Doing some personal projects can help fill in missing job experience. For example, if you’re in web programming and are looking to move into a product atmosphere, download a Java environment and develop a small shareware or freeware application. You’ll have something tangible to point to and you’ll find out whether you really like doing that kind of development work.

There’s a world of software out there, some of it hiding where you might not suspect. Do some web searching and personal networking. The economy may stink right now, but there are many companies that still need to get work done and there are jobs out there if you dig enough.

I’ve been doing this for a long time – over 22 years, in fact. A couple of years ago I started to lose the love of programming. What happened? It was a conglomeration of things. I worked for an idiot boss for a year. I worked on a large project that was very touchy and was full of spaghetti code. Changing something that fixed your problem always caused something else horrible to happen. Probably the worst things were that I no longer felt like a vital part of the decision-making process and had been relegated to being a cog.

Being a small cog in a large machine is not unusual for a programmer; some people actual prefer this kind of role. They enjoy going to work, being given a set of tasks to complete to given specifications, and going home at night without worrying about what’s next. However, this doesn’t suit everyone and it sure doesn’t work for me. I need a little freedom. Freedom to design my code, my UI (or at least have some feedback into it), my platform, my tools, and my environment. After working in C++ for many years, where everything is hard because hardly anything is built in, the constant struggle to get a simple job done and the fact that everything takes days or weeks can get to you.

So, how do you find the love again? First, try to regain some control over your domain. Lobby for some design input. If your product is defined and designed by a product manager, marketing group, or product designer, ask to be included in the design discussions for the next release. It never ceases to amaze me what assumptions are made about implementation by people who don’t actually implement things. It also boggles the mind how complicated some people can make even the simplest tasks because they think it will be more elegant. Users like to use slick, beautiful user interfaces, but they also want to get their jobs done as quickly and easily as possible. How many UIs have you used that seem like it takes 5 steps to get somewhere when 1 or 2 is all it should take?

Second, start to take control of your environment. Are you using a reasonable IDE or editor for your coding? There are lots of choices, but whatever you pick should be helping you do your work more easily. Do you have help with formatting, automatic code completion, and UI development? If not, and you think it would help, get a hold of something better. Convince your boss that the money spent on better tools will cost less in the long run because it will save you time.

Third, if you find that every task in your application looks like you’re slogging through the jungle or that you have to constantly build things that just ought to be there already, make it happen yourself. Change your mindset for a minute. Start thinking about what kind of functionality should be just built into your environment. Could you use a easy interface to file saving and loading, a better string library, or something else? Rather than simply building it into your next piece of code, think about making it part of your new toolkit. Turn this functionality into a library or module of its own. You’ll end up with something more reusable and that will help you and the rest of your team for a long time to come. Be sure to document it with some comments, a few examples, and a brief overview. I’ve found that as soon as I start to write a little documentation on something (even if it’s not extensive documentation) that I realize that I could make the design easier to use and understand.

Chances are, you may already have code in your system that could be reused if were simply packaged better. Instead, people just cut and paste code or have to figure it out on their own. Refactor the code into a toolkit and users of the toolkit. Future coding will be much easier.

Have you ever noticed that every time you have to use some code, you have to read the function or method definitions or even the code carefully to figure out what it does. These are great targets for a little refactoring, commenting, and light documentation. Even some simple function renaming may make things clearer and easier to use.

Taking control of what you’re doing and how you do it, can help you start to find the love again. Try it.

I wrote a while ago about how writing software and writing a book were similar. It’s my pleasure to announce that Design, Code, Test, Repeat: Your Instruction Manual for a Great Software Career is now available! Go here for more information.