2020 Developer Survey Results
stackoverflow.blog
stackoverflow.blog
[1] https://insights.stackoverflow.com/survey/2020#work-most-imp...
There's a few technologies I actively try to avoid (.NET, etc.) but otherwise I'm open minded.
But I am much more peculiar on what kind of company environment and culture I want to work for. Call me trivial, but I really, really, don't want to work for any company that forces me to wear business casual (or worse). It's not just the dress code that irks me, but the wider culture it typically implies.
In fact, the reason I'm adverse to certain tech like .NET is also related to company type/culture that would use such tech, more so than the actual tech itself. I happen to like C#.
This is interesting to read - what does a .NET company type look like to you? (And follow-up, does that stereotype assume developing on Windows with .NET Framework; does it hold for .NET Core?)
Generally these projects are not fun to work on and having colleagues that spend significant chunks of time "refactoring" or talking about refactoring is not fun.
Even saying this is going to open a bunch of sealioning from these types ( https://knowyourmeme.com/photos/873260-sea-lioning) but that's just my experience.
C# has pretty good support for lambdas and implicitly typed variables these days, so a lot of the enterprise stuff is overkill. Implementations in C# could look more like Python while being more type safe but they tend not to.
I once had a developer commenting on one of my blog posts who was very angry that I did not use a proper layered architecture in the blog post :)
C# itself is an ok language. It's just the culture around developing web applications with .Net that's painful.
At my workplace, we're currently transitioning from C# to Typescript. As you can imagine, it's not pretty. Key to this is how Microsoft have managed to encode much of the misdirection inherent in .Net webapp development, into the Azure API surface.
I dunno...
Now I sound as dogmatic as the community I'm accusing of dogmatism...
I was in a project that involved a team of mostly traditional enterprise .NET devs writing a greenfield app in Python (language choice mandated from up top). The result was basically something that was designed like a dogmatic enterprise .NET application, only using Python abused and wrangled to fit that style.
After that project was done, for subsequent work, the team split into two camps - one camp that despised being forced to work with Python and continued to write Python in enterprise .NET style, and one camp that decided to explore more about Python and try working in more "Pythonic" style. Code review sessions were full of emotions and drama.
Pretty much everyone in the first camp eventually left, either for other internal teams that were still working in .NET, or for other companies.
Anyway, everything else you mentioned sounds uncannily similar.
Makes you wonder how such a culture develops. The only constant appears to be Microsoft development tools, curiously.
Does anyone really use .NET Core in production? Maybe in certain locales and industries only? I've been on the job hunt for a while, talked to and interviewed at numerous companies, and I've yet to encounter a single company advertising that they use .NET Core.
Friends from other companies are also using .NET Core whenever they can, so yea.
Eastern Europe here.
The point of these surveys is to tease out the trends, since data points like us are noisy.
[1]https://www.pewresearch.org/fact-tank/2015/10/01/women-more-...
No men have yet given birth (yet?).
It's no surprise that the childcare/teaching industries are almost entirely made up of women.
There’s also some research that over-representation of women as K-12 teachers is responsible for the growing education gap where men are falling behind women. It isn’t just women who are held back by gender stereotypes.
- Women do most of the shuttling of kids? I've yet to see any evidence of this.
- There are differences between the genders, but 'genetic behavioral differences' is a very broad and deep assumption regarding nature vs nurture and opens a whole other spectrum of basic questions.
- Over representation of a gender in some particular field. Being equal does not mean we all have the same aptitudes and interests.
For example, it groups technology as "web frameworks" that just are not equitable [e.g. rail != express != jquery != react] and compares things like react native to node.js [makes no sense].
Personally, this survey feels more like a marketing handout than anything else and I would take it all with a giant grain of salt if at all.
You seem to equate "actual professional" with "meaningful complexity" or "deployed to production", which seems limited. I'm pretty sure I've written meaningfully complex code outside my day job -- and I would guess many open source developers write such code outside the context of their job.
This is the metric for most loved language. So if 15 developers responded that they use rust, and all 15 have interest in continuing with it, then its score is 100%.
This is not such a great metric of rust's success IMO. you can't try to push a well designed systems language into applications space and expect it to win everywhere.
The actual problem is, there is no mature language with sufficient compile time guarantees for applications space. Go which is somehow treated as rust's competitor, is nowhere near that in terms of expressiveness or compile time checking. You would actually want generics, nullable types, exceptions, and streams in an applications language.
I'm pretty sure that no-one wants to fight with the borrow checker whilst implementing a data structure either on a whiteboard or in Hackerrank / Leetcode.
I want to like Rust, but its "do anything and everything" packaging system (Cargo) makes it hard to properly integrate into external build systems, which is pretty important to large companies or any company that has an integrated build system or an existing build system. The language is also increasingly complex and shows no sign of slowing.
Developers may have a high opinion on Rust, but the evident scarcity of Rust jobs and underusage in the real world doesn't give me the impression that it's a production ready language.
[1] https://en.wikipedia.org/wiki/Go_(programming_language)
[2] https://en.wikipedia.org/wiki/Rust_(programming_language)
Note that I didn't say that Rust was buggy or was too small or something like that, I said that Rust was too complex and it didn't allow integration into external build systems. Both are things that the Rust project is completely capable of addressing but has chosen not to prioritize in favor of other language features.
Correct me if I'm wrong, the earliest discussion I can find about meeting large org requirements took place in 2019 [1], 8 years after it first appeared, or 3 years after v1.0.
It's their choice what to do and when to do it, but I think it's misleading to perpetually point at Google and ignore the Rust project's priorities. I'm open to a better explanation as to how Rust is somehow production-ready and extremely well known but comparatively few professionals actually choose to use it.
[1] https://users.rust-lang.org/t/rust-in-large-organizations-me...
* kubernets - 2.5k contributors, 66.5k stars, 3.2k forks, 91k commits
* cargo - 609 contributors, 5.6k stars, 1.1k forks, 9.5k commits
No doubt there are large companies using Rust but that's peanuts compared to Go.
A few things I noticed: Other than management and sysadmin, the area with the highest average seniority was embedded programming. That fits nicely with my view that embedded is an area with less age age discrimination.
Haskell pays better than C++, by a fair amount internationally, but only fractionally better in the US. I'm not sure what to make of that, but I thought it was interesting.
If you can design your schema and usage patterns so as not to hit those limits, it's a very scalable option. But in return, you are in for a very strong vendor lockin.
Unfortunately, almost all pay as you go, linearly scalable managed databases, for example, FireStore, DynamoDB, CosmosDB are essentially lockin in nature (and maybe by design)!
Other OSS NoSQL products almost always need a base cluster costing $1000 (or more) per month to get decent baseline performance. After that point, you can scale to a very high scale by vertically and horizontally scaling your cluster.
Even some simple sharing can be a pain and counter intrutive.
I would add that tooling and stability are also not a thing for Rust as of now, that being said it's pretty clear that Rust is here to stay like Go.
That being said, those structures are a subset of all possible structures and may feel roundabout. Sharing does end up being even less obvious, but it also steers you away from bugs which would be difficult to spot in other laguages. I think it comes out even here.
There are little conveniences in Rust like switch / if being expressions and the ? operator, but the gimped Templates and refusal to do Implicit Conversion wind up littering boilerplate everywhere. I do somewhat prefer the way its standard library handles iterators, though.
C++?
Structs and enums are all over the place
Free function definitions, and methods defined on a data type, are extremely common
Rust Traits are ways of naming groups of operations to be associated with different types, and share a lot of similarity with Type classes, roles, interfaces, mixins, etc. present in many common languages
async/await is similarly present in many common languages
Generics / Parametric Polymorphism, extremely familiar from C++, Java, C#, etc.
It's almost all modern takes on normal common PL things that have been in many languages for decades
So by my perspective, I see a very normal imperative language, with its own take and small quirks on very familiar features, and the only feature I've been able to come up with that's "completely unlike every other language people have been using for decades" is the borrow checker. One new unique feature seems well within the weirdness budget of a new language.
Could you expand a bit more on what it looks like from your perspective? What other features or properties of the language seem strange, alien, foreign, or otherwise completely unfamiliar to you?
I agree that Rust has some things (maybe just one thing: the ownership + borrow checking system) that are "completely unlike every other language people have been using for decades", but so does C++.
Neither is Rust, most of the things that seem weird or new in Rust already exist in functional languages.
It has developed a lot of idiosyncrasies that range from "confusing unique syntax" to "using these two features together will blow your app up with no warning from the compiler".
let v: Vec<u8> = b"3q2+7w==".iter().cloned().collect();
let v: HashSet<u8> = b"3q2+7w==".iter().cloned().collect();
I don't know what the name for this sort of behavior is, and I haven't seen it in other languages. Perhaps it's just a property of Rust's trait system? Regardless, it feels intuitive to me - like the compiler is taking type information and using it to make implicit casts throughout the program.
Not a huge impediment - just something I found confusing that isn't related to the borrow checker.
[0] https://users.rust-lang.org/t/why-cant-the-compiler-the-type...
It's not a cast. Rather, it's an inferred/omitted type parameter. In this case, the collect() method is actually collect::<ContainerType>(). So it's not that collect returns something to be cast, but rather that there is a different collect() implementation for each target type. When the compiler is able to infer the target type unambiguously -- for example here, because you assign it to a typed variable -- then you don't have to specify it.
What's throwing him off is static method dispatch based on type inference on the return value.
Haskell, for example, does this too:
class Foo a where foo :: a
instance Foo Integer where foo = 3
instance Foo Char where foo = '*'
foo1 :: Integer
foo1 = foo
foo2 :: Char
foo2 = foo
main = do
print foo1 -- prints: 3
print foo2 -- prints: '*'As a language though, Dart is MUCH better than Typescript. If you're going to go all-in on types, at least go with a decent type system rather than one who's core objectives explicitly do NOT include soundness.
https://www.typescriptlang.org/docs/handbook/type-compatibil...
[1]: https://flutter.dev
It's amazing how no solution has yet been found for this very real problem.
Well as someone who doesn't have a formal comp. sci. education, this is a bit alarming for me. Personally didn't think the number was that high.
Formal education is not necessary to be capable of doing the job, especially if you have some good people to learn from and are willing to learn on your own.
However, it is very very good at filling in the things you don't realize you don't know. It provides a huge number of hooks in your mind you can investigate further as necessary on the job, as well as random little factoids you didn't know were important.
For example, those bootcampers I worked with? Never encountered deep copy/shallow copy, and had trouble figuring out a bug caused by using shallow when it should have been deep. None of them had issues the moment it was explained to them, but they'd just never experienced it before, so had nothing to work from.
Maybe they'd have figured it out and understood it eventually, or maybe they'd make guesses from StackOverflow and find something that works well enough without understanding why it works (so next time it comes up they're starting from scratch) (and yes, I have seen this).
It's just lots of small things like this that make up that split (and a sibling comment mentions more of them). The survey was not well-structured to get this nuance.
The common consensus is it is pretty important for every developer to know some low level programming (C, asm) and algorithms/Data Structures stuff. Not so much about other things covered in standard CS curriculum.
The bigger problem is that I feel a bit of a cultural outsider. There are jokes, stories, language that coworkers use and I'm just not familiar with. That can promote impostor syndrome and definitely affects interviews (eg "cultural fit").
> When asked what steps to take when stuck on a coding problem, 90% of respondents indicated they visit Stack Overflow.
> 0.3% of respondents had never visited Stack Overflow before taking the survey.
> More than 40% of respondents reported that they are members of other online developer communities beyond Stack Overflow.
> More than 15% of people find Stack Overflow at least somewhat more welcome than last year. We still have work to do, but it’s a start.
A big difference from last year's page, if you check. Probably the effect of new CEO and bunch of new CTAs popping up everywhere about their paid tools!
Rust is a complete breakthrough in modern popular languages as a safe, fast, and expressive alternative.
MongoDB, or really any aggregate-oriented database, is perfect when you’re modeling your domain as aggregates and you align your data access patterns with the design of these aggregates. Do your homework to set the right settings, take regular backups, then focus on what matters (hint: it’s not really persistence).
Redis is a no-brainer, it’s just plain great for managing user sessions.
There’s a place for everything, keep your mind open :) https://martinfowler.com/bliki/PolyglotPersistence.html
My impression is the opposite. Julia forces you to think more about CS concepts early on (which is nice) while with Python or R you can get further by just figuring out the syntax for what you want to do and not worrying about how your code is executed.
Is it just popular with 9-5 big-co dev jobs and their large numbers influence the survey?
The problem still is the traditional .NET conservative developer culture that I've experienced in .NET jobs IMO. It stops them from trying out the best things in their space (e.g. F# as one thing that comes to mind). NET Core as a runtime on a Linux platform is actually pretty good these days. This can vary by team and company however so not a reason to not choose the technology per se.
It would be interesting if we knew that in the larger world, equal number of programmers were in each experience bracket. So then we could see which experience group visits SO the most often. But we already know there are far more programmers with 5 to 9 years experience than there are programmers with 35 to 39 years experience. So are those stats showing anything other than the natural bell curve of experience distribution of all programmers in the world?
If we had the experience distribution over all programmers whether or not they visit SO that we could compare with, it would be interesting to see any differences. My guess is that there isn't. I bet highly experienced programmers visit SO just as often as those with 5 to 9 years experience.
Maybe to a recruiter or for someone paying for job adverts, those numbers are interesting on their own.
I'm sure that women leave tech jobs at higher rates than men, but hasn't there been a stronger focus on educating women for tech jobs in recent years as well? In other words, if more women have been learning to code in the past decade, then I'd assume that that also leads to a larger percentage of women in tech having learned to code more recently.
edit: I can count the number of Perl scripts I have used at my job (0). I cannot count the number of Node and Python scripts I have used at my job (there are too many). The niche has been filled.
[1]https://insights.stackoverflow.com/survey/2020#technology-wh...
I don’t usually live in the world of enterprise programming so I’m not sure how normal that is, but it definitely surprised me.
The web specs are millions of pages of legalese (and that's without mentioning things like WebGL which are handled by groups other than w3c). Learning all the stuff required for building a modern application on the web takes a long time. In addition, the incompatibilities and inconsistencies (between both browsers and browser versions) paired with the inconsistencies of much of the tooling and frameworks (though that has gotten much better in the past couple years) leads to a frustrating experience.
If you need an actual web app and want to hire a knowledgeable developer who's willing to learn everything and not burn out from dealing with all the frustrating parts, it's very likely that you'll wind up paying more than for a back-end dev with similar amounts of experience.
"White or of European descent: 68.3%"
...seriously though, how relevant is that racial statistic? Should we break it down by eye color? Hair color?... I think categorising people based on race does more harm than good...
Problems don’t get solved unless they’re being tracked.
You come across like you have an agenda. What is it?
I'm also not seeing what "under fire" means. The IT area has dozens of millions of people employed. If it was truly under fire then I'd assume it would shrink in numbers, at least in terms of representation of white men? But I'm not seeing it happening. If you have links proving otherwise I'd be interested to read them.
It's a measurement that I am certainly curious about.
I do not belong to that most popular demographic, and have a passive interest in that demographic distribution becoming more proportional to its global distribution.
And these graphs convince people that it somehow is important on what skin color you have...
Unfortunately, we live in a world where they do matter.
Measurements like this are necessary if we want to make them matter less.
The closest thing that can be said is that StackOverflow is biased towards western English speakers, which correlates well with white/European.
How does measuring skin color help make skin color matter less?
To me it emphasises the importance of skin color, when it should be ignored