Agreed, but you're going to have usability problems when the use of a poor UI continues to be dictated from above despite the opinions of the people that actually have to use it.
GUIs are suppose to be less work, not more - typing is more work (as the AC pointed out)
They're better for some things, not as good for others. I can pop up a command prompt and type "copy *.txt \newdirectory" a lot faster than I can select the same files in the UI and drag them to another window. Conversely, if I want to copy everything in a particular folder between a range of dates, it's usually faster to use the UI.
If we were talking about metallurgists you'd have a point but most programmers I don't think size of local industry is their main obstacle to employment nor do I think the availability of workers is a driver for the size of the industry.
It isn't always, but depending on the kind of skills/work needed it can be. For instance, if you're primarily an embedded or industial automation developer, you're going to have an easier time finding work in an area that already does a lot of similar work, if for no other reason than there are non-trivial costs to running an embedded shop beyond just the software tools.
Where I work now, we have two H-1Bs in our dev group of 12. Both are outstanding workers, and "legitimate" in that the company made a good-faith effort to fill the positions with Americans, but wasn't able to find people with the needed skills. Both are also paid at what I would consider to be an appropriate wage comparable to ours, and HR takes good care of them and makes a real effort to abide by both the letter and spirit of the law. This is how it's supposed to work.
Having said that, I've also worked at places that brought in H-1Bs in preference to American workers, even when the domestic workers were more qualified for the position. The reason? Money. At one place I worked (dev group of 14 with 4 domestic workers), the highest paid of that group was at about my experience and competence level, yet was paid less than 2/3 of my salary, and the company made it very clear to all of them that if they didn't toe the line, they were welcome to go right back to the five different nations they came from. Of course, personal experience doesn't mean it happens everywhere, but I've seen it enough to believe that there are a non-trivial number of employers that are in fact abusing the program.
Okay, there's the misunderstanding - I hadn't understood you were talking about automated pre-checkin testing. I still am not seeing the need for "multiple compilers, multiple OSes, and multiple binary architectures" mentioned by the original poster for a product that is intended for a single platform. I frankly don't care whether my code builds and how it runs under Clang when we're a Visual Studio shop. Of course it's different for an open-source organization or a library vendor that needs to support multiple build/run environments, but those are rare exceptions. For most, we're talking about adding a lot of complexity, time, and maintenance costs to get a common code base for a number of different build environments that will never be used in production, particularly when there's a full-time QA department available.
Developers may build with the IDE’s own compiler during development, but must ensure the code successfully builds with the centralized build system before committing.
Which is fine if you have the good fortune to have a mirror of the build system on your own machine, but in a lot of situations that isn't the case. Where I work we of course have the raw build scripts that we're expected to run locally before committing, but the CB system we use (Jenkins) occasionally just doesn't behave the same way because it has to do additional processing that we can't do locally, and sometimes will flag spurious errors that can only be fixed by clearing the workspace. Yay for incremental builds.
Multiple compilers, multiple OSes and multiple binary architectures should all be used and they should all be available to every developer on the network.
That's fine for something that's intended to run cross-platform, but not so much for something targeted to a specific operating system - code that's hooking Windows drivers isn't going to fare too well under Linux, for instance. As regards the unit tests, it's trivially easy to have code that runs fine in the unit tests but won't build for production because the test project contains the needed dependencies, but the coder forgot to put those dependencies into the production project. That's not an excuse for broken builds, but it does happen.
Your QA/Build process is seriously broken if you don't have one person or one team in charge of the build at all times.
We do have someone that owns the responsibility for the build system, but we also largely subscribe to the "you break it, you fix it" philosophy, and all of the devs have the tools to see when something breaks on the CB system right then and there. Social pressure among the devs ("Awesome job breaking the build, Bob. Did you even compile it before checking it in?") tends to help keep the builds clean, although there still are a couple of guys on the team that can be counted on to break the build a few times a week. 9 times out of 10 our busted builds are because someone didn't take the time to build all of the required configurations on their own machine before checking something in.
The problem is that sometimes that's not an option. For instance, a few weeks ago I was working with some code in VS 2010 that used named enums. Even though Intellisense was smart enough to recognize the enum without the explicit name ("enum" instead of "name::enum"), the compiler kept throwing "unknown symbol" errors if the enum was left as-is, and it would throw a warning indicating that the syntax given was only valid under C++11 if I explicitly scoped the enum, which failed the build because we compile with warnings equating to errors. Changing the enum itself to be enclosed in a class or at least a namespace probably was the right way to do it, but it would end up affecting a lot of other code, which in turn meant an extra regression pass for the QA guys. So, the only practical solution at the time was to disable the warning for that block of code, and re-enable it afterwards with a comment explaining the reason.
Oh yeah, and if you get an efficient diesel generator you're looking at using 14 gallons for that 455 miles of range, giving you 32.5 mpg, which while it isn't great, isn't bad either.
The shipping weight on the first generator you gave was over 400 pounds, so we'll be conservative and call it 350. Fuel is another 7 pounds per gallon, which adds another 100 or so pounds (or more with a bigger tank, although this will go down as the fuel is consumed), and the trailer will likely weigh in the neighborhood of 150 pounds, with the hitch adding another 30 pounds or so. The upshot of this is that with the extra weight the car will be pulling (600+ pounds or so, plus whatever the passengers weigh), you're not likely to get the advertised 265 miles of range, plus if the generator is running at 85-90% of capacity to charge the car it's going to burn fuel at close to twice the advertised rate (which usually assumes a 50% load), both of which will substantially reduce the effective MPG.
It's doable, but not practical. To me it seems kind of silly to spend thousands of dollars in addition to the rather steep cost of the car itself just to turn it into an expensive, jury-rigged hybrid when any $30,000 ICE sedan will give roughly equivalent if not better range, and you have to buy a LOT of fuel to make up that $40,000 price difference (minus whatever tax credits, etc. come into play). And yes, if you happen to have any charging stations along the way you can mitigate the financial cost, but the charge time is far from trivial, even for the Superchargers. For an ICE car that gets 30mpg, it takes about a minute to fill it with enough energy to go 300 miles. For a Tesla on a Supercharger, it takes an hour or so to load not quite 90% of that much energy, and far longer at most other stations.
But you never know if you could have gotten the better deal even when you do agree. You may indeed get a price that you agree on but you never know how low the dealer might have gone.
You're absolutely right, of course, but in my case, I placed a non-trivial value on my free time, and given that what I was offering was a couple thousand dollars under the researched "invoice price" (which of course is bogus, given the nebulous value of the dealer's holdback and other potential dealer incentives) and *many* thousands under the MSRP, I felt that it was at the very least a fair price and that it represented a case of diminishing returns to pursue anything lower.
If it helps any, I hate the car. It's what my ex wanted to get, not me.
Who here has actually had a 'good' experience when buying a car from a dealer?
The last car I bought was pretty much trouble-free. I researched the vehicle, determined what I was willing to pay for it, and called the dealerships with my out-the-door price. Three of them balked, the fourth faxed me a quote with my price, and I picked the car up later that day for exactly that amount. They weren't real pleased to find out I already had financing in place through my bank, but that wasn't my problem.:-)
Haggling means that the person with the most experience at it wins
No, haggling means the person that's least willing to walk away loses. It's not hard, you just have to say, "okay, no deal then", get in your car, and drive away if they won't sell for what you're willing to pay. Plus you get the bonus of knowing the salesman is going to be sweating as he explains to the sales manager why he lost the sale.
All they need to do is place a generator on a trailer and tow it with them.
If you don't mind spending thousands of dollars on a generator that can keep up with the car's power drain, and the snickers of everyone around you when you pull into a gas station with your $100K EV to fill up the tank.:-)
A 39 inch 4kTV is the equivalent of 4 20 inch 1080p monitors together.
But useless for when you need to run the debugged program full-screen while watching what happens in a debugger, network sniffer, etc. at the same time. There really are times when you need multiple displays not just for the added screen area, but because each display is being used for something different.
The same is true of Publix in the Southeast. Their normal pricing is higher than Walmart, but they run so many sales and BOGOs that it often ends up as a wash.
Slashdot Mirror
The operative and contested term being reasonable.
Which essentially is what the Fourth Amendment defines.
"Yeah, they broke the law, but they had good reasons!" Another useless government agency.
There were enough usability problems with them
Agreed, but you're going to have usability problems when the use of a poor UI continues to be dictated from above despite the opinions of the people that actually have to use it.
GUIs are suppose to be less work, not more - typing is more work (as the AC pointed out)
They're better for some things, not as good for others. I can pop up a command prompt and type "copy *.txt \newdirectory" a lot faster than I can select the same files in the UI and drag them to another window. Conversely, if I want to copy everything in a particular folder between a range of dates, it's usually faster to use the UI.
If we were talking about metallurgists you'd have a point but most programmers I don't think size of local industry is their main obstacle to employment nor do I think the availability of workers is a driver for the size of the industry.
It isn't always, but depending on the kind of skills/work needed it can be. For instance, if you're primarily an embedded or industial automation developer, you're going to have an easier time finding work in an area that already does a lot of similar work, if for no other reason than there are non-trivial costs to running an embedded shop beyond just the software tools.
I can't speak for everyone, but I most certainly have turned down jobs when the salary wasn't adequate, and I know plenty of others than have as well.
Where I work now, we have two H-1Bs in our dev group of 12. Both are outstanding workers, and "legitimate" in that the company made a good-faith effort to fill the positions with Americans, but wasn't able to find people with the needed skills. Both are also paid at what I would consider to be an appropriate wage comparable to ours, and HR takes good care of them and makes a real effort to abide by both the letter and spirit of the law. This is how it's supposed to work.
Having said that, I've also worked at places that brought in H-1Bs in preference to American workers, even when the domestic workers were more qualified for the position. The reason? Money. At one place I worked (dev group of 14 with 4 domestic workers), the highest paid of that group was at about my experience and competence level, yet was paid less than 2/3 of my salary, and the company made it very clear to all of them that if they didn't toe the line, they were welcome to go right back to the five different nations they came from. Of course, personal experience doesn't mean it happens everywhere, but I've seen it enough to believe that there are a non-trivial number of employers that are in fact abusing the program.
Okay, there's the misunderstanding - I hadn't understood you were talking about automated pre-checkin testing. I still am not seeing the need for "multiple compilers, multiple OSes, and multiple binary architectures" mentioned by the original poster for a product that is intended for a single platform. I frankly don't care whether my code builds and how it runs under Clang when we're a Visual Studio shop. Of course it's different for an open-source organization or a library vendor that needs to support multiple build/run environments, but those are rare exceptions. For most, we're talking about adding a lot of complexity, time, and maintenance costs to get a common code base for a number of different build environments that will never be used in production, particularly when there's a full-time QA department available.
And the benefit of this extra step is...?
On the flip side, we usually get bitched at if there are no unit tests for new code.
Developers may build with the IDE’s own compiler during development, but must ensure the code successfully builds with the centralized build system before committing.
Which is fine if you have the good fortune to have a mirror of the build system on your own machine, but in a lot of situations that isn't the case. Where I work we of course have the raw build scripts that we're expected to run locally before committing, but the CB system we use (Jenkins) occasionally just doesn't behave the same way because it has to do additional processing that we can't do locally, and sometimes will flag spurious errors that can only be fixed by clearing the workspace. Yay for incremental builds.
Multiple compilers, multiple OSes and multiple binary architectures should all be used and they should all be available to every developer on the network.
That's fine for something that's intended to run cross-platform, but not so much for something targeted to a specific operating system - code that's hooking Windows drivers isn't going to fare too well under Linux, for instance. As regards the unit tests, it's trivially easy to have code that runs fine in the unit tests but won't build for production because the test project contains the needed dependencies, but the coder forgot to put those dependencies into the production project. That's not an excuse for broken builds, but it does happen.
Your QA/Build process is seriously broken if you don't have one person or one team in charge of the build at all times.
We do have someone that owns the responsibility for the build system, but we also largely subscribe to the "you break it, you fix it" philosophy, and all of the devs have the tools to see when something breaks on the CB system right then and there. Social pressure among the devs ("Awesome job breaking the build, Bob. Did you even compile it before checking it in?") tends to help keep the builds clean, although there still are a couple of guys on the team that can be counted on to break the build a few times a week. 9 times out of 10 our busted builds are because someone didn't take the time to build all of the required configurations on their own machine before checking something in.
Rework the code so that it doesn't warn.
The problem is that sometimes that's not an option. For instance, a few weeks ago I was working with some code in VS 2010 that used named enums. Even though Intellisense was smart enough to recognize the enum without the explicit name ("enum" instead of "name::enum"), the compiler kept throwing "unknown symbol" errors if the enum was left as-is, and it would throw a warning indicating that the syntax given was only valid under C++11 if I explicitly scoped the enum, which failed the build because we compile with warnings equating to errors. Changing the enum itself to be enclosed in a class or at least a namespace probably was the right way to do it, but it would end up affecting a lot of other code, which in turn meant an extra regression pass for the QA guys. So, the only practical solution at the time was to disable the warning for that block of code, and re-enable it afterwards with a comment explaining the reason.
Of course they're afraid of that. Heaven forbid we actually allow the accused to exercise their right to a fair trial.
MIT is already working on something similar.
Oh yeah, and if you get an efficient diesel generator you're looking at using 14 gallons for that 455 miles of range, giving you 32.5 mpg, which while it isn't great, isn't bad either.
The shipping weight on the first generator you gave was over 400 pounds, so we'll be conservative and call it 350. Fuel is another 7 pounds per gallon, which adds another 100 or so pounds (or more with a bigger tank, although this will go down as the fuel is consumed), and the trailer will likely weigh in the neighborhood of 150 pounds, with the hitch adding another 30 pounds or so. The upshot of this is that with the extra weight the car will be pulling (600+ pounds or so, plus whatever the passengers weigh), you're not likely to get the advertised 265 miles of range, plus if the generator is running at 85-90% of capacity to charge the car it's going to burn fuel at close to twice the advertised rate (which usually assumes a 50% load), both of which will substantially reduce the effective MPG.
It's doable, but not practical. To me it seems kind of silly to spend thousands of dollars in addition to the rather steep cost of the car itself just to turn it into an expensive, jury-rigged hybrid when any $30,000 ICE sedan will give roughly equivalent if not better range, and you have to buy a LOT of fuel to make up that $40,000 price difference (minus whatever tax credits, etc. come into play). And yes, if you happen to have any charging stations along the way you can mitigate the financial cost, but the charge time is far from trivial, even for the Superchargers. For an ICE car that gets 30mpg, it takes about a minute to fill it with enough energy to go 300 miles. For a Tesla on a Supercharger, it takes an hour or so to load not quite 90% of that much energy, and far longer at most other stations.
But you never know if you could have gotten the better deal even when you do agree. You may indeed get a price that you agree on but you never know how low the dealer might have gone.
You're absolutely right, of course, but in my case, I placed a non-trivial value on my free time, and given that what I was offering was a couple thousand dollars under the researched "invoice price" (which of course is bogus, given the nebulous value of the dealer's holdback and other potential dealer incentives) and *many* thousands under the MSRP, I felt that it was at the very least a fair price and that it represented a case of diminishing returns to pursue anything lower.
If it helps any, I hate the car. It's what my ex wanted to get, not me.
Who here has actually had a 'good' experience when buying a car from a dealer?
:-)
The last car I bought was pretty much trouble-free. I researched the vehicle, determined what I was willing to pay for it, and called the dealerships with my out-the-door price. Three of them balked, the fourth faxed me a quote with my price, and I picked the car up later that day for exactly that amount. They weren't real pleased to find out I already had financing in place through my bank, but that wasn't my problem.
Haggling means that the person with the most experience at it wins
No, haggling means the person that's least willing to walk away loses. It's not hard, you just have to say, "okay, no deal then", get in your car, and drive away if they won't sell for what you're willing to pay. Plus you get the bonus of knowing the salesman is going to be sweating as he explains to the sales manager why he lost the sale.
All they need to do is place a generator on a trailer and tow it with them.
:-)
If you don't mind spending thousands of dollars on a generator that can keep up with the car's power drain, and the snickers of everyone around you when you pull into a gas station with your $100K EV to fill up the tank.
A 39 inch 4kTV is the equivalent of 4 20 inch 1080p monitors together.
But useless for when you need to run the debugged program full-screen while watching what happens in a debugger, network sniffer, etc. at the same time. There really are times when you need multiple displays not just for the added screen area, but because each display is being used for something different.
What do game programmers need?
Multiple displays that work well for the task at hand.
There is no warrant with the use of a stingray device, hence no legal permission for a search
Not to mention the various FCC-related issues.
The same is true of Publix in the Southeast. Their normal pricing is higher than Walmart, but they run so many sales and BOGOs that it often ends up as a wash.