I agree that if we want more people to train for STEM jobs, we need to focus on jobs in that sector not in education. We already have an education system qualified enough to produce STEM graduates. We just don't have enough quality jobs for those graduates, so many of our best and brightest go into law, medicine, finance, etc. instead of STEM fields.

Take that $240 million, plus another $240 billion, and put it into research. Go to Mars, invent better batteries, create DNA specific medical treatments ... the sky really is the limit. By doing this we won't care about just creating new jobs because we will be creating new industries.

People smart enough to work in STEM are usually smart enough to go where the money is as well.

Government absolutely force unions in the work place. There are plenty of laws which protect union membership. I'm not arguing that those laws are a good or bad thing, just that to ignore the government's role in supporting unions is ridiculous.

Powerful unions are essentially monopolies that the government won't protect society from. If Ford cars become too expensive I can just buy a car from another company. If Ford was the only option, their only incentive to lower prices would be so people don't keep used cars for too long. That is obviously a horrible situation and the government would step in. If the UAW asks for too much money, however, Ford can't turn to another automotive union with more reasonable rates. And going with non-union workers in an industry dominated by a powerful union also has its problems.

There is also a strong correlation between the time where a significant portion of the population became college educated and stagnant wages. Wages grew substantially when the average worker was becoming far more valuable economically then generations past. This was low hanging fruit solved by increased government funding of higher education and a shift in middle class mindsets that college was necessary for a middle class life. Once a tipping point of the number of college educated employees in the workforce, average wage growth started to stagnate again.

Productivity gains which occurred 40-50 years ago were largely because of a more highly educated work force. Productivity gains today are largely because of increased use of capital. Computer systems, robotics, operational improvements, etc. are responsible for that increased productivity over the past few decades. And just like the 50's and 60's saw the rise of the middle class because of college participation, the 80's through today saw the rise of the upper middle class.

The upper middle class is now responsible for the productivity gains we see today so they are the ones who are reaping the benefits (along with the capital holders of course). When a middle class worker becomes more productive today, it is probably because of a CRM system or robotics assembly created by someone in the upper middle class. And the upper middle class wages have not been stagnant by a long shot over the past 20-30 years. The upper middle class hardly even existed before the 80's.

Labor unions aren't solely responsible for workers rights. The government is our primary tool for enabling worker's rights. The government enacted the 40 day work week, overtime laws, etc (with help from unions), and governments are the ones who enforce these laws today. Unions were a tool which was necessary because in the early 1900's the government simply did not take on the responsibility. That is not the case today.

There are plenty of times where drastic actions are necessary because the government is not doing its job well enough. The US Civil War is such an example. We needed a war to prevent secession, but we don't need perpetual war to stop it from occurring regularly. Just like we needed unions to set reasonable work standards after the industrial revolution, but we don't need them perpetually.

Long standing unions almost always become as big of a problem as the robber baron monopolies they were created to fight against. They drive up consumer costs of any service they have a hand in providing; that is if the industries they taint can't just move overseas. They are especially dangerous when they mix with public services, because tax payers are stuck with bills promised by politicians decades ago who knew they would be out of office long before the bills came due.

The first guy said to give the parents a break because parenting is hard. The second guy said "she took the job", obviously implying you shouldn't have kids unless you are prepared to do a good job at that very hard job. Sounds like he was refuting exactly what the first poster said. Be careful about calling people stupid when you can't understand a very simple argument (regardless of whether or not you agree with it).

There are plenty of very tough jobs in this world. My job is a lot more difficult than raising my daughter is (although not a more important job than being a dad). But I can't just shrug and say my job is tough if I fail at work. I took a job where I knew the responsibilities and challenges were significant, both at home and work, so now it is my duty to do well at both.

That said, even the best of kids can make horrible mistakes, so you would need to know quite a bit about the home dynamic before immediately blaming the parents. From personal experience I would say these kids' parents are more than likely bad parents, but it would be idiotic for me to just assume they are. Even good kids can be convinced to do bad things through peer pressure, for instance.

1. You feel Mac hardware fits your needs at your price point better than other options.
2. Your employer bought you a Macbook but you want to use Windows (I was in this situation until a couple months ago).
3. If you are buying a Macbook / Surface / etc. you probably don't care about the extra cost of an OS. If you do care, you probably should be buying cheaper hardware anyway.

The benefit of an AI is generally its superior memory and consistency when compared to a human. Those are things humans cannot be evolved or conditioned to match. We could possibly be improved to match the memory through the use of bionics, but the consistency may never be matched.

The good thing about the memory and consistency is they can both be utilized by humans in hybrid decision systems. That is why the best chess players are humans using computers, and why business intelligence tools are almost always better when they merge computer generated data with human intuition.

Oh that is so cute. You think if taxpayers could be adversely affected by something that they will have a significant voice in the matter. It's just so adorable.

That is not even close to true. Regulation is partly responsible for why there are so few companies laying wires, but lack of regulation is what is holding back more companies from selling services which use those wires.

The United States is almost the only country in the OECD which does not require the owners of broadband physical infrastructure to sell access to independent providers on a regulated wholesale market. This is almost the only reason our broadband speeds are so much worse and our costs are so much higher than other OECD countries. If we treated our broadband line like we do our telephone, electric, and gas lines, there would be plenty of competition. And using dozens of European countries as an example, the quality of our physical infrastructure would not suffer if this changed.

Local governments do enact regulations and fees which make building our physical infrastructure more expensive, but that would be even worse if the local governments didn't exist. Having to deal with hundreds of individual property owners per neighborhood instead of one local government per township would make it near impossible to build our infrastructure. We can at least try to reign in corrupt government.

It may not allow for 3rd party presidential candidates, but the presedency isn't the only elected office in our government. Getting third party candidates into Congress is still incredibly difficult, but I believe is within the realm of possibility. Just think how much of a difference having just 10% of our congressmen as independents would make. No party would likely ever get over 50% majority, and it would also be unlikely that any minority party could block legislation. Good legislation (those that independents would vote for) from both sides could pass.

Well said

So there is no such thing as a complete delivery then?

Well said.

This is indeed a worst case scenario, which unfortunately play out too often. It is most often caused by not having enough developers on the "His side" of the argument. I for instance am a senior level developer who is very involved in the business side of my employer's decisions. This probably comes from my time as a contractor where I have also seen these his side, her side, and the truth arguments play out time and again. A company that does not have enough developer minded people in CTO, VP of Software Development, Director of Application Architecture, etc. positions is going to find themselves in your worst case scenario quite often. Most well run companies I have worked for and contracted for have CS/EE majors with MBAs (or equivalently minded people) in the positions I listed above, so "His Side" in these companies have many of the best arguments from "Her Side" already included.

Technical debt is a necessity in any product. Being aware of this debt and estimating its impact going forward is very much a part of any quality change management process. Martin Fowler has a great blog post describing the relationship between prudent, reckless, deliberate, and inadvertent technical debt that is worth a read. I particularly like his reasoning behind the inadvertent / prudent quadrant.

If you don't take proper care of your technical debt, it will ruin any software product. But properly managing your technical debt is not the same thing as just taking "Her Side" every time she complains about technical debt.

There is rarely just one possible solution for any single bug. Change management processes are still involved even at this level of granularity. One solution may be to disable the feature causing the bug. One may be to provide a work around. One may be to put a quick "band-aid" on the code in question, and one may be to find and fix the root cause. If a bug needs to be fixed by Thursday, there are still options even if your developers can't figure out the root causes by then. Once again you weigh the risk of providing a quick fix now with the risk of providing a better fix after the deadline has past.

Honestly I feel your heart is in the right place, and your level of principles will produce far better products than those who care little for software quality. But your statements really don't reflect those of someone who has ever actually been in charge of large software projects. Either that or you are one who constantly feels things would have been done better if your bosses simply got out of your way. I could very well be wrong, but I doubt it. My guess would be you are a skilled senior level developer who likes to stay on the technical side of things, but that is mostly just a wild guess.

Code is not predestined to do anything. It does what humans have it do, either consciously or accidentally. If I say to release a product (with my bosses' approval), then the software is doing what it is supposed to do, which is go into production.

This is why I don't feel you are speaking from experience. The fact is getting those Christmas sales are probably far more important than your viewpoints on perfection. And sometimes those deadlines are there for a reason. Developers are not tasked with creating some shining example of what perfect code can be, they are tasked with making a return on investment. I have a project right now which is due at the end of April because it really has to be done by the end of April. The scope of the project has changed frequently as planning and development has taken place to ensure this April 30th deadline will be hit. And it will be hit. It will be hit without 80 hour weeks; it will be hit because proper project management techniques were used throughout the project. And part of those proper project management techniques are respecting that the deadline is there for a reason and there are very few requested features that are more important than this deadline.

Honestly, writing code is the least important and easiest job of a developer. We learn how to write code in the first few years of our career; probably in school. A quality software developer's career is spent learning the more important tasks of software engineering. This includes your senior developers knowing what can be done by Thursday. You can hit deadlines without just pretending your code is working. You hit deadlines by understanding the progress of the project and understanding the priority of its features at all times. This isn't some hobby or college assignment. There may be millions of dollars on the line, and thousands of employees or customers waiting.

I have worked in situations where some features were more important than the project's success. In safety critical situations there are times where you would rather have an entire project scrapped than product an un-safe product. Obtaining FDA approval, for instance, is the type of requirement which must be fulfilled. But these situations are rare; in most software development almost all features can have their priority level be put up for review.

These are all very real concerns for real world projects. These are exactly why project management is so important. You often cannot guarantee something will work, which is why you have plan B. The project I mentioned before has many aspects which we cannot guarantee success. As you mentioned, this is usually because of third party software we aren't experience in yet. But we have contingency plans for each of these risks. For one important risk we even have an employee developing the contingency plan just in case because it is that important. This plan B is missing many desired features, but we have enough experience to know it will absolutely work and can be done fairly quickly.

No one will ever guarantee 100% IT project success rates. But project success is not as rare as you make it out to be if things are done properly. Success does not always mean you get 100% of what stakeholders asked for and sometimes it does not even mean hitting a deadline. And I certainly do not mean by sticking to a motto such as "it will be done when it's right."

Success usually just means the stakeholders are happy with the result.