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.