Because I have exactly zero interest in deviating from what I should be focusing on (my business, my product, my clients, my revenue stream) to go dork around with a text/code editor.
Doing so, in the context of a real working business with clients, projects, timelines, deadlines and deliverables would be irresponsible if you can simply pay a company for which that product IS their product and business to deliver what you need and support it.
I can see messing around with FOSS as a hobby but unless you are a huge company that can afford to lose clock cycles to your devs playing with FOSS or a medium size company for whom FOSS is a a business it just doesn't make sense.
The vast majority of software developers across all disciplines (there's a huge world outside of Silicon Valley, Web Dev and Mobile) have exactly zero need or interest in deviating from their mission to go fix their tools.
This is the same reason the vast majority of software developers (again, think outside web folk) have exactly zero interest in vim. It is an utter waste of time compared to point-click-go-go-go.
> Because I have exactly zero interest in deviating from what I should be focusing on (my business, my product, my clients, my revenue stream) to go dork around with a text/code editor.
You can improve your productivity (i.e., increase your revenue) by improving your tools.
A blacksmith makes his tools; a developer should be want to extend his environment.
> unless you are a huge company that can afford to lose clock cycles to your devs playing with FOSS
It's not a loss: it's an investment which pays dividends.
> The vast majority of software developers across all disciplines (there's a huge world outside of Silicon Valley, Web Dev and Mobile) have exactly zero need or interest in deviating from their mission to go fix their tools.
I have exactly zero interest in hiring or working with someone who is uninterested in improving his productivity.
> This is the same reason the vast majority of software developers (again, think outside web folk) have exactly zero interest in vim. It is an utter waste of time compared to point-click-go-go-go.
Both vim and emacs are far better and faster at moving structures of code around than the vast majority of GUI editors. Better and faster means…more revenue for less effort. And it's fun!
No idea why this is being downvoted. If you ask me, it's irresponsible not to invest in your tools and productivity. If you don't, you're wasting your employer's time and money. A bit of time "dorking around" in Vim will pay huge dividends over time.
Give it a shot. Open up `vimtutor`. It's easier than you think!
Interesting. You see, to me you are wasting our time and money if you do not realize that the time devoted to code entry is insignificant when compared to other aspects of a non-trivial project. It's like putting $300 racing tires on a Toyota Sienna minivan. You can quote all kinds of skid-pad numbers and amazing high speed capabilities, yet you'd be focusing on the wrong problem. You can go much faster by getting a better car with less expensive tires.
I know a good percentage of HN members are focused around web development. Please stop for a moment to understand there's much more to software engineering than the web. Much more. Your view of reality is decidedly skewed.
I'll give you an example. We've been working on a system that has required over a year of real R&D and thousands of man-hours before we understood how to solve the problem. The software development phase will take about a month or two. And a good chunk of that is debugging, reevaluating assumptions and testing. Nobody here cares one bit about what we use to enter the code (in various languages) comprising this system. It isn't a factor.
Of course there's much more to software engineering than entering and editing text, and you'll need to make a judgment call based on your priorities. I do more than web development, so I don't think your "web dev bias" applies to me. I merely find disagree with your absolutism:
> It is an utter waste of time compared to point-click-go-go-go.
If you don't have free time to devote to learning an editor, then that's fine. I was referring to those who spend most of their time programming (i.e. at an editor/terminal).
As an aside, I'm not sure why you keep mentioning web development. Of all the things that I do, web development requires the least amount of code. Other things have vastly bigger codebases. But yes, if most of your time is spent doing R&D, then you won't benefit much from improving your engineering tools.
> I'm not sure why you keep mentioning web development.
Only because I think it is fair to say that a large portion of HN's members are in web development rather than, say, robotics and aerospace which is a significant portion of what we do.
> But yes, if most of your time is spent doing R&D, then you won't benefit much from improving your engineering tools.
Let me add a twist to this, only because I think it got lost somewhere.
I am not opposed to better tools. I simply want to pay for them and let others who's business it is to focus on making better tools create them for me. My job isn't to become an expert on a code editor's source code or our FEA tool's code base. My job is to use these tools and others to develop the products our clients want us to develop.
So, yeah, I will gladly pay --and we do pay tens of thousands of dollars per year-- for the right tools, with the right performance, the right support and the right feature set. If we need something special and it can be done with some easy scripting, sure, absolutely. Otherwise I prefer to communicate needs to our vendors and hope they see the need to address these pain points.
We've had at least half a dozen cases of software providers sending members of their development team to our office to spend time learning about issues we found and how to fix them. One of them was a team of software developers from India that made the trip to try and figure out why their CAM software was crashing end-mills on our Haas vertical machining centers and churning aluminum like it was butter with the 20 HP spindles.
Our mission was to make parts. We made that happen one way or the other. It took them --while being fully versed in their own code-base-- a week to find the problem and another month to fix it and go through regression testing. It probably would have taken us three to six months to do the same thing (had it been open source) while completely deviating from our core mission.
On another occasion we devoted three months to write this application that automated component creation for an EDA tool we were using. The tool had shortcomings. Thankfully it had an API that, of all things, could be accessed through Visual Basic. We talked about it and decided to fix it by creating an external tool in VB.
It took one engineer three months of total dedication to the cause to write the code and produce a working tool. And it was great. What used to take three hours could now be done in 30 minutes.
That seemed like an example of resources and time well used. Except, as the EDA tool company issued updates our tool would break and we very quickly found ourselves chasing our tails constantly fixing our code. It was the old "when you are up to your ass in alligators" story.
Six months later we decided it was a far better to jettison the EDA tool and buy a better tool instead. That was the right decision. We should have made that decision nine months earlier rather than completely deviate from our core business to fix someone else's problems.
I have more stories like that one. I am not saying what I say to be difficult, I have the scars to prove which business and engineering decisions are right and wrong, not in absolute terms, of course, but in the context of the task at hand.
You are confusing matters and overstating productivity factors. Editors, yes, including vim, have nearly zero impact on the timeline for any non-trivial project. The time devoted to all things outside of typing code dwarfs any gains had by counting keystrokes with vim. It's an illusion of the first order.
Now, good tools, such as the JetBrains tools can have an impact that has little to do with productivity. We do hardware and software development. It is useful to have a tool that has the potential to feel like you are doing pair programming by helping you along. Why? Because if you are popping between Verilog and Python with a range of other languages across server, desktop and embedded while using multiple tools and IDE's you start valuing tools that can help you context switch. And, no, I do not want to waste time messing with source for the two dozen tools we use on a regular basis. And, no, in this context vim has no real measurable value whatsoever.
My guess is you might disagree. And that's OK. If your context is web development you simply don't have enough of a view of the rest of the tech ecosystem to understand. If you've never run a tech business you will not have had the financial feedback loop that allows you to understand these issues. I can improve productivity by a far larger margin by providing every workstation with three large monitors, lots of memory and making sure people work reasonable hours and don't burn out than through some magical editor that also requires my engineers to even as much as look at source due to shortcomings.
In fact, I can, and have, improved productivity dramatically by having everyone work half days on Fridays while being very flexible with daily schedules and liberal with vacation times. As an example, I had one engineer ask me if he could take a few days off to go to a concert in London. I said "send pictures", paid him for the time he was away and did not take vacation days off.
We are a team, we know what our mission is and we get shit done. We are not factory workers counting keystrokes per second. We are knowledge workers, which automatically means we spend far more time on things other than typing code.
> The time devoted to all things outside of typing code dwarfs any gains had by counting keystrokes with vim. It's an illusion of the first order.
Editors are, or should be, the sole tool necessary to sculpt a system. Using poor languages, yes, there's a lot of ritual outside of coding which is necessary. With powerful languages, the design is the code and the code is the design and it all lives within an editor.
The editor is the interface to the documentation; it's the interface to the running system; it's an interface to the debugger; it's the interface to the world.
> Because if you are popping between Verilog and Python with a range of other languages across server, desktop and embedded while using multiple tools and IDE's you start valuing tools that can help you context switch. And, no, I do not want to waste time messing with source for the two dozen tools we use on a regular basis. And, no, in this context vim has no real measurable value whatsoever.
Which is why I use emacs, which is able to provide a seamless interface between server, desktop, laptop and embedded environments, in which context switching simply doesn't have to be necessary. Emacs provides a whole heck of a lot more than vim. Vim is a powerful editor; emacs is an ultra-powerful environment.
Yes, it's also important to have large monitors, lots of memory and a great work environment. And kudos to you (honestly) for providing that.
> We are knowledge workers, which automatically means we spend far more time on things other than typing code.
Which is why I use a tool which enables me to work with units of knowledge, not just letters and symbols.
> Editors are, or should be, the sole tool necessary to sculpt a system.
Absolutely not true. My guess is you are a web developer.
I am not going to spar with you. Engineering is a world that goes way beyond web development. I urge you to consider there's far more out there than what you might have been exposed to. To think that everything starts and ends with a text editor is a bit myopic.
rebootthesystem, you have simultaneously some of the best and worst views on productivity I have ever heard. You seem to understand human factors around burnout and work quite well, but completely misunderstand an engineer's relationship with his or her tools. It is precisely because we are not unskilled factory workers that we can and should each individualize and tune our tools to our liking. I would hope that you at least don't forbid the use of editors such as emacs or vim.
I don't forbid anything at all. All decisions are made as a team. And all have to be justified. I own the company. I am not the king. Yet, with this a given I have yet to run into a single engineer who's suggested we use vim extensivey. It does see use while supporting servers and that's about it.
Don't get me wrong, a nice IDE can be a pleasure to use. Does it make a significance difference in ROI or project timelines? Not at all. If we are working on an IMU for an aerospace project the time spent on the editor is almost a rounding error.
I think a lot of people on HN view the world through web development lenses. That is most certainly not how the rest of the engineering world works. For example, when doing muliti-GHz PCB design you can quite literally blow WEEKS of work if you make a mistake. Weeks. And so the idea of fretting over keystrokes per second or amazing refactoring tools --in that context-- is nothing less than laughable. And that's why, in my world, nobody has ever come up and said "you know, if we took a couple of weeks to get good at vim we could rock this thing". It hasn't come-up because, in our context, like I said, code entry is a rounding error. Nobody cares because it does not matter.
Its one of the reasons why I'm using OSX instead of Linux on my main machine. I do dual boot, but i always come back to OSX for work related stuff. So much easier to install Office 365 (Company Version) and use it directly locally. I could use Linux, and access Office in the Corp VDI session, but i hate the lag. So, in the end, for work, I have learned to pay for the product upfront and then play around during the weekends :)
> in the context of a real working business with clients, projects, timelines, deadlines and deliverables
Sounds like FOSS with a support contract would also be appropriate. They might sell you a warranty and indemnity too. Plus your business would have a much better disaster recovery plan if you're not reliant on DRM dev/build tools. Further, selling your business and/or productizing your internal tech can be simpler with FOSS.
> It is an utter waste of time compared to point-click-go-go-go.
Clicking = moving your hand from the keyboard to the mouse. So it's actually point-click-go-back-to-keyboard-go-go-go when it could be type-go-go-go (or go-go-go-go, if you prefer) . I use vim and when I help colleagues that use phpStorm, they seem slow as fuck. Since they have a sidebarmenu, they don't think about their fuzzy matcher, they don't split their display to show 4 files instead of just one and keep navigating through tabs they did not really mean to open.
> Because I have exactly zero interest in deviating from what I should be focusing on
I don't get it. Even if you have no interest, why would you willingly give up the option? All other things being equal, wouldn't you want the ability to do it? You'll get a great product, you'll pay someone else to take care of it, and, should you ever want to fix it yourself or take it to someone else to fix it, you can do that too?
Why are you so aggressive against the notion of being allowed to do anything you could possibly want?
Not aggressive. I am simply stating my position based on thirty years of running a range of tech businesses. Others can do as they wish. And they do. And the overwhelming majority of software developers have exactly zero time or interest in deviating from their work to mess with tools source code. Some percentage will customize via macros and relatively minor scripts but virtually none go so far off course as to spend non-trivial time hacking source.
Language such as "exactly zero", "dork around", "mess around" sounds aggressive, as if people who decide to hack on their tools were beneath you. When you say "utter waste of time" on people who do enjoy working on their vimrc or init.el or whatever, it sounds like you think the person themself is a waste of a person. When you mention how many years you have, you sound pompous, as if you were stating your opinions as facts (years of experience can't be wrong!).
It sounds aggressive even if you don't intend it to sound that way. There are ways to other ways to express your opinion without sounding this way.
Here, let me try to show you what I mean:
"I am not interested in modifying my tools. I would rather pay someone else to do it. If you are spending time modifying your tools, then that is time that could have been better spent on another task. I have many years of experience, which have convinced me that the right way to spend your time is on your product, not your tools."
Note the lack of dismissive language such as "absolutely zero" or "exactly zero" or "waste of time" or "I am simply" (this last one is another attempt to present opinions as facts).
Doing so, in the context of a real working business with clients, projects, timelines, deadlines and deliverables would be irresponsible if you can simply pay a company for which that product IS their product and business to deliver what you need and support it.
I can see messing around with FOSS as a hobby but unless you are a huge company that can afford to lose clock cycles to your devs playing with FOSS or a medium size company for whom FOSS is a a business it just doesn't make sense.
The vast majority of software developers across all disciplines (there's a huge world outside of Silicon Valley, Web Dev and Mobile) have exactly zero need or interest in deviating from their mission to go fix their tools.
This is the same reason the vast majority of software developers (again, think outside web folk) have exactly zero interest in vim. It is an utter waste of time compared to point-click-go-go-go.