Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Databases IT

'Top Programming Skills' List Shows Employers Want SQL (dice.com) 108

Posted by EditorDavid from the data-on-data-workers dept.
Former Slashdot contributor Nick Kolakowski is now a senior editor at Dice Insights, where he's just published a list of the top programming skills employers were looking for during the last 30 days.
If you're a software developer on the hunt for a new gig (or you're merely curious about what programming skills employers are looking for these days), one thing is clear: employers really, really, really want technologists who know how to build, maintain, and scale everything database- (and data-) related.

We've come to that conclusion after analyzing data about programming skills from Burning Glass, which collects and organizes millions of job postings from across the country.
The biggest takeaway? "When it comes to programming skills, employers are hungriest for SQL." Here's their ranking of the top most in-demand skills:
  1. SQL
  2. Java
  3. "Software development"
  4. "Software engineering"
  5. Python
  6. JavaScript
  7. Linux
  8. Oracle
  9. C#
  10. Git

The list actually includes the top 18 programming skills, but besides languages like C++ and .NET, it also includes more generalized skills like "Agile development," "debugging," and "Unix."

But Nick concludes that "As a developer, if you've mastered database and data-analytics skills, that makes you insanely valuable to a whole range of companies out there."


This discussion has been archived. No new comments can be posted.

'Top Programming Skills' List Shows Employers Want SQL More

'Top Programming Skills' List Shows Employers Want SQL

Comments Filter:

  • what the query (Score:4, Informative)

    by tamarik ( 1163 ) on Sunday January 12, 2020 @12:56PM (#59612744) Homepage

    Don't be like my old boss! He made a query that spent 15 SECONDS in the query engine figuring out what to do before the query which took 3 seconds to perform. Don't try to do everything in one query. I broke it into 4 parts and wrote an aggregater in about 20 lines of php for a total runtime of 6 seconds with much prettier results. Sheesh, kids these days...

    • Kids these days might have SQL on their resume, but writing stored procedures is often beyond them, and you'll be hard pressed to find one able to interpret or even run a query plan...

      • Probably because they're stuck on MS SQL Server and have to say GO GO GO after every line of SQL and they get discouraged and just write a bunch of shitty PHP to do the same thing.

        • MS SQL Server and have to say GO

          That hasn't been true for ages.

        • Probably because they're stuck on MS SQL Server and have to say GO GO GO after every line of SQL and they get discouraged and just write a bunch of shitty PHP to do the same thing.

          Huh? I haven't the slightest clue what you are talking about. I've written thousands upon thousands of lines of SQL and I almost never use GO. I believe the only case I've used it...When bulk running code manually from a .sql file, I believe (if my memory is correct) that if you try to run a block with create table statement first, and then query that table, it will throw an error on the queries saying the table doesn't exist. Throwing a go in between makes it work.

          With certain other things, like when us

          • GO

            is used in the interactive command line environment and means to submit the previous content to the server and execute it. In other words, when an interactive user types characters, those characters are accumulated into a string which continues to grow (on the client side) until the user types GO which causes the accumulation to be submitted to the server for execution.

            The same is used for the using redirected input from a file (which is merely character at a time input from a file rather than the keyboa

      • find one able to interpret or even run a query plan

        Holy fuck this rings so damn true. However, it isn't just the new kids that have issues. I've seen so many programmers of different walks looks at a plan and not have one clue as to where to optimize it. I'm just floored by the number of people who have no clue how to look at a plan and point to the spot on that plan that needs the most help. Old COBOL guy the other day where I work was using Visual Explain for an IBM i query he was running in an ILE service. It might as well have been Sanskrit because

      • I ran into some recent code at a fairly large tech company with a query that used the "manual join" approach... you know, query the first table, then for each result in that result set, query the second? It was obvious from the code that there should have been a join there, and it was worsened by the fact that it was a Linq to Entities query rather than a sproc... but just changing the Linq query to use a join lead to almost a 75% improvement in execution time.

    • Re:what the query (Score:5, Insightful)

      by K. S. Kyosuke ( 729550 ) on Sunday January 12, 2020 @01:02PM (#59612774)

      He made a query that spent 15 SECONDS in the query engine figuring out what to do before the query which took 3 seconds to perform.

      Yeah, that's why smarter RDBMS' need to do the first part only once.

      for a total runtime of 6 seconds

      So you've made it worse?

      • Re: (Score:2)

        by dissy ( 172727 )

        So you've made it worse?

        No.
        It's like your score in golf, the goal is to make it take less time.

        6 is less than 15+3

        • Re:what the query (Score:4, Informative)

          by K. S. Kyosuke ( 729550 ) on Sunday January 12, 2020 @01:57PM (#59612924)
          But we already know that a pre-compiled query would have taken three seconds, so it's far from clear that this was an improvement. For all you know, the rewrite may have well made the execution worse, assuming that query analysis of relational expressions one quarter the size was significantly faster (which owing to the combinatorial nature of such problems it very often is).

          • Re: (Score:2)

            by dissy ( 172727 )

            Until one of the user settings stored in a bunch of DB tables changes on you, and your query is now using old parameters and preference options.

            At that point you might as well remove the parameters completely, and hard code all the options as permanent.

            Just tell the users that "changing the 'active users' drop down menu to 'inactive' won't change the report because I hard coded 'active=true'

        • PHP sql query: 15 + 3 = 18 seconds.
          PHP sql queries plus aggregator: 6 seconds
          Original SQL compiled as a stored proc (or even just a normal query compiled first time and then cached): 3 seconds.

          I imagine he could have put those 4 queries into a stored proc and the runtime would have been 1 second, DBs being very good at aggregating result sets, and also only transferring the final result set saving network bandwidth too.

        • Which is just showing your ignorance, the 15 seconds happens ONCE, on FIRST execution of the script. After that ALL subsequent runs will take 3 seconds (or less, as the query plan will probably be further optimised by the RDBMS) so yes, the FIRST ever run of the query takes 18 seconds, thereafter all subsequent executions take 3. Every time you run the PHP code it will take 6 seconds. So he made it worse. And as someone else mentioned the PHP code would also use WAY more bandwidth as the data is transfe

          • Re: (Score:2)

            by dissy ( 172727 )

            Which is just showing your ignorance, the 15 seconds happens ONCE, on FIRST execution of the script. After that ALL subsequent runs will take 3 seconds

            Why would you even think that?

            Just because "active" has a "1" for user "bob" right this very second, doesn't mean that will never change at any point after writing this query.
            You absolutely need to look up the value for "active" on user bob each time you run the query to ensure you give the proper results.

            You never hard code parameters that others can and do change, unless this is a query to only ever run manually by hand. The fact PHP is involved to fetch those parameter values from other tables shows the

            • Except it's very unlikely that this has anything to do with what he's talking about. And even in servers without query caches such as Firebird you can still pre-compile queries by turning them into selectable stored procedures such that even if statistics of the database change to the extent that the old execution plan is now sub-optimal, all you have to do is to recompile the existing query. So you should be able to always avoid the planning overhead, except maybe for the stupidest servers there are (which

              • Re: (Score:2)

                by dissy ( 172727 )

                No I never argued against a stored procedure containing the multiple queries, actually that's what I would have done and completely skipped involving PHP in the first place.

                But unless parent is using their terms wrong I'm confident that is the very type of usage they are talking about.
                My example was probably far from ideal, but those types of things I see all the time.
                Key/value pairs scattered around different tables that need to become part of your limiting set, thus become part of some monster join (or wo

            • What are prepared statements?

            • You absolutely need to look up the value for "active"

              That what inner joins are for. Although technically you are hard coding the "active" value, but I digress.
              The PHP in getting all the 0, 1, 2 etc. from all the status / postal code / blah tables to finally include in the main query is hitting the database multiple times, using network traffic to do so and even with connection pooling on the client machine is opening and closing connections to the database, all with their own overhead.
              If you take all th

    • Optimize the first query can made in run in milliseconds, I suspect... (I've seen and made it happen several times in my work... kids these days...)

    • depending on the use case, 18 seconds vs 6 seconds sometimes isn't really that big of deal. I've seen badly written queries that when written differently drop from hours down to seconds.

    • I have encountered many developers who believe that SQL is something your ORM layer should write for you, and that's the end of the story.

      They want to use something like Hibernate [hibernate.org] or Entity Framework [microsoft.com] to manage data retrieval and storage, so they can do all the processing work in-memory using a neat set of strongly-typed objects. And this fits well with an n-tier architecture. So it seems like a win all around.

      And, in many cases, it is. But it is simply NOT the end of the story for SQL. For applications

      • Re: (Score:3, Insightful)

        by ClickOnThis ( 137803 )

        My (admittedly biased) summary of your post. Avoid writing SQL if you can. But sometimes you can't.

        Pure SQL is a query language, not a programming language. Some flavors may be Turing-complete, but if you're doing general programming entirely in SQL, you're doing it wrong.

        • No, you got it wrong.

          Doing all the data access using SQL is the right way - its the native tool for accessing the DB. Trying to do all tat in c# or Java is the wrong way, its trying to translate your tool to be a different one.

          So the post is effectively, use the right tool for the job. Write SQL when you need to query DBs (not write everything in SQL, that's just daft)

          • excellent point.

            due to working at a non-profit with a small recruitment budget, we pretty much have to hire new grads all the time. NONE of them have a clue how to use SQL but are pretty good with python, C# etc. We are running a lot of workload in AWS and it's pretty funny seeing them try to pull data out using really convoluted routines in jupyter notebooks or pyspark.

          • I'm afraid you're getting me wrong. I'm not against writing SQL as part of the solution. I'm against writing too much SQL. And believe me, I have seen what too much SQL looks like. It's a heap of boolean spaghetti that strains the language to do something it wasn't designed for.

            I do get what Brain-Fu is talking about. Being overly enamored of ORM can cost you. The key thing is to recognize the balance. Write enough SQL to get the data efficiently into your analysis code, but no more than that. SQL code is h

            • SLQ code is truly trivial to unit test. You even have transactions so you can unit test on any DB you have - start txn, input test data, run sql, compare, rollback.

              Admittedly, you do not want to use SQL to do things it shouldn't be used for. Exactly the same argument against trying to use an ORM and C# for stuff that you should use SQL for!

      • My god, I HATE HATE HATE those entity frameworks. They might be handy if you only ever need to work 1 level deep at a time in your DB access. But honestly in 20 years I don't think I've ever worked on a project where an entity framework wouldn't have resulted in some nested loop of repeated queries that would result in terrible performance. So I just avoid them like the plague and write all my queries myself. Even when I'm just trying to a load a single object into memory, usually there's some type of join

        • Re: (Score:1)

          by bob4u2c ( 73467 )
          I remember a problem just like that. The framework made it possible to make an awesome bit of code that could build a nested tree of objects with everything you could possibly want with just a single call. The problem, it took upwards of 90 seconds to retrieve all the data. When I broke down what it was doing I found for each main object it was firing 4-6 additional sub-queries, often times for the same data. In the end I broke then single call into 4 simple SQL statements and used java to piece the dat

    • He made a query that spent 15 SECONDS in the query engine figuring out what to do before the query which took 3 seconds to perform.

      Was the query, "Does this dress make me look fat?" 'cause then I understand the delay figuring out what to do.

    • Re:what the query (Score:4, Interesting)

      by Burdell ( 228580 ) on Sunday January 12, 2020 @02:05PM (#59612944)

      I'm a systems administrator at work... our ticket system is something they paid somebody to layer onto SugarCRM (then they stopped using SugarCRM and only use the ticket system). The reporting is another layer on top of that (I think built by our development department). I got tired of reports taking seconds to minutes to run, so I finally took a look. I figured there was probably some unindexed field being used or some such, but no...

      The queries are terrible (like, to took me a bit to figure out how they even worked), but the performance is terrible because a key field used in multiple parts of the joins is latin1 in one table and utf8 in the rest (this is MySQL), which means that no indexes can be used because an implicit type conversion has to take place on every access, across the 5000+ rows on the latin1 table. Everything else in this system is utf8, and the field is storing ASCII UUIDs, so the obvious fix is to just convert the particular column to utf8. In my dev test, this took one main query from 74 seconds (and that's hot-cache!) to 0.3 seconds.

      You'd think that since it is doing a one-time explicit type conversion on the ASCII data, to replace the implicit type conversion already happening and dramatically speed up an operation done many times per day by a number of employees, this would be a simple change. So far, a month after I pointed it out, the development department is still pondering it. How/why they managed to create a single latin1 table to begin with boggles the mind...

      • Re: (Score:3)

        by rl117 ( 110595 )

        Don't know about MySQL, but in PostgreSQL you can create an index on that column to store the result of the conversion function so that it's both cached for immediate use and automatically kept up to date. If you can do that, it's a workaround which might save a lot of time without needing to adjust the schema immediately.

      • Wow, that is actually a super good hint!!

      • Re: (Score:2)

        by imidan ( 559239 )
        I was at a place where the ticketing system was built on some kind of CMS that resulted in every *field* stored in a ticket being represented by a *table* in the database. So simply displaying a ticket was somewhere near a couple dozen joins. It was just painfully slow.

    • Don't be like my old boss! He made a query that spent 15 SECONDS in the query engine figuring out what to do before the query which took 3 seconds to perform. Don't try to do everything in one query. I broke it into 4 parts and wrote an aggregater in about 20 lines of php for a total runtime of 6 seconds with much prettier results. Sheesh, kids these days...

      If the problem was making the results look prettier, that's not what SQL is used for. Use your PHP or another general purpose language for that. SQL is not a general purpose language. The SQL language is used specifically for managing and processing data, structured data, in a relational data management system (RDBMS).
      About your boss's time delay, my guess is he was doing the query wrong.
      Considering how small the SQL language is, I should be surprised more people don't take the time to master it. But I

      • SQL is an acronym for Structured Query Language.

        It has nothing whatsoever to do with the architecture of the underlying datastore. SQL can be used as a Query Language for systems which store data in Relational, Hierarchical, Network, or Network Extended (just to name a few) datastores, just as a navigational interface can be used to access data in any of those datastores just as well.

        If fact, there are many products which provide BOTH SQL and navigational interfaces to a plethora of underlying datastore or

    • Re: (Score:2)

      by Z00L00K ( 682162 )

      SQL - write more to get less output.

      But more important than knowing SQL is to know how to make a proper database model with correct indexing to achieve the best possible performance.

      • Yes! Otherwise you get the idiot who creates a binary blob for a property bag and then has queries that pull the whole table and parse each blob for a particular property. I ask, _Why?!_ They reply, _Serializing the objects was easier than creating a whole schema._ **sigh**

    • Re: (Score:2)

      by ttfkam ( 37064 )

      Let me guess: MySQL?

    • or you could have written it as a stored procedure, that aggregated 4 query results into one, that would have been much faster and efficient.

      But you need the SQL skills to do these things.... which is the point.

    • Re: (Score:2)

      by jrumney ( 197329 )

      This has always been the problem with SQL. Everyone "knows it", but very few actually understand it. And when the PHB figures this out, he changes all his recruitment ads to request "SqlServer" or "Oracle" instead, as if that will magically solve the problem.

    • Your boss should have put the query in a stored proc that cached the query plan so that the 15 seconds is spent once and then after that it's 3 seconds a pop instead of your 6.

  • I don't know C#, so I've got 9 out of the 10. I guess that means my family should have shelter and food for the foreseeable future. Yay

    • My knowing of Lisp and PROLOG are useless...

      • My knowing of Lisp and PROLOG are useless...

        I know them too, and was paid to program in them as a research assistant in college. Those languages helped my programming and logical problems-solving skills. I've been pretty successful career-wise and monetarily over the past 30 years.

    • If you know Java, you know C#. The only difference between a Java programmer and a C# programmer is your tastes are more refined. So you have that for you.

      • The only difference between a Java programmer and a C# programmer is where their code can run.

        FTFY.

        Yes, I know that jvm and .NET core are available on a broad spectrum of systems. And that's a good thing. But Java is more common.

      • Re: (Score:2)

        by Z00L00K ( 682162 )

        Tastes for C# are more crude due to the fact that C# has the "anonymous" 'var' declaration of variables, which is a dirty solution.

        • "var" is not anonymous - its syntactic sugar for "oy, compiler, put the variable type here for me". When the compiler knows the type, its all good - it even shows you what it is if you hover over it. If it doesn't know, it complains with an error.

          That's not anonymous type, thats a little bit more programmer productivity.

          • Java got support for var in v10 (2 years old)

            https://blog.codefx.org/java/j... [codefx.org]

            • Comment removed based on user account deletion

              • Nearly all the times i've used var is in direct variable assignment: var x = new MyObj(); for example. You can tell what that variable is pretty easily.

                For those coming out of a function call, the var is almost as good, because you know what the return type is in order to create the declaration in the first place.

                And most of the time, if you want ot know the variable type, your editor tells you, if you have a dumb editor where you have to scroll up to find the declaration, then you have other problems that

        • I hate having to put the type twice in initialization. Such fluff.

          MySlashDotClassExampleCouldBeLongish anotherMaybeLongVariableName = new MySlashDotClassExampleCouldBeLongish ();

          That just initializes it.

          Redundant and bad afaic.

      • You're a fucking moron. The .NET framework is gigantic and one person cannot possibly know all of it. Java has piles of different frameworks, I don't even consider "Java" to be a thing you can have experience with. You know a few frameworks, you don't necessarily know the one we use.

        Yes a few simple regex replacements can convert one to another. But it won't build nor run. And now you have to read a bunch of stack exchange questions. Sure we all do that but it's not knowing.

      • They put a bunch of features in C#, which Java has been slowly catching up with but not there.

        Java recently got lambdas (that's a big deal), but it doesn't have the same parallelization API.

        Overall, they are very similar.

        Visual Studio is a strong case for C#. I work in eclipse everyday and hate it.
  • Recruiters don't care if you know SQL. Their checklist will call for a certain flavor of SQL, say, Oracle. Unless you have Oracle SQL on your resume, forget about applying for their positions. I ran into this problem with Linux positions when recruiters demanded Red Hat Linux (sometimes Red Hat GUI!) even though I know every other flavor of Linux.

    • But if you know one flavor inside and out, you can pick up a new flavor very quickly. Recruiters expect you to do that on your own time.

      • Try explaining that to a recruiter with a checklist who ABSOLUTELY must check off every checkbox because they know NOTHING about technology.

        • The problem is one of your own making.

          Instead of putting "Linux" put "Linux (All Variants)" and instead of "SQL" put "SQL (All Variants)".

          Do this for anything for which there is more than one variant. If secretaries had to deal with the same sort of inbred useless crap they would put "Typewriters (All Variants)" on their resumes too in order to meet the demands of assholes who do not know that there is very little difference between an "Underwood Typewriter" and an "IBM Selectric Typewriter" (assuming that

      • If you give the wrong answer to the recruiter you are out.
        The guy who hied the recruiter expects that, the recruiter only checks checkboxes.

  • SQL will be my COBOL (Score:5, Funny)

    by reanjr ( 588767 ) on Sunday January 12, 2020 @01:20PM (#59612830) Homepage

    I look forward to retiring to a nice cushy job writing SQL queries. Right now, it's not interesting enough, but when I get tired and all the juniors who grew up on NoSQL have no idea how to work in the old systems, I can step in for stupid amounts of money.

    • I know COBOL, and the truth is there is no demand.

      The pay is high, because the companies still running the old systems still have the old senior-level programmers. If they're actually hiring somebody new, they offer the same pay as for other languages. But they don't actually hire somebody new.

      This is different. SQL isn't the old thing. It is the only thing for that use case. NoSQL is just for different use cases, it isn't an alternative to SQL.

    • The trend is moving back towards SQL. I know a couple different companies who started on NoSQL and spent quite a bit of effort to move back to SQL because they missed transactions. Amazon also recommends it [youtube.com] for companies that plan to scale.

      The trend now is to start with SQL, then when you start growing, profile the slow or frequent queries and migrate those to Redis (or something else), instead of trying to do it all in NoSQL.
      • we do this with a lot of our AWS workloads; the default is to access data using Athena (presto), but we also have a lot of ETL jobs pushing key measures and things needing very fast retrieval (eg for chat/voice applications) off to Dynamo DB. It should always be about using the best tool for the job - I have no issue telling our junior devs to cool down and take time to learn SQL.

    • Re: (Score:2)

      by ttfkam ( 37064 )

      You either have a misunderstanding about the ease or the simplicity of developing and maintaining databases.

      Window functions. Recursive queries. Aggregates. CTEs. JSON transformations. Pivots. Temporal queries. Partitioning. Foreign tables. Replication. Triggers. Event triggers. Proper indexing including partial and expression indexes. Stored procedures. Row-level security.

      SQL is a DSL for set theory.

    • Re: (Score:1)

      by coreyh ( 30451 )

      I look forward to retiring to a nice cushy job writing SQL queries. Right now, it's not interesting enough, but when I get tired and all the juniors who grew up on NoSQL have no idea how to work in the old systems, I can step in for stupid amounts of money.

      This has been my entire business model since about 1998.

    • NoSQL is a small part of the query language scene. Like 20%.

  • ... declared HTML a "programming language".

    Also, I don't have an employer. I have *clients*! *They* try to get *me*. Employers are for chumps and livestock.

    • current employer pays more than what I had consulting though, it's very nice to have the benefits too when having a family.

  • The list actually includes the top 18 programming skills, but besides languages like C++ and .NET, it also includes more generalized skills like "Agile development," "debugging," and "Unix."

    "Agile development" and "Unix" are not a "skill". And they're not really things learned and known in the same sense as a programming language. They're experience, methodologies and approaches -- mostly useful, though I have many mixed feelings about "Agile".

    • "Agile development" and "Unix" are not a "skill".
      Of course they are skills, what else would they be? Knowledge? Ability?

      And they're not really things learned and known in the same sense as a programming language.
      Of course they are.

      In the end they are all turtles down to the bottom.

      though I have many mixed feelings about "Agile".
      Obviously, when you approach it differently than a programming language ... rofl.

  • Java still maintains a heady position on that list, because a while ago it moved into use across many, many enterprises.

    It seems like maybe Put-on is heading the same way, but then over time I've seen python come and go in enterprise rolls, usually replaced by some language/flavor of the day...

    I wonder if things are being built in the enterprise now in Python that will be as enduring as Java has become, it seems like this time it might have a chance as Python has much wider adoption then I've ever seen befo

    • I don't know enough to speak on this in depth but Java seems to be on its way out although large corporations have no choice but to maintain their systems. First I understand Java is soon charging a license fee. Besides that having a Java runtime on your computer that never seems to be the right version is a huge headache. Some systems you must run an outdated version which I think leaves security holes. And Java isnt good for mobile phones as it you can't install that runtime and phones are the future for
  • Comment removed based on user account deletion
  • SQL is one rung above visual basic. The only complexity to SQL is not to do something which destroys data.

  • As a systems administrator with scripting skills who is now doing mostly scripting and development work which needed to access many data sets coming from various systems such as corporate databases it became insanely valuable to learn SQL and understand it for my role and future career path.

    The ability to write a SQL query that can do many joins across many tables and also query remote databases on other servers in the same query with a join and perform aggregates and also do manipulation on datain various

  • The "Simple Query Language" is about the easiest thing to learn in the world. What is hard is known in what specific way a specific SQL-Engine is messed up.

    • Comment removed based on user account deletion

      • Re: (Score:2)

        by gweihir ( 88907 )

        I did expect that somebody would fall for the bait....

        However, if you think complex (relative) SQL is complex (absolute), you have never done real complex algorithms.

  • Going to university (for actuarial), got an IT internship at a life insurance company.

    Boss man recommended I learn SQL.

    Great recommendation.

    Subqueries as joined data is the secret. It is the power.

Slashdot Top Deals

The trouble with being punctual is that nobody's there to appreciate it. -- Franklin P. Jones

Close