> 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.
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.