OK, since we're wasting our time on the Pointless Editor War, I shall confess I know exactly one thing about Vim, the command `:q!'. That's all I've ever needed to know.
Technoreligious wars are emotional / black-and-white / stupid thinking / herd mentality, a priori. There is more than one way and one tool in the toolbox. You might not "like" every thing, but other things exist, function, and accomplish work.
People who write “our only real option is VSCode” about Python and Go programmers are ignorant of what Emacs can do. Some people may prefer something else, but Emacs is a real option.
As a five+ year Emacs user who primarily codes in Go and some Python, and is aware of eglot, other LSPs, elpy, etc: I fully agree that VSCode is the only real option. If you happen to have a passion for Emacs, as I do, awesome. But it's not realistic to start using Emacs when you need to switch off of another editor. I would never suggest to a new co-worker "try Emacs", though I would be more than happy to help them if they wanted to.
Emacs is an extremely esoteric program, from shortcuts, to documentation, to package management (should you use elpa? melpa? melpa-unstable), to configuration (I love Lisp, but it's much more esoteric than JSON), to bugs (who has regular UI locking as an expected part of the experience, e.g. when using eglot, in 2024?).
I love emacs, and tinkering with it, and will probably never stop using it. That doesn't mean it's a real option for someone who doesn't want to make it a hobby.
As an enthusiast myself I'd be tempted to come to the same conclusion but I'm surprised with the options and learning resources out there how quick some people can get up to speed in Emacs. Yeah, it will probably take a good weekend project worth of time, but it's pretty easily doable to make the switch.
Learning the basics you need is just one part. It takes far longer to get used to actually using what you learned. Whereas switching from IntelliJ to VSCode, you'll need the basic setup and appropriate plug-ins, and then you'll be basically fully up to speed. You'll take much longer just to get used to M-w instead of Ctrl+C.
> Emacs is an extremely esoteric program [with respect to] documentation
I sort of get the other points, but I really don't get this at all. How is Emacs documentation esoteric? Emacs is without a doubt the best-documented application I've ever used. I can't think of a single thing with documentation as comprehensive, accessible, navigable, interactive, searchable, or genre-spanning as Emacs' documentation.
Emacs' documentation is so far from assuming that you already know how Emacs works that it'll literally teach you not only how to use the available configuration options for its built-ins (and any external packages you choose to install) or the language used to set them, or even how to write code in that language, but what computer programs even are.
Someone with zero programming knowledge whatsoever could sit down at a computer with no internet connection, open Emacs and its manuals, and learn everything they need to use, understand, and modify Emacs all the way to the point of contributing their own Elisp code to popular packages or Emacs itself. All that without reference to a single external document or a minute of personal instruction. Emacs documentation covers everything from how to change your colorscheme to what a loop is. How is that 'esoteric'?
I don't think anyone is arguing that emacs is *incapable* of being a good editor for Go and Python. I personally just don't want to. These same reasons are as applicable to emacs as they are to (neo)vim (which I used as my daily driver for a while).
1. I don't really want to bother with a DSL for configuring my editor (even if the language is usable outside of that context for other things)
2. I don't have time to bother with maintaining extensive configuration to get the level of code completion/refactoring/etc that I expect from a modern IDE (nor do I want to have to stop what I'm trying to work on to debug a problem with my config)
3. I don't want to have to research various plugins and stuff to provide functionality that I get out of the box with VS Code (or other editors)
4. I don't want to have a bespoke environment that only I understand when I'm trying to collaborate with my teammates
Don't get me wrong: I think digging into emacs and/or (neo)vim is a valuable thing to do and that everybody probably *should* do it at some point (even if only as an academic exercise), but to assert that they are a viable path for everyone is ignoring the reality that some people simply aren't interested in investing that time/effort into getting their tools working.
One can argue whether or not that stance is a good one or not, but you're just debating personal preferences and priorities at that point.
> I don't think anyone is arguing that emacs is *incapable* of being a good editor for Go and Python.
On the contrary, the article said, literally: ”We are primarily a Go and Python shop, which means our only real option is VSCode”. Meaning they do not consider Emacs to be a ”real” option. This is expressing more than mere personal preference; it is, at best, profound ignorance of what Emacs is capable of.
IMO, emacs isn't a real option when you're talking about a group of developers. The people for whom emacs is a real option likely already use emacs (same with (n)vim), but that choice is made at the individual level, rather than at the team level.
It's unlikely that a given team/workplace is going to roll out dev tooling that is just a pile of elisp. With VS Code, you can drop a couple of JSON files into your project, commit and push them, and then everyone has a preconfigured set of tools that match the needs of that project.
I've used GNU Emacs since the mid 80s. It was good in its day, but I think there may be better alternatives nowadays.
I can't be sure, though, because using Emacs as an expert is definitely better than using those other systems as a beginner, so I haven't gotten around to getting over the learning curve.
I first started using Emacs in 2015 or so, sometimes still relying on other editors (usually IDEs) alongside it.
I was still in school then. By then, I'd used for varying lengths of time (and had been taught, to varying degrees): DrScheme, BlueJ, Visual Studio, Eclipse, NetBeans, and IntelliJ IDEA. (I'd also used vim, Kate, and Notepad++, but I used those mostly for editing configuration files, plaintext notes, and shell/batch scripts. Vim was the only non-IDE editor I'd ever used for any real programming, which amounted to my coursework for a few classes in college.)
I didn't dive in with writing my own config from scratch, but started with Spacemacs as someone with prior (and merely casual) vim experience. It was better in some ways and worse in others than those 'modern' IDEs I'd used previously. Performance was worse (although resource usage was much better) in that sometimes Emacs would hang or pause for slow operations. Startup time was slow, but client/daemon support made that invisible. The total stack I ran was noticeably buggier than alternatives like JetBrains, because a distro like Spacemacs glues a ton of external packages together. Spacemacs releases were infrequent so I ran against development branch, inviting more bugs.
But the main thing that struck me was how nothing else I'd ever used was as easy to learn as Emacs. I loved all the search-driven workflows and interfaces, how fuzzy-filtering was everywhere. I loved how running commands 'manually' always showed and reminded me what their keybindings were. I found myself learning many more keybindings than I ever did with other editors/IDEs, because they were so easy to look up, and looking for many more 'interactive functions' (commands) than I ever had before, because they were so easy to search. It had quirks, and I was grateful to have a 'starter kit' in Spacemacs (without which I likely never would have picked it up). But overall it was clearly, decisively better than anything I'd ever used in virtue of its radical discoverability alone, and I quickly built up muscle-memory for the Spacemacs bindings.
Automated refactoring and advanced code navigation were clear weaknesses, though. That's why I sometimes used JetBrains IDEs for some languages in the years immediately following.
Nowadays I'd say things look even better for Emacs as compared fo IDEs. It has pretty good performance, and more and more packages do things asynchronously where it makes sense. Virtually every programming language has one or more LSP implementations, so good code navigation functionality is easy to come by and old tools like etags can still be used as seamless fallbacks. (I don't do much work in static languages lately so idk how good the refactoring support for popular LSP implementations really gets, but basic refactoring in Python seems fine.) Emacs even gets along well with the new 'AI' hotness; its documentation culture and fine vintage mean that ChatGPT and friends are better at writing and explaining Emacs Lisp than the vast majority of programming languages, plus they 'know' lots about not only Emacs built-ins and popular packages, but even the configuration idioms and special macros of popular Emacs distributions like Spacemacs and Doom Emacs.
I no longer use any other IDEs anymore because I don't see any reason to for my current use cases, though I do still use Vim a little. Recently, I've started occasionally using VSCode to test things on behalf of my users at work, who are other developers. Far from decaying or falling behind, I think Emacs has become a steadily more attractive alternative to IDEs since I started using it. I don't begrudge anyone their VSCode or JetBrains IDE if that's what they've already chosen, but I'd still recommend Emacs (with a good starter kit) over either to programming novices today.
> In addition to terminating all sales, all of our offices in Russia, including Moscow, Novosibirsk, and St. Petersburg were shut down. Work on the new campus in St. Petersburg was also terminated. All R&D activities were gradually stopped and liquidation papers for our Russian legal entity were filed in August 2022.
And a fair amount of people were relocated, Russian and Ukrainian both. I wanted to be mad at JetBrains for joining the “screw the closest Russian we can get our hands on” wave[1], but I’m not really able to because of that.
[1] A contemporary joke went (hope the translation works): “Durex has announced it is leaving Russia. When asked for comment, the company’s representative responded, ‘Not our fucking problem now.’ ”
My guess is continued heavy employment of Russian citizens is the problem. Risk of state putting pressure on their families and turning them may be too high for certain government agencies.
I've seen so many editors come and go, and yet I've been using Vim for the past 20 years and have never had a problem. As stupid as it sounds, if I could give one piece of advice to any entry level SWE, it would be to learn Vim or Emacs and just stick with it for your whole career.
I find this and the emacs sentiment really weird. I use vim daily for quick edits, but for any sizeable codebase, especially new/unfamiliar, IDE's are just better. It's like depriving yourself of a bunch of tools and helpers for no visible benefit.
Since I graduated, I've had people try to sell me on the following editors, which were going to be the future: BBEdit, TextMate, Sublime Text, Atom, Komodo Edit, NetBeans, and Eclipse.
Each was going to kill Emacs.
Somehow, I think I'll be using a version of Emacs until the day I can no longer type.
Meanwhile, everyone else is wasting months getting up to speed on the latest and greatest thing every 8 years or so.
This adds up over a career.
Oh, and by the by, this was written in Emacs using GhostText as the link between Firefox and Emacs.
>Meanwhile, everyone else is wasting months getting up to speed on the latest and greatest thing every 8 years or so.
Yeah I used to think this way, because you're right: becoming proficient in emacs takes significant effort and time.
But becoming proficient in VS code takes maybe 25 minutes. 25 minutes to change IDEs every 8 years or so doesn't seem like an onerous requirement to me.
Emacs just has extremely poor defaults and out of box UX.
>But becoming proficient in VS code takes maybe 25 minutes.
Becoming proficient in kicking a ball takes 5 minutes. Becoming proficient in football takes slightly longer. Magit alone makes VS Code look like a child's finger painting.
>Magit alone makes VS Code look like a child's finger painting.
Magit is indeed a great git client, but I don't see what that has to do with emacs having bad defaults and an out of box experience that could be charitably described as antique.
>You'll understand in 20 years when you're on your 4th IDE which will change the world^tm.
How condescending.
But no, I probably won't mind changing editors every few years because I am capable of learning new things and do not require a safe space to keep me insulated from the outside world.
An editor is the least interesting thing to learn in computer engineering. If you enjoy wasting your time may I suggest something like stamp collecting that doesn't create billions of dollars of lost productivity for the rest of us?
Plus I’m changing editors every 8 or 4 years because the “new one” is better in some regard. VSCode is a very good editor. Sublime was a good editor too, but VSCode was better enough to make me switch. Whatever comes after VSCode will be that much better!
So there is nothing wrong at all with switching to a new editor… it just means things are getting even better!!!
Bad defaults for who? Emacs userbase is quite heterogeneous, not everyone is a swdev, not everyone is young. All it takes to have great defaults is maybe ten instructions in init.el.
So true! Now don't get me wrong, I quite like VS Code as it's so easy to set up and there is a plugin for almost anything, but I find myself always coming back to Emacs.
He's right about the defaults though. Use something like Spacemacs or Doom if you just want to dip your toes in the goodness that is Emacs.
I typed up some thoughts about the nth time I tried out Visual Studio Code to see what all the fuss was about and if my productivity could be improved vs. Emacs. I might turn it into a blog post, if I can be arsed to start a blog again.
One header read: "Not better enough". Inasmuch as Visual Studio Code does anything better than Emacs, it doesn't do things better enough to justify expending the high activation energy of switching, unlearning my Emacs workflow and learning all that I need to know to do things Visual Studio Code's way.
I honestly believe emacs UX to be fairly superior. I watch my colleagues struggle to find open files among tens of open tabs in vs code every day. Or endlessly navigating on the filesystem tree with the side bar before finding what they need.
Things that take half a second in emacs take minutes for them. And the UI is so cluttered.
There are a number of neurodiverse hackers who've "switched off the targeting computer" precisely because it's disruptive to thought to always be having to constantly juggle the state of code in your head with the fucking video game appearing before your eyes as you type. I am one of them.
Maybe i just never gave the heavyweight ide tools a fair chance, but i always found them more distracting than helpful. Focus is king for me, and vim gives me that.
idk, I find I don't miss anything from heavyweight IDEs. I switched to neovim like 6 years ago. 95% of working with a codebase, familiar or not, is navigation and editing. LSPs enable pretty much any editor to intelligently navigate to definitions and find usages of a given construct. Anything beyond that is quickly hitting diminishing returns.
The one exception is maybe untangling particularly gnarly git conflicts.
Emacs is fine, but it's not really about the visual diff and more that you get syntax checking and other features in the diff view that afaik aren't available in lighter weight tool. Neogit is quite good and is heavily inspired by magit, so it's not like they're appreciably different.
Not OP, but I was confused as well, but found that a lot of people who did this had basically created an IDE-like experience with tmux, etc around vim, etc.
Not really my thing but I guess it works for them.
What tools, what helpers? I hear this comment a lot and it's just ignorance on the part of people who clearly have never tried to actually learn how to use (Neo)vim or Emacs. I've used Jetbrains, VSCode, Atom, Xcode plenty and there's nothing that I can do in those IDEs that I can't do in Vim besides things related to platform specific SDKs.
My current codebase is a liberal mixture of C, C++, Java, and mksh. The whole project uses CMake and GNU Autotools and ndk-build and whatever the heck calling mma with AOSP does.
There's no way to unify it given how many different moving parts are involved. Trying to fit this all within an IDE would be a project of its own...
A similar mix took me under 20 minutes to get a C++ + Rust + C# + TypeScript codebase working between VS proper and VS Code. In fact, I don't remember doing anything at all to get it working except installing damn node for TS and choosing CMake configuration in a dropdown.
Everyone's brain is different, but I'd bet you'd be surprised by how good you are at things you rely on an IDE for (autocomplete, go to definition). For other stuff, sed and grep will cover 90% of your needs. Source: me, and I'm pretty good at this.
Strongly disagree, but I am in a niche field, Linux kernel development. Emacs is really struggling with it's tools. But for Neovim: the plugins and good keycombos are absolutely essential to get certain functionality for my productivity.
* rg with telescope window to quickly find text in very large code basis is essential.
* Pressing spc, spc, to bring up a telescope window of my open buffers and typing in text to narrow them, very important.
* To date I still struggle to get the LSP to work the Linux kernel on VSCode, but on Neovim I got it working.
IDE's have a lot of menu clutter that I struggle to make good use of-most programmers working on user-space apps, it is likely fine, but for the kernel, we often need more control.
First I've heard of this. As a long-time vanilla Emacs user, I'm using consult-ripgrep and rg-project for ripgrep interfaces, consult-buffer for fast buffer and file switching, Eglot for LSP integration (mainly with clangd), etc. I've also got org-mode for note taking, magit for speedy Git manipulation, etc.
And all without any visible menus or clutter.
I suspect that a power Emacs user and a power Neovim user are more akin here to each other than to VS Code users.
I mostly use kickstart.nvim in Neovim. I really like using mnemonic key bindings (which do show a menu) with the functionality above. One real issue was the lack of a telescope competitor (and I noticed you did not mention one above). I really like the quick overlay for those actions is how Telescope in kickstart is programmed. I really do not like the results smushed at the bottom of the screen like how Doom handles it.
Spacemacs got me into mnemonic key bindings, but it was too buggy and development had slowed. I got some things working with Doom Emacs, but it had a lot of bugs as well. Part of that reason is projectile also seemed to no longer be worked on. They were converting over to project.el but that seems to be slow.
I struggle to find good bundles for Emacs. Doom Emacs is struggling with migrating their plugins. Most programmers I know use Emacs with few plugins and not the better IDE like plugins in Neovim.
I probably used vim exclusively for about a decade. I've worked with a handful of developers who've only used vim and I've only known one who was anywhere near as effective with it as most IDE users. A few examples
-- debugging with print statement because they don't know how to use a command line debugger
-- using find and grep to find files/methods
-- hand-formatting files because they don't have a inline formatter or something to notify them when they've missed a semicolon or spelled a method wrong.
I strongly encourage them to move to an IDE because I can't stand looking over their shoulder and watching them code so inefficiently. There probably are vim plugins to handle many/all of these things, but if a developer doesn't put the effort in to find them than they're just hurting they're own productivity.
I'm kind of doubtful of this. Just to take print debugging as an example. While there is definitely a time and place for debuggers, i think print debugging can be shockingly efficient in many circumstances.
Besides, typing speed is usually not the limiting factor in programming speed. I think overall efficiency needs to take a broader look.
Those developers frankly sound like idiots, I don't think they should be coding at all. Also yes, all of those things are easily done in both vim and emacs.
It takes seconds or more to grep for a function, especially if it has a common name. It takes milliseconds to Go To Definition / Find Usages (either with an IDE or a LSP extension for any text editor).
If they're not using fzf, ctags or LSP at all, sure. But find and grep absolutely have their place, and I tend to use them even when using IntelliJ/VSCode.
Yes, no one said find or grep are useless, far from it. The original premise was people using grep to look for a function in a code base, or find to get to a file (presumably to get to an include file or imported module by name). And they are definitely sub optimal for this - as you mention, even outside of an IDE, there are plenty of better tools to integrate with vim or nano or ed (the standard text editor!) or whatever you prefer.
And then you go full circle when the project is bigger and Find Usages no longer works across projects (specifically in the context of a typescript monorepo) and it's back to grepping for usages.
The premise is that using proper code navigation functions will increase productivity over grep. Not that using an IDE will increase productivity over vim, assuming you use actual code navigation tools in vim.
As for the click: all IDEs and all code navigation tools for popular text editors like vim or emacs have full keyboard support. And M-. Or F2 or whatever are much quicker to type than "grep function_name".
But this is people that use their autocomplete, F8 step through debugging and the like.
I was like that about 20 years ago, working with Eclipse and later NetBeans for Java and Visual Studio for C# .net v1 (anyone remembers whole tomato extensions?).
I needed the IDE , the autocomplete, the debugger and all that. Nowadays, I do mostly Vim and Vscode for more complex projects. I don't know why, but I "grew out" of needing an IDE.
Shudder to think that in 20 years (or less!) there will be a generation of programmers who suckled at the teat of ChatGPT and firmly believe that software is impossible to write without LLM help.
No worries, I think maybe I replied to the wrong comment - I would have expected to reply to someone who can't see how an Emacs (or vi) user could be as productive as an IDE user.
As someone who programs Java daily and uses Neovim daily, I don't think I could be any less productive than when programming with Java in nvim.
Some features that I do not have in nvim, but use daily in IntelliJ: Run configurations, proper debugger, SQL integration, hot reloading, and most importantly everything just working OOTB (auto complete, snippets, docs, ...). Can (n)vim do these things? Probably, but it'd take me days or even weeks to get it configured to the point where it's as seamless as IntelliJ.
I do use the IdeaVim plugin, so not all of my muscle memory is wasted.
Java is really unpleasant to program in without IntelliJ IMO. I strongly prefer NVim for Python and C++, but still use IntelliJ for anything non-trivial in Java.
one thing missed is intellij can cross-complete over several domains, like correctly showing tables in a sql statement in a java string in your project, if you also have the database added, etc.
ive never seen any vim-with-plugins setup come close to this
Vim is great but I think VSCode really is the one tool to rule them all going forward. It's extremely well designed, snappy, and I think does the correct thing of first treating everything as a text file and allowing plugins to provide semantic meaning. I never liked visual studio because it was too specific to writing software and using the GUI to do what I wanted. Editing msbuild files directly was a pain for example. If I wanted to do some shell scripting or system debugging, I had to leave that environment.
Whereas with VSCode, I really never have to leave the VSCode environment to do what I want. I can pop open a shell within VSCode and don't have to switch windows. I can easily open random files not associated with my project and VSCode does the right thing (usually). It opens images easily, renders markdown well, etc. my favorite feature is that you can pipe cli output directly to VSCode in the shell and then it opens a tab displaying that output. You'd be so surprised how often that feature comes in handy.
I mean, nothing stops you from not using it. It's just a really well designed piece of software and it does a good job of getting out the way something a lot of IDEs don't do well (visual studio for example).
You can do all the things you mentioned in Vim. I also can't imagine that you would be comparing the performance of VSCode and Vim, my vim with all of its plugins and vim script starts up in 95ms. That's faster than the threshold of human perception.
I think you missed the point of my comment you are replying to. You can get things done in any editor. The point is that Vim/Emacs have been around for decades and last your whole career, VSCode has been around for a fraction of the time and killed off the previous editor, Atom, that everyone though was "the editor".
In college I used exclusively plain text editors, and like 80% of my edit-compile-run cycles were wasted on noise like symbol names and the ordering of positional arguments. When I got into professional life and started using JetBrains IDEs, I felt like I was flying.
I'm one of those people that doesn't like polluting his brain with a ton of keyboard shortcuts and likes clicking with a mouse on stuff and is just more efficient with it. I've seen video clips of "efficient" terminal text editor use, and while it looks cool in a hacker way, it just isn't any faster than what I do without all of the overhead of memorizing a ton of keyboard shortcuts and editor commands.
I would definitely much rather install VSCode or an IntelliJ product on a Jr's machine, show them how to setup their terminal, get their dev environment setup, how to run and debug the app, and off they go. Edit code. Run code. Debug code. Rinse repeat.
Much more reasonable and preferable to having them spend months learning Emacs. Let's remember, they likely don't know how to use the terminal either these days.
> I've seen video clips of "efficient" terminal text editor use, and while it looks cool in a hacker way, it just isn't any faster than what I do without all of the overhead of memorizing a ton of keyboard shortcuts and editor commands.
Would that still be true if the ordering of your menus (and the items within, recursively) were randomly shuffled each day, and which side submenus opened on were also randomized? How about if the speed of your mouse or mouse acceleration behaviors varied?
I think you may be discounting memorization which benefits your workflow because that memorization is spatial rather than symbolic. Perhaps there's an argument to be made that such memorization is more natural, gradual, or easy, but there's definitely memorization involved in mousing around with any degree of efficiency or speed.
> Let's remember, they likely don't know how to use the terminal either these days.
Which is a huge issue. If all you know how to do is crank up a GUI and write code, you are easily replaceable in a world where the demand for SWEs has gone way down. The best thing I ever did in my career is invest in learning how things actually work. Learning how something like Vim works is just a litmus test for absorbing and applying information quickly. Vim is just one in hundreds of tools I've learned how to use and string together.
How can you possibly be as productive as someone working in Visual Studio? I'm asking honestly - working without the solution explorer, being able to look at any immediate variable, instruction pointer dragging, and others seems like it would slow me down immensely.
With vanilla Vim, you're right. I recently switched to NeoVim after years of using VSCode, and after about 2 weeks, I am probably back at about 90% of my productivity as VSCode. I had to spend a little time learning Lua and learning the internals of a text editor, but I wanted to learn those skills anyway so I'm glad to have had an excuse. If you have no interest in those things, then I wouldn't recommend leaving VSCode.
I am also excited by the fact that the text editor configuration is programmable in a Turing-complete language, as opposed to pure JSON configurations that VS Code offers (correct me if I'm wrong, but settings are just a JSON file right?). It means that anything is possible.
In VSCode, my biggest complaint was that, for the Vim extension, the status bar was not configurable - I wanted to make the whole page change color when in "Normal" mode, versus "Insert" mode. Not possible in VSCode, but it's only a handful of lines of Lua in Vim.
Is that a huge productivity boost? No, but it makes me happy. Just as much as I want to be productive, I also want to be happy while programming
I'd give the opposite advice. Learning a new editor is fun and thankfully they are mostly inexpensive. You will build up a suite of editors that you use in different contexts and be able to talk about the differences based on experience and not just dogma.
I was a heavy Emacs user for just short of 10 years. I don't use it now because I am more productive with JetBrains IDEs. Your advice seems too rigid and dogmatic to me.
Just posting to balance things out for any entry level SWEs reading.
I don't even know what to say to this other than that you are right that it does sound stupid and it is stupid. A software developer should not be afraid of learning software, learning new things is fundamental in our work. Comparing an IDE with basic editor like vi, really, that may have worked out for you since you started 20 years ago when that worked, but it should not be the advice today.
I learn new tools and platforms all the time, but editing needs muscle memory and I don't want to abandon that every five years for the new hotness. IDEA is just starting to show some longevity for Scala and Kotlin.
Mainly, a seftware developer should not be afraid of creating neW tools to solve their own specific problems. Programmable editors like Vim allow you to do that, proprietary corporate IDEs do not.
I know this is so common to say that it's a joke at this point but...
I'd just quit. If people in my company are making sweeping decisions that I disagree with (how much they are based in reality aside), I would just leave. If the company isn't aligning with you on something you feel passionately about, just leave. There are oodles of companies out there that would align with you on this.
I'm genuinely super curious because I hear this a lot, but the deepest I ever got was... 5 apps? Do you have some kind of like generic cover letter/resume you fire off 3 times a day? What is your process?
The first ~3 months I wrote specific cover letters and modified my resume according to what I was applying. Then I gave up and just blindly applied to everything without bothering to read anything other than the title and specific qualifications using a generic (but detailed and well-structured) resume.
from your response it is not clear whether you are still searching or if you found a job. i can understand getting tired, i feel the same, but i worry that taking less effort reduces my chances.
what are your thoughts on that?
(what is a well structured resume in your opinion? did you get any feedback if it is well perceived? i'd like to think that mine is detailed and well-structured too, but i don't feel certain that it is good)
I sold my house and fucked off to Europe. Hopefully will outlast whatever thing is happening, but I'm not that hopeful, so I'm searching for new passions. I still look for work once in a while and blindly apply to what a carefully crafted search query yields (searching job application sites (not job boards!) + position and/or skills). I decided after 3 months to go for quantity over quality. It hasn't been much more successful, but at least I don't get frustrated spending 2h researching a company, crafting a cover letter and creating a resume to get a refusal the next day.
Any time you'll ask for feedback someone will tell you to do things differently and it will never end. I've been hiring tech folks for 15 years, with 25 years total experience, so I know what I want to see when I look to fill a role, that's how I build my resume. I want it to show at a glance where I've worked and what I did there, no more no less.
If efforts are made and you see a difference, then don't stop. If you see no difference (eg uptick in responses or interviews), as is my case, I've got nothing to say that will help you. Sell your house and fuck off to Europe maybe.
I've been hiring tech folks for 15 years, with 25 years total experience, so I know what I want to see when I look to fill a role, that's how I build my resume
maybe you could share some insights here?
my CV starts with a few paragraphs highlighting what i think are my biggest accomplishments and showing off how broad my experience is. followed by a list of tools and languages i have worked with, then a list of projects and the employment history. for jobs where it seems relevant i also have a list of talks and workshops i have given. the whole thing is quite long though. 5 pages for the short version and 8 pages for the long one.
searching job application sites (not job boards!)
what's the difference here? do you mean the career/job lists on company websites?
I definitely don't want to read 5 pages especially if it's all redundant information. Mine is two pages, I don't dig in gigs past 10 years, they can ask if they want my origin story.
I don't care about the languages you know, I care about the languages you know and how recently you used them and your level of proficiency. Without that trifecta the information is useless (well, I'd have to ask). Was it a school project or did you blow someone's mind professionally?
I wouldn't do more than a sentence if you're going to summarize (eg 25 years of experience in building and leading technical teams), I can make my own unbiased summary.
As for application sites, I mean something like jobs.lever.co or boards.greenhouse.io.
I care about the languages you know and how recently you used them and your level of proficiency. Without that trifecta the information is useless
this is not a question just for you, but i wonder what others think about this too.
i get that the number of years of using a language is a useful indicator, but the age? is my experience from 10 years ago no longer valid? also, proficiency in one language does translate to overall proficiency in any language. not 100% obviously, but the more programming experience i have the better i can learn new languages, and the faster i can get productive. same goes for any other tools. old experience is not forgotten. so even the years i have worked with any particular tool is missleading. and if i only list my work from the last 10 years then i'd look like all i have ever done is javascript, and that would limit my options very much.
i have been able to work on python and php projects as a mid-level developer without any formal prior experience in those languages. in the python case the employer knew about it and was still comfortable to hire me. in the php case i was able to cite some php work (which i had done) and i was still producing better results than any of the junior developers on my team. only the team lead was clearly more experienced then me.
how am i going to make that point if i don't list all of the projects i have worked on, no matter how long ago?
That's a great point. Either have a ton of money saved up or just start applying to jobs elsewhere immediately. The latter is what I assume most would want to shoot for.
It's not a stretch. The job market is terrible and has been for some time. I was 400-500 applications into my job hunt when I *finally* found something and that was at the end of 2022. It has gotten worse since then.
Being in a position to point out the privilege of another is itself quite a privilege.
There is rarely a suggestion given in modern society that doesn't assume a good amount of privilege, and pointing this out every time isn't helpful.
I welcome suggestions that can help those who cannot simply quit, but you didn't give such a suggestion, which is why I say it wasn't helpful.
Accusing people of privilege is a dead end. A person who has been accused of privilege is left without direction. It is better to say "what about these other people" than to say "you're privileged", because it directs attention to the other people. It avoids accusation and focuses attention on those in need.
Somewhere on this planet is a single individual human who is the very unluckiest and most unfortunate. Everyone else is privileged. Even that guy is lucky to be alive now and not 1000 years ago.
Calling out a solution as "privileged" adds nothing to this site.
You have a job at all? You have the brain and attention span to read this far? You can use computers to solve problems? That's a privilege. And yet we don't point that out every time a programming or career or product question is asked and answered.
Perhaps OP could have added something a bit gentler like "quit your job - if you can". But it's fundamentally a sound plan for many of us, and crucially, also even for many of us who aren't aware how much market power they really have.
Is it okay to post suggestions that only apply to a small portion (say, 5%) of HN readers and trust people to determine for themselves whether or not the advice is applicable?
Yet, it doesn't mean that quitting is always going to be the solution. There are specific conditions that need to be met (sufficient savings, decent possibilities to get a similar job, and so on) in order for quitting to not hurt you financially and professionally. Yes, everyone can be seen as "privileged" if we compare our lives to how it was back then, but that doesn't dismiss the issue.
"Decisions that I disagree with" are one thing, treating people like children and telling them how to work is quite ridiculous. Yes, not everyone can afford to leave, but I definitely would at that point.
The perspective here in Russia is diametrically opposite. The common opinion is that JetBrains has completely severed its ties with Russia and appears to have pro-Western, probably European management: they don't sell in Russia anymore, and recently they have started silently deleting licenses of users who appear to have Russian IPs as detected by their license server. Local companies have to use proxies.
JetBrains has gone downhill since they purged their original developers. The IDE is not as performant, and newer versions are full of bugs. I have heard this first hand from people in Russia. Cursor.sh and ai development tools are a huge threat to the company, and are far outside their core competency. Decent chance they cannot keep up with innovation, and their hyper tuned IDEs become obsolete.
Eclipse is still a great option for Java. And I was pleasantly surprised at Devoxx last month when Oracle's Stuart Marks whipped out ye olde Netbeans for some live coding during a talk.
Dev tool monopolies are as bad as any other monopoly.
Honestly if Eclipse was the only option for writing code, I'd probably just find another job. I would probably choose Notepad and a terminal over Eclipse.
Out of the box JB apps have much more built in feature. You can reach a similar level with multiple extensions in vs code, but you have to spend significant time on that. And the behaviour from independent extensions is not as polished in the end.
I used to love using JB products, especially for refactoring massive Java projects. But over the years, the IDEs have become more and more bloated. Even without adding any plugins, the IDE is very clunky.
Have switched back to using neovim (my go-to during college with a crappy MacBook, lol) and set it up with nvchad to lazy load the LSP plugins.
Haven’t looked back.
Did it take months (gradually improving and re-learning) to get to this point? Yes, it did. But in the long run, I learned to be more efficient in my writing and removed a yearly subscription as well.
Same path for me. Sick of things changing and breaking underneath me. Neovim is a labour of love for a while but once you have your config dialled in and some muscle memory, it’s very performant.
I really like Neovide as a gui. Brings the whole experience together.
IIRC jetbrains was a russian company, backed by people close to putin. Then they "migrated" away from russia (jetbrains users are 90% westerners) to avoid losing their users, and even made some blog post about it, but from what i have heard the people behind the curtains whose names are in no legal papers are in fact still the same people with close ties to putin and his inner circle.
Putin has nothing to do with it, pretty sure he doesn’t even know who they are. JetBrains founders are Russians, but they registered the company in Prague as their goal was foreign markets from the beginning and it was much safer to do business there than in 90’s Russia. Most of their programmers and RnD were Russians, they had close ties with several top Russian Universities to hire students from there. But yes, in 2022 they were told by their Western customers that they have to leave if they want their products to be bought, and JB evacuated from Russia, relocated people and fired those, who refused to leave, blocked Russian customers and in some cases terminated their ongoing licenses, forced their employees to cut any cooperation with Russia (their head of Kotlin decided to quit the company due to this policy and returned to Russia). And since then the quality of JB products has dropped noticeably, they had to cancel some of their products, looks like they still struggle to replace those people they’ve lost and Western companies still refusing to work with them due to a mass amount of ethnic Russians still in place.
> But yes, in 2022 they were told by their Western customers that they have to leave if they want their products to be bought, and JB evacuated from Russia, relocated people and fired those, who refused to leave, blocked Russian customers and in some cases terminated their ongoing licenses, forced their employees to cut any cooperation with Russia (their head of Kotlin decided to quit the company due to this policy and returned to Russia).
And they're still considered Russian company, how hilarious.
They were choosing between being humiliated and losing customers, now they're both humiliated and losing customers.
The original post says nothing about "the people behind the curtains whose names are in no legal papers are in fact still the same people with close ties to putin and his inner circle.", which is the sentence that comes directly after phplovesong says "from what I've heard"
As far as I remember, JetBrains was founded in 2000 by a couple of Russian immigrants in Prague back when no one knew who Putin was. They had an office in St.Petersburg which was closed in 2022, they don't sell in Russia anymore, and ban all Russian users. What's the evidence of them having ties to Putin?
It's perfectly valid to boycott a company if you disagree with their ideology.
For example, when chick-fil-a was openly anti-gay marriage (including after Obergefell), I stopped eating there. As a gay man, I don't want my money going to people who actively wish to harm me.
And it's fine. It was low friction, and I've saved a lot of calories.
That doesn't mean you're then required to boycott everything. Perfect isn't the enemy of good. If you feel like it, boycott.
It's a valid position to have. Same way as our customers are important targets for Russian state intel. actors so to minimize risk we will not be using product X is also perfectly valid position to have.
Exactly. The context here requires us to remember that US, and UK, etc governments are funding and providing weapons to a genocide being carried out by Israel.
I’d like to echo the sentiments of Reddit user tikhonjelvis, who commented¹:
“Man, I knew CS programs were skimping on Emacs fundamentals, but I hadn't realized it was this bad.”
1. <https://old.reddit.com/r/ExperiencedDevs/comments/1gqj7qa/my...>