Having gone through Triplebyte's interview process, I'll propose another interpretation: Triplebyte's interview is <i>on aggregate</i> biased against Java and C# developers. I'm not accusing Triplebyte of "being biased", but rather pointing out that Java and C# tend to correlate to a skill set that Triplebyte's test process values less.<p>My experience of Triplebyte's interview process is slanted towards frontend/backend developers of web apps. Fortunately for me, that was my background. However, in the team I currently work with, the team is in aggregate heavily C# with only secondary experience in web frontend/backend development. That's because their expertise is in low level security. Several developers on this team are exceptions to the "don't roll your own cryptography" adage.<p>They're all competent developers, but the version of Triplebyte's coding test that I took (and passed) would be in unfamiliar territory for people in this team. That's fine since most of Triplebyte's clients are probably looking for web frontend/backend skills, but I think this means that Triplebyte's test shouldn't be seen as an objective measure of programmer skill, just an objective measure of fit for Triplebyte's clients.
There are some warts, but it seems nice from afar. The biggest wart is/was the "FUCK FUCK FUCK" git clean vs git reset UX error: <a href="https://github.com/microsoft/vscode/issues/32405" rel="nofollow">https://github.com/microsoft/vscode/issues/32405</a> . This is a fantastic demonstration of why i exclusively use git from a command prompt -- i <i>know</i> what will happen and nobody's going to reinvent terms to put on buttons that just confuse me.<p>In my life:<p>- I'm committed to emacs for org-mode and LaTeX editing and daily use.<p>- I paid for sublime so i will use it -- and multiple cursors everywhere is a boon for quick and dirty data munging.<p>- I write serious python code in pycharm.<p>- I write serious c# in full blown Visual Studio
> Engineers who use Go are also especially strong. If you know why, please let me know.<p>Because there is almost no reason to learn Go. Most shops want JS/Java/Python/C# etc... The primary reason to learn a language like Go is because you want to for it's own sake.<p>It's not that you must learn Go in order to be good, or that knowing Go makes you better. Rather it's difficult to be bad and still have the desire/interest to spend time learning something unnecessary.
It's a good text editor, first and foremost. Compared to netbeans, eclipse, visual studio, even intellj idea in my opinion. The same thing that made textmate, then sublime text successful made VSC successful. I takes a few seconds to launch, even on my celeron machine with 2Gigs of RAM, it's relatively minimal and unlike intellj it doesn't appear to be analyzing my whole hard drive for hours for no reason...<p>the irony is that Microsoft did hire Eclipse creator to work on that product... hopefully it doesn't end up bloated. Having an open spec for language servers is also a smart move. While others have their proprietary, often non speced protocol, now any text editor can implement the same protocol and basically use any language server already developed.<p>So kudos for Microsoft, it's a great piece of engineering.
VSCode is fast and it's certainly the best editor/IDE I've used since back when I was a Java dev using Eclipse back in 2006 or so.<p>But I recently opened up Sublime Text to compare some editor behaviour, and the difference in UI performance is <i>astounding</i>.<p>It's possible that VSCode has regressed a bit the last couple of years. It was always faster than Atom. But comparing it to Sublime shows that there are clear advantages to writing UI code in a natively compiled language. Sublime's widget drawing seems very well optimized.<p>VSCode has also become slower for me the last few years, simply from the load of extensions. I use the ESLint extension and the Go extension heavily, both of which parse code a lot. Neither is doing any sort of incremental parsing, so there's potentially a lot of churn. There's also some kind of indexing of symbols that happens in the background in the language server or in the extension. I sometimes have to kill the "Code Helper" process because it's sitting there consuming a whole core when idle.<p>Overall, VSCode is becoming increasingly closer to how I remember Atom, when I used it. I worry that it's slowly turning into Atom, performance-wise.
It seems strange to me to compare VSCode against PyCharm, IntelliJ, and Android Studio separately.
While PyCharm, IntelliJ, and Android Studio are distinct applications, I believe they share much of their code, UI, 3rd party plugins, and workflows for all being JetBrains language-flavored IDEs.<p>On the other hand, VSCode supports different languages through its extensions instead of having separate language-flavored applications like "VSCode Python", "VSCode Java", or "VSCode Android".<p>So I feel that reaching for IntelliJ vs. PyCharm vs. Android Studio is roughly equivalent to installing a particular set of extensions in VSCode. If you look at it that way, the data from the article seems to tell a different story - while VSCode has grown significantly in popularity, JetBrains IDEs seem to dominate in terms of overall usage (11.3% + 6.9% + 4.1% = 22.3% vs. VSCode's 16.8%).
VSCode is fast, stable, and the plugin ecosystem really beats Sublime Text at this point. I was skeptical because Microsoft but it is hands down my favorite editor.
Like it was said in this thread, as long as you have an editor that is built on something js-related like electron or node-js, it just cannot beat alternatives that are made in C++.<p>I've tried VSCode because I wanted to have UI breakpoints with GDB, I admit that vscode seems better than atom, but for performance I have my doubts.<p>I really don't understand why engineers choose to use JS to made a text editor. I know that js and the dom have enabled the web, but it's because there was nothing better, choosing js to do non-web stuff doesn't only sound silly, IT IS silly.
One of my favorite things about VS Code is how usable it is with its default configuration, and how easy it is to customize to my liking. I found Atom and Sublime Text very frustrating in that regard.
VS Code solves different problems then IntelliJ, PyCharm and Atom. I'm not sure this is a fair comparison. For example, I wouldn't ever code a full Java stack in VS Code. I'd go straight to IntelliJ.
Frankly, I think we're seeing the results of the new era of Python paradox. Except it's not Python 3, it's TypeScript, VS Code, and React.<p>If you look at the education space, many of the deployments are either Chromebooks or iPads. Back in 2012, the "learn to code" sites (like Khan Academy or Code.org) ended up building their lesson plans around JavaScript.<p><a href="https://johnresig.com/blog/introducing-khan-cs/" rel="nofollow">https://johnresig.com/blog/introducing-khan-cs/</a><p>People who were in 3rd- and 4th-grade in 2012 would now be finishing up high school. Someone in 7th- or 8th- grade would have just finished a bachelor's, or maybe be looking for their second job after two or three years in the industry.<p>For these folks, TypeScript/VS Code/React would be a short jump from these learn-to-code-JavaScript-in-the-browser sandboxes.<p>As for Go... I suspect that's the set of people who can handle Google-scale software complexity. So either former Google employees, or people who are in the kubernetes ecosystem.
The "live shared coding" angle in VSCode makes it a great option in many areas where there's a need for it. People have been asking jetbrains for this for a decade, and there's nothing on the horizon as far as I can tell.
Ok I stopped reading when they started drawing graphs how well the people using certain editors fared better in their test as if the editor could have anything to do with it.
I've told you guys before - my 10 year old son scored 'well above average' on their interview process. We live in the UK but they are still trying to recruit him. And no - he cannot write code.
I'm not Microsoft's biggest fan (I switched away from .NET and their platforms a few years ago, switched to Mac, etc).<p>But I use VS Code, it really is a great little editor with a good ecosystem.<p>The JavaScript support pulled me in, but it's a pretty decent Rust environment now as well!
Another interesting angle on this is that VS Code is free (and open source), while Sublime is proprietary and (nominally) costs $80. I wonder how many people don't use Sublime because of the price? Atom is free too and never surpassed Sublime.
"Do Emacs and Vim users have some other characteristic that makes them more likely to succeed during interviews?"<p>I think the Interview Pass Rates chart makes it clear that the answer is a statistical "Yes", at least for Emacs.
> However, it seems that the average C# or Java engineer who goes through our process does less well than the average Ruby or Go engineer. I have no idea why.<p>Given that they have the test info... and they're the ones deciding pass/fail... it's a bit strange they "have no idea why". Well, perhaps just this person doesn't?<p>Are people not finishing the projects? Do the projects have syntax errors in them? Or logical bugs? What metrics do they use for "pass/fail"?
> Do Emacs and Vim users have some other characteristic that makes them more likely to succeed during interviews?<p>I think it comes down to users of those editors probably are used to keeping code/libraries in their head more. IDEs tend to suggest a lot to you and if you're not used to having that happen you could get more nervous during whiteboarding rituals.<p>Edit: I guess this really doesn't apply as their interview process is on the web.
I have tried VSCode a few times for C++ on macOS and always found it more hassle than it was worth to get it up and running.<p>I saw it had debugging options and I thought that looked pretty cool but it is a bit of a mess with tasks.json and some other file I have forgotten about now. I recall I did finally get a working setup but it wasn't portable between folders/projects as the binary filenames were hardcoded and I just lost interest in fixing it.<p>I think the VSCode team could make this a lot smoother. I want my tools to simplify these things for me with automatic configuration like every other editor seems to be able to do. Not sure why VSCode needed a couple of json config files to know to use /usr/bin/gcc on the current C++ file when no other programmers editor does.
> With 17% of the pie, VS Code was the editor used by the majority of Triplebyte candidates last year.<p>Huh? This has broken the world of math for me.
It's interesting to me that Go does so well. I have a buddy who convinced his shop to switch over to Go for the following reason: he knew that they were not going to be able to consistently hire good programmers, and he thought Go was a way to mitigate the problems arising from this situation. In other words, Go is a language where newbie programmers can still do okay. He also claimed that Google developed Go for this reason, referencing the infamous Ron Pike quote ("They're not capable of understanding a brilliant language, but we want to use them to build good software").
Just as an aside, there is this sentence in the article: <i>"On the peninsula, where larger companies tend to be located, you see a lot of Java developers. In San Francisco, where startups dominate, you see more JavaScript."</i><p>None of the non-SF cities is on the peninsula. They're 100% in the Silicon Valley / Santa Clara Valley.
I was also surprised to see how much VS Code has grown in popularity among WakaTime users in such a short amount of time. [1]<p><a href="https://wakatime.com/static/img/wakatime-editor-usage-2018-12-07.png" rel="nofollow">https://wakatime.com/static/img/wakatime-editor-usage-2018-1...</a>
Intellij, pystorm, Android Studio (and half of "Other") make up more than a quarter and are the same jetbrains editor with different plugins pre-installed and some plugins unavailable..<p>That is more than VSCode and these identical IDEs are all over the place in these charts.<p>So what was I supposed to have learned from this article?
What I would gladly pay 100$/month for is Vim with correct syntax highlighting, intellisense and nice plugins (such as fuzzy finder) by default.<p>It would not need to be Vim, but I have only tried one Vim emulator that didn't suck and was terminal-first: emacs with evil-mode. Let that be the bar for vim-emulation.<p>Why is nobody doing this? I think this would appeal to a lot of people.<p>The criteria for me to to pay for something like this would be:<p>1. Terminal first. It would either have to become my main shell or open fast within my shell.<p>2. Vim based or with GOOD Vim emulation. Macros, remapping and all normal mode key combinations must be implemented.<p>3. Fast terminal<->editor loop. I don't want to wait >300ms to edit a file.<p>4. Actual production quality zero-config syntax highlighting, intellisense and fuzzyfinder.<p>Sign me up!
Funny how people analyse data and draw conclusions without applying any statistical method. Yeah, maybe more people use VS Code, but I don't think it has anything to do with people's failure or success.
VS Code has taken me off Emacs for Python development on Windows. I was never able to get a clean and speedy code completion, navigation, or refactoring to work with Emacs. I hope the situation changes someday.
The killer feature for my switch from Atom was the built in terminal. Enough to let me be ok using a ms product temporarily to try it out. I appreciate their energy behind it - the update schedule, the changelog write ups, the listening to the feedback from the users.<p>I really liked the json config of atom. the code gui isn't my fave but it's ok.<p>Two other things helped me transition easily:<p>- click a button to edit `PATH` or whatever so that `$ code` opens up the editor from the terminal<p>- atom keymapping<p>The coffee script use in atom was unfamiliar territory for me too, so that part seemed distant.
> The first thing that jumps out from this graph is the prominence of Visual Studio Code.<p>Maybe to some. 10.2% percent for vim!<p>For some reason that makes me really happy even though I use emacs. I guess the (d)evil you know...
Anyone who still uses VSCode, probably haven't read about all the features IntelliJ and its ilk offer.
The local history, for example, and its integration with the test runner (knowing at which point of your editing process your tests started to break) has saved me a tremendous amount of time.
(I've accidentally erased changes that were uncommitted with a stroke of a `checkout -f`, and managed to save hours of work with that feature alone.)
These conclusions are frustrating to read because they haven't handled the numbers properly at all and have drawn poor conclusions.<p>Take a scenario where Java/C# are popular and have 20 people applying for each position but Go isn't and only has 5 people applying for each position.<p>You'd then have a far far better "pass rate" for Go developers. But it doesn't actually say anything about Java or Go in terms of developer proficiency.
The only issue I have with VS code is it's awful UI/UX performance - it behaves like an Electron app or something.<p>I realize that's a fair insult around these crowds, but it really does have that lack-of-polish, weird-UI/UX feeling. I know Microsoft would obviously never build an IDE off it, but I'm almost curious to see what on earth they did wrong.<p>Comparing it side-by-side with Xcode is certainly the easiest way to tell.
Because of the popularity of VS Code on HN, I decided to give it a try. It's good. Much better than Electron or Atom for my workflow. And much faster IME.<p>The one thing that keeps me from switching from my current IDE is the lack of Whitesmiths brace formatting. I'd pay up to $15 for a Whitesmiths plugin. Until then, I can't change. But I'll keep checking.
I like VSCode a lot. The only reason why I sometimes switch to other alternative is the multi-file search results. When the fix this, I will be a happy camper: <a href="https://github.com/Microsoft/vscode/issues/63465" rel="nofollow">https://github.com/Microsoft/vscode/issues/63465</a>
What editor do Go devs use??? Their numbers for Go only add up to 12%!
<a href="https://d25hn4jiqx5f7l.cloudfront.net/file_attachments/files/original/96551f0f84b87bd438ab1e7be23c269038383620.png?1543937640" rel="nofollow">https://d25hn4jiqx5f7l.cloudfront.net/file_attachments/files...</a>
Sure, maybe it is the old-school nature of Vim and Emacs that makes then standout in performance, but why not throw a years-since-graduation variable into the equation to find out with greater certainty?
I recently helped make a VS Code extension during a Microsoft internship, and I found the language server interface really easy to use. It really makes it easy to write an extension.
"Do Emacs and Vim users have some other characteristic that makes them more likely to succeed during interviews? Perhaps they tend to be more willing to invest time and effort customizing a complex editor in the short-term in order to get returns from a more powerful tool in the long-term?"<p>One thing I noticed on Lobste.rs is that a lot of them like the old school editors. That's normal. What was more interesting was that they were constantly sharing and discussing their customizations that made them more productive. Kept making me want to have another go at those editors. I didn't since I came from Windows with big, full-featured editors that could do everything (or Notepad++ or Notepad). Still, I keep reading those comments since there's always new and interesting things people are coming up with.<p>In other words, I think the author is onto something worth further investigation and comparisons. Especially comparing VS Code programming to experienced folks using highly-customized, full-featured setups in the other stuff. I bet the results would be more interesting than a random person tried using Emacs or whatever.