Are there drawbacks to taking a job where I will be using a unique programming language? [closed]

Question

I just graduated from college with a degree in CS, so I would like to find a job where I can learn more about the field and build up some professional experience.

I've interviewed at a company that uses their own in-house programming language, and I don't think any others use it. They have not mentioned using any other languages or what they use for a development environment.

What should I be concerned by taking a job like this? If I were to switch jobs later, would I have to start looking for entry level positions again because I haven't gained any language-specific experience?

Answer 1

The main downsides:

• working in a "custom environment" can mean limited tools/support which can be infuriating when you get stuck on a problem.
• The language they use may be poorly designed, leading to you picking up bad habits early on and write hacky code to create workarounds.
• HR baffoons will not recognize your experience. (This is OK. A company that leans on HR to make technical hires is not the kind you typically want to work for. After a couple years, most of the great jobs come through connections anyway.)

If it were me, I would ask them why they use an in-house language. If it is for a legitimate reason, such as crazy hardware contraints, a domain that is not easily modeled in any existing languages then this is totally fine. On the other hand, if their answer suggests that they created their own language so that they could roll together a bunch of hacks and business logic into what amounts to a bunch of wacky macros, then this is a big red flag. You want to make sure that they use good engineering principles, so that you can learn from them and succeed with them. In this case you can see whether they can rationally justify using a home-grown language that does not have a community knowledge base and external support. You may find that their decision is perfectly rational (I believe facebook built their own version of PHP to deal with scalability, which has done pretty well for them), or you may find that they have created a monstrosity of a language that has been so tightly coupled with their core systems, that they cannot seem to break away from it. Trust me, you do not want to be working in a language who's core data type is called ImARInObj (Immutable Accounts Receivable Invoice Object). Tight coupling between a language and a business need often occur in these types of situations, and it would be an absolute nightmare to deal with that sort of system everyday.

Answer 2

Run away, and run away quickly. Unless you're desperate for a job and are very hungry, this is a situation you want to steer clear of.

I have experience with a company that did this, and the only reason that they did so was so that their employees wouldn't gain meaningful, transferable experience. It really was all about control.

Others who said here that "programming is programming" are right, but I'd turn that on its head and ask, why not use some standard language for which there is external support, libraries, forums, and a pool of available programmers to choose from?

The only time I think such a situation would be OK would be if the company-only language was for custom hardware. For example, you have to write everything for the 9000X Gamma-Ray Interferometer using an assembly/machine code specific to that machine.

Answer 3

Since your resume is basically blank after you graduate, your first job puts a lot of momentum on your future career path. Your next potential employer(s) will be putting a lot of weight on this job. So, unless you will be programming in other (more marketable) languages as well, I would highly recommend against taking this job.

I say this from experience because I just left the first job I had after graduating with my C.S. degree, where I was in a position almost exactly as you describe. Most of the programming was done in a basically unknown language called Progress (a.k.a. OpenEdge ABL). It's horrible. Not as bad as COBOL, but close. I was stuck there because the area around where I graduated does not have many programming jobs, and I was waiting on my wife to graduate with her degree before moving.

Getting that language to talk with other languages or databases was nearly impossible (it came locked in with its own proprietary database as well - bonus!). I spent a lot of time writing frameworks on my own that already existed in other languages, and were probably better implemented already as the language did not support this type of "extension" paradigm very well. The language was more tailored towards a "contact Progress Corp. with a feature request, and wait until version n+1 for the new feature" approach. Needless to say, the software industry doesn't move slow enough for this to be a viable approach. I won't go on about how bad it was, but I assume you will face a similar thing if you are dealing with a proprietary language as well. Rewriting existing frameworks in unknown languages has proven to not be a very marketable skill, in my own experience.

To add to that, the existing codebase was, shall we say, sub-optimal. Lots of legacy code dating back to the late 80's / early 90's. I would wager you should expect something similar, since I think most companies only stick with the proprietary languages because they carry a lot of this legacy baggage with them. Remember, it's probably hard for such an employer to find programmers willing to code in this legacy/proprietary environment, plus they probably have to pay for training as well since no one's ever heard of it. Your coworkers probably won't be titans of software engineering, either, due to the Dead Sea effect (anyone with talent probably already left). I had a lot of trouble at code reviews trying to use object-oriented code, let alone any type of design patterns, as they just didn't understand it (the people on my team had, at best, an MIS degree (no offense)).

Finally, assuming you do take this job but yearn to do something better once you leave, in order to make yourself competitive for your next job you either have to sacrifice a lot of your free time outside work creating breakable toys in more marketable languages (and probably open source most of what you make), or do what I did and save up some money before you quit and spend a month or two doing same. Either way, this is a very stressful thing, especially if you enjoy having any type of social relationships outside of work or spending your free time doing something that isn't coding once in awhile.

Now, my experiences may not map directly to your choice, but I'm sure some of it will apply. Hopefully it will at least give you some questions to bring up. As others have mentioned, you probably want to find out what tools they use (hardware, software development environment/IDE, and definitely version control). The Joel Test might be a useful guide.

TL;DR

Don't do it.

P.S. To those saying that learning any new language is useful, that on its own is true. The problem is when you get stuck using that language almost exclusively full-time for a long period of time, losing exposure to more useful languages (and techniques). That is what you want to avoid.

Answer 4

The obvious downside is you won't be able to add this job to the "5+ experience using language x" requirement that the future jobs that you'll want to apply to will have. This can be more annoying than you might think (speaking as someone who has had many years of experience, but a wide range of programming languages). I've got professional experience with VBA that might as well have been experience with LOLCODE, based on the jobs I look for today.

But, do they use that language exclusively? It's rare that a company only ever uses one language. Even my time with VBA included some ASP, Java, and PostgreSQL.

Answer 5

I tend to agree with the mantra, "programming is programming", regardless of what language you've been working in. So much of programming is learning to think and the rest is just syntax. A potential future employer will more impressed by, "I accomplished X with Company Y" than they would by "I have known X language for Y years".

The last job I took involved a lot of PL/SQL work and I had never written a single line of PL/SQL - I picked it up in about two weeks.

That said, I would definitely keep in practice with other languages, just to stay current. While at the new job, have a pet project or two that will keep your programming arm in shape with a more standard language, but don't fuss too much over it.

Answer 6

In IT, company has often to do with recruiter to find good candidates. Recruiters are not IT specialists, so has some criteria and match candidates with and then send them back to the company. It goes the sam way with humman resources in big companies.

You have a problem with that. You will not fit in recruiter criterias. So, I would say that it's not a problem reguarding your competancies. Programming is programming, and a solid programmer should know how to switch from one language to another, because the syntax is less important than knowing how to do reliable code, testable code and maintenable code. Thoses capacities are mostly language independant.

However, as long as you will not fit with matching criteria of no IT people recruiting you, it will probably be an inconvenience to find a future employement. Even if you will be competant anyway. Those persons don't know how to judge that because they are non IT.

I would definitively not recommand this job for a first one. But if you already have some entry in your CV about broadly used technologies (Java, PHP, C, C++, C#, . . .) go for it if you like it.

Answer 7

There are definitely skills that you can pick up/improve using proprietary languages and environments. As has been mentioned in other answers, some skills transcend language, and they can be very valuable on a resume.

However, those skills are frequently overlooked when the people reviewing the resumes are not technical. Often (in the lower end of the job quality spectrum, which, unfortunately, is frequently the best bet for relatively inexperienced developers) resumes will be evaluated primarily on x years of language y, and the other skills you might have don't come into play until after you've gotten a foot in the door with an interview.

One other factor to consider is that proprietary environments tend (imo, at least) to be more likely to be poorly designed, kludgey, and generally frustrating than mainstream environments. Working exclusively in a bad proprietary system can be very discouraging, especially to someone just starting on a career in programming.

That being said, remember that experience with a proprietary system, while not as good as similar experience working with popular mainstream languages, is still better than no experience by a long shot. You will have a leg up beyond entry-level for some positions, and for others, you may (or may not) still qualify as entry-level for specific languages, but your experience will put you significantly ahead of most of the other people competing for those jobs.

Before you consider passing up an offer because of focus on a proprietary language, be sure to consider the current job market, and how your applications are generally being received.

Answer 8

It comes down to what ancillary languages and skills you'll pick up. If indeed their in house language is not used or even known outside the company it will be of limited benefit career wise (unless its likely to burst out and be the next big thing). I spent a few years working with a third party tool which in itself is useless to me (careerwise), however by working on those projects my HTML, css, and javascript skills improved. I also learned a lot about how enterprise projects are run and structured, dealing with clients, managing expectations. All the things that are part and parcel of modern software development that are not actually the language.

Answer 9

What about the framework: I.D.E, editor, libraries ? Most complex business apps. on this days cannot been done with a plain text editor and command-line compiler.

Do they have some of that for their custom programming language ?

Answer 10

Often, learning a business is more important than learning a technology. If you think you might want to stay in the particular industry this company is in, then go ahead and take it. If it's a niche market, or one you're not particularly interested in, then I'd suggest skipping it. Knowing the ins and outs of (say) pharmacokinetics and the drug discovery process will open doors that being just another C#/Python/Java programmer won't. And unless this "unique" language is more of a code generator or configurator, you'll still be solving common problems, so you'll still get some overall experience, even if the specific techniques might not be directly transferable.

Answer 11

I'd consider taking it if, and only if, you can have plenty of experience in other languages. If you do take the job, you can (and should) keep up your skills with mainstream languages by working on open-source projects in your spare time.

What you want to avoid is the possibility of your skills becoming highly tuned to this one specific company and non-transferable to others. Technically, programming is programming, and experience outside a single programming environment is beneficial, not harmful, as it helps you see problems more clearly.

Think of it this way: if you take a job writing Perl programs, that doesn't necessarily doom you to an eternity of writing Perl programs. Nor does taking a job in .NET doom you to being forever bound to Microsoft.

But here's the important part: I would never hire a programmer who only knows one language, even if it's the one I want him to use. A programmer who doesn't have a wide range of experience in many languages is often poor even with his language of choice. It also reflects lack of ambition to learn new things.

On the other hand, if a programmer knows Python, Ruby, C#, PHP, C and Erlang, then the fact that he also knows APL is not a strike against him, even though there's no chance in hell that we'd use APL for anything.

So, if you have the discipline keep the language from becoming your sole focus, then take the job.

And it's worth stating again: contribute to open-source projects. They count for tons more than "work experience" because it's not something something you just did to make a paycheck. Programmers who work on open-source projects are like gold.

Answer 12

My first job after graduating with my CS degree involved developing with an obscure language. Not unique. Not in-house developed. But an obscure enough VMS 4GL that I never saw anyone else using it.

In retrospect, this was an unwise decision. While I learned a lot about professional software development doing that job, it would have been a whole lot better to also develop a marketable language proficiency to go along with the "soft" skills.

I got lucky - my second job was working with another obscure VMS 4GL. They hired me because they knew they couldn't find people who already knew the language - the fact that I had experience on the VMS platform with a 4GL was enough. And at that job, I had the opportunity to get trained in a marketable language as they looked to move away from VMS towards Windows servers.

But I could easily have not had that luck, and found myself five years into my career with absolutely zero experience that would persuade a recruiter or HR person to look at my resume.

For your first job after graduation, I really, really don't recommend it.

Answer 13

To give a meta-response, I've noticed that many responses say, "From personal experience, this is a bad thing."

Many others say, "In theory, this doesn't have to be bad."

But none of the responses I've seen are from folks who have done something similar and thought that it was a good experience.

Now maybe some folks have done this and are thrilled with their jobs, but aren't on Stack Exchange. This is true for some commercial software. For example, there are some really dedicated Software AG Natural/Adabas administrators, but there aren't a lot of related discussions on Stack Exchange. However at least someone is looking for even these niche specialists. That wouldn't be true of a completely proprietary language.

So if the goal is to move toward the type of technologies discussed here, the fact that few endorse this from real experience suggests that it's not necessarily the best start. It may not be the kiss of death. But you'd want to work to keep it from becoming a terrible road block, such as by starting or contributing to an open source project related to your aspirations.

Answer 14

Take the job if you feel there are good/great programmers who will help and mentor you. You'd think a place that does this has pretty good people, but can't be certain. Also, does this company have any kind of reputation for hiring top candidates? You may get hired by someone else regardless of languages used on the job.

Answer 15

Be particularly wary if the problem domain is dominated by one or a few languages in the industry. Database development is closely tied to SQL. FPGA development is mostly split between Verilog and VHDL. Contrast that to web applications which are written in (combinations of) Java, PHP, perl, python, Scala, C++, etc. A hiring manager looking for web developers is going to be much more understanding about transferable skills if you have no specific experience in their language of choice. A hiring manager looking for someone to write database queries is going to expect SQL experience.

Answer 16

I have programmed in a proprietary language. But that was not the language that was used all over the place. I have nothing against that experience now, though I whinged every moment of doing that work. I did get chance of using that language, maintaining that language and, improving it, along with maintaining the program that were written in that language.

Along the way, I learned to read and understand how a small interpreter would work. If your potential employer has the sources for the compiler/interpreter for the proprietary language, you might just as well get a chance to work on its internals. I can say, from experience, you will treasure this work experience for years to come.

What transferable skills you would have gained is, team working, software engineering, writing a compiler/interpreter or, parts of it, algorithms, etc. If it is an interpreter, the proprietary language is just a mask under which you will find the interpreter written in, say, C, or, such other language. If proprietary language is compiled, you would be getting a chance to work on a production compiler that is fully boot strapped. So, when you look for the next work, you need to sell these skills harder than the, say, C/C++/Java/Python for application developer or, Python, Perl, Java, HTML, CSS, JavaScript, Flash for web development or, Verilog, VHDL for embedded development, or, any other set of languages for other domain of applications.

All this, assuming that your potential employer has the sources for the proprietary language and you are willing to more than work on the programs written in the proprietary language. Still, I admit I am being extremely optimistic in saying that you might get a similar opportunity like I got a few years ago.

At interviews, years of experience and technical skills are not alone in hiring decisions. Your thirst for learning, cultural fit, cultural leaning, make a big part of the decision.

So, for a first job, if your work will not be limited to the programs written in the proprietary language alone, but allow you to work on its implementation as well, take it.

Answer 17

I think there are two sides to this. First there's this specific job and, second, there's how it affects your career prospects.

What I'd want to know about this job is why they created their own programming language. Does it make sense? If not I'd take a different job.

In the last ten years I've worked for three companies with their own language. The first one because, when the project was started, there was nothing that could do what they needed. (They wrote a techie version of Visual Basic, but this was on Unix and years before VB existed.) The other two had performance requirements that couldn't be met with existing languages. I consider these pretty good reasons.

On the career prospect side, as others have mentioned, recruiters and HR people who don't understand programming and work using a series of check-boxes will have difficulty with your CV. Many companies who want a plug-and-play C++ programmer will baulk at paying for you to learn a new language. All this is true.

But do you really want to work for a company like that?

If the answer to that is 'Yes,' then you should probably turn down this job and look for one with more conventional requirements. Also, depending on where you live, you might not get much choice and would have to work for companies who don't really understand programmers.

Personally, I don't want to work for a company like that and I think it's fair to say that I've not found my choices to be overly limiting. If you have a track record of quickly learning new technologies, solving real world problems and, maybe, some "business" knowledge then I think you should be fine.

Also there are positives. How many other places do you get to play around with the compiler/interpreter? How often do you get to influence new features and syntax of the language you use every day?

Answer 18

First of all, a in-house programming language is not necessary a bad thing, however, there are a few ground rules you need to justify a custom language.

You write you think they do not use any other language. First question you should ask is if they use any other language as well.

Custom programming languages can have good justifications. I know mathematics work with specialized languages. I heard the tax agency uses a special language to calculate the taxes with the yearly changing laws about them. Welcome to the domain of metaprogramming.

Any custom language however, should never implement a full language. Outside it's domain you should still fall back on a classic/widely known programming language. Even in the language domain it's not likely every little detail is covered by the domain language.

Good questions to ask:

1. Are other languages used at this company?
2. What is the reason other language did not fit for them?
3. Is the language used outside the company (by researchers or under licence to other companies)
4. How many people know the language.
5. How many (successful) projects/programs are made with the language.

From these answers you should be able to find out what the state of the language is. if it's a domain language that add great value, it's all ok. If it's somebodies pet project to replace Java or C# then get out of there asap.

Edit: i suggest you read into the domain spesific language article on wikipedia, that should give some more insight.

Answer 19

We may not like it, but as computer programmer we have to have a CV that agents and HR departments are willing to forward to project managers. Our CV must also stand out as matching the needed still set within 30 seconds of someone looking at it, it must also have the correct keywords to it matches a search of the cv database.

So just working in a unique programming language is a great risk! However using a mix of the DSL and a main stream language can be presented well on the CV. (You must tell the truth on your CV, but it does not have to be the whole truth!)

Answer 20

I'd be less nervous about taking a job like that if you already had a pretty wide breadth of programming knowledge. If you're brand new to the industry, this could pigeon hole you professionally pretty badly, possibly to the point that you'd have to virtually start over as a Jr or an intern later... This could be particularly bad if you stay with this company for awhile, only to leave with no transferable skills.

If you're already pretty experienced in the industry, then this could be really cool bullet point to your career. And the perception if/when you left this place would be more of "damn, he's a jedi, he's done everything"

Answer 21

Join the company only if you will be working in the company whole of your life time,or else never even think of taking it up even if you are getting a good salary package.I have experience of joining such a company and being stuck there despite of lots of frustrations in the job,because no experience in other programming languages to look out for another job.

Answer 22

I've seen someone with 15 years of experience, primarily as a lead or principal developer, unable to get a job over a long time, primarily because the company left him with no experience in what had become contemporary languages and APIs.

Programmers get put mentally into bins just like actors in movies do (hero, villian, etc...) and once you establish what your bin is, I think you can make it much harder to find a job than if you are fresh out of college.

That is, if you have a CS degree, you are probably a candidate for a number of jobs.

But if you have a CS degree with 3 years experience in PHP, you are actually LESS of a candidate for a Java web developer position than when you graduated. You have pegged yourself as a PHP developer and until you have experience to the contrary, that is what you are going to be hired to do. (Weird, but I think true, you have more total experience, but your resume will be disregarded as irrelevant because it is the wrong type of experience, whereas fresh out of college your resume might not have been)

And if you have a CS degree with 1 years experience in SpecialtyLanguageX then you have closed all sorts of doors for yourself.

These are just my opinions and observations of course, I've never done the hiring, this is just what it looks like to me.