Unpopular Programming Languages That Are Still Lucrative 387
Nerval's Lobster writes In theory, learning less-popular programming languages could end up paying off big—provided the programmers who pursue them play their proverbial cards right. And as with any good card game, there's a considerable element of chance involved: In order to land a great job, you need to become an expert in a language, which involves a considerable amount of work with no guarantee of a payoff. With that in mind, do you think it's worth learning R, Scala, Haskell, Clojure, or even COBOL (the lattermost is still in use among companies with decades-old infrastructure, and they reportedly have trouble filling jobs that rely on it)? Or is it better to devote your precious hours and memory to popular, much-used languages that have a lot of use out there?
COBOL (Score:3)
My college still teaches COBOL, requiring two semesters of it. But I'm not sure if this is because they illegitimately believe it's still useful or just because of old habit (and to keep the guy teaching it employed).
Re:COBOL (Score:5, Interesting)
When I asked why they still taught the CS students COBOL 20+ years ago the explanation was 'it's a weed out, you have to really love computers to put up with COBOL'.
They didn't make EEs/CompEs take it. Thank dog. I had taken a semester at a Jr College at 15, thinking it might get me respect and a job from the big iron idiots of the day.
Re: (Score:3)
Re:COBOL (Score:5, Funny)
I learned the one, what's it called? it has the little turtle that moves around in straight lines? Is that one still in use?
Ah, you're thinking of LOGO. It isn't widely used anymore, except as a niche language for cruise missile guidance systems.
Re:COBOL (Score:5, Funny)
Ah, you're thinking of LOGO. It isn't widely used anymore, except as a niche language for cruise missile guidance systems.
[Image of panicking missile controllers attempting to abort an erroneous launch by frantically typing PEN UP repeatedly.]
Re: (Score:3)
I don't think LOGO [wikipedia.org] was ever actually used for anything but teaching programming.
I think I learned it when I was around 10 or so (yes, that was back in dickety doo) ... it was good for teaching concepts, but I would be surprised if there's anything doing any real work at companies using it (or if there ever was).
Though, I'm sure someone will tell me how utterly wrong I am, and that something like the air traffic systems still runs on it. ;-)
I haven't thought of that language in years. Thanks for that. :-P
Re: (Score:3)
I don't care what the first sentence in wikipedia is.
It is wrong.
Would be a no brainer if you looked at a small piece of Logo and a small piece of Lisp. Check the german Logo page on Wikipedia e.g they have a Logo and Lisp example side by side. You clearly see both langugaes have nothing at all in common.
See here: headline Logo&Lisp
http://de.wikipedia.org/wiki/L... [wikipedia.org]
Re: (Score:2)
All four year CS degrees are 'MIS degrees' so to speak. Just as with all the sciences, a four year degree qualifies you to be a tech, not a 'scientist'.
Re: (Score:3)
So what? Chemistry students don't take 'lab technique' classes. Yet with a BS all they are qualified for is lab technician. Just like a BS is CS qualifies you to be an entry level programmer or computer tech.
Re:COBOL (Score:5, Interesting)
For what it's worth:
I work in the power industry. We are upgrading to the very latest version of the application we need to operate our power plants.
It is COBOL throughout.
The vendor is taking away access to the source code soon, as the version that replaces this one will be Java. By Java, they mean all the COBOL code wrapped in Java.
So, a major application for use in the power industry will be COBOL until at least 2030.
Our COBOL devs make nearly six figures. And after our salary review is done, will get some serious raises.
They're all in their late 40s-50s. We have no COBOL people in the pipeline.
Re: (Score:2, Interesting)
Right, but would they hire someone who didn't know what a COBOL was 4 years ago?
It seems to me that the people looking for COBOL programmers are looking for experience. This image of taking a COBOL class or two then going out to make a fortune has been fed to me since I was in school, but I've yet to see it actually happen. I do hear plenty of stories of people who stayed with COBOL and are now doing very well, but no success stories of people jumping into it at this late point in the game.
Re: (Score:2)
I did COBOL for 15 years. It's not difficult to learn if someone already knows another language. It only takes about 6 months to become proficient in it, maybe a year or two to become an expert for someone who is good.. Many shops are maintaining old code for the most part, so no one has to design something new. Even if they do, there are probably tons of examples.
We still use COBOL at the company I work at on the IBM systems. Who would I pick given the choice between a COBOL programmer with 20 years expe
Re: (Score:2)
Operations? In COBOL?
Are you sure you aren't talking about a bean counting function? A database backend?
Operations? COBOL? Doesn't make sense.
Re:COBOL (Score:4, Insightful)
Re: (Score:3)
I wonder why they didn't just move to COBOL.net.
Re:COBOL (Score:4, Insightful)
That is what I love about COBOL - that the people who do it are doing it as a job, rather than a hobby where they get to play with new toys.
If you want to see what the future of programming looks like, as a professional industry, COBOL shops are the leader. I bet none of your guys has thrown a tantrum because he was asked to put some comments in his code, or had week-long arguments about implementing unit tests for every component.
Re: (Score:3)
Re: (Score:3, Insightful)
COBOL is great and prolific programming language. COBOL programms will be running long after we are dead. I almost wish I saw more COBOL on Linux. Designed by Grace Hopper she made it so average people with limited CS knowledge could get work done. It's about a sexy as Mom's minivan but it brings the groceries home.
Re:COBOL (Score:4, Interesting)
I've worked at a three places that did MicroFocus COBOL on Linux, huge in insurance world
if you just want to play, 'sudo apt-get open-cobol' on your debian or ubuntu or mint box http://sourceforge.net/project... [sourceforge.net]
Re:COBOL (Score:5, Funny)
In 2010, a COBOL programmer developed a rare fatal disease for which there was no known cure. The programmer was cryogenically frozen, to be revived when a cure had been found.
In the year 9999, the programmer is revived. When he wakes up, he asks the doctors what year it is, and when they tell him, he asks if they finally found a cure for his disease. They answered, "We're sorry, but no, we still haven't found a cure. But it's almost the year 10,000, you see, and you know COBOL..."
In Theory (Score:5, Interesting)
Key words "in theory".
The type of businesses who need an actual expert in COBOL and not just a programmer who can pick up what they need to know need just that: an expert. You can't really become an expert without actual experience. When a company wants a COBOL expert, they want someone with 20 years experience to sort out the problems the programmers with a c++ or java background can't figure out.
I've been hearing since I was in school that the "smart" thing to do is learn COBOL and go make a billion dollars maintaining someones mainframe, but I've never heard of anyone actually doing it. Not saying it doesn't happen, just not in my chunk of visible world.
On the other hand, a friend of mine started working with Foxpro back when it was popular, and unlike everyone else, stuck with it. She makes egregious amounts of money maintaining the small number of things still using it. In her words: "keep laughing, it paid for my house".
TLDR: if you were lucky enough to have started in some old tool/language that's still used and have kept your skills up to date, there is big money. Good luck jumping into it now though.
Re: (Score:3, Insightful)
It's not COBOL that gets the jobs. It's CICS. The COBOL 'database layer'.
Re:In Theory (Score:5, Informative)
CICS is not a database layer, it is a transaction manager. The database layer is IMS or DB2. And CICS is callable from languages other than COBOL.
Re: (Score:2)
I used to do Foxpro, it at least paid for my education. i would still pick it over MS Access on most days. we long ago converted everything out of foxpro and had never allowed anything that uses Access.
my favorite little side project that i had worked on in my free time was a sort of foxpro VM written in foxpro...yeah everyone thought i was crazy.
Re: (Score:3)
Re: (Score:3)
I'm currently *reading a LOT of COBOL (JCL, etc) We're doing a migration project away from the existing 370 mainframe to 'modern' tech. The requirements gathering was spotty at best so every time I get a new chunk to replace I'm reading lots of COBOL to grep for what I need my new code to do.
I'm very thankful I'm not writing any 'new' COBOL but I can read it fairly smoothly. I can say for certain that skill will never be on my resume.
On the topic as a whole: This article (or at least the summary) seem to
Re: (Score:3)
Learn em all I say! Sort it out later...
Anyone who is proficient in programming shouldn't have a problem picking up a book (or website) and learning a new langauge, API, etc. in a weekend or two.
Re:In Theory (Score:5, Insightful)
Anyone who is proficient in programming shouldn't have a problem picking up a book (or website) and learning a new langauge, API, etc. in a weekend or two.
This is true as long as you're hacking something together. If you're expected to work with other developers and create something maintainable, you've got to learn a million little standards, conventions, quirks, tricks, and optional 3rd-party libraries.
Picking up the basics is easy, but in my experience it takes a couple of years before one can truly be comfortable with a new language.
Re: (Score:3)
Re: (Score:2)
Yeah, but on the other hand, I don't know of many Rexx ninjas who are still out there. Back in the 1990's, Rexx was THE shit for banks. Now it's basically evaporated.
FoxPro and xBase (Re:In Theory) (Score:4, Interesting)
I wish there were an open-source version of FoxPro. There is the Harbour project for xBase, but it's not interpretive, and lacked many of the interactive features the last time I checked.
FoxPro and xBase are great for hobby CRUD-centric or smaller data-centric projects: Lots of functionality with very little code because the imperative code could be tightly bound to the database rather than requiring application-code-to/from-SQL translation layers like the current stuff. One learned to "think in tables", and thus become a Tablizer. It's sort of like APL re-shaped by practical concerns.
There's something magical about it in that it can dance nimbly between high table abstraction and nitty-gritty imperative fiddling code. Some try to compare it to LINQ, but LINQ feels like an add-on to the regular clunky way, and not part of a bigger united experience.
The xBase approach may not work well for "big team" programming, but for certain projects it could scream.
Ah, the good 'ol days. You Ruby-ites get off my lawn!
Lucrative isn't all it's cracked up to be (Score:5, Insightful)
Many jobs are lucrative, but so what? Try to do work you enjoy. If you go off trying to learn something just because it's lucrative you'll probably end up in a job where you're maintaining some obsolete system that's held together with duct tape. Not fun. Probably not worth the money for the amount of anguish it'll cost you.
Re:Lucrative isn't all it's cracked up to be (Score:4, Insightful)
Indeed.
It's all a package. Geographic location, work culture, personal interest, and money all play a part in various proportions. I have an interest in money, but I have no interest in maintaining some old accounting system that's been bandaged for decades any more than I have an interest in moving to where that kind of work exists.
Re: (Score:3)
mainframe and midrange financial system apps are tested and rolled out over very long time periods, usually not 'held together with duct tape". That phrase describes popular script based web stack apps.
Re: (Score:2)
I find that the more reliably lucrative jobs are the ones that provide efficiency and cost-savings to organizations.
Re:Lucrative isn't all it's cracked up to be (Score:5, Insightful)
The problem becomes when you have an application which has been worked on for 30+ years, and which is tightly integrated with everything at the company.
I've seen several attempts to replace those type things which have failed utterly, because it was impossible for a new vendor to write the same functionality, as well as the tight integration with every other system at the company.
There's a reason mainframes are still sold and supported, because many organizations have learned it's easier, cheaper, and less disruptive to keep using the stuff that works, instead of trying to build it from scratch.
And, as I've said elsewhere, I've known people who were retired and getting 4-5x their previous salary to maintain those systems.
Throw enough zeroes on the pay, and obsolete systems paying super well can be an attractive option.
Of course, the problem has always been with these system that going out and learning the environment doesn't give you the equivalent of the years of experience people have with these systems ... if you don't already have a lot of experience, these systems aren't really going to be made available to you to learn on. Because the people who have them, really really need them and rely on them.
Re:Lucrative isn't all it's cracked up to be (Score:5, Interesting)
Exactly.
I started writing a replacement for our company's 20+ year-old file-based data system 7 years ago. I didn't tell anyone about it until a few years later when I had a prototype ready and started producing better and faster reports for management than the old system. But they still wouldn't okay me to go ahead and start designing a full replacement for our old system. Then the old system coughed up some blood for a couple weeks and nearly caused us a to lose a couple million in sales.
After everyone stopped running aroud with their hair on fire they asked me what it would take to get my new system up and running as a replacement. I did it and now I am the one who controls all company data. At least a half-dozen people now work supporting the system and writing new code for it, but no one else has 7 years experience thinking about and designing this system, so a lot of the details escape them. HA! Try to get rid of me now.
Proactive programming will get you far.
Re: (Score:3)
Sadly, not all systems can be replaced by one guy over a 7 year period.
Now take a mainframe system, which has a database which feeds dozens of other applications, all of which are integral to the business of the company, and which implement the business process and logic for many aspects of the business -- either you fully solve the integration across ALL of those at once, or the system is essentially useless.
I'm certainly not saying all pieces of legacy software can't be replaced, but some of the scarier/h
Re:Lucrative isn't all it's cracked up to be (Score:4, Insightful)
Congratulations. You are now UN-promotable.
Re: (Score:3)
It only takes one PHB who thinks that programmers are a fungible commodity.
COBOL & Scala & HTML5 (Score:3)
The TFA author has an interesting perspective.
I dove into TFA because the description lists *Scala* with languages like COBOL as both being "unpopular"...not sure if Scala is "unpopular" in the way COBOL is that...
While reading TFA, I discovered his link to his other article of *5 Programming Languages to Learn* [dice.com]
in it, he lists HTML5/CSS3/PHP as *2* of the 5! haha! i hope this doesn't cause another round of "HTML5 isnt a language" arguments...Erlang gets a shout out
good articles...i'd stay away from anything M$ proprietary so that #F language or w/e I don't agree with...but i like his analysis in both articles and learned alot...
Re: (Score:2)
Re: (Score:3)
Yep, I try to do a few basic programs in nearly every language I hear about, just to see what works well in which situation.
Re:COBOL & Scala & HTML5 (Score:4, Insightful)
I think R is similar. R is not as well known as many other languages, but it serves a very important purpose and is getting more and more popular every day. I know some people who as adults are "learning to code" for the first time right now for their jobs. Why? We are starting to get into territory where every business person worth their salt needs to have some familiarity with data science.
R still in heavy use (Score:2, Informative)
MATLAB/R/SAS are still used a lot in life sciences and probably other businesses. I don't use them directly but have users who do.
In the olden days I got a lot of programming and database experience iwth MUMPS (or M as it's sometimes called). Think hierarchical rather than relational databases which makes things like patient data a lot easier to sort through.
Re:R still in heavy use (Score:5, Insightful)
R is on the upswing so I wouldn't call it "still used" really :)
That said, you can make money knowing R. I am doing it, but you really need some database experience and possibly some python, c++ and the like.
SAS won't die in a _long_ time either, in the banks I've been too except for this last one have been using SAS almost exclusively.
The problem with SAS/R code is that neither is usually written by a programmer but a statistician that want something to work there and then.
It can be a nightmare if you inherit too much legacy code.
Also, you actually need to know statistics to be effective :)
Exactly: it's not about R, it's about statistics (Score:3)
Most R code does things like model fitting, parameter estimation, data visualisation, data analysis etc.. The code mostly is just a way to capture and operationalise an idea in statistics or data processing. If you can recognise, grasp, and follow through that idea then the code usually starts to make sense pretty quickly.
On the other hand, if you can't, then you'll be hard p
Perl, anyone? (Score:2)
I'm still getting paid for some Perl 5 work. Learned some when it was still hot, built something with passing value, and now I'm pulling a small but significant monthly fee for supporting it.
It's still what I do best, thanks to all this regular practice. Coding is otherwise more of a hobby than a job for me. Can't say that I see a lot of demand for Perl code monkeys out there, though.
Python is eating Perls lunch (Score:5, Insightful)
Perl was used because it was a powerful scripting language despite a god awful syntax that took the worst parts of unix shell and awk and made them even more painfully contorted. When an equally (some would say more) powerful scripting language called Python came along with a sane syntax, a shallower learning curve and a properly interactive interpreter its no surprise huge numbers of people jumped ship.
I for one won't miss Perl - it had its day but its day is pretty much done apart from legacy code and the few dyed in the wool web sites still using CGI.
Re:Python is eating Perls lunch (Score:4, Insightful)
Uh-huh. And when the Python people learn something about backward compatibility and make up their minds (so we all don't have to keep half-a-dozen different versions of it lying around), then it might actually get somewhere. Until then, it's just the new shiny-shiny.
Re: (Score:3)
which python are you talking about? 3.x, 2.5...2.7???? yes those different languages used for things....
COBOL and FORTRAN (Score:5, Insightful)
The story implies that COBOL is an ancient outdated language. But this is not true. COBOL serves a specific niche and does so quite well, and indeed like C and FORTRAN has been enhanced through the ages. Sure, you can't really code a bleeding edge website with COBOL (and FORTRAN), but that's not what they are for.
Re: (Score:2)
Is it ever chosen for new projects though? Would there ever be a reason to?
I get that for the type of programs originally written in COBOL it makes no sense to do a complete re-write. Things like accounting and payroll and inventory management are pretty static, and once you've got a working system, why change it.
But does COBOL offer any reason to start a new system with it?
Re: (Score:2)
Re: (Score:3)
Well, let's face it ... it is an ancient and outdated language. It was when I was in university 20+ years ago.
But ... it's still entrenched in a lot of places and isn't going to go away any time soon, simply because there are legacy systems out there which can't readily be replaced.
Years ago I was working with a client, and one of their people was retired from the company after something like 35-40 years. He was getting his
Re: (Score:2)
, but he was also getting paid something like 4-5x his previous salary as a consultant to maintain the systems he used to simply because there wasn't anybody else on the planet who knew it.
Wow, that is an extremely expensive mistake. He's bound to take his final breath at the least convenient moment. In fact, the later the less convenient. If you rely on tools that much and have no control over it, you have a very dangerous business.
Re:COBOL and FORTRAN (Score:5, Interesting)
It's not so much that it was a mistake, as it was actual reality of the situation the company found themselves in.
We're talking about systems with 40-50 years of data, for highly complex machines with incredibly long service lives that generate billions in revenue, which are tightly integrated into everything in the company, and which would likely cost 10's of millions of dollars (if not 100's) and several years to replace -- with the risk that you'd spend the money and still not end up with a viable replacement.
The reality is, in long-established businesses in highly regulated industries with systems which are literally decades old and not easily replaced ... many many organizations find that it would be impossible to replace/retire these systems, and that it's cheaper to keep paying the people who have familiarity with these systems. And if they die, you find someone else with a lot of years on a similar system.
Saying "oh, just replace it with something new" is something which I hear from naive, inexperienced people who have never encountered these kinds of systems. Sure, it sounds great, but it doesn't match up with actual reality.
I've encountered several of these systems, and been on projects to try to replace a couple -- and almost universally when you try to do it, you realize that the scope of the problem, and the way in which it will break everything else you have, corporations decide it's not possible or cost effective.
Say what you will about the old school mainframe applications, but they did exactly what they were supposed to, for very long periods of time, with thousands of pieces of institutional and business process embedded in them ... and they do it without crashing, breaking, or otherwise being unavailable. EVER!
Systems which have been running robustly since decades before Microsoft was even founded are about as non-trivial to replace as you can possibly imagine.
Precisely because they are so big, so important, so complex, and so tightly integrated into every one of your business processes.
So, you'll excuse me if I question if you've actually encountered any of these systems, or been part of trying to replace one.
Because anybody who has usually looks at the project and says "no way am I getting dragged into that".
Mainframe Programmers (Score:2)
Re: (Score:2)
Simple, steal one.
Or get one of the free emulators. The problem is finding the OS. You can only run zOS legally on real IBM hardware.
Re: (Score:2)
If you are really serious about it, buy the IBM zPDT (Personal Development Tool). Let's you run z/OS, z/VM, and z/VSE on a PC (legally). A little pricey (about $5K for the tool, and $900/yr subscription for the software), but comes with a whole bunch of mainframe environments and tools.
Re: (Score:3)
"...access to a mainframe system"....
Well, there is more than one kind of mainframe, and they aren't much alike. But let's assume you really mean IBM zSeries. You have several options:
1) Take a course. Many schools have IBM sponsored classes with access provided.
2) Find a copy of the "Hercules" emulate http://www.hercules-390.org/ [hercules-390.org]
3) Sign up for ANY university class to become a "student" and apply to IBM http://www-03.ibm.com/systems/... [ibm.com]
Also note the growing popularity of Linux on zSeries systems, so your Li
Yo got time to lean, you got time to clean (Score:3, Insightful)
The problem is not what to learn (Score:2)
In other words, hire R developers to make better PHP programs.
think about what it says about the company (Score:3, Interesting)
You should think of what the choice of language says about a company. Any company that built its business on Clojure, Scala, or Haskell has a management problem in my opinion: while those languages may be more productive than, say, plain Java, hiring and tool support has always much more difficult. COBOL is indicative of lots of legacy code and a company that has been in business for a long time. That has some advantages, but also means a work environment that's likely very different from others in the industry. R is something used by statisticians and scientists; if you get hired solely as a programmer (rather than a scientist/analyst) to do R programming, your job is likely to clean up other people's messy R code. Can you make money with any of those languages? Sure, but the job may not be quite what you expect or what you are used to.
Why limit yourself? (Score:5, Insightful)
Why limit yourself? Learn both a popular language and a less-popular one. I had the fortune of picking up both Java and COBOL in a previous job, which helped me land my next job, which involved (guess what?) both Java and COBOL (and Perl, and SQL, and XML, and C#, and PHP, and....). Never have I encountered a job where you only need to know one language. All those big banks and manufacturing companies running COBOL? They probably need to make those systems talk to something written in a more modern language like Java, or C#, or PHP, or even Ruby or Python. They are probably even trying to move some of their old legacy systems off on to newer systems, so having an engineer who knows both the legacy technology as well as newer technologies is just what they need. Knowing more than one language and more than one technology also means you don't get stuck when the company re-orgs or you finally decommission the old system or they hit a rough patch and downsize.
What makes a valuable employee isn't someone who is an expert in one thing. A valuable employee is flexible, can teach themselves new things without having to take a class or being asked. A good programmer is good at programing regardless of language. The more you learn, the more valuable you are, and the more options you have finding a job. Once you have experience solving problems with software, picking up a new language isn't really that hard. Yes, you could specialize in something like mainframe COBOL and there will be niche jobs for you in the financial industry for a long time to come, and you might be able to command a hefty salary as well, but do you really want to write COBOL for the foreseeable future?
How much money are we talking about? (Score:3)
I'm a software engineer who works mainly in C++. There are tons of jobs available to me, and they generally pay a metric fuckload of money. How much more could these jobs for unpopular languages pay? Having the choice of many employers is a big benefit of being strong in C++, and that allows me to choose a company that will treat me well both in terms of compensation and work/life balance. There would have to be an extremely very large premium for me to focus on an unpopular language and limit my choice of employers.
Re: (Score:3)
Actually I think you're more representative of someone who's making a lot of money working with an unpopular language.
C++ has fallen way down the charts, and I'd be willing to bet fewer than 10% of those writing software today are writing C++, especially using recent/advanced features. You're making good money because you're using one of the more difficult and painful languages out there. :-)
Sooner or later a superior language that fills the C++ niche will come along, then it will go to a truly legacy statu
Re: (Score:2)
90% of all the jobs I have seen listed were either Java, SQL, or C#, with the occasional reference to iPhone programming.
C++ is not even remotely close to being a popular language unless you are looking for jobs that require a masters / Ph.D in electrical engineering.
Re: (Score:2)
a metric fuckload of money
Is that more than an imperial fuckload?
How to make money (Score:2)
You can make good money two ways. 1) Be able to do something not many others can do for which there is a need OR 2) Be able to do something not many others want to do for which there is a need. You can make a lot of money if the activity fills both requirements and is under served. If you enjoy or at least can tolerate working with unpopular technology for which there is a need you can make a nice little living for yourself so long as the need remains and is not over served.
Lisp, Forth, APL, J, Prolog, PostScript (Score:2)
old languages never die, the programmers just start charging a prohibitive amount of money to code in them. Forth is only justifiable doing embedded programming when you don't have an OS. APL and J are only justifiable if you don't have a popular OS, AND you're stuck with a low speed printing terminal.
Re: (Score:2)
APL and J are useful for doing the sort of ad hoc big data analysis that R is also popular for.
The speed (or lack thereof) of your terminal isn't really the issue, its being able to think in matrix/vector transformations. A skill which is actually more important today than 40 years ago.
LotusScript (Score:2)
Not holding my breath for My LotusScript skills to come back into style.
Old coder here (Score:2)
Highschool girl logic (Score:5, Insightful)
It's interesting how many programmers make decisions while ignoring the wisdom of the high school girl. When in doubt, you pick something that is popular. When you are really good at it, you pick something that is going to become popular, and by choosing it, you make it more popular.
Seriously though, it really depends on where you are, market wise, and where you want to be. There are a lot jobs around here for Java programmers that understand Spring and Hibernate. However, the people hiring for those jobs are looking for competence, and little else. You won't be able to ask for a great salary in those conditions, because while good performers aren't that easy to find, the hiring pool is also pretty large.
Instead, imagine that you have 15 years of experience, and you want to remain technical. At that point, having a decade of experience on the exact same thing won't really help you. Your selling point has to be that you've seen everything, and that you are up to date with the latest and greatest. So you don't look for yet another generic job with popular tools: You have to learn shiny new things, and sell that your know-how with many tools means you'll make a lot less architectural mistakes than a youngster. At the same time, this gives you a chance of getting into a technology early, when finding experienced people is harder. You ride the top of the wave, get paid well, and can keep in the tech switching train.
Soyou need both serious knowledge of a couple of popular languages, and then to try to spend your time working on the less popular ones, that are still growing, because that's where real opportunity is.
Re:Highschool girl logic (Score:4, Interesting)
At that point, having a decade of experience on the exact same thing won't really help you
... unless you specialized in something that's still used, and the company you're at still uses it or some other company out there needs it.
I mean, if the "thing" you did for those 15 years was streamlining TCP traffic in assembly, then you could go make $500,000/year as a quant dev on wallstreet. If it was abstract computer generated graphics in turboPascal... then not so much.
So yeah, it depends on where you are market-wise. Sometimes specializing is a good idea. Sometimes it pays to be a generalist.
Personally? I went with embedded C and every now and then dip into general business applications just so I'm not super-specialized. But so far, low-level C has been a stable bedrock for a career. And I don't think I'm being too optimistic when I say it's probably going to stay that way.
Comment removed (Score:5, Funny)
Job vs interview (Score:2)
You may not get to use much Haskell on the job at Google, but I guarantee you that really knowing Haskell is one of the best ways to *get* the job.
Lucrative for whom? (Score:2)
Lucrative is relative. Yes, COBOL programmers are in demand right now, because most of them have retired. Does that mean somebody just starting out should expend the resources and time to learn COBOL? Probably not, because the return on their personal investment would be less than if they spent it on more current/in-demand technologies. OTOH, a programmer that already has COBOL experience, can still find employment.
It's like buggy whips. As the buggy was replaced by the automobile, the demand for buggy whi
Supply vs demand not popularity which matters (Score:3)
I would probably avoid looking into Clojure or Scala to make money based on popularity. Problem is that these languages are 'cool' which means that there is considerable amount of good programmers playing with them in free time and willing to take a job where they could code in that. Let's say that there are
- 2 million java programmers
- 2.1 million java jobs
Doesn't look good? But if you compare it to (completely random numbers)
- 50k Clojure programmers
- 1k Clojure jobs
Then the fact that there is 40 times less Clojure that java programmers is not going to help you much.
If you are trying to game the popularity, you need to find languages platform which are in some demand, skillset is rare and they are horrible to work with. With that, you may get into job which you will hate, but you will be paid a good money and have job security.
Look what is happening with game development. So many people want to work there that you work very long hours and pay is very low. I knew some people who were willing to get pay cut to switch from Java to Scala. They weren't learning Scala to earn more, but to have fun again.
From my experience, domain you work in has a lot bigger factor in salary than platform. Investment banking people will earn same money, regardless if they code C#, java, C++ or python, but might get considerably different packages based on domain knowledge and actual skill. Game developers will be paid badly regardless if they do Flash, Android (talking about salaries, not indie games) or C++.
Switching language in same industry can give you maybe 20-30% salary increase? Switching industries can double or triple it.
Examples:
C# developer with 5 years experience in banking
http://jobview.monster.co.uk/C... [monster.co.uk]
600-700 GBP per day (which gives 130-150k yearly)
plus plenty of other 500-600 GBP per day jobs.
Web C# jobs outside banking (same city)
30-50k GBP yearly
and no offer for daily contracts.
Learning Scala just to move from 30k to 35k job is not worth it. If you want money, go for proper industry. Learn languages/platforms if you want to have fun in work - but then base it on what you want, not what is best paid.
Avoid pigeonholing and this can work. (Score:5, Insightful)
I'm a systems architect with a company that does IT services for the airline industry. Airlines are the third oldest users of computers, next to banks and the military. There has been an amazing amount of legacy technology that has been built around for the last 60+ years. Systems that are running modern languages and OSes today need to interface with systems via IATA protocols that were invented decades ago. Even though those legacy systems may run on new mainframes, they're still speaking the exact same language they were when they were rolled out. All that whizzy new stuff passengers see (cell phone boarding passes, full function booking websites, etc.) is riding on top of an ancient core that fewer and fewer people know everything about.
Anyway, my point is this -- we do have some people on staff who know about all these systems, and have built or worked on parts of them. They're paid very well, but I guarantee they would have a very difficult time finding work if they were suddenly not needed. The main reason for this is that they're solely dedicated to supporting these older systems. People sometimes allow themselves to be pigenholed into a single task or set of tasks. In my side of the house (systems engineering,) admin tasks are becoming like this through things like ITIL. ITIL is solely designed to remove any sort of judgement from an administration job so that you can plug an interchangeable human into any process, give them a runbook and tell them to execute only these steps when prompted. It's a huge problem, because the next generation of admins is having difficulty graduating to systems engineer and systems architect roles, simply because they don't have a big-picture view of everything.
I've been with the same company for quite a while, but have taken this approach to managing my career -- never do the exact same thing for more than a few years. I get to work in the same field and do _similar_ projects, but I also don't stagnate into a single role. This is very difficult to do because it requires you to be very flexible and constantly learning new things. You need to push your way into new projects because managers will want to hang on to the skills you've developed. Because of this, you need to be willing to document your work and train a replacement when the time comes. Also, you need to actually have some depth in the technology you're working with. There must be 20 or 30 new web frameworks that come out every year, on top of everything else that exists out there. You could try to learn everything but you'd never get good enough at any of it to be useful. At the same time, specializing in ancient languages and systems may be lucrative but you need to be prepared to jump as soon as your skills aren't needed anymore.
If you do it right, you can make a lot of money by being able to jump into a position that no one else knows anything about. But if you can't jump right back out, you will end up doing the same thing forever.
Comparative advantage (Score:5, Insightful)
I have yet to see a young person say, "I'm going to learn COBOL so I can spend my career nursing 40-year old code." You want to be building new things instead, and for that you choose the best tools for the job right this moment. Those are also usually the skills that will make you most marketable to companies that are building new things.
Conversely it's rare to see an IT person keep up with the latest technologies throughout their careers. At a certain point in life you get other things that need attention, such as raising kids, taking care of parents, mowing the lawn, or whatever. And you start to get more risk averse because people depend on you. Although you are very good at your job, truthfully your confidence starts to wane a bit when you see all the really good young people coming up, who can absorb the new skills with relative ease.
The result is what economists refer to as comparative advantage: The younger people who are more adaptable focus on the latest and greatest technologies, and the older people focus on problems that benefit from their experience and judgment.
Bullcrap (Score:5, Funny)
Haskell code never has any bugs. But that's just because it's never used in production.
Trendy != popular (Score:2)
It might be fashionable in academia and certain CS circles but I've never once seen it used commercially in 20 years of working in IT. Now maybe I've not worked in the right sort of companies but I've worked for some pretty big blue chip ones and small houses so I reckon I've got a good spread of experience there.
Re: (Score:2)
Re:Trendy != popular (Score:5, Interesting)
Three words:
High frequency trading
Most of the code driving that is written in Haskell, which is just criminal, since it's some very bright people writing that code, and they're not contributing in any meaningful way to humanity, just fiddling bits to determine who has how much of what money at the end of each trade.
http://adtmag.com/articles/201... [adtmag.com]
Re: (Score:3)
Allocating capital profitably is extremely beneficial to humanity.
Re: (Score:3)
High frequency trading is not about allocating capital, it's about bleeding the people who are seeking to reallocate it.
Re: (Score:2)
please list the huge companies using it
Re:Bullcrap (Score:5, Insightful)
The entire premise of the article is bull. Are companies ever going to get off this fixation on specific programming languages? There used to be such a thing as training. Companies once did that.
Now it sounds like everyone has accepted that you should train on your own time. Worse, you have to do speculative training. Learn the specifics of some platform, and you might get a job doing it.
Re:Bullcrap (Score:4, Insightful)
The entire premise of the article is bull. Are companies ever going to get off this fixation on specific programming languages?
No. Companies (at least the executives running them) look at their code base differently than technologists. They see the cost of maintenance as X$, and if it's written in ten languages, the cost of hiring ten people to do maintenance is 10X. If you say "one person can know ten languages" they assume such people are expensive and very hard to find.
They want a simple way to manage the cost of maintenance. Cutting the number of languages in use accomplishes that goal, in their minds. Therefore, this practice will continue at companies that don't have unlimited IT budgets.
Re: (Score:3)
And they still do. They just want to pretend new recruits are up to speed right away. That looks better on the balance sheet, I guess.
It's all about the appearance of efficiency, rather than actual efficiency. You get the former by measuring and micro-managing everything, and the latter by ensuring your employees want you to succeed and then cooperating with them. Yet companies insist on re-enacting Soviet Union in their own structures and
Re:Ugh (Score:4, Funny)
The actual cards would be those 80 column things that the ancient languages were stored (and inpuy) on.
Re: (Score:2)
No. I remember when Ada was required by the DOD.
I've also heard it referred to as 'writing code in triplicate'.
Re: (Score:2)
Interestingly there is a small but strong Ada community with Apple levels of fanboyism going on.
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Sure, but how many systems were written with it that you expect to be around in 10 years.
COBOL is still around because complicated yet relatively static systems were written in it, and those systems are still needed, still do what they need to, and are big enough that re-writing them would be a massive risk.
Web apps come and go, old school payroll systems are forever.
Re: (Score:3)