Can you choose your tools or do you take what you get?

Question

I often see questions about what tools to use for a particular problem, or suggesting that one tool is preferable over another, and that it says something about the quality of the programmer who uses the subpar tool. Some of that is religious arguements, but some tools generally are considered less than ideal.

In every job I've had, the environment and tools are already bought and in use. I start using what they have, and while I might have some small say in a future direction, have no say in the current environment.

Is it common for a company to allow the programmer to choose the tools they will use? Or is it more common that a programmer is dropped into an existing environment, and they make use of what they are given? I'm guessing a contract programmer has more say than a FT programmer -- true?

(For an example, at my previous job we used Access for a database, Visual C++ for a programming language, and Visual Studio for an IDE, with WinXP for an OS. We also had Source Safe and Test Track. So, that's what I used. In my current job I get SQL Server and Oracle instead of Access, more ColdFusion than C#.net and VB.net, and we're moving from XP to Win7.)

Answer 1

Generally compiler, target, and source control are mandated, and a default is provided for everything else, which you are not required to use, but if it doesn't work, you're on your own.

For example, I use my own editor, my own diff/merge gui, and git on top of my company's centralized source control. I usually use the default IDE's compiler and debugger GUIs, but I have my own build script that integrates better with my editor when I have a lot of compiler errors to fix. I write embedded software, but it's sometimes useful to write a test program that runs natively on my development environment, so I have a completely different compiler of my choice for that. One-off scripts for various purposes I write in python. One of my most useful tools is a custom wireshark plugin I wrote.

Basically, as long as you are productive, all but the most draconian companies don't mind what tools you personally use, as long as you use standard tools where they need to be the same for collaboration purposes.

Obviously, I feel I am more productive with the tools of my own choosing, as many of them I have used far longer than I have held my current job, but I also have colleagues who have become just as proficient at the default tools provided.

Answer 2

IME usually we are stuck with what is mandated, whether or not it's good or suited to the task. I prefer environments where I can choose my own tools that help me be more productive, but they are rare.

Things like IDE, source control and bug tracking systems need to be standard, IMO (although you can still use things locally e.g. use Git locally but then push your changes out to the company's SVN server) but I'm also a firm believer that the tools used should evolve at a consistent pace - you don't want to be stuck using legacy tools when there are better tools, or your productivity suffers.

Answer 3

It varies quite a bit, but it's certainly not uncommon to find workplaces that allow their developers to choose tools. There are going to be projects that have a very strong affinity for certain tools and others where developers have more free reign, even within the same company as well. For example, at my current position, there are projects with essentially no latitude in tool choices (iPhone client, for example), some with limited choices (Android client as an example) and ones where there is quite a bit of diversity on the team as to environment and tools (Python backend services as an example). Management is also not prescriptive with respect to additional tooling, so the dev team chose our continuous integration tools and even swapped them out when the old ones weren't working for a project.

There is certainly value in having a relatively homogeneous set of tools among a team, since the team can mutually support each other and can leverage the work of each other as far as custom tooling built on top of the basics. But the better places I've worked have had quite a bit of freedom as far as choices, and what was important from the viewpoint of management was that the work was being done, not the specific tools that were used. Probably the biggest exception to that is bug tracking, since that often is a company-wide tool and most teams won't have free choice as far as what to use.

Answer 4

The basics are usually set. There are tools everybody really has to agree on, like which compiler and build tools, which issue tracking system, which source control, and so forth. Those are usually mandated. In addition, the production system will use certain things, and therefore you will need to use those in development and testing.

In the jobs I've had, I've usually been able to add other tools as I pleased as long as it was free and legal. In one case, I was restricted to a large repository of available software that had been approved by somebody or other, but I was able to get the tools I wanted from there.

Many tools cost money, and that's another matter. I typically haven't used them, but it's always possible to ask your manager about them.

Answer 5

Taking what you get shows you can use existing tools and have talent and are flexible enough to be productive regardless of tools.And its easier to communicate , and easily facilitates problem solving in a team when every one uses the same tools.

IMHO it may be worthwhile to show the talent of artist is not defined in the brush he wields but rather in the painting he creates.

Answer 6

I've usually had to take over the previous developer's computer and tools. Once you prove yourself, you can ask to purchase what you want as long as it fits in with the team. Sometimes a new project can prompt an upgrade or new tools depending on the nature of the app.

Answer 7

I usually found a combination of provided/personal tools.

As several people already pointed out, the deeper you get into development, the more likely it is, that the tools are already set. When the company usually implements applications in Java you will use the compiler already there (there aren't many to choose from anyway). You also most likely won't be able to introduce git on the fly if Subversion is already in use.

Often that's the where the provided part ends.

When moving to IDEs, I usually bringt Eclipse. If it's already in place wonderful, if not - that's the tool I use. Same thing goes for other types of tools (editors, screen capture utilities, etc.).

What matters is the outcome (the text file, the image, the source file) and not the way it's produced. You don't tell a plumber coming into your house "Here is the wrench I always work with - I suppost that's good enough for you" but you let him bring the right tools, or rather the tools he thinks are best suited for the job you want him to perform.

Answer 8

We have a set of officially supported tools. However, you're allowed to use anything (legal) that you want as long as it doesn't affect your work adversely. It is your responsibility to play nice.

For instance, we use a pretty old and official version of Eclipse rather than newer release candidates and previews, because we have a lot of important internal plugins that are not yet upgraded to these preview versions.

In my previous jobs, I worked with Java with no plugins so I could always use a preview version.

Since I felt that the company plugins were more useful than the new features of Eclipse, I begrudgingly accepted the use of an older version.

Answer 9

Usually it is a tech architect who decides what tools to use for a new project. The decisions are sometimes dependent on the resources available. For instance companies X and Y are both biding for the same project. If X has more Java resources on bench they may promote Java as the solution while Y may promote C++ as the solution because they hae a bench strength in C++. For the subsidiary tools(add ons such as the documenting tool or mocking framework) , I beleive it is rare that individual developers decide which tools are used. compaines may force you to use a particular tool instead of a more suitable one because they have licenses available and dont want to "waste" money on new one. However sometimes you may get to choose subsididary tools since they do not affect the main project

Answer 10

In most of my jobs I've had a fairly large amount of leeway. The things that are mandated are things like version control, where collaboration is important (although even in that case, nobody much cares what client you use, as long as it supports the VCS you're using). There are certainly situations where the project requirements mean that there is really only one or a few tools that could reasonable be selected, but that's not so much a mandate as a lack of viable alternatives.

I see having tools mandated as a major job smell. To me it indicates a company thats more concerned with process than productivity or morale.