Most of what you describe takes place at the state and federal level, but not local. In fact, discretionary funds are plentiful in our target market—people are often shocked to learn that we've never run into price objections when selling, and we've successfully sold to cities ranging in population from 20k to 4m. In other words, they aren't "awful purchasers" as you call them—they're hard-working, dedicated people looking to improve their efficiency with money to spend, but they aren't being provided with solutions they can experiment with on a monthly basis. We're trying to change that.
In addition, the strategy you've outlined is the one nearly every incumbent in every enterprise space has leaned on to protect themselves from disruption, but it only works for so long (as we've seen time and time again). I also think people overestimate the ability of large companies to quickly adapt their offering—the machinery of enormous sales, marketing, and product organizations can't turn on a dime.
Every state is different in terms of regulations and local governments can vary in terms of processes, especially with the size of the jurisdiction.
In my experience cities have just as many procurement problems as state/federal but with far less money to spend. You may have success with a Dropbox/Hootsuite approach of selling to non-traditional users under certain price limits. It just makes it so much harder when it's your only market.
As to plentiful discretionary funds... everyone's definition of this is different. Another challenge I've faced with local governments is that their speed to spend is similar to state & feds. Smaller sales with a sales velocity the same as if not slower than the feds is another challenge.
But if you've got people to make fast decisions and spend enough so that the unit economics makes sense you have my heartiest congratulations.
> Every state is different in terms of regulations and local governments ...
But still it is no accident that ncd's analysis works at the local government level: there are tens of thousands of those governments so variation means there will be some viable customers around.
Just noticed this went up! Happy to answer any questions about what we're doing, or more importantly, how the amazing folks in local government are performing their jobs. Also, I noticed the article doesn't link to our site, so https://www.senecagov.com
I don't feel like adoption of another proprietary platform is the way. I like the idea of open data, APIs or even open IoT networks like TTN that can be used and even improved by anyone. How are you planning to handle various integration requests with other services the cities run?
Totally agree about open data and we actually do integrate with a large number of systems via http://www.open311.org/, an open standard built by cities and vendors working together.
Full disclosure: I am currently an engineer at Seneca Systems and an ex-engineer of Zendesk, which I loved :)
From my experience, Zendesk is a private sector-oriented customer relationship platform with communications at its core. The relationship between local government and their constituents doesn't look like the private sector relationship between customer service department and customer (though this comparison is frequently made). A customer service rep needs to answer, respond, and pass along... But in government, a worker has to actually get the work done.
The relationship between government and constituent isn't a sales relationship, it is a services one, and it's in the service request management area that workers are really suffering. The communication is only important insofar as it becomes a unit of work for the government to deliver on... A pothole, for example, or a streetlight issue. They struggle with geolocation and the need for mapping, the ability to visualize community issue trends and seeing them as they happen rather than when the shoe falls, FOIA requests, and more. These things are highly specific to government, and not really addressable by a generic private sector solution no matter how customizable.
As a result, in Romulus managing the constituent communications is only the first piece of the puzzle. In my opinion, the real value Seneca provides is in the service request management, which takes the communication and tracks the unit of work that comes from it internally, as well as providing the ability to communicate the progress externally as Zendesk does.
This reminds me of some threads about the difference between Slack and IRC. Could one be dramatically retrofitted to accomplish what the other does? Sure, but it wouldn't do it well, and people aren't looking for it to do that.
This looks awesome (although I think the name could use a little work). It also brings up a question I have for HN:
Every few years, I make an attempt to learn to use one of the classic editors like vim or emacs, and inevitably give up after the enormous productivity drop I suffer when writing code. I just can't seem to pick up the muscle memory required to become fast with these tools, and the overwhelming array of customization options leaves me frustrated.
The most annoying thing is that I want to learn one of these, because I think I'll enjoy it once I do. Any suggestions from people who have picked one up on how to accomplish this seemingly Herculean task?
And, I suppose, I have another another question: is it worth it?
Get a shell/terminal that you can open/close with a hotkey (iTerm2 on Mac or something like yakuake on linux)
Run the editor you want to learn (I recommend emacs) in your hotkey terminal (basically you want an 'always there' emacs that you can just pop open at the press of a shortcut key)
Spend 5 minutes learning the basic commands.
+) Move the cursor around.
+) Open a file.
+) Save a file.
+) Switch between buffers/files
Now while coding in your existing editor, use the hotkey window with the new editor as your 'scratchpad' or diary. Note down ideas, todo items, thoughts about the code your are writing etc. Google commands as you need them and you'll pick things up bit by bit.
You don't see the productivity drop because you're not using the editor for your main task of coding, but you'll be using it 'little and often' which is a great way to pick things up.
I made the full switch when after a year or so at work I found myself pseudo-coding and stubbing out methods in my scratch file in emacs and copying them to my IDE.
> use … the new editor as your 'scratchpad' or diary. … Google commands as you need them and you'll pick things up bit by bit.
I personally found myself using vim a lot as, uh, some sort of poor man's one-shot data analysis/text reformatting tool among other things. What I mean is, quite often I paste in some semi-formatted text like logfile snippet (or open some data that is quite hard to process using shell and extensive piping if turning into csv/tsv and is painful to manipulate via dragging-and-dropping-and-cutting-and-pasting in spreadsheet software afterwards) to do all sorts of manipulations: I can use :s to replace things, or use macros with conventional actions like n3w2de, or bail out to :!awk, :!grep, :!cut, :!paste, :!column -t, :sort (or :!sort -nk123) if I need to format, filter, cut out some columns, sum over columns/rows etc. (I can even do |xargs!), or I can (rarely albeit quite ineffectively) use Ctrl-v to merge lines (if :!paste is not enough), or 'Ctrl-v I' to quickly type in something on multiple lines at the same position before processing any further -- all of that in any combination and with any selection. And I'm pretty sure I forgot something while writing all these things down before sleep.
I doubt if any other text editor or IDE could be as useful as vim in tasks like these, and now I also see this as a great opportunity to learn vim through googling for things one does not do every day (and does not know how to do) in any other editor, as these quite often will turn to be benefitial for everyday vim (or shell, or both) users. (However, it is also quite hard to me to imagine vast amounts of people with similar use cases, let alone people that would even consider vim as a tool that would solve their problems even with some time invested in it.)
The problem is the people who reply will be the people for whom vim and Emacs "clicked".
I'm like you, and when I looked at my vim using friends, they really aren't any more efficient. Also, while your editor will "work forever", expect interesting plugins (like C++ integration via clang) to be less stable than say atom or visual studio, and to have to nice plugins every few years.
Also, they don't fit well on a modern desktop. I use lots of apos, each best for their use, that all use the same shortcut keys. That's integration that I like.
I agree with saying no. Vim and Emacs will "click" for you when you want to learn them. Wanting to learn them is different than wanting to have learned them. It's the difference between wanting to write a novel and wanting to have written a novel.
Personally I would nominate emacs using spacemacs[0], but I knew both already going in. I have a hard time understanding what people find hard about Vim, but I've used it for 7 years now (well, spacemacs now), so I probably just don't remember what was hard.
I think it wasn't so bad for me because I didn't try to learn much about it. I learned how to move, (just the hjkl part), and basic selection. Anything else was learned "just in time."
For example, even after having used vim for 7 years, I never knew about the "ib" selector. Never needed it, and doing that sort of selection has never been painful enough to me that I went searching for a "better way."
While things like vim-tutor or vim-golf or whatever they have now might work for some people, that would have killed it for me. Learning for the sake of learning will get you part of the way there, but learning out of a personal need is what leads toward "mastery." And I define mastery in a restricted sense of being able to do what you want, fluently.
Exactly. The only thing needed to configure when starting out is disabling of arrow keys and low keyboard repeat rate so that you don't do wrong things like holding down keys (arrow keys, delete, backspace etc.). Holding down keys is a Vim anti-pattern.
Spacemacs might be great for existing Emacs and vim users, but it is horrible for beginners of both (in my experience), as you can't follow Emacs tutorials, can't follow vim ones, and there just aren't many spacemacs tutorials yet, and several I found were out of date.
Emacs user here. No it didn't just "click" with me. I was learning Lisp and learning Emacs became a necessity. I don't think it was easy for anyone to learn Emacs or Vim. It takes a lot effort to learn these tools. In my case, it took about 2 months before I felt like I was efficient with the text editing, and I still learn new things today.
If it matters, I don't think many people can program any faster than I can in Emacs, especially against macros, interesting plugins, functions, and snippets.
There is a trope about how a new Emacs user will be faster than most Vim users, but watching an expert Vim user work blows the best Emacs / IDE user out of the water.
I know you're seeing a ton of "yes it's worth it" posts, but i just wanted to add a slightly different perspective. Yes, it's worth it even when you aren't an expert at Vim.
I am constantly learning new Vim commands[1], and i feel i only know a tiny fraction of the vim editing language. Yet, i still love vim, and use it constantly, for everything.
The approach i take, as to make it enjoyable and not a job, is: "is what i am doing now annoying?". If you find yourself hitting j (to move down) 40 times in a row, or holding it to move down slowly, etc - Google for a solution[2]. It can be a little annoying in the beginning, but when you're starting out your far less likely to want to "fix" every bad pattern, and therefor you aren't spending all your time Googling. In my experience, you are only improving upon the things that most annoy you, and as time goes on, you improve quite a bit while not even trying.
[1]: discoverability is not it's strong suite, which is why i'm going to try Kakoune.
[2]: You can multiply the command (40j), or <Ctrl-f>/<Ctrl-b> to jump. Among other things.
Strongly endorsing the "make the pain go away" path to learning, but I'd also like to mention a secret weapon for really nailing down the more powerful movement and editing commands in vim: macros.
Macros are immensely useful themselves and everyone should learn and use them, but they have another benefit beyond simple utility - writing good macros requires using commands that generalize rather than "eyeballing" how many times you should press a key. If you want to move to the next paragraph in a macro, you can't just mash j until you're there because every use of the macro might require moving a different number of lines. What you can do is use { and }, vim's built-in commands for moving by paragraphs that are underused because holding down j is "good enough" for interactive use. I find that after I start using a command to make better macros, it filters into my interactive use soon after.
As a bonus, using more powerful motions instead of repeating weaker motions makes your macros execute a lot faster.
Not familiar with ace-jump, but i don't count lines. I use relative line numbers, and just hit the number i want to go down to. Ie, it will say 15 below me, so i hit `15j` if i want to go there.
I somewhat agree. I'm proficient enough in vim that I do most non-IDE file manipulation in it, but I haven't gone into much depth about what commands I have available. For example, duplicating a line is ddup. yyp would probably be better, but I already have that in muscle memory and it's good enough for what I use vim for. Like you, I've also switched to Jetbrains for most programming, it's much easier to find the one off commands I know I used last year but can't quite remember how to repeat now.
(Although, some of the reason I switched from vim is that I have been using an Alphagrip keyboard for a while now and mouse/arrow keys are always available _right now_. It really changed how I interact with software.)
This is what I'm discovering as well. For the past month I've been learning node.js, express.js and everything that comes with it.
I'm an (inefficient) vim user. I learned vim because I didn't want to ssh into a terminal and type nano. For this purpose learning an editor that is shipped with every (?) unix-system is amazing. I don't know if emacs is also shipped with every unix-system, but learning the basics for the sake of configuring servers is quite handy. I also loved Sublime Text, so I combined using vim and Sublime Text as my main editor.
However, when learning node and writing good javascript I noticed that my debug cycle was very slow. It was so slow that I noticed that I was debugging 80% of the time and writing code about 5 to 10, and thinking about code 10 to 15. So in my case getting a good debugger was a lot more important than having an editor with which I can whizz through text.
For me, I learned vim & touch typing at the same time. Generally I learned while doing side projects, supplemented with general vim sessions (such as the built-in tutor, and http://vim-adventures.com/).
Many find it easier to start off with GUI vim as your favourite keyboard shortcuts are still there, but I found that too much of a crutch. Once you commit a few standard sets of motions to muscle memory, I don't think you'll find that much holds you back in day-to-day typing. If you notice yourself doing something repetitive when editing, go and look up how to do that thing more elegantly, and carry on.
I'd also just ignore all the customisations until you find yourself at least somewhat productive with the 'factory settings'.
Can you add code completion or basic static analysis to vim? I've found it fine for editing but it lacks the information of the IDEs that I generally use
I've had trouble with the completion plugins for Vim. There'd be a "completion engine" that needed a language-specific "plugin" and I had trouble getting those + dependencies working in various environments (or they'd suck down CPU resources). Maybe if I just set it up once in one place it'd work fine. It might just be me since the CPU resource suck bothers me in other IDEs like PyCharm.
I really like the out of the box completion vim has where it completes against words in files you have open. Most of the completion I need is long variable names or functions/modules and if it's not in the same file I'm editing I already had it open in another buffer.
That and a basic PEP8 linter work just as well for me as any of the major IDEs I've used.
I started to use Vim maybe six months ago and I found it obviously quite difficult to start with but I took it quite slow. I use Visual Studio at work and installed VsVim so I practiced VIM at work and at home on personal projects I used Vim exclusively.
To start off I used no addons at all, and didn't use any for probably a month or two. I'm a front end developer and spend most of my time in Javascript and Rails at home to give you an idea of what tasks I'd do in Vim.
Eventually I started to notice things I found hard in Vim and slowly set about finding some addons to complement my usage, maybe just two or three at a time. I still probably only use about ten addons so it's not too heavy.
Was it worth it? I'd say so, I'm still learning but I can do most things without using the keyboard although I'm certain there are more simple and elegant ways to do things in Vim heh.
Oh and the best tip I heard? Don't place anything in your .vimrc you don't understand.
If you want to board a train, you don't try to jump in through an open window while it's moving at full speed. Emacs and vim are very fast trains with very slow acceleration. You're going to spend days, possibly weeks, struggling to do things that were trivial in your old editor as you get up to speed.
If you can't afford that during your productive coding hours, you'll need to set aside dedicated time to be productive at learning - time when practicing vim or Emacs is the only goal. Run through vimtutor or the Emacs tutorial (Ctrl-h t) to learn the basics, then run through it again. Repeat until you can do the tasks without reading the parts explaining the commands.
Grab a random long file of code, make a copy, open the copy in your editor. Practice navigating - pick a character on the screen, work out a fast way to get there without touching the keyboard, then execute it. Practice selecting words, bracket/quote-delimited chunks, lines, functions. Practice making small but precise edits. Get used to the different paradigm of cut/copy/paste that both use, including registers (vim) or the kill ring (Emacs). Practice using searches to move around, and also search/replace.
Learn how to use the built-in help. Both Emacs and vim have amazing help systems that cover every default keybind, built-in command and user-customizable setting.
Do all of the above without any customizations or plugins. After you've mastered the basics, you can start customizing, but try to only do it to fix pain you've already experienced rather than add things you might need some day.
I completely agree, but I do think there's value in immersion.
After learning the basics, maybe find a subset of tasks to use with your new editor. For example, continue using your IDE for day-to-day, but edit config files with the new editor. Then go from there.
Yes. Learning Emacs is 100% worth it. I feel like everything else is a joke by comparison (no offense).
Emacs, IMO isn't like any other editor. You can't just install it and have it work for you out of the box. Another poster suggested that there would be people for whom Emacs and vi 'just click', but I don't think that's how anyone learns to use emacs. You need to customize the editor in order to make it useful. It's not about memorizing key combinations (that'll come with use over a long period of time), it's about employing the ridiculously powerful tools that come with Emacs or can be downloaded from the package repositories. With Emacs, you can do anything you want. When I first started using Emacs, it felt like I was laying siege to a fortress. Doing basic things like saving a file involved looking up a key combination. Now anything else feels not much better than notepad.
To learn emacs, I think that the best place to start (after giving up on the tutorial) is to read other people's init.el files. You can find these all over github. You should read through them and any customization or function that you think you'd like to have for yourself, copy (the key combination for paste is C-y FYI) that into your init.el file (~/.emacs by default). As you read through the init files, you'll find out more and more about what Emacs can do for you, and you'll build an editor that's comfortable for you. IMO, without a custom init file, Emacs isn't really Emacs. Treat it like a side project for the first month or so, and I believe that eventually you'll move over completely. Have fun!
I feel your enthusiasm but I think your message will be a little off putting for new users. Personally I've been using emacs for about 15 years and would have no trouble sitting down at a fresh install and using it. I use all the default keys. Most of my customizations are in relation to org mode or custom applications I've written in emacs lisp. While I'd say emacs is very configurable, it's certainly not a requirement that you configure it for yourself before it is useful.
Don't waste your time with these cryptic editors. Get a more reasonable editor such as Sublime Text or VSCode that allow you to install plugins for emacs/vim bindings etc.
IMHO the best bang for buck that you get with these editors comes from learning just a handful of commands for the most common stuff, i.e. open/close/save, move caret, cut/copy/paste/, switch between buffers. So with a more modern editor with emacs/vim like plugin you can have the best of both worlds, i.e. enable fast operations for the common stuff while also having sensible menus etc. for the non-common stuff. If you go "raw" emacs/vim, then everything is cryptic.
I learned Emacs because I was interested in following the SICP and learning Scheme. The synergy between lispy languages and Emacs is just too great to look for another editor.
In that spirit, I'd say learning an editor with a steep learning curve just for the sake of learning isn't very effective - and that is probably the reason you end up frustrated. However, if you can find something else to learn within the editor - so that learning the editor comes as a side-effect - you'll progress much faster.
I believe this to be the reason I haven't been able to pick up Vim. Editors are tools - and if we see no use in the tool, we'll never get good at it.
Long time vim user here, but I think that the best setup is to use a regular text editor, which has vim bindings. All major editors seem to have them, including Sublime and IntelliJ.
I think the biggest gains in using vim are the small navigation, copying, and editing keystrokes, and that there are little to no productivity gains of using other vim features like tabs and buffers, over say tabs in IntelliJ / Sublime. I am a little biased but I really think that being quick with the vim bindings really makes me a lot more productive at editing code than my non-vimming co-workers. When we're pair programming, it's usually me who does the driving because in one or two keystrokes I can do something that would take them 5+ seconds with a mouse.
So just install the vim bindings on your favourite editor and start picking it up bit by bit. You can start simple with the h,j,k,l keys for navigation, and i for insert, and use the mouse for the rest until you get up to speed.
I'm learning Vi(m) right now because next semester our C++ course (programming 2) will be taught within a UNIX environment. I'm new to linux as well, so after recently installing Fedora, I limited myself to using Vim as a way of practicing.
So far it has helped to work on a project that involves typing in source code that has already been laid out (its Douglas Crockford's essay[1] on writing a JS parser). Literally I'm just typing it into one file, making a few decisions about whether to put all of the factory functions at the top and have the instances at the bottom, etc. It lets me focus on:
-Opening files
-Saving (:w to keep the file open, :x to save and close)
-Basic copy/paste
-Navigating around the file
-Switching modes
I've spent a few nights messing around over the last week and I feel like I'm picking it up. I like not having to do much with the mouse since I have a bad habit of straining my arm/wrist by holding the mouse while I'm not using it (while reading). Keeping my hands on the keyboard feels more comfortable and ballanced.
It's too early in my usage to say whether it's worth it or not, but I feel confident that being familiar with other text-editing 'paradigms' is a good thing.
You can install mc file manager (dnf install mc), and can use built-in editor mcedit for codding. ^O will switch to console (^C^O to switch back to editor), so it's easy to code and test console applications. It's a lot less powerful than vim/emacs, but it's easy to learn and use.
If you do any amount of work via command line or SSH, you need to be competent with one of them. I've been using vim for 18 years now and I'd consider myself a barely competent vim user at this point.
I know enough to use it, but not enough to like it.
For virtually all work where I don't have to use a terminal editor, I use Sublime/Textmate or one of the language specific Jetbrains IntelliJ derivatives. The "jump-to-declaration" functionality of Jetbrains is so smooth and so good that I actually have a hard time not having it available now.
Truly useful things get committed to muscle memory almost immediately.
> If you do any amount of work via command line or SSH,
> you need to be competent with one of them.
The one you need to be competent with is vi: it's part of the Single UNIS specification, so practically all random hosts you ever SSH to will have /bin/vi. This comes in handy when you're paged at 3am by a host you've never seen before, and you want to change some code quickly so you can get back to sleep. Being familiar with basic vi will save you time and potentially making an error scp'ing files from your dev host (which has your editor set up just the right way).
I also tried a few times, always failing (apart from basic survival, i.e. <Esc><Esc><Esc>:qa! to quit ASAP...); I finally learnt vim when I was forced to at my previous workplace, because our main work environment was on remote servers with crappy connection.
I always said that love for vim is an example of Stockholm Syndrome; and now I'm using it daily as my main editor of choice. The killer feature for me is :cex system('foobar | grep something | ...') | copen. Other than that, various plugins, especially for Go (vim/emacs/acme(?) have the most mature plugin ecosystem for Go) and CtrlP. My current opinion is that vim is in some ways super cringeworthy, but in other ways lightyears ahead of competition. And as to the Stockholm Syndrome... I'm kinda on the fence now. But then... isn't it actually what the Syndrome is all about?...
I learned vim for three month. After a vimrc of close to 150 lines, I had to admit that sublime text has more functionality than vim and all of them are far more difficult and slow to use (long and hard to memorize command names). It's even worst compared with IDEA.
Now I only use vim as my default editor in terminal.
Mutli cursor. There is plugins which try to emulate it, but it either didn't work or was lacking a lot functionnality. Other things bothered me, but the lack of good multi cursor implementation was a reason to stop using vim by itself. Just can't live without it now.
I don't think there is anything you can do with multiple cursors that you cannot do with macros or regex replacements. But I also think multiple cursors are worth having!
I'm an Emacs user and there is a good multiple-cursors package for Emacs which I also use, so I have access to all of macros, regex-replacement and multiple cursors. I find that I do use all of them, but in different situations. I think of multiple cursors as "lightweight, instant feedback" macros.
I often screw up macros because of little edge cases that don't occur in the location where I'm recording but do occur somewhere else I want to apply the macro. You don't notice the mistake until you run the macro at that other location! If you ran the macro many times, you might not even notice the mistake until much later. When I do notice a mistake, I undo and edit the macro so that it applies to the other location too and then rerun.
With multiple cursors, if I can see all of the cursors on the screen at once, I usually spot mistakes while I go along and fix them immediately. Macros are like the compile and run cycle, whereas multiple cursors are like using a REPL (even more like a Bret Victor style live environment). I always prefer REPLs for the same reason.
If I can't get all the cursors to fit on the screen at once, I typically use macros, but thinking much more carefully about the macros than I would with multiple cursors. If you almost never screw up macros multiple cursors might not benefit you. But then again they might, because they let you be sloppier and go faster.
I move daily between different environments (OS X, Windows, Linux in VMs and on Raspberry Pi) and languages (C, Python, shell scripts).
Switching between different editors on all platforms was a chore. Emacs provides me with the same basic functionality in all environments and for all languages I use. Additionally, it works very similarly both on the desktop and in a terminal, so I can use a powerful editor even in fairly restricted environments.
So yes, for me it's worth it.
I started with plain file-editing, with a focus on keyboard shortcuts for editing. When they felt somewhat comfortable, I started using basic modes (fill-mode for better editing, C and Python modes). As you go along, you'll find things you want to do (format paragraph, autocomplete,...) You'll look them up, and find that they are either built-in, or available as a mode. Rinse, repeat :-)
---
When I got back into emacs I dedicated two weeks to re-learn it after years of not using it.
I watched/read a couple of tutorials for setting up a python development environment - which happened to be one of my drivers since I hadn't found a decent python editor.
I read through the built in tutorial once, and referenced it a few times in the following days as I was editing. I had coding to do, but I did manage to slim down my task list to account for the potential of lost productivity.
For emacs M-x describe-mode was very helpful in getting a list of chords/hotkeys, but the ones that I really needed to develop a memory for were navigation/search/save/exit.
It probably was the full two weeks before I was comfortable. Now I get into other environments and I wonder how people deal with how slow things are or how you are supposed to remain focused when you have to use your mouse all the time.
My favorite plugin is yasnippet. Quick and easy templates for repetitive tasks with multiple stop points and dynamic content.
After that, any effort is simply in googling what you need your editor to do. If it's not built in, somebody has already wrote something for it 90% of the time.
I bounce between Visual Studio+Resharper, IntelliJ, and XCode (the worse of the three by far). Unless I'm having to manipulate UI element on a wysiwyg editor...I really don't touch the mouse in any of those IDEs. For the most part, I don't need it (even with the piece of crap XCode).
But each of those editors requires time to really learn, just like vi and emacs (formerly I was proficient in them too). Many people look at Visual Studio for example, see the Solution Explorer and just go "well, that must be the only way to open a file"...um, no.
I've found that for Node.JS / Golang / PHP / JavaScript it has been well worth it, my workflow feels faster, I have less time spent missing clicking around even copying a line or changing text inside quotes or braces. Things like ci" or da" make life a lot easier dealing with parenthesis. The editing capabilities just feel natural I always feel like I'm programming and not just 'thinking' I believe it just comes fluently from practice and motivation for learning it. I prefer Emacs + Evil (vim modal editing) due to ELisp and I started with Emacs first never gave VIM a chance.
I also find the packages out there are pure genius such as ace-jump (originally from vim i know..)
I find that having a good cheat sheet in front of me helps a lot. A good book goes a long way. I recommend Practical Vim by Drew Neil. And of course, use it when you are not programming on the clock. I find that this is the best way to develop the muscle memory.
> And, I suppose, I have another another question: is it worth it?
As a relatively new vim user I would say it is definitely worth it. I started slowly adapting the navigation just for fun and upgraded vim as my main editor roughly a year ago.
The thing why I personally like vim is because I can optimize every movement, every text change and every action to maximum. If something is not intuitive or feels awkward, I am one step away from changing my vimrc [0] to fix it. As a result, you end up with a editor that never forces you to leave the home row and does exactly to 100% what you expect it to do. Every function outcome and every cursor position after a motion becomes predictable, and if you get better/faster on the way, vim becomes better/faster as well. I am discovering new things or different approaches to existing techniques every day and love every bit of it.
At my job, I spend the majority of my time thinking, browsing code, more thinking and a lot of reading. Once I know what I want to change, no matter where it is, I can jump with minimum keystrokes to the exact spot and do what I wanted to do.
If you want to learn vim, here is what I did: I installed Vintageous in SublimeText and only used hjkl for navigation while still using sublime functionality for everything else. Then step by step adapted motions, text objects and Ex. Once I felt comfortable enough, I gave real vim a try. On the way somewhere I also stole a entire vimrc from someone popular on github and started with that as my base.
The only problem in my opinion is that once you adapted to using vim, it is hard to go to any other editor that does not have vim keybindings/support/motions.
Emacs I think is worth it as well. Almost all terminals and editors come with built-in emacs keybindings for basic navigation and actions: Kill a word, jump to the beginning of the line, jump to the end of the line, go back a word and so on.
Pick a small subdomain of your work, and use it exclusively there. Perhaps that's editing config files, or editing when sshed into a remote machine. Maybe for a language you only use in one-off scripts. Something you do at least weekly, but not more than an hour a day. That way you can get regular practice, without a huge productivity drop from going all-in.
Another suggestion: Start vanilla, and slowly add in new commands/customizations slowly. For vim, for the first day, just stay in Insert mode, and move around with the arrow keys. The rest of the week, just add in Command mode, and use hjkl to move around. Next week, add in something else.
I learned vim about 2 months ago. I started by doing vimtutor and just messing around practicing a few nights. Then I forced myself to start using it for work. At first, things were really slow and a bit frustrating, but after a few days, I felt like I was editing faster than before. Then you pick up more and more tricks, and it just keeps getting faster. I would never go back now. And if you're the type of person who gets excited by learning little productivity boosts, you'll love it. I know if may seem like a Herculean task at first, but really, in just a few days practice your muscle memory will be there.
It's worth it, just have to get through that first few days where you want to run back to familiar territory. I don't know of any shortcuts, just repetition. My particular choice is Vim, and my only advice would be don't try to master it all at once. Work on just editing text, saving and opening files, find/replace. When that's all second nature, get wild and start using window splits, macros, and remapping keys(if you want to).
Once you're all trained up though, I think you'll really be happy you spent the time.
Totally worth it. I felt the productivity drop when I started emacs, but now I fly through editing tasks. I should probably put in the effort for vi as well, but that idea exhausts me :)
I learned emacs by using it as my note-taking editor, not for code at first. I'd have a cheatsheet open and all I needed were the basic navigation commands. Once I was comfortable I started coding in it.
The biggest benefit to emacs is the Mac UI and bash both share the same navigation keystrokes. My hand almost never needs to move over to the arrow/paging keys anymore.
When I started with Emacs, I customized a bunch of things to make it behave in a more familiar way. That let me learn new things in small batches without taking a huge up-front productivity hit.
Over time I've changed a lot of things to be closer to defaults. But I've also kept some of my customizations (I still use cua-mode, for example).
One downside to this approach is that you may miss out on useful parts of Emacs because your customizations cover them up or conflict with them. But on the whole it has worked very well for me.
I would say that it is worth it for one simple reason: vi and emacs are going to be around for a very long time. This has the advantage of letting you learn and build upon your skills as time progresses. Even though vi and emacs usually take much longer to learn and modern editors frequently offer many more features, you will probably end up being more productive with the old school editors simply because you aren't relearning existing skills every few years.
No, it's not worth it. Modern IDEs make so many things easier than vi / vim / emacs ever did.
vi / vim / emacs can be useful in certain situations (Unix / Cygwin command lines, low level embedded systems that don't have a desktop, etc), but for most code, the modern IDE GUIs blow them away. Code navigation / inspection / contextual browsing is much, much better, easier, and far more productive using Eclipse, CLion, Visual Studio, etc.
I'm in a similar position. I do use vim but only for the most basic of editing tasks. I certainly haven't made the switch - but I read this just the other day and it's at least addressing the issue that we have:
I also seem to have an annual attempt at switching to Vim [1]. I can do enough basic commands to survive, but I am so far from the productivity in Sublime/Atom that I always end up going back to them.
I just installed vim on the side and used it for little notes and so on. After a while I started missing the basic movement keys in my IDE, and installed an emulator. For two weeks it was utter pain and then I was back to normal productivity. Over time I gradually added little tricks and now it drives me crazy to go back.
Happy vim user for 3 years, and SOOOOO worth it. Being able to work with text in an editing language immensely shortens the loop from thought to code, and having an editor that you can adapt to any language or framework or toolset you want is invaluable.
I learnt (what relatively little I know of) Vim purely through version control commit messages and "quick edits" to config files that aren't visible in my gui editor project views (dotfiles, hosts etc.)
I will try to answer your questions as I have seen both sides of the fence.
I initially used Visual Studio (around 2012) and really loved the power it gave me. I never felt slow or inefficient until I saw a screencast about Apache config that used vim and I was amazed to see how the person could simply jump to places he wanted. So I set out to try vim. I switched it for all my hobby work but it didn't catch on. So I went back to Visual Studio and in 2014 I thought I should give it another go. This time I started by installing the VsVim extension for Visual Studio.
This is how I got good with Vim:
- In the beginning (I think 2 weeks) I only focused on using the motions (word, next character, paragraph, blocks and regex motion), common commands like d, c and R.
If it helps I saw a screencast (one of the Vim London meetup videos) which broke down Vim into a grammar to be thought of as "operator + count + motion".
I also slowed the key repeat rate to make sure I don't hold arrow keys to move. DISABLE ARROW KEYS IN VSVIMRC.
- After around 2 weeks I got comfortable with that and switched to pure Vim whenever I could. You can set up an external program to call up on the current file in Visual Studio. I also learned to touch type in the next 2 weeks so that I could reap more benefits.
- After a week of moving to Vim, I started writing my vimrc with things like colorcolumn, autoindent and other simple stuff. I also installed relevant text object plugins [1]. I installed some language specific plugins and started reading the :help pages. :helpgrep is very handy. At this time I think I felt I was back to my old productivity level if not above it. It took around 3 weeks I think.
- I then proceeded to learn about jumplist, named registers, location list, differences between buffers, windows, splits and tabs and how they are INTENDED to be used. It took me around one week.
- At that point I simply started looking at some Vim screencasts [3], [4], [5], [6], [7], [8] and [9].
CONCLUSION:
I am more productive in Vim when writing anything other than C#, F# or Java. Visual Studio excels in that department.
I debug NodeJS in VSCode.
For all other things I use Vim and am noticeably faster now compared to other editors.
Although yes, I really miss Visual Studio a lot when using Vim. But thankfully Visual Studio has the great VsVim plugin.
I use Emacs with evil-mode (vim bindings) and Programmer Dvorak for my keyboard layout.
It's like anything in life, you just have to make yourself do it. There's no substitute for putting in the work and time. Sure, it's painful for the first few months, but I believe it pays off in the end.
I think the biggest thing is this: you say you try every few years to learn these editors. Don't quit next time.
That's quite the stretch, and I'm even one of the commenters in your linked thread who used to work there. Gusto has made some mistakes on the employee equity side, but, with a few exceptions, it was a wonderful place to work.
I suggest reading http://plato.stanford.edu/entries/freewill for a pretty good overview of the arguments in favor of the existence of "free will" (which itself has many definitions).
Which isn't to say you're wrong, but I think it's pretty uncharitable to say there aren't any "coherent" arguments in favor of free will. You did say you haven't "seen" any arguments, which I suppose is not the same as a claim that are none, but a cursory glance at that article should be illuminating for you. People have been thinking about this for a very long time, and no consensus seems to have emerged. :-)
Michael was one of our group partners during S16, and I cannot think of a person better suited for this position than him. He consistently demonstrated the ability to cut through all of the nonsense founders tried to use to defend their actions (ourselves included) and delivered fantastic insights into our businesses to which we were blinded.
For me, the group partners were the primary value delivered by YC during the program, and I look forward to that value being continued under Michael's leadership. Congratulations!
In addition, the strategy you've outlined is the one nearly every incumbent in every enterprise space has leaned on to protect themselves from disruption, but it only works for so long (as we've seen time and time again). I also think people overestimate the ability of large companies to quickly adapt their offering—the machinery of enormous sales, marketing, and product organizations can't turn on a dime.