Sunday, April 24, 2016

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.

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.

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.

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.

3 comments:

While I understand where you're coming from but I have to disagree about version control.

A few months ago I started a job at ASU where they're using SVN. They've been using SVN for a loooong time and all their projects use it not just the one I work on.

I think I mentioned/asked about moving to git (not necessarily Github though that would be ideal) within a couple weeks.

I think that's perfectly reasonable, especially for the project I work on as I'm the sole developer/maintainer (it's been mostly unmaintained for close to a decade) and it's completely open source (GPL) and independent of other projects. (davinci.asu.edu)

Additionally SVN is just bad, really bad. If they were using Mercurial or Git or similar modern DVCS that'd be one thing but SVN (and CVS etc.) should die and I'm not alone in feeling that way.

I quick glance at Google Trends tells the story (Git, Github, svn, subversion, mercurial, "Apache Subversion") as do articles like this onehttp://www.joelonsoftware.com/items/2010/03/17.html

from *6* years ago

At every programming job I've had besides this one (including internships/part time that's 5 total) they've used Git though one was using bazaar for a different project at the clients request, but the dev's didn't like it. Later, after I left and the company was sold (twice) the local devs setup their own local git server in defiance of the corporate mandate/policy to use some other system/infrastructure.

Also, no one here really knows how to use SVN beyond the basics, even the people who have been using it for ~20 years and certainly not the vast majority of devs who've been here 3-5 years (even though their average age is at least 45). Soon after I got here they had to merge 5 months of piecemeal work someone had done on their own branch. It took 3 or 4 developers and a sysadmin almost all day to figure it out. That included my boss the veteran of almost 20 years.

Branching absolutely sucks on SVN. Everyone has a multiple copies of trunk checked out because there are no local branches and that's the easiest alternative. Any time you want to do anything new and make sure you don't mess anything up, best to just start fresh. Also .gitignore at the root is soooo much better than svn::ignore properties on every folder.

Finally, ASU is huge and from what I've gathered attending a general dev meeting, almost all other development in other departments/colleges/teams etc. at ASU are using modern tools, notably git and Github (taking advantage of educational deals).

It's bad enough that we're running CentOS 6.7, gcc 4.4.7 (which gives very few and very poor warnings which negatively impacts the project), ancient incompatible versions of autotools etc. (everyone these days uses cmake though I prefer premake) which means you can't make any configure.ac/Makefile.am changes while working on a recent Linux distro because it'll break on CentOS6.7. I can put up with all of that but not using modern source control (again not necessarily git but at least DVCS at least for the code) is unpardonable especially in 2016.

In the end I started my own Github repo and do all of my work, occasionally (and painfully) merging back to SVN. There's no way I could work without local branches, history, etc. especially trying to fix broken builds for mac and windows.

Additionally I do most of my development in a UbuntuMate 16.04 VM and occasionally Fedora 23 to get access to modern compilers and tools (and for root access).

Have to stop here to stay under 4096 characters. Will post last paragraph inseparate comment.

For the record I agree with your other categories. There are very few circumstances where change, especially immediately is necessary or wise in those categories and a new employee pushing for them could be seen as an indicator of naivety. You might be a little harsh to say they're incompetent, or even inexperienced. They might just be enthusiastic and honestly think it'll be better for everyone. Also I've never been in a company where they would fire someone over something like that, a suggestion/idea to change. The large companies never fire anyone (only do layoffs when they're massively mismanaged up like Intel currently) and the small companies appreciate/value the initiative assuming you can deliver. But this last paragraph is beside the point of this rant. This was about version control.

The Japanese always listen to their newest hire first, which is attributed to the Japanese competitiveness. Fresh ideas and out-of-the-box thinking is good. So is change, you have to change sooner or later anyway.

If I ever again end up somewhere where people refuse to listen to new ideas because they are not the norm I will escape as soon as possible.