The Liberal Gun Club Forum

Ok this is really weird. Ted Cruz, the guy we all love to hate, has apparently put forth a bill that is ... well ... it has a LOT of good stuff in it. Powerfully good stuff.

http://www.cruz.senate.gov/files/docume ... rstAct.pdf

Here are some excerpts:

1) Sets a minimum salary on H1B of $110,000 per year. Keeps the prevailing wage statement, but sets a minimum as well; i.e. whichever is higher is the one used.
2) There is a 2 year "cool off" period after any layoff, furlough, employee strike, lockout, etc. during which the employer may not hire so much as 1 single H1B worker. This one is worded real strictly. If even 1 single worker is terminated without cause, the company goes into that 2 year cool off period.
3) Employers can't force an H1B holder to pay a penalty if they leave before their agreed upon date.
4) Employers can't deduct any fees associated with H1B from the H1B recipient's pay
5) Employers can't charge H1B recipients for vehicle, lodging, etc. If lodging and transportation is provided by the employer, they have to do so free of any charge.

For those unfamiliar with H1B, it is a type of work visa for workers with skillsets are that in "high demand" and "cannot be found in the United States".

H1B requirements state that workers must be paid above the prevailing wage for that position so as to prevent using H1B as a means to import foreign workers for skilled jobs and thereby suppress wages. In this function, it has failed. It is also supposedly not granted unless you can demonstrate that you cannot find enough US workers with that skillset. It is EXTREMELY easy to get around both requirements. Create a job with a unique title and a skillset requirement that is physically impossible. For example, 15 years of Android SDK experience. Any US worker who has this on their resume is lying so you can exclude them and say they were lying on their resume as your reason for excluding them. The unique title allows you to define the prevailing wage since no one else has that title. Either that or you can give them a title for a job that has a much lower wage than the one you are REALLY hiring for.

At many companies H1B is not abused in this manner. The big names like Google, Amazon, etc. all pay their H1B holders well. However, the largest holders of H1B and the average salary of those on H1B at those companies:

Infosys - 23,816 visas - $76,794
Tata Consultancy Services - 14,096 visas - $67,673
Wipro - 8,365 visas - $69,936

Those 3 companies are scumbag pieces of shit who fuck over workers. There's no mincing words. Please keep in mind that the jobs these companies contract for are replacing workers that are paid well into 6 figures.

The "2 year cool off" thing is pretty harsh, but I didn't see anything in there about hiring contractors. Remember that contractors who are working for you through a contracting company are employees of the contracting company and NOT your employees. Any H1B they might be here on is back by their employer which is the contracting company. So, for example, I don't think what Disney did would have been prevented by this.

However, the only reason companies layoff a ton of people and replace them with contractors is because the contractors are cheaper. Please note, in the list above of H1B and their average salaries that these are averages, not minimums. They are offset by a number of H1B holders in high positions at those firms. There are H1B holders in Director and senior management positions at those companies who do not typically go out on contracting gigs. They make hundreds of thousands of dollars. The wage of a typical software engineer from Infosys is closer to 50k than 76k. If you fire a bunch of workers who made, let's say, 120k. The hourly rate would have to be less than 60 an hour to make your money back. Your typical contractor at one of the top 3 mentioned above is likely paid by his employer around $25 per hour. That's a lot of wiggle room for profit for both the contracting company and the employer who just laid off their workers.

What happens then if those software engineer grunts go from 50k all the way to 110k? It means in order to have enough profit to stay in business, the contracting company's rates jump way above $60 an hour. At that price, it's no longer worth it for the employer to layoff their American workers.


Btw, for these types of jobs, most companies have now realized that attempting to offshore as a means of replacement results in disaster. Offshoring for skilled jobs mostly happens for 2 reasons:

1) Need for rapid expansion with low cost (i.e. new jobs)
2) Need to cover night shift with more people


Anyway, this is shocking coming from Ted Cruz. Not just because I think it's a pretty good bill. That in and of itself is shocking coming from Ted Cruz. What's even crazier is that Ted Cruz just like 1 or 2 years ago was practically Mr. H1B trying to double or triple the number of visas issued.

Well I'll be damned. Actually putting forward something that might actually help US tech workers...... Is this bizarro world?

shinzen wrote:Well I'll be damned. Actually putting forward something that might actually help US tech workers...... Is this bizarro world?

It's election season. There's probably a "repeal Obamacare" clause in it somewhere.

Would be nice to add a provision if the company's lays off people and then uses a contractor to replace the laid off workers the same restrictions apply to the contractor as they would apply to the original company if they were hiring HB1 workers even if they are offshore or the company's hiring the contractor will have to pay the same as if they were hiring the visa holders.

Buckling down on H1B is more of a meh thing. The key is to invest in our workforce to do those jobs. Most employers go H1B not to cut costs but because a given skill set cannot be obtained locally. A lot of them are in IT and engineering. If the employer wants to cut costs they will offshore the work. It will always be cheaper to staff a project in Bangalore than here in the US. If an employer can't find a local to do the work, can't import the skill set, then what is the next step? India and China have many problems, but they both hustle their talent through technical education. For free.

I look at all the people here with talent that are working in stupid land because they can't swing the cost of an education. But we talk about tuition free state school here and immediately who squawks the loudest? Cruz et.al. that's who.

So yeah, meh.

....one other point I'd like to make. That doesn't sound like a "small government" type of policy. Hypocrites.

Well consider me surprised! =)

Merkwuerdigliebe wrote:Buckling down on H1B is more of a meh thing. The key is to invest in our workforce to do those jobs. Most employers go H1B not to cut costs but because a given skill set cannot be obtained locally.

What leads you to this conclusion?

I find it far more likely that employers are squeezing the system to reduce costs, rather than not actually finding qualified candidates. I think there are plenty of candidates. Employers would just rather bring in indentured servants instead.

http://cis.org/labor-shortage-not-reaso ... en-workers

modernhamlet wrote:

Merkwuerdigliebe wrote:Buckling down on H1B is more of a meh thing. The key is to invest in our workforce to do those jobs. Most employers go H1B not to cut costs but because a given skill set cannot be obtained locally.

What leads you to this conclusion?

I find it far more likely that employers are squeezing the system to reduce costs, rather than not actually finding qualified candidates. I think there are plenty of candidates. Employers would just rather bring in indentured servants instead.

http://cis.org/labor-shortage-not-reaso ... en-workers

I'm sure it's true in some circumstances. But my experience is IT and it can be tough finding candidates many times. When I could, and found a candidate with good fundamental potential, I trained them myself many times.

Maybe he's trying to slap Outsource Carly before tonight's debate.

Merkwuerdigliebe wrote:

modernhamlet wrote:

Merkwuerdigliebe wrote:Buckling down on H1B is more of a meh thing. The key is to invest in our workforce to do those jobs. Most employers go H1B not to cut costs but because a given skill set cannot be obtained locally.

What leads you to this conclusion?

I find it far more likely that employers are squeezing the system to reduce costs, rather than not actually finding qualified candidates. I think there are plenty of candidates. Employers would just rather bring in indentured servants instead.

http://cis.org/labor-shortage-not-reaso ... en-workers

I'm sure it's true in some circumstances. But my experience is IT and it can be tough finding candidates many times. When I could, and found a candidate with good fundamental potential, I trained them myself many times.

1) You must be on the low end of the totem pole
and/or
2) You must work for a place with at least some level of ethics

I've seen both happen. I've been on the budgeting side of things and I know the conversations that happen. I've seen the numbers and they are very attractive. When your job is to make budget, doing things like what Disney did make sense. The thought probably never crossed the minds at Disney that what they were doing was unethical. When bad press came out they were likely dumbfounded. Afterall, it made really great business sense. Why would they keep X developers for Y money when they could get 1.5X developers for 0.75Y money? And local too! And contractors so no worry about benefits and the ability to terminate them any time with no worry or anything. Perfect business sense.

Your comment about outsourcing being the real way to save money is something most business of come to realize is largely false. There is a language barrier and timezone gap that causes major communication problems. There's also an issue of quality of workmanship. Outsourcing firms in IT have gotten a really bad reputation and very rightly so. In my experience, never rely on outsourced people for any heavy lifting. Use them for offhours support and that's it. Ask them to develop anything and your onshore resources will spend double the manhours fixing it.

Since outsourcing can only reliably be used to expand and not to replace, the next route to go is replacing with cheap contractors. This HAS actually been effective assuming you engage the same hiring practice with your contractors that you do with FTEs. i.e. you run them through the interview process, etc. In my experience, such contractors have a largely equal success rate compared to FTEs. Given that, if you ignore ethics, why wouldn't you replace most of your workforce with them? You keep a small core group of FTEs to be the key SMEs and use them to train up any contractors you bring onboard. You pay those FTEs nicely with better than average compensation so they won't leave. That way your key knowledge holders are permanent and anyone doing grunt work is cheap. This makes very good business sense.


Yes, the pool of really talented engineers is somewhat low. But a large number of contractors at places like HCL and TCS are perfectly willing to relocate anywhere at the drop of a hat without any expenses reimbursed. Most are living somewhat lightly here even if they have family; they are used to moving regularly. You can't say that of permanent residents and citizens. Most permanent residents and citizens are NOT willing to relocate even if you pay for it. So the pool of talent to sift through for local recruits? Small. The pool of talent from a contracting company like Wipro? HUGE.

Wurble wrote:

Merkwuerdigliebe wrote:

modernhamlet wrote:

Merkwuerdigliebe wrote:Buckling down on H1B is more of a meh thing. The key is to invest in our workforce to do those jobs. Most employers go H1B not to cut costs but because a given skill set cannot be obtained locally.

What leads you to this conclusion?

I find it far more likely that employers are squeezing the system to reduce costs, rather than not actually finding qualified candidates. I think there are plenty of candidates. Employers would just rather bring in indentured servants instead.

http://cis.org/labor-shortage-not-reaso ... en-workers

I'm sure it's true in some circumstances. But my experience is IT and it can be tough finding candidates many times. When I could, and found a candidate with good fundamental potential, I trained them myself many times.

1) You must be on the low end of the totem pole
and/or
2) You must work for a place with at least some level of ethics

I've seen both happen. I've been on the budgeting side of things and I know the conversations that happen. I've seen the numbers and they are very attractive. When your job is to make budget, doing things like what Disney did make sense. The thought probably never crossed the minds at Disney that what they were doing was unethical. When bad press came out they were likely dumbfounded. Afterall, it made really great business sense. Why would they keep X developers for Y money when they could get 1.5X developers for 0.75Y money? And local too! And contractors so no worry about benefits and the ability to terminate them any time with no worry or anything. Perfect business sense.

Your comment about outsourcing being the real way to save money is something most business of come to realize is largely false. There is a language barrier and timezone gap that causes major communication problems. There's also an issue of quality of workmanship. Outsourcing firms in IT have gotten a really bad reputation and very rightly so. In my experience, never rely on outsourced people for any heavy lifting. Use them for offhours support and that's it. Ask them to develop anything and your onshore resources will spend double the manhours fixing it.

Since outsourcing can only reliably be used to expand and not to replace, the next route to go is replacing with cheap contractors. This HAS actually been effective assuming you engage the same hiring practice with your contractors that you do with FTEs. i.e. you run them through the interview process, etc. In my experience, such contractors have a largely equal success rate compared to FTEs. Given that, if you ignore ethics, why wouldn't you replace most of your workforce with them? You keep a small core group of FTEs to be the key SMEs and use them to train up any contractors you bring onboard. You pay those FTEs nicely with better than average compensation so they won't leave. That way your key knowledge holders are permanent and anyone doing grunt work is cheap. This makes very good business sense.


Yes, the pool of really talented engineers is somewhat low. But a large number of contractors at places like HCL and TCS are perfectly willing to relocate anywhere at the drop of a hat without any expenses reimbursed. Most are living somewhat lightly here even if they have family; they are used to moving regularly. You can't say that of permanent residents and citizens. Most permanent residents and citizens are NOT willing to relocate even if you pay for it. So the pool of talent to sift through for local recruits? Small. The pool of talent from a contracting company like Wipro? HUGE.

You are confusing the terms outsourcing and offshoring. It depends a great deal upon the type of work you do. Some of the things you mention are true when you get into actual customer support areas -- either tech support operations or to customizations needed for thing like SAP Software. Trying to offshore those functions doesn't work so well. But if you are working at strictly under the hood projects, and you have your initial development blueprint well developed, offshoring or outsourcing both work about as well as trying to staff it internally.

Merkwuerdigliebe wrote: You are confusing the terms outsourcing and offshoring. It depends a great deal upon the type of work you do. Some of the things you mention are true when you get into actual customer support areas -- either tech support operations or to customizations needed for thing like SAP Software. Trying to offshore those functions doesn't work so well. But if you are working at strictly under the hood projects, and you have your initial development blueprint well developed, offshoring or outsourcing both work about as well as trying to staff it internally.

Outsourcing means simply you hire another company to do it for you. You only do that when the work isn't part of your core competency. If you are a software company, you don't outsource software development. It might make sense however to outsource some of your operations like server hosting. Outsourcing makes sense when you have to pay for something that is not part of your core business. Sometimes it makes sense to keep it inhouse even under those circumstances but probably not. I'm not talking about outsourcing.

Offshoring is about cheap labor. Whether FTEs or contractors, offshore simply means offshore. You know, jobs shipped to India, that sort of thing. This is what I was saying doesn't work well for critical projects.

"initial development blueprint well developed"

Waterfall has never worked. The guy who invented the waterfall methodology even said he described it as a development process that could only work in an ideal world, not the real world. Requirements always change and engineers will never get it right on the first try. Communicate is ALWAYS an issue with offshore resources both from a timing and language barrier perspective. Communicating an idea properly is hard enough with local resources, it's compounded greatly when dealing with folks for whom American English is not terribly familiar.

I have never once seen any offshored hands off project do anything other than fail utterly and totally. I have seen projects whose initial development was as small as 20k wind up costing several million to fix because of bad code and miscommunication.

There is only way offshoring works. It works when you establish a major presence overseas and treat the offshore office the same as you do your onshore one. You establish major SMEs PERMANENTLY overseas and makes sure communication and knowledge sharing happens entirely over there. Your communication points between ocerseas and local are done between SMEs and not grunts. It takes a couple years to build up a new base of operations that way but it can be done. That however requires long term planning and major investment. Any short term savings are more than wiped out by investment in a new location. ROI is about 3 years depending on how its done and if you can find good people for the new office quickly.

Wurble wrote:

Merkwuerdigliebe wrote: You are confusing the terms outsourcing and offshoring. It depends a great deal upon the type of work you do. Some of the things you mention are true when you get into actual customer support areas -- either tech support operations or to customizations needed for thing like SAP Software. Trying to offshore those functions doesn't work so well. But if you are working at strictly under the hood projects, and you have your initial development blueprint well developed, offshoring or outsourcing both work about as well as trying to staff it internally.

Outsourcing means simply you hire another company to do it for you. You only do that when the work isn't part of your core competency. If you are a software company, you don't outsource software development. It might make sense however to outsource some of your operations like server hosting. Outsourcing makes sense when you have to pay for something that is not part of your core business. Sometimes it makes sense to keep it inhouse even under those circumstances but probably not. I'm not talking about outsourcing.

Offshoring is about cheap labor. Whether FTEs or contractors, offshore simply means offshore. You know, jobs shipped to India, that sort of thing. This is what I was saying doesn't work well for critical projects.

"initial development blueprint well developed"

Waterfall has never worked. The guy who invented the waterfall methodology even said he described it as a development process that could only work in an ideal world, not the real world. Requirements always change and engineers will never get it right on the first try. Communicate is ALWAYS an issue with offshore resources both from a timing and language barrier perspective. Communicating an idea properly is hard enough with local resources, it's compounded greatly when dealing with folks for whom American English is not terribly familiar.

I have never once seen any offshored hands off project do anything other than fail utterly and totally. I have seen projects whose initial development was as small as 20k wind up costing several million to fix because of bad code and miscommunication.

There is only way offshoring works. It works when you establish a major presence overseas and treat the offshore office the same as you do your onshore one. You establish major SMEs PERMANENTLY overseas and makes sure communication and knowledge sharing happens entirely over there. Your communication points between ocerseas and local are done between SMEs and not grunts. It takes a couple years to build up a new base of operations that way but it can be done. That however requires long term planning and major investment. Any short term savings are more than wiped out by investment in a new location. ROI is about 3 years depending on how its done and if you can find good people for the new office quickly.

Friend, not wanting to argue about it. But your exposure to modern software development appears to be limited. Waterfall Project Management has nothing at all to do with it. An application development blueprint is basically scripting out the entire application -- it's almost equivalent to a movie script with logic structures mapped out like stick figures in a storyboard. User interface screens are almost exactly a storyboard. These and some other aspects are called a development blueprint because it is put together exactly like a architectural blueprint with layers, views, and subsystems. Maps and dictionaries of variables, cross module value passing, error handling structures, blah, blah, blah...

How many complex engineering tasks are completed using in-house, contract, and offshore pieces assembled to a complete product? Lots right? Airplanes are a good example. Your Smartphone is another. How do these projects succeed? They work from detailed engineering schematics assembled into -- project blueprints! So it is with application development blueprints, you can successfully complete development projects using a variety of sources for technical talent. When do application development projects NOT succeed? When they don't have a good set of development blueprints and you have multiple teams each doing their own thang...

You've apparantly seen software development from the resources allocation perspective. If you try to manage a development project like that (which people actually do try to do) it doesn't matter if you use in-house, outsourced, or offshore talent, your potential for project failure is equally high across the board. It doesn't help a project to successfully complete if you work by "programming" in resources and telling the resource that they are responsible for doing, for example, the user interfaces. Another resource is programmed in to do database backends. You allocate all your resources and you get everyone together in a meeting, hand out the project timeline, and then say now "Go!" You'll go to a massive crash and burn!

Merkwuerdigliebe wrote: Friend, not wanting to argue about it. But your exposure to modern software development appears to be limited.

Decades in software development at all levels from grunt, lead, manager, and director. From projects in diverse fields from pharma to finance to eCommerce with companies of different sizes and shapes. Local teams and teams distributed across 3 continents. Teams working strict waterfall, to fake Agile, to strict Scrum. Oh no, I have totally limited experience. There should be a middle finger smiley.

Waterfall Project Management has nothing at all to do with it. An application development blueprint is basically scripting out the entire application -- it's almost equivalent to a movie script with logic structures mapped out like stick figures in a storyboard.

This right here is an example of limited exposure. The reality is, what your asking for is only delivered when the requirements are highly predictable. What you are describing is most definitely waterfall. You are saying that all of your requirements and design are 100% complete before development begins. That's waterfall and that only works when requirements are highly predictable. So you've got your business analysts / product managers / whatever title your company uses writing up requirements. Maybe you have some visual folks transforming them into pixel perfect visual IADs. You have architects taking the functional requirements and coming up with a full technical design and UMLing the whole thing. Once that's all done it's handed over to developers nice and neat. A set of instructions for code monkeys. Right?

Again, that only works in environments where requirements are highly predictable and not subject to change. That's like 1% of all software development projects. It assumes that after you start development the client won't come back to you and say "um, can you add X feature?" or "we changed our mind, we want it to look like Y instead" or really most commonly "since it's taking so long, add in Z too". There's always saying "no" to clients, but many times the new ask is something that really has to be done.

This also assumes that your architects are perfect. Design flaws happen. Bugs are found in code that are the result of design oversights. Sometimes requirements are written up that are discovered to be impossible with the technology being used. This is especially true of highly integrated systems. Let's say for example that you're working on a shipment tracking screen for a customer. The visual requirements show shipping tracking numbers on the summary screen with all orders. It goes into development and when the engineers are trying to get the data they find out the order service they are interfacing with can't give tracking numbers (for whatever reason). Or maybe it they can't get a tracking number in the context they are in; like they need the order number first and changing the code to match the visual requirement would result in hammering the order service really bad. So now your entire visual design has to change.

You've apparantly seen software development from the resources allocation perspective. If you try to manage a development project like that (which people actually do try to do) it doesn't matter if you use in-house, outsourced, or offshore talent, your potential for project failure is equally high across the board. It doesn't help a project to successfully complete if you work by "programming" in resources and telling the resource that they are responsible for doing, for example, the user interfaces. Another resource is programmed in to do database backends. You allocate all your resources and you get everyone together in a meeting, hand out the project timeline, and then say now "Go!" You'll go to a massive crash and burn!

I've seen software development from all levels. I've seen the mistakes management makes from all levels and all perspectives except executive. I admittedly have never been at the executive level. You apparently have never been at a high enough level though to understand the mentality and concerns at a director level and above. While I haven't been an executive or VP, I report directly to them and thus do know what their concerns are. Doing your job well and knowing what your responsibilities are means knowing your boss's responsibilities and concerns.

What you are failing to see is what the concerns are at the higher levels, the levels that are responsible deciding things like whether or not to do a major layoff, when to outsource, when to offshore, when to replace with cheap contractors, etc. Executives and VPs who make those decisions are largely divorced from any ground level view. Most will view engineers as interchangeable cogs. This is incorrect, but it is nonetheless the common way in which executives and VPs view engineers. From that perspective one engineer is as good as any other. And from that perspective, cheap engineers are better.

Knowing this is the view of executives and VPs, it is the rest of management's job to make sure that whatever "cheap" alternative is pursued manages to acquire engineers who are good.

Wurble wrote:

Merkwuerdigliebe wrote: Friend, not wanting to argue about it. But your exposure to modern software development appears to be limited.

Decades in software development at all levels from grunt, lead, manager, and director. From projects in diverse fields from pharma to finance to eCommerce with companies of different sizes and shapes. Local teams and teams distributed across 3 continents. Teams working strict waterfall, to fake Agile, to strict Scrum. Oh no, I have totally limited experience. There should be a middle finger smiley.

Waterfall Project Management has nothing at all to do with it. An application development blueprint is basically scripting out the entire application -- it's almost equivalent to a movie script with logic structures mapped out like stick figures in a storyboard.

This right here is an example of limited exposure. The reality is, what your asking for is only delivered when the requirements are highly predictable. What you are describing is most definitely waterfall. You are saying that all of your requirements and design are 100% complete before development begins. That's waterfall and that only works when requirements are highly predictable. So you've got your business analysts / product managers / whatever title your company uses writing up requirements. Maybe you have some visual folks transforming them into pixel perfect visual IADs. You have architects taking the functional requirements and coming up with a full technical design and UMLing the whole thing. Once that's all done it's handed over to developers nice and neat. A set of instructions for code monkeys. Right?

Again, that only works in environments where requirements are highly predictable and not subject to change. That's like 1% of all software development projects. It assumes that after you start development the client won't come back to you and say "um, can you add X feature?" or "we changed our mind, we want it to look like Y instead" or really most commonly "since it's taking so long, add in Z too". There's always saying "no" to clients, but many times the new ask is something that really has to be done.

This also assumes that your architects are perfect. Design flaws happen. Bugs are found in code that are the result of design oversights. Sometimes requirements are written up that are discovered to be impossible with the technology being used. This is especially true of highly integrated systems. Let's say for example that you're working on a shipment tracking screen for a customer. The visual requirements show shipping tracking numbers on the summary screen with all orders. It goes into development and when the engineers are trying to get the data they find out the order service they are interfacing with can't give tracking numbers (for whatever reason). Or maybe it they can't get a tracking number in the context they are in; like they need the order number first and changing the code to match the visual requirement would result in hammering the order service really bad. So now your entire visual design has to change.

You've apparantly seen software development from the resources allocation perspective. If you try to manage a development project like that (which people actually do try to do) it doesn't matter if you use in-house, outsourced, or offshore talent, your potential for project failure is equally high across the board. It doesn't help a project to successfully complete if you work by "programming" in resources and telling the resource that they are responsible for doing, for example, the user interfaces. Another resource is programmed in to do database backends. You allocate all your resources and you get everyone together in a meeting, hand out the project timeline, and then say now "Go!" You'll go to a massive crash and burn!

I've seen software development from all levels. I've seen the mistakes management makes from all levels and all perspectives except executive. I admittedly have never been at the executive level. You apparently have never been at a high enough level though to understand the mentality and concerns at a director level and above. While I haven't been an executive or VP, I report directly to them and thus do know what their concerns are. Doing your job well and knowing what your responsibilities are means knowing your boss's responsibilities and concerns.

What you are failing to see is what the concerns are at the higher levels, the levels that are responsible deciding things like whether or not to do a major layoff, when to outsource, when to offshore, when to replace with cheap contractors, etc. Executives and VPs who make those decisions are largely divorced from any ground level view. Most will view engineers as interchangeable cogs. This is incorrect, but it is nonetheless the common way in which executives and VPs view engineers. From that perspective one engineer is as good as any other. And from that perspective, cheap engineers are better.

Knowing this is the view of executives and VPs, it is the rest of management's job to make sure that whatever "cheap" alternative is pursued manages to acquire engineers who are good.

No middle finger but the wall will do. Career spanning 35 years here. Done it all and retired early (hey thanks IT!) 3 years ago. Final exit from Senior Executive level. Unable to say more than that because certain projects I worked on never existed (cough cough).

So according to you IT is the only engineering discipline that has to deal with changing requirements? Wow, how did we ever get any applications delivered! Could be different perspectives, don't know. The stuff I worked on were integrated datacenter/application solutions. Picture a semi trailer that you roll up to a facility, plug a couple of wires into it, and hit HPC nirvana in under 2-hours. These were patterned more like engineering projects rather than IT projects.

What any of this has to do with Cruz -- shrug. I think we hijacked OP's thread.

Really, an SES?

begemot wrote:Really, an SES?

You may well think that. I couldn't possibly comment.

So the only takeaway I get from this thread is that Cruz is going for the IT field vote? The rest is just a pissing contest on who has more experience in the IT field.

whitey wrote:So the only takeaway I get from this thread is that Cruz is going for the IT field vote? The rest is just a pissing contest on who has more experience in the IT field.

Pretty much. I won.

[youtu_be]http://youtu.be/e3hB3iOQKjY[/youtu_be]

Merkwuerdigliebe wrote:

whitey wrote:So the only takeaway I get from this thread is that Cruz is going for the IT field vote? The rest is just a pissing contest on who has more experience in the IT field.

Pretty much. I won.

I dunno if I would agree with that, the rest of us remembered this was the wrong forum for that argument, and certainly the rong thread.

hoosier8 wrote:[youtu_be]http://youtu.be/e3hB3iOQKjY[/youtu_be]

Love it!