Suggestions not to make when starting a new programming job

When starting a new programming job, it can be risky to suggest certain things. Others at the company do not know you well enough, and saying the wrong thing will immediately create a bad first impression, branding you as too inexperienced for your role or not a team player. Make one of the following suggestions, and your new job may not even last you a week.

Let's rewrite the codebase for the application in another language.

If you weren't hired as a design consultant or to re-engineer the big-picture, suggesting to rewrite a key application in another language is almost certainly going to get you fired close to immediately.

There can be many good reasons why an existing code base is in a particular language:

• It's a language all the other developers at the company already know.
• It's the only language certain key libraries exist in.
• The language for whatever reason excels at what is being accomplished with it.

In any of these situations, your suggestion is saying to switch to something the existing talent is unfamiliar with, or an admission of not understanding the scope of what is being done. In the former, you've just admitted to not being a team player, in the latter, you've admitted to having too little experience. Further, such a suggestion will indicate you probably are not as experienced with the language as your resume or initial interview seemed to convey, and perhaps you're a liar as well.

Additionally, even if none of the above reasons are valid for the case at hand, no manager wants to delay a project to rewrite everything. Furthermore, rewrites are nearly every manager's nightmare, as they fear new bugs being introduced. All this combined, expect little job security when making such a suggestion early on.

If you're tasked from the get go with fixing some small script, you can probably get away with changing the language - if you get approval first. But ask about it in a way where it is clear you are concerned what is best for maintaining it by others in the future, not as what is easiest for you and shows indifference to the company's needs.

This applies to any sizable rewrite in general. Few will care about rewriting some small script or component. But offering up front when no one knows you to rewrite a large project, even in the same language, is just asking for trouble. Sizable rewrites normally aren't done unless there's a team in place that are already known to be able to work together, and can do so reasonably quickly and with relatively few bugs in the process.

Let's switch to another version control system.

You may find yourself on your first day having to use a version control system you are unfamiliar with. Do not blurt out that you'd prefer an alternate system. Doing so is tantamount to demanding the rest of the company cater to your familiarity or preferences, instead of you trying to conform with the rest of the company.

Existing version control systems may also be entrenched into much of the existing infrastructure and work-flows. There can be many scripts in place that were written long ago and only work with the particular version control system in use. The entire business may even depend on these scripts for managing all deployments or builds. If so, you just asked to flush the entire company down the drain.

I've had the recent displeasure of hiring a short-lived employee who demanded and fought for us to switch to Github from his second day at work, before even learning about what our needs were and if Github was or wasn't a good fit. Github may be terrific for working with Git for an open source project, but it's not necessarily a good fit for proprietary projects. Github for private repositories costs money, and even if it were free, you don't necessarily want to share your code with a third party when you are quite capable of locally hosting Git repositories and tools. It was pretty clear from this employee's passionate backing of Github that he had little idea of what our source code hosting objectives were, too inexperienced to realize there are considerations other than the features Github offers, and his passion revealed he wasn't going to be a team player. He was let go fairly quickly.

Let's move everything to another hosting provider such as Amazon Web Services.

Amazon's web services provide a continuously growing offering of all kinds of web services to run your business. It is getting quite popular due to being a one-stop-shop for many kinds of businesses, and offering very low prices for various use-cases. Amazon also provides elaborate APIs for developers to make use of in order to manage their services and maintain interesting software. Similar kinds of hosting services are showing up from Microsoft, Google, and others as well.

Some developers who have experience with these services want everything hosted there due to their existing experience or ease they know they can get certain tasks accomplished with them. But that doesn't mean these services are necessarily right for a business.

These services, such as AWS, bill according to every kind of individual usage they can meter. Their costs are very low and highly competitive for minimal usage. However, once you get into large amounts of usage, competing services from smaller companies which offer flat rates may be more cost effective. Some business will also choose a flat rate service over AWS and those like them, because with those metered services, pricing is unpredictable. One doesn't necessarily know up front how much usage will be occurring, and that can make it difficult to work out a budget or be profitable with certain pricing models for applications built upon these services. These businesses will choose a flat rate model even if AWS or others like them are cheaper, simply because there are no surprises later.

Whatever existing service is in use may also be entrenched for a variety of reasons. So before making a suggestion which may show you have zero business sense, or disregard for how things are currently running, get an understanding of what is presently being used and what the pros and cons of a switch are. There can be very good reasons why some hosting company's service is not already in use by the company before you arrived at your new job.

Let's switch the servers to a different Operating System, Application Server, or Database System.

For many of the same reasons described by previous statements, such a suggestion is revealing inexperience, incompetence, or a demand for everyone else to revolve around you. Various OSs, servers, or DB systems are better geared towards working in certain areas. Demanding a change will make people think you don't understand why something is being used. Even if you are correct that something else is better, the existing system is probably entrenched, or the existing talent can't work with anything else. Such demands only show you have little business sense, or can't be a team player. Unless you're specifically asked for an opinion in these matters, don't offer one!

Conclusion

Nobody likes change. Change is hard. Change may even be a very bad idea. Change can fail. Others may be unable to adapt to change.

Before suggesting changes like those above or similar things, really understand why something is being used, and what others are able to deal with. If you can't work out the pros and cons or understand what the impact of a change is going to be, nobody wants your opinion. If you're a new and lowly employee on the corporate ladder, it is best to keep your mouth shut.

If you feel strongly a change is needed, this is usually an indication you are inexperienced or cannot be a team player. Experienced programmers will find a way to do almost anything with anything, they aren't locked into a single tool to solve a problem. If you've been somewhere a while, and your colleagues respect you, then approach these things very carefully. Ensure your proposal is in the spirit of being a team player and in the company's best interest. Otherwise, prepare for a pink slip.

If you're a manager, it may be useful to note that all these above kinds of statements, if made early on, are symptomatic of programmers who are incompetent. Probably best to fire them immediately and not waste resources on them that can be better spent training their replacement.