Hacker News new | comments | show | ask | jobs | submit login
Ask HN: What tech stack is in demand, and why?
56 points by pydox 11 months ago | hide | past | web | favorite | 62 comments

Slightly out of date now but this gives you a good idea of what companies want (no why though)


COBOL and Fortran. Probably with some z/OS as well.

Much of the world's financial systems run on it, replacing it is infeasible, but the expert's in this area are aging out (and many have retired more than once). But the tech still needs maintaining, and is difficult to work with.

Fewer and fewer grad students seem interested in learning it, and the expectation that you'll stay and work on this stack for 20+ years is something that drives others away.

These systems will be fixed and then tossed out

Nothing is infeasible to replace, it might be costly, but not infeasible

And of course IBM is happy to get paid millions to keep backward compatibility on the systems they sell

Nobody wants to invest their time learning a dying platform that is good for nothing but a dead end job at a bank and won't teach anything usable in any form of modern system (hope you like wearing a tie for your job as well)

(Fortran is still used, z/OS might be dying down as well but it runs some modern software)

That's exactly what we were told in 1996 (21 years ago that is) when I entered my engineering school: to disregard Cobol and Fortran, because, you know, OLD tech. Won't matter much longer.

If the cost of training peons to make it last and run is less than the cost of rebuilding it, be it from scratch or piece by piece, it will matter longer (that's the point of view of insurances, banks and big corps today, and what's still happening in the IT industry).

They might be maintained for a foreseeable time, but if you take a job maintaining them you've committed your entire career to only do that. That's not appetizing to young engineers.

Latin is dead not because no one uses it anymore, but because you're limited in what you can do with it.

> These systems will be fixed and then tossed out

Hahaha, nope. It's easier and cheaper to train a copule of COBOL programmers than replace the systems that run COBOL.

At a previous company I worked for, it was estimated that the cost to replace just a single COBOL based system was upwards of $50 million.

Not only that, banks are notoriously risk averse, especially with their software. They are very reluctant to change things that already work.

I've taken to learning more about both languages so I can work at the banks that use these. Job stability is #1 for me and if it's at a "dead end" job in tech, at this point I don't see a risk as long as my relevant skills are kept reasonably up to date on the side job/home lab.

> These systems will be fixed and then tossed out

> Nothing is infeasible to replace, it might be costly, but not infeasible

Too costly. Which does make it infeasible.

Five minutes of downtime can result in multi-million dollar profit losses. (At least that's the quote I was given by the CTO when he was explaining the scope of my role when I was consulting at a major Australian bank).

When you have literally millions of transactions a second you need to handle, building a new system to handle the same:

* Regulations * Specifications (Some thousands of pages) * Edge cases * Load

Turns into a multi-year, multi-million dollar operation that will likely be outclassed by the old system by the time it is ready.

No manager in their right mind would approve such a project, no matter how forward-thinking it may be.

Not impossible, but entirely infeasible.

> Fewer and fewer grad students seem interested in learning it

Probably because it's not really fun languages to work in compared to newer things. I'd rather get paid a bit less and work with C# for example than get paid a lot more and being miserable. :)

And since it is a language that will probably die off sooner or later, it is not really a good investment since it will limit your job prospects if the bank you work for would ever change their financial system.

> Probably because it's not really fun languages to work in compared to newer things.

I work on z/OS utilities, mostly assembler. It can be fun, you have to be resourceful. z/OS is actually quite pleasant environment compared to many newer platforms (such as Windows), because you get a very high visibility into what's going on in the system.

I guess it depends on type of person. If you love to understand things across the stack (what's going on under), you might like it. If you would rather focus on an application (or framework) layer only, you probably won't.

I can appreciate that, but I don't think I would enjoy developing using assembler or older languages like Fortran and Cobol.

But yeah, totally depends on the type of person and while I could potentially see myself doing these things I much rather develop in newer languages that makes my life easier. It isn't like it's bad pay for modern languages anyway.

The compensation would have to be a lot in order for me to even consider it :)

How does one typically get into doing what you do? I spent my career (just 6 years) doing C# but mainframes really interest me. I did some COBOL back at my last job and liked it but don't know how to break into that segment of industry without prior experience (without having to be entry level as I'm senior now).

the word is 'paid', not 'payed'. Spellcheckers fail to catch this because 'payed' is an actual word,

Yeah, sorry, I should know that. Thanks for pointing it out. I am not a native speaker but I consider myself to be pretty good at written english anyway..

There's something very true about that. COBOL knowledge is quite literally dying out.

However, for the most part those systems have been running for decades and aren't modified that much any more. While probably not completely bug-free they tend to have a low error rate, in terms of functional requirements at least. They also mostly deal with low-level mathematical and accounting functions that don't change frequently.

For better or worse a lot of COBOL code also gets replaced when new compliance measures like Basel II and III are implemented. Additionally, there are even transpiler-like tools that convert COBOL to Java code. The resulting code of course is horrible but at least it then is available in a language with a long-term maintenance outlook.

In addition to a very conservative work environment all of this contributes to COBOL not having the prospects it might seem to have at face value.

> For better or worse a lot of COBOL code also gets replaced when new compliance measures like Basel II and III are implemented.

That's really not my experience.

I was brought in to maintain, and manage a series of changes to a major bank in Australia, where I trained a full-time replacement before leaving.

We replaced COBOL code... With more COBOL.

> Additionally, there are even transpiler-like tools that convert COBOL to Java code. The resulting code of course is horrible but at least it then is available in a language with a long-term maintenance outlook.

Not just horrible to look at. Slow. Performance that is hundreds to thousands of times slower than the pre-existing code. That's just not acceptable.


Now, we were writing "new" stuff in a different language - C++, because IBM has a wonderful linker framework between Fortran and C++ on their mainframes. But the COBOL is staying put, because nothing can really replace it without unacceptable downtime or performance regressions.

https://masterthemainframe.com/ is a pretty cool website that intends to teach students how to do this kind of work by using a real IBM Z mainframe.

My first job was writing COBOL on an IBM 390. I hated it at the time, but I realise now how many important lessons I learned from it. It wasn't trendy, but it was worth doing and I'm glad I had the opportunity.

wrt fortran, it's not really dying, afaik. It has found its niche in very performant numerical computing.

As for the web development the situation currently stabilized as an oligopoly between Facebook (React) and Google (Angular). Some projects are trying Vue, some leftover ones with Backbone, Meteor here and there, but it's overall a minor share.

Share of new projects being spun up in Angular is probably on a serious decline as well. I don’t see too much future potential there. React will probably dominate for the immediate future.

From both my experience in enterprise software and recent JavaScript conferences I can say that Angular 2 / 4 is still widely used for new projects in that area, much more so than React.

There are a few reasons for this. First, Angular’s programming model lends itself to typical enterprise software requirements. Secondly, Angular, and TypeScript in particular, is similar to what enterprise programmers are typically used to (namely Java and C#). There also is Ionic, which is largely based on Angular.

Finally, Angular and React is one of those odd cases of regional variation in technology distribution. React appears to be more popular in the US, particularly with Silicon Valley companies, than in Europe.

Not what I see. If anything the opposite is true. Angular is very popular in "corporate" environments, basically where the decision makers have a background in Java / .NET and look down on JS. The number of job offers I am getting where angular is required is increasing.

> The number of job offers I am getting where angular is required is increasing.

Job postings on job boards, or talking with real people from real companies asking for and ready to pay for the skill? The perception of what is needed could be skewed by someone investing more in postings, recruitment spam is notorious as well.

Job postings on job boards are not job offers :-) I am talking about real companies in the corporate world who are thinking of upgrading to Angular from whatever proprietary

Basically they didn't jump on the React bandwagon because of the licensing thing, but are ready to jump on Angular's because it ticks all their boxes

Why nobody mentions ember? I thought it was the third most popular thing behind react and angular?

Framework adoption is likely power law distributed and therefore exponentially greater mindshare and ecosystem development (e.g. supporting libraries, learning material, best practices, blog posts, etc) accrue to the first place contender. It tends to be the case that technologies become fairly entrenched as a result of these effects, once they break out into mainstream adoption (think UNIX, SQL, etc).

Ember never made it to that point and almost certainly never will. People are still free to use it of course, but it’s going to be a poor technology choice in light of the above factors.

A _distant_ third. Very distant. And I don't even know whether they are really third or were overtaken by Vue - Vue is part of the PHP ecosystem which alone is enough to raise its profile.

Because it’s mature and stable, hence not cool anymore

"It's not fun if the code you wrote in the morning works in the afternoon after your .js framework updates some 5 times"

I think ember will stick around. I even think it'll overtake Angular one day since it has a better dev/upgrade experience. I don't think it'll ever hit mass appeal, partially because it's quite a niche cookie cutter and the frontend world seems to value flexibility above all else.

I have high hopes for Glimmer[1] though as something that can compete with other view libraries and/or frameworks. I'm especially glad that Glimmer diverges from the Ember brand a bit, because there seems to be a lot of outdated (mis)conceptions about Ember from older versions.

I personally feel productive with Ember, but the custom object models and getters and setters for everything are a bit of a turn off, especially after working on an Angular project recently with typescript support. Mobx, for instance, seems to be able to accomplish similar things as Ember but without the custom object model and getters/setters.

[1] For those wondering, Glimmer is Ember's next iteration of view layer and rendering engine, pulled out into a separate library. It's built from the ground up (and so isn't subject to backwards compatibility with Ember just yet), uses typescript, is component based, and it compiles down to op-codes that are used to update the DOM instead of DOM-diffing. http://glimmerjs.com/

Not a chance.

Stackoverflow Insights might help answer your question:


Honestly not very exciting, and possible region specific to my neck of the woods (South Australia): Office 365 and Azure.

Every non-tech company, and even some tech companies seem to be moving whatever they can into Office 365 and Azure. Some are just moving Exchange, others are moving Sharepoint, and some are just using Azure as an alternative to running a VM farm on-prem (bit boring really). But MS is marketing this HARD here and everyone seems to be buying the message.

Plenty of lower-tier 'Infrastructure Admin' type roles going all over the place, most MSP's are looking for architecture and engineering types as well in fairly high numbers (I count about 20-30 such roles on Linkedin). A lot of Dev roles also seem to be angling towards "Experience with Data Lake/App Service/Some other Azure-ey thing is preferred".

Living in Sweden, it seems to be to be Java and .NET that keeps the world running. React might be the most popular frontend library though.

... and Java (i.e. TypeScript) in the front end, until someone realizes that Java is nothing like JavaScript... now we have to hire some front end w* * * *s and throw the pile of TS at them.

My impression so far is that TSQL, SSIS and .Net keeps world running. Frontend Angular/Bootstrap, but again frontend is not that important.

Although, node is pretty big in Sweden as well.

In the .NET universe, demand seems to continue to grow in the UK, especially in the CMS landscape.

However, demand for lower-paying jobs using open-source CMS's like Umbraco seems to be rising, whereas the rates for contractors are rising for the enterprise level choices like Sitecore.

I mention contractor rates because in Bristol companies are struggling to keep experience in full-time development. For Umbraco, we're seeing the space grow with more full-time people, whereas if you're a developer that can work with Sitecore you can earn a LOT more by moving into contracting. Developers are going from £40-50k roles into £550-600 a day roles as contractors, earning over double what they were before. It's also lucrative for recruiters, as they get a percentage of a bigger overall salary.

Sure, it's fairly niche, and it's as unglamorous as it gets, but the work is there if you know this proprietary CMS as it is widely used by a number of large businesses based on its marketing platforms.

Looking at the local newspaper, C# Client Applications, C++/Java Business Applications and PHP+MySQL Websites with a few Node.js Jobs sprinkled in.

Some lonely ads are also asking for Ruby or Python.

Do people still look up jobs in newspapers? I thought those ads were just legally-mandated foils to prove companies had looked for local people before importing cheaper foreign talent.

I do and they may be foils, I'm not sure on that, but if you send in your application it's unlikely to get handled differently. It's a job ad.

TensorFlow, Linear Algebra, Calculus and Probability are in high demand right now. They’re the building blocks for Machine Learning.

I'd question this. These things might be trending in mind share. And companies looking to hire people with these skills might have somewhat of a shortage. But I'm not sure they are actually in high demand.

It's easy to forget on HN that 90% of tech jobs are in 'dull' bread and butter languages used in enterprises, and nothing to do with the latest trends.

I think the stack overflow jobs stats linked elsewhere in this thread says it all... Java, JavaScript, Python are the most in demand languages right now. Tensorflow doesn't even show up on their list of popular tools.

SQL has been up there for the last 20 years. I doubt its going away any time soon either.

I agree, I'd say anything that solves a companies problem of "we need this fixed yesterday" is in demand - no one is really at that stage with Tensorflow (yet?)

Where? Even the few ML jobs I'm seeing are really 'basic' from a math point of view, as in apply well studied algorithms from well tested libraries in the most obvious ways to relatively small amount of data. The number of ML jobs that actually require you to understand the underlying building blocks of ML is tiny.

Kubernetes, not a stack per say but increasingly important and worth understanding.


Current form of "server less" is not that useful to most people. Not talking about proprietary tech, AWS is good, but considering Amazon web services as a profession sounds really distopian

Or is it one of the building blocks of severless infrastructure? Banks etc will want to host serverless in house

No, that's OpenStack. :)

Verilog and VHDL, and related software suite; Quartus, ISE, Vivado, etc.

PHP, believe it or not there's huge demand

This awesome new framework called PlainJS :)

Really efficient some say :)

Absolutely not - very hard to get hired in any senior capability if that's all you know

Bash and sql, because it's what really keeps things running, despite constant claims by hipster-hackers about how you should be using something else.

Real IDE usage (vim/emacs).

Bash may keep things running, but how many developers need to know it? In my limited experience, maybe 10%, and even they barely use it. It's just for writing some bits of the infrastructure, which is then calcified for years.

I'm always really impressed when I check out the source of a bash program that I use, and part of me wishes I could be at that level, but really I'm more likely to use python for any non-trivial cli scripting. It's more that sufficient for everything I've had to do so far, and python skills have much wider applications beyond just scripting.

It's what really keeps things running sure, but it's not what will get you hired.

being great at SQL, and a particular DB, will get you hired.

~"Plastics and metal is what really keeps things running, despite constant claims by software hipsters."

Just because something is on an underlying layer doesn't mean it's more important or more in demand.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact