Besides pay and benefits, what would you consider the pros and cons of these non-contractor jobs:
To me, each job is far more dependent upon the people there than the function of the company. I work as a "contractor" (I never move contracts or buildings or desks. I have been here for four years.) in a government agency. However, I work for a group of young, motivated, talented developers and designers.
You can work for a software company or a contractor that has great people. You can work at a software company that is boring and does nothing cutting edge. I think you need to evaluate each situation individually. I have come to learn that the people you work with are far more important than the company you work for.
Pros: Your software could become widely known - good when you look for a new job. You often focus on novel features that will give commercial advantage. Cons: You can be distanced from the users. Features can be at the mercy of marketing people. Rarely get to start something from scratch.
Pros: Close interaction with the users, get to work on real business problems. Scope to innovate.
Cons: People tend not to enthuse about internal applications - they do complain when they break through. May have a less rigorous methodology than producing commercial products.
Pros: Some government software has the scope to positively influence the lives of millions, advance science, etc. Cons: Mostly contractors - very few software jobs working directly for the government. Lots of politics and bureaucracy.
There are definite differences in the work atmosphere.
Starting with #3, government work. The government regulates itself even more severely than it regulates commercial entities, so expect lots of red tape and approvals.
Next #2, internal software. This can be summed up by... The Cobbler's Children Have No Shoes... It refers to the fact that a busy cobbler will be so busy making shoes for his customers that he has no time to make some for his own children. In other words, you will not be the businesses priority until there is a crisis.
Finally #1, external software. This depends on whether the software is a service or shrink wrap, but in both cases it mean that customer is king. If they want something stupid, they usually get it cause they pay the bills.
Now its not all bad as this implies, but these are the big issues to look out for.
I've had the opportunity to work for #1 and #2, and think you should add an option 4: a consulting company. I don't ship shrink-wrapped software, or SAAS. I crank out data-driven web applications for a wide variety of industries, and I think it's the best of both worlds. I get to work on a wide variety of applications and industries, and don't get stuck on any one project for very long. This allows me to keep up on a lot of different technologies, and stay on the cutting edge.
An added benefit is that, as a consultant, we're often regarded as the "Pros from Dover", so our recommendations are often accepted. That wasn't my experience when working as an internal developer at a company (option #2), for a couple of reasons. First of all, you're perceived as "just" a staffer -- so your opinions are often discounted. Furthermore, there's often a big bureaucracy to contend with, along with the associated politics. For some reasons expensive consultants are listened to more than internal developers -- who know the business need better than us!! -- just because they're expensive. Rediculous? Yes. Maddening? Certainly. True? Frequently, yes.
When I kick off a consulting gig, one of the first things I do is ask the customer's IT department what they think we should do. It certainly helps gather buy-in, but usually they have solid, cogent ideas that just got hung up in the "that's not the way we do it" cycle. Even little things -- TDD, using an ORM or framework, etc -- frequently can't be pulled off when an internal guy suggests it. It's assinine, but if the company pays someone $175/hr to suggest it, then the idea suddenly has merit.
The same can often be said of option #1 -- working at a software shop -- for many of the same reasons. Once the managers know you, then the luster has worn off. Your ideas have less merit because you're a known entity. Only a good manager, coupled with a good culture, can get beyond that.
Edit: The downside of consulting is that deadlines are often hard core deadlines. In consulting you'll often work your tookus off as deadlines approach. That being said, the rewards for making your deadlines are often better than in other work environments.
Also, if you're a consultant you always need to be at the top of your game. If you can't keep up with multiple technologies -- be able to discuss them at the drop of a hat -- then you won't do as well as your colleagues who can.
1) Commercial & shipping software is often tedious as you spend extraordinary amounts of time patching and maintaining a code-base that someone envisioned years ago.
2) Internal software revolves around "good enough" and having to accept that the product is riddled with flaws. End users almost always hate the product.
3) Government software usually becomes a "process is king" mantra. You'll be too busy writing documentation that you'll rarely get to develop anything.
1) Working for a company that creates commercial (shipping) software. You might get to work with bright people and experience a well-run software shop! This can be really incredible when it comes together. Also, you might get appropriate training and there's something to be said about working with (and for) people who understand what you do.
On the other hand, you might get pidgeonholed and become a McDev. One of the things I look out for when I interview devs for my consulting firm is people who have been stuck maintaining a small part of a single project for many years. That's not good - your skills can really get dull when you're just churning out reports or cleaning up EDI documents year in and year out.
Also, crazy hours, deadlines, and brutal death march situations are a fact of life in many large companies that ship big projects. That's something to feel out.
2) Working for a company on software used internally. This can be good if the shop is not too bloated. One thing I've noticed in my consulting experience is that the busines units in large companies tend to loathe their IT departments because they can't get anything done and they can't hold on to good people. When this happens, I theorize that it's because they are seen as cost centers and are therefore underfunded. Also, when it goes bad, there are usually empire builders involved.
Also, you might end up taking orders from people who don't really understand development, which is very frustrating. Between the politics and the budget pressure, it can be a real pressure cooker where you never get to make anything really cool and your projects are contantly being cancelled. Or you just spend your days answering trouble tickets and putting out fires. And that sounds miserable.
One of my buddies works on a three-man team for an up and coming fortune 500. It was a great experience for a long time, but they've grown tremendously and now he's stuck dealing with things like ERP nightmares caused by incompetent CIOs. So that's something to keep an eye out for.
3) Working on software for the government. I'm sure someone out there has had good experiences coding for the man, but I don't know them. One of the guys I work with came from a local sherrif's office, and it sounds like it was even worse than your typical horrible IT department. Just brutal. Among other things, they were preventing him from moving to VS 2005 and VS 2008 was already out.
I'm sure there are government groups out there that have sensible budgets, interesting projects, and good management. But that isn't typical.
I have done consulting for the government... All I can say is they give you room to do things right, but projects move incredibly slow. Twice now it has taken over a year for a project to get approved and then it was cancelled a month into development. Seriously.
4) Consulting (secret bonus question) Don't forget about this possibility! I've been consulting for a small firm for 8+ years and I love it. Project work means it's always something new, plus you can stay on the cutting edge and get total life cycle/design experience, which to me is much better than working on a tiny tentacle of someone's enterprise accounting package. You get to do a little of everything.
I feel that doing this type of work has put me way ahead of a lot of the people I've interviewed, some of whom have been in the game longer but have been able to rest on their laurels, whereas I must constantly pull my weight. If I ever want to do something else in the software world, I have the sense that my advantage will be substantial, and that's not because I'm special - it's because I was fortunate enough to end up in a place where I get a lot of variety in my work.
To be fair (and yes, I am biased because I love my job), I will say that there can be a bit of pressure to rush through things and sometimes the people who run these types of shops are often fine with cutting corners. If you're the type of person who wants things to be more of an institution with enterprise-class packages for things that aren't really necessary and so on, be aware that this is the way of the huge bloated institution, not the way of the small sleek consulting team, whos life depends on excellent service and the ability to outmaneuver the lumbering and often inept competition.
It's really about the people and the environment. I'm sure environments like the one I work in could be created in each of your scenarios, however I feel that they are probably the least fragile in small to medium-sized consulting firms or in rapidly growing businesses. In government and large corporations they are probably the most fragile.
I hope that helps!
I just started working in private industry after having worked for a government agencies for just over 3 years and have to say that the main differences I've noticed are the pace that work gets done, and the competence of the people I work with.
Deadlines are a joke in Government. As you get into smaller government orgs, where they can't afford to pay the rates that more senior engineers command, tallented co-workers become scarce because interviews are conducted by non-technical folks who end up evaluating people based on personality.
Working for a company that ships software.
Pros: I think the best part about working for a place that does commercial software is that you tend to switch projects and have new projects introduced moreso than for 2 and 3. Also pay tends to be higher either through direct compensation or stock. Cons: in my experience - a lot of crunch time, job instability, and being at the mercy of your sales department at times.
Working on internal software/tooling.
Pros: Usually the problems are more interesting or intellectual in nature than a commercial company. Also you get to have very in depth knowledge of a certain problem. Cons: depending on where you work, you may get stuck with programming stack/platform stagnation.
Working for the Government
Pros: as RichH said, you may be able to have a positive impact on millions of lives. Also, people working for the government tend to be career employees so I've found that they actually care about the maintainability of a project. Also, due to length of time in a single or few domains, you can really become an expert in multiple areas.
Cons: Like being at the mercy of a sales department in commercial software, you can find yourself at the mercy of politicians that pass laws that are extremely difficult to implement in the given timeline. Also, you'll have to deal with your fair share of red tape and people who are doing the minimum to get by. Wages/total compensation are somewhat less than commercial software companies until you get to the upper echelons. Once you get up to an architect or management position your total compensation will be much less than the same job in the public sector.
I'm currently working on enterprise development for a government agency, so I guess I am presently experiencing a mix between 2 and 3.