How is a "Software Developer" different from a "Software Consultant"? What makes a consultant?

A "Software Consultant" differs from a "Software Developer" based on terms of employment. The "Software Consultant" is hired as a contractor for a specified period of time and for a very specific task/role/project whereas the "Software Developer" (who is not a contractor or consultant) is a full-time staff member on salary, and may have multiple roles/projects within the company. "Sofware Consultant" could refer to a developer/programmer who is employed on a contract-basis rather than a developer/programmer who is employed on a full-time basis. It could also refer to someone who give guidance and high-level project management/design/architechture, as others have mentioned, though in my experiences the title "Software Consultant" usually ends up being someone who works 60-90% of the time as a developer/programmer and is employed on a contract rather than full-time. Any developer can be a Consultant by working as a contractor. To do this it usually is a question of either being a freelance contractor, or working with a consulting firm.

I don't see any different between "consultant" and "contractor" other than that the consultant somehow strikes me as classy and potentially more expensive. :) In either case, I've called consultants/contractors "software developers" when they were working in a development role, but I also expect that when I hire someone as a "consultant" that they are going to do some level of hands on mentoring of the permanent employee team. I expect that when I hire a consultant, I'm hiring someone who already has experience in the technology that I'm hiring them for, and that it's quite possible that most of my permanent team is already coming up speed on the particular details of that technology. So I expect that my team will pump the consultant for information and the consultant will manage to both provide smart time-saving answers to the team and get a certain amount of hands work done at a faster speed/better quality than my just-coming-up-to-speed regular employees. In other cases, I've hired consultants to be permanently "consulting" - meaning they aren't doing any hands on work, they are teaching the team to be a better team or to be better with a given tool or technology. As the other posts say, I don't expect that consultants will be permanent. I do expect that regular employees will be permanent, or at least will have an affiliation with the company that lasts beyond a single project or a short time period. If you want to become a consultant and charge accordingly, I'd say you need some resume building. When I review consultant resumes, I look for a really solid depth of experience on cutting art tools and technologies. It varies from domain to domain, but I'm looking for someone who's implemented complex stuff at the bleeding edge, so that they've already hit the learning curve on the technologies I'm trying to implement. Most of the consultants I know are addicted tinkerers. They work hard in the day time and then spend their evenings running even farther ahead in their areas of speciality because they know that they need hands on skills to sell to their next employment.

Consultants are supposed to improve the business not just develop some software. I've been a developer for over 30 years. I've only known enough to be a consultant for the last ten or so.

How to become a software consultant: Go to a copy shop and print some 100 business cards with your name, your phone number, your mail adress and the title "Software Consultant". Mission accomplished: You are now a software consultant.

It's too bad the question is framed as it is. I think a better question might be "How is a 'software contractor' different than a 'software consultant'?" It is these terms that really raise the question, at least here in the U.S. The term 'software developer' can apply across any type of employment, developer being the type of role or resource one serves. The contractor/consultant issue revolves around employment issues, and again, I am speaking in reference to how it works here in the U.S. But to really answer this question definitively (and you will see, even that is difficult to do!), first we need to define some terms and explore some history. A software developer, regardless of how they are employed, creates software, and probably does many other tasks related to the creation of software, usually with the exception of a management role, although even that is quite common on some projects, such as team leads. Software project and program managers rarely get involved in the nuts-and-bolts activities of creating software (aside from team leads). Again, these are roles. As to employment and payment, there are several types (applicable to U.S.). The most common type of employment is regular or 'direct,' where the worker is on the payroll of the company developing the software. They fill out a W-4 with the employer each year and receive a W-2 from that employer at the end of the year for their taxes. Outside of direct employment, there are contractors, and (depending on definition) consultants. The term 'contractor' is a bit misleading, however. Technically, a contractor is an entity or person who signs a contract with the client company, in this case the one developing the software. But the reality is, nearly all contractors in the U.S. work through a contracting company (also refered to as 'body shops' and even less complimentary terms); they do not 'contract,' per se, directly with the client. These so-called contractors actually fill out a W-4 with the contract company -- not the client -- each year and receive a W-2 from that contract company at the end of the year for their taxes. They are taxed the exact same way as their directly-employed brethren and sisteren. As far as the IRS is concerned all W-2 workers are direct employees. The point here is that it is the 'contracting company' that actually signs a contract with the client company, not the so-called contractors (the 'contract employees'). The contract employees are actually employed by the contract company, and the contract company is the party to the contract with the client. So the contract and direct employees working on a software project are essentially the same in terms of taxation, and usually work in adjacent cubicles with no particular special status, the only major difference being that contractors are limited to a certain time they can continue working on the project for that client. This is because the contracting company they work for is not supposed to keep them there for longer than that time or our IRS may reclassify them as direct employees, and the parties (client and contracting firm) to the contract would become liable for the difference in taxes. In my own experience, contractors are often extended by HR trickery, re-classifying a contract employee from, say, 'contractor' to 'temp' or the like. Clients that wanted to keep me on have done that on occasion. The client companies do have to be careful though; the IRS may audit them to determine the true relationship of those contractors. If the IRS finds that the client has been treating them like direct employees, keeping them on site indefinitely for instance, the client becomes liable for any benefits those (now-regular) employees were not receiving as contract employees. And the contracting company can be liable as well. I do not know all of the ramifications, but it can become messy. Oh, yeah. What is a 'consultant?' That term is kind of 'squishy' -- there have been many wars fought over that sacred territory. It used to be, maybe 40 years ago, that 'consultant' was more-or-less synonymous with 'independent contractor,' meaning a worker who directly contracted with a client. That is, the worker signed a contract with the client (maybe the one developing software, as above). That worker does NOT fill out a W-4 with the client and does not receive a W-2 from the client at the end of the year. Instead, a direct contractor (what was often referred to as a 'consultant' back then) receives a 1099 from the client. The direct contractor usually had their own corporation that paid its taxes at corporate rates and had to obey IRS business tax rules (and of course also enjoyed benefits of being a corporation!). Along with this very different tax arrangement, the term 'consultant' had a certain aura about it. Consultants were generally more experienced (at least 10 years working in the field) and usually had some area of expertise that might have been difficult to locate, making them very desirable to clients, and clients were willing to pay $500 or $1000 a day (a very generous amount then) for their expert services. Consultants ran with an elite crowd of fairly-well connected people, and it was generally hard to break into those cliques. Membership was necessary if one was to be a successful consultant. There was an organization, recently defunct but being revived now, called ICCA which was sort of an old-boys club for computer consultants. Anyone could join, and I did at one point; being accepted and getting work was a different story. There was a niche industry also, especially in places like the financial district of NYC, that specialized in brokering contracts for these consultants. But back then, in order to get work in software -- and especially the financial sector -- one had to be well connected (I know because I had tried back then). Today, these brokers have been swallowed up or run out of business by the big placement companies. Independent contracting has been nearly eviscerated (it does exist, but that sector is much smaller now, nearly non-existent) by a series of legislation that has slowly and certainly destroyed independent contracting like that. Today, the term 'consultant' is rarely used in the software development employment realm. At least, I have rarely heard it. Sometimes a contract software developer is referred to as a consultant, but it is hardly any distinction other than, perhaps, some attempt to flatter or compliment some particular contractor for their expertise in a throw-back to that earlier tiem when the term meant something special. I should state that there are still software project managers called "software management consultants," but almost all of them are also direct employees to some contractor company that performs the same purpose to these management contract employees as the companies that provide the W-4's to those software developer contract employees. And, as you might imagine, sometimes they are the same contract firms. Some clients want to deal with one source of workers for both developers and managers working on a project. Genuine, independent software consultancy in the U.S. is mostly dead thanks to changes in federal legislation and the changing landscape of corporate America. As companies (potential consulting clients) get larger, their HR departments become more brutally centralized, arrogantly efficient, and technologically black-boxed. It is nearly impossible these days to contact a hiring manager to discuss an employment opportunity of any kind, direct or contract. Part of this is corporate secrecy and employee protection, but a lot of this is the trend toward ensuring that as many workers as possible are direct employees, or at least working through a contracting company. The alternative to this scenario, similar to that earlier time of 40 years ago or so, was quite different. Back then, it was more difficult for employers to control the work of their contracted employees, especially the consultant type. Control of workers has been increasingly becoming the main issue of employment in the U.S. to ensure increasing productivity which, in turn, is important for competition with nations like India and Vietnam, whose workers are even more accustomed to ever-increasing demands of productivity. The key to understanding all of this is to understand that the independent contractor cannot be told exactly how or when to do their work. They usually must provide their own tools. They have to comply with about 20 of these types of constraints for the IRS to recognize them as legitimate independent contractors. Otherwise, those legal issues I referred to above kick in, along with potential lawsuits between contract employees and their contract companies for back-benefits that would then be lawfully due to them. Sorry for the long-winded explanation, but it really is this complex. I am a software developer who has worked direct for companies and through contract companies. I have many times considered going "indy" but that has become a very treacherous (and intimidating!) road to follow in recent decades. And the corporations, plying and leveraging their influence in government, continue to tighten up this arrangement. The American Software Consultant is dead; any remaining survivors are suffering their last breaths.

My understanding of "consultant" is someone who does both the business analysis (requirements gathering) and at least some software design/development, although they don't get quite down as far into the trenches as a fulltime software developer. IOW, consultants wear multiple hats, whereas developers wear the one hat.

What is a consultant? A consultant is someone, who takes away your watch, tells you the time, charges money for it, and also keeps your watch.

Consultants are more paid for each hour they work. But as a permanent full-time developer in your company, you get your salary each month. Your job is "safer". Young people like challenges and like to work as consultants. This is nice if you like to see new faces, have more responsability and independence. I suppose after marriage and children you prefer "security" rather than "adventure". You like to know what's going to happen next week, etc. I'm not sure the pay is the most important point here. Working alone has a lot of advantages. You can't buy happiness with money, and sometimes I'd rather earn $500 less each month (althrough if you work at home you don't have to pay for transporation for example) than work on shitty projects, in the busy 10-persons-per-room environment with delays and everything... It's the same as working as an employee or create your own business. (althrough there is almost no investment to do as an alone software developer)

In my own experience, there is a consultant in the company I work for and he has the role as a developer but worse, he has no clue what he's doing and he comes to the office just 2 or 3 days a week for around 3 hours, and he earns more WTF!? hahaha