In general I would suggest not putting too much emphasis on these sorts of lists, especially once you're an experienced programmer. Yes, over time new technologies become more useful, but there's a whole bunch of core skills that will last you far longer than web-framework of the week:
1. General problem solving skills. A lead developer needs a whole bunch of skills that aren't listed anywhere on that list.
2. More slowly changing technologies, and underlying principles. E.g. Python and Java will be around for a long time. RDBMS have been around for even longer, and will continue to be around.
3. Ability to learn new technologies quickly.
And if you do it right you can get job that claims to require certain technologies even if you don't have know them.
They do, yes, but that's what companies think they want; it's not what they actually need. And if you present yourself the right way you can get past that and get hired anyway.
But how do you screen for these things without tipping off to candidates that that is what you are looking for? As soon as you explicitly mention a set of requirements, you will have candidates looking to game interview processes built around those requirements.
If I'm trying to hire people, why wouldn't I want to "tip people off" to what I want? I'm supposed to lie and then trick people into telling me what they're really capable of? That seems ineffective.
Interviewing people about their experience is a traditional way to verify things. E.g. If I'm looking for someone who can solve hard problems I can ask for examples. If they're beginning programmer who just got handed tasks like "code this function"... they will have no good examples.
I can also explain a problem I'm working on and see how the candidate approaches it.
But writing job posting that hides the fact I need someone who can solve hard problems seems silly.
Unless it's some revolutionary tech, like Haskell to a C programmer, the problem-solving skills and good knowledge of general principles would let you study it to a reasonable level in a reasonably short time.
That is, if you understand the ideas behind Smalltalk well enough, you will have no trouble picking up Ruby, Python, or even PHP; swap the initial language to taste.
If you are a beginner and the amount of ideas you know is limited by the two languages and a framework you picked up so far, then yes, matching a checklist of an employer is more about the specific tech. The farther from that, the less.
Exactly. As a newly minted programmer you're stuck with those lists, or ideally a company that's intelligent enough to be willing to invest in training (sadly too few of those).
Once you're experienced you can start treating those lists as nice-to-haves, if you have the right core skills and present yourself the right way.
Yeah. But most of the beast Python programmers at my work are guys that used C for decades, and have a strong grasp of classic programming and the full toolbelt of awk, sed, perl, bash etc.. I think the "danger" of these lists is they can convince newer devs that all they need is to learn a Python or JS framework to be a valuable contributor on a software team, viewing the world of C programming to be useless. Many of them will end up writing awful code without understanding why, lacking the larger context of the computing ecosystem.
For what it's worth, the site aside from the trends page is mobile friendly. The trends pages are something I thought would be cool to throw together with the data I have on the topic and admittedly haven't spent enough time trying to make sure it works everywhere.
Apparently,the experience is unusable or terrible in Safari for iOS and Chrome for Android also, but I too came here to complain about it being completely unusable on Firefox Mobile. Hello, fellow Firefox Mobile user!
Some fluctuations I noticed when comparing the trends from last month and now:
- Go took a dip in demand, down from the 6th most mentioned language in listings to 8th.
When looking at trends from all 2017 reports:
- The top languages steadily in demand this year have been: Python, JavaScript, Java, Ruby, SQL, CSS, HTML, Go, C, and C++
- The top four application frameworks have fairly steadily been: Rails, Spring, Flask, and Django
- React is the top choice when it comes to UI libraries/frameworks. Angular doesn't seem to be gaining on it, and mentions of jQuery have been steadily declining.
- The top three databases/stores have steadily been PostgreSQL, MySQL, and Redis
Actually in terms of finding if job site is useful for me that listing is nice. Quick scroll and I see there are no technologies that I use. No .NET, C#, Entity framework.
A ton of it is security and Data Science related, if you actually look at the jobs. That's one of the reasons python is so popular, it's pretty dominate in those circles.
I'm surprised to see no mention of SQL Server as a required skill. Surely, there must be at least one job posting that requires knowledge of some sort of an MS/.net stack?
It looks like it's a survey of startup-type organisations listed on that particular site. All across the globe there are plenty of SQL Server and .NET-related roles, but many are corporate jobs and not posted to the same places.
I'm surprised hadoop is at the top for distributed processing. I don't imagine many businesses really actually want hadoop. Anybody here using it as part of their stack and can justify its use?
I don't imagine many businesses really actually want hadoop.
I imagine quite a few do. They may not be using the map/reduce API (although there are almost certainly use cases where that makes sense too), but HDFS and Yarn are pretty ubiquitous.
I assume the main reason people are using hadoop these days is for HDFS. Spark has supplanted it for actual processing. So the reason hadoop could be so high is that when organizations use part of the hadoop ecosystem (like Cassandra, Hive, and of course Spark) they mention hadoop along with it. Then even though not many organizations are using vanilla hadoop, since it's used in conjunction with many other technologies, it dominates the list.
Problem is recruiter's and co are the ones always coming up with such nonsensical lists. As a lot of commenters have mentioned, these lists are meaningless to a seasoned programmers who can adapt with changing time and tech.
One of the things I find missing from this list of soft skills. These lists are all concentrated in the technical skills, but the professional value gets realized through the soft skills.
But few people ask for soft skills, and no one tests for them beyond noting it if you do something wrong.
"Must be an excellent communicator" - unless they notice you have a hard time talking to them in the interviewer they don't check for it. They don't ask you to write an email for something, or create a presentation, or explain some difficult technical concept to a non-technical person, etc.
I'm not saying these things aren't important. Just that it's almost never included in a job description, and it's invariably eye-roll worthy the few times they are, because no one tests for them explicitly anyway.
"Time management skills", "Ability to prioritize effectively", "Able to handle stress in positive ways", "Able to self-task", etc; no one changes their interviews to actually test for these things. Well, except maybe for seeing how someone handles stress, but frankly, we've heard about companies who do that, purposely make the interview as stressful as possible just to see how someone handles it, and we hate the very idea of it.
I got started in software in the late 90s. At that time, there were immense philosophical differences between the communities that drove each programming language. Perl had a well known culture, which was utterly different than what the Python folks were doing. The people around Java were excited about the thought of building the ultimate enterprise language, and there was talk of some day automating UML schemas so that projects would only need architects, not actual coders -- an idea utterly foreign to the Python crowd. Ruby's culture was shaped by Matz, who said that programmers should experience joy while working. PHP rejected all the hype about Object Oriented Programming, instead, PHP was for people who wanted to write programs using a collection of functions, with an emphasis on quick and dirty projects -- and in an era when there were no package managers, PHP's "all in one" philosophy was a real blessing. A huge amount of code was included in the default install of PHP. And C programming was a different beast depending on whether you were focused on Unix machines, or Windows, or Macs.
The idea of Open Source was still in its early days, and only Perl had a great central library of code that was free for anyone to use.
And of all these languages, most were hot with a fanatic idealism about how Object Oriented Programming would solve the problems of the tech industry. Those languages that rejected Object Oriented Programming (Python and PHP, and also, to a lesser extent, Perl) were proud of their defiance, till the moment (a few years later) when they gave in and decided to become Object Oriented.
There has been a convergence of culture. Nowadays most programming languages have all of the same things:
1.) package managers to manage your dependencies
2.) frameworks with command line tools to automate setup and database migrations
3.) multi paradigm -- most languages now facilitate Object Oriented Programming, but also Logic programming and Functional programming and pattern matching, and other paradigms.
4.) open source libraries of code for everything, typically on Github
Nowadays I can go from writing in Python to writing in Javascript, and most of the stuff I expect is exactly the same in both languages. I can think these words about practically any language that I am asked to work with: "Oh, I have to write a module to send email to new users? Okay, let me look up the open source libraries that handle email. There are probably a dozen projects on Github"
There is much more of a mainstream to computer programming than their used to be. This "normalization" happened first with software for the Internet, though lately its even been spreading to hardware projects. A few languages (Clojure, Haskell) still have strong philosophical differences from the mainstream, but they offer the common basics, like any languages that nowadays wants to make a programmer feel productive.
So these lists of skills are less meaningful than they used to be. Once upon a time it would take months to give up one language and learn a new one, whereas nowadays the switch is easier, since so many assumptions that are true in one language remain true when you switch to a different language.
That makes sense. Most iOS and MacOS programming uses those languages, and most use of those languages is for iOS or MacOS programming. Thus, I'd generally only expect to see those languages listed for the small fraction of jobs where a company is using those languages for something other than iOS or MacOS.
1. General problem solving skills. A lead developer needs a whole bunch of skills that aren't listed anywhere on that list.
2. More slowly changing technologies, and underlying principles. E.g. Python and Java will be around for a long time. RDBMS have been around for even longer, and will continue to be around.
3. Ability to learn new technologies quickly.
And if you do it right you can get job that claims to require certain technologies even if you don't have know them.
Longer version: https://codewithoutrules.com/2017/07/16/which-programming-sk...