Slashdot Mirror
Which Programming Language Pays the Best? Probably Python
Nerval's Lobster writes: What programming language will earn you the biggest salary over the long run? According to Quartz, which relied partially on data compiled by employment-analytics firm Burning Glass and a Brookings Institution economist, Ruby on Rails, Objective-C, and Python are all programming skills that will earn you more than $100,000 per year. But salary doesn't necessarily correlate with popularity. Earlier this year, for example, tech-industry analyst firm RedMonk produced its latest ranking of the most-used languages, and Java/JavaScript topped the list, followed by PHP, Python, C#, and C++/Ruby. Meanwhile, Python was the one programming language to appear on Dice's recent list of the fastest-growing tech skills, which is assembled from mentions in Dice job postings. Python is a staple language in college-level computer-science courses, and has repeatedly topped the lists of popular programming languages as compiled by TIOBE Software and others. Should someone learn a language just because it could come with a six-figure salary, or are there better reasons to learn a particular language and not others?
Ada is paying me ~$140k
Should someone learn a language just because it could come with a six-figure salary, or are there better reasons to learn a particular language and not others?
Yes.
It's the problem domain, not the language. Front-end webdev seems more concerned with language fashion, and kernel work still scoffs at anything but C, but in-between language doesn't seem to matter that much.
I've most of my career writing no-UI usermode code, and employers haven't much cared which language I knew. It's sort-of moved from C++/C#/Java being interchangeable to Java/C#/Python, though many hiring managers still seem skeptical of Python as a "real language" (I expect that will change over time).
It's not your ability to bang out code in any language that will advance your career anyhow - whether tech track or management, it's one set of leadership skills or another that come to matter most.
Socialism: a lie told by totalitarians and believed by fools.
Not a single programming language makes the best figures in a year for you..but the ability to adapt and learn new technologies as well as completing your task does.
I read that LinkedIn is a job website that will get you more than $100,000 per year. Meanwhile, LinkedIN was the one programming language to appear on LinkedIn's recent list of the fastest-growing tech skills, which is assembled from mentions in LinkedIn job postings.
Fuuuuuck Yoooooouuuuuuuu Dice!
and Java/JavaScript topped the list, followed by PHP, Python, C#, and C++/Ruby.
C/C++ is old, C#/C++ is tired, but C++/Ruby is so hot right now.
But it's not the language, it's the domain knowledge I bring to the table. I was hired to write embedded software for scientific instruments. As a former research scientist and current software engineer I can understand the problem, the solutions, and write code to do what the device needs to do. C/C++ just happens to be the tool I use to build the device. Python, Java, and so on just wouldn't cut it.
$100k and sharing a rented hovel in silicon valley with seven other brogrammers ?
Or are we talking $100k in a mansion on the golf course in Arkansas?
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
The salary data is taken from the subset of job ads that list compensation. I don't know the last time I saw a want ad in the software industry that said anything beyond "competitive compensation" or the like. That suggests that they are only looking at a very skewed subset of jobs, my guess would be much greater representation from government, academic, non-profit, and non-tech companies looking for developers.
.NET stack, which is a very low-expertise, low-standards type of job.
Getting into speculation here, but I would guess that the higher premium on things like python would be because non-tech firms hiring python devs probably need scripts for efficient data mining, analysis, and reporting, a skill requiring far more expertise than run-of-the-mill software development.
C#, which I don't think anyone would argue is vastly more marketable than python, Ruby, or Objective-C in the highly lucrative tech sector, is likely so low because the sort of want ads they are looking at are mostly going to be positions that build web-based business management sites on the
Beyond the stupid methodology of only looking at want ad compensation (a better - though still suspect - method would be to look at something like glassdoor for salaries and then correlate those to the skills asked for in want ads for the same position and company), they should really be including the full requirements list for this to be at all meaningful. If one ad asks for "python, plus 7 years of experience working with large scientific datasets, strong understanding of statistics, and experience with one or more data visualization libraries" and the second asks for "c#, knows what a website is", then saying the first one is better paying because of python is silly.
Big Data isn't a fad. It's what built Google and Facebook into the companies they are today, and the applications for it are growing rapidly in tons of non-tech fields. Sure it's a buzzword, but a useful one since there wasn't previously a way to describe the various aspects of it succinctly.
I hate this comment.
I probably hate it because I make about $90k (plus one of the best benefits/retirement packages in the United States...you can suck your 401k, I gots me a pension!)
But really, I hear this all the time. "Oh, you only make $90k? You must suck. Any mid-level programmer can make more than that."
First, it really isn't just about the take-home. The benefits are really important.
Second, there are sooo many other factors, it is incredible. I live about 70 miles from Silicon Valley. My salary *is* something to scoff at by the denizens of the Valley, but for quality of life? I have most of them beat.
I live in a beautiful house that I can easily afford. I average 40 hours per week- with the variance being about 3 hours each way. A 'crazy' time means that I come in at 7:30, and maybe stay as late as 5:30 if I have some process running.
I get to lift my head out of the screen and go do REAL things during my work. I am consulted on many different business processes- my opinion is valued well beyond the technical side of my job.
Someone else mentioned 7 brogrammers huddled together in some Santa Clara shit-shack, all making $150,000. That's a miserable existence that I want no part of- no matter how great they are at programming, or how many Google logoed items they own.
It isn't all about the dollars- don't let some HR firm tell you it is! Don't base your career/life trajectory on your paystubs.
**As an aside, I have visited the Google campus a few time for different projects- meeting with 'fairly high level' employees. We typically compare quality of life notes...I haven't talked to any Google employees over the age of 35 who thought they had made a good life decision to be there. Except for the former CEO's of companies Google has purchased...those guys are happy as shit.
No reason to lie.
They think it's great because, in a tragic case of hilarity, jumping into code with minimal design is what python is great at.
We think it's great because, among other things, it has first-class functions and a very high code:boilerplate ratio. This lets us write very concise, readable, and maintainable code.
If you're a diligent programmer in python/php/javascript/etc then, in each function you write, you're going to double-check that the type passed in is correct, anyway.
Eww, no. I've never seen good Python code that asserts types because it's not the idiom for you to care. For instance, suppose you write a function like:
In this case, obj might be a file, or a web request, or a string (via the StringIO interface). Who knows? Who cares? As long as obj.read returns something, it works. BTW, this is supremely nice for unit testing when you don't really want to hit an SQL server 1,000 times in a tight loop.
Now, you could write something like assert isinstance(obj, file) to guarantee that you're only dealing with file objects. Of course, that lays waste to the whole concept of duck typing and people will laugh at you for doing it. So dropping that bad idea, you could write assert hasattr(obj, 'read') to ensure that the object has the needed methods. But why? Python gives you that check for free when you try to call the method. Let it do the heavy lifting and concentrate on the parts of the problem you actually care about.
Exceptions are one of the worst things to have become common - an "error" is almost always only caught outside the scope that it occurred in, hence the stack has already been unwound and thus there is no sane way to fix the error and retry the operation that caused the exception.
Yeah, that would be terrible. You almost never use them in Python like that, partially because Python tends to have a vastly shallower call stack than, say, Java (largely because you don't need 10 layers of abstraction between bits of code thanks to the duck typing we just talked about).
I think it boils down to you not knowing idiomatic Python. That's OK. I'm ignorant about lots of things, too. But I think you'd find that you enjoy it more if you stop trying to write C or Java in Python, because that almost never works out well.
Dewey, what part of this looks like authorities should be involved?
I'll bet it was easier than hunting down the invisible bugs from mixed tabs/spaces or introduced by your editor mangling indentation while moving bits of code around.
Which is easily solvable by setting spaces-for-tabs in your editor (and which I do when working in Python, ... or Java... or C/C++... or pretty much everything because that really solves a whole bunch of issues.)
And violations of spacing/indentation rules are trivially caught by with automated testing/CI, which I do with Jython... or Java... or even C/C++ .... or pretty much everything whenever possible because it is the sane thing to do.
I've only been doing Python for 2 years, including C-to-Python bindings using Python 2.7x, Java-to-Jython/WLST integration (with Jython/WLST being based on Python 2.2), and a tiny bit of Windows automation with IronPython.
Most of my background is Java for enterprise development and C/C++ for embedded/system-level development.
As such, I initially I stumbled across some of the nuisances with Python, the spaces, the lack of a stack trace on exceptions, or the fact that exception hierarchies are slightly, but oh-so-different between Python 2.2 and 2.7. But past those stumbles, I simply use tool configs, procedures and coding standards to deal with them.
And that is the same when I do Java or C++. Each has their own gotchas and effective Java/C++ developers simply do the same - use tool configs, procedures and coding standards to deal with them.
Why would anyone mix tabs with spaces. Use one or the other, regardless of whether you do Python or not. If I see a code base in any language that has that shit mixed up, I know I'm bound to find some other stupid shit in the code.
Why? Because mixing tabs with spaces all over the place, like spelling errors, lack of meaningful comments and/or deeply nested code (arrow anti-patterns), these are all proxies for bad coding practices.
I originally found Python indentation rules to be annoying. After all, how hard is it to auto-indent from an IDE or a command line (or force an auto-indent of code before checking in, or en mass before merging back to the trunk)?
But you know what, people are idiots, and I've learned IN GENERAL not to expect them to write clean code (nor tell clean code from apple pie.)
It is still possible to write horrible Python code, but it is a lot harder to do so in it than in Java or C++ or C#. I would still have preferred to see Python having start and end markers for blocks (a-la begin/end or curly braces) on top of indentation rules.
But it is still a good compromise. Hard to see where code blocks end? Increase indentation. Better yet, refactor that shit out. If I see I have a harder time telling the end of a block, chances are that block is already large (time to refactor out), or that there is a lot of code around it (time to split it into better levels of abstraction).
You know, the kind of stuff we are supposed to do in any language anyways.
Besides, accidental violations that render Python code invalid, those things are trivially solvable by doing shit we are supposed to be doing anyway (namely, avoiding mixing tabs and spaces, automated testing, keeping code small and at least dry-run your shit before committing it to source control.)
I'm not saying programming in Python is Nirvana (for some things, it truly sucks.) But some of the things people complain about, they are just asinine complains for shit that broke because, on a fundamental level, they are not following good industrial practices IMO.