Short disclosure, I work as a Software Developer in the US, and often have to keep my negative opinions about the tech industry to myself. I often post podcasts and articles critical of the tech industry here in order to vent and, in a way, commiserate over the current state of tech and its negative effects on our environment and the Global/American sociopolitical landscape.
I’m generally reluctant to express these opinions IRL as I’m afraid of burning certain bridges in the tech industry that could one day lead to further employment opportunities. I also don’t want to get into these kinds of discussions except with my closest friends and family, as I could foresee them getting quite heated and lengthy with certain people in my social circles.
Some of these negative opinions include:
- I think that the industries based around cryptocurrencies and other blockchain technologies have always been, and have repeatedly proven themselves to be, nothing more or less than scams run and perpetuated by scam artists.
- I think that the AI industry is particularly harmful to writers, journalists, actors, artists, and others. This is not because AI produces better pieces of work, but rather due to misanthropic viewpoints of particularly toxic and powerful individuals at the top of the tech industry hierarchy pushing AI as the next big thing due to their general misunderstanding or outright dislike of the general public.
- I think that capitalism will ultimately doom the tech industry as it reinforces poor system design that deemphasizes maintenance and maintainability in preference of a move fast and break things mentality that still pervades many parts of tech.
- I think we’ve squeezed as much capital out of advertising as is possible without completely alienating the modern user, and we risk creating strong anti tech sentiments among the general population if we don’t figure out a less intrusive way of monetizing software.
You can agree or disagree with me, but in this thread I’d prefer not to get into arguments over the particular details of why any one of our opinions are wrong or right. Rather, I’d hope you could list what opinions on the tech industry you hold that you feel comfortable expressing here, but are, for whatever reason, reluctant to express in public or at work. I’d also welcome an elaboration of said reason, should you feel comfortable to give it.
I doubt we can completely avoid disagreements, but I’ll humbly ask that we all attempt to keep this as civil as possible. Thanks in advance for all thoughtful responses.
I actually would go further and say that collectively, we are terrible at what we do. Not every individual, but the combination of individuals, teams, management, and business requirements mean that collectively we produce terrible results. If bridges failed at anywhere near the rate that software does, processes would be changed to fix the problem. But bugs, glitches, vulnerabilities etc. are rife in the software industry. And it just gets accepted as normal.
It is possible to do better. We know this, from things like the stuff that sent us to the moon. But we’ve collectively decided not to do better.
Main difference is, a bridge that fails physically breaks, takes months to repair, and risks killing people. Your average CRUD app… maybe a dev loses a couple or hours figuring out how to fix live data for the affected client, bug gets fixed, and everybody goes on with their day.
Remember that we almost all code to make products that will make a company money. There’s just no financial upside to doing better in most cases, so we don’t. The financial consequences of most bugs just aren’t great enough to make the industry care. It’s always about maximizing revenue.
Or thousands of people get stranded at airports as the ticketing system goes down or there is a data breach that exposes millions of people’s private data.
Some companies have been able to implement robust systems that can take major attacks, but that is generally because they are more sensitive to revenue loss when these systems go down.
I’m not sure if you’re agreeing or trying to disprove my previous comment - IMHO, we are saying the exact same thing. As long as those stranded travelers or data breaches cost less than the missed business from not getting the product out in the first place, from a purely financial point of view, it makes no sense to withhold the product’s release.
Let’s be real here, most developers are not working on airport ticketing systems or handling millions of users’ private data, and the cost of those systems failing isn’t nearly as dramatic. Those rigid procedures civil engineers have to follow come from somewhere, and it’s usually not from any individual engineer’s good will, but from regulations and procedures written from the blood of previous failures. If companies really had to feel the cost of data breaches, I’d be willing to wager we’d suddenly see a lot more traction over good development practices.
that’s probably why downtime clauses are a thing in contracts between corporations; it sets a cap at the amount of losses a corporation can suffer and it’s always significantly less than getting slapped by the gov’t if it ever went to court.
I’m just trying to highlight that there is a fuzzier middle ground than a lot of programmers want to admit. Also, a lot of regulations for that middle ground haven’t been written; the only attention to that middle ground have been when done companies have seen failures hit their bottom line.
I’m not saying the middle ground doesn’t exist, but that said middle ground visibly doesn’t cause enough damage to businesses’ bottom line to warrant regulation, leading to companies having zero incentive to “fix” it. It just becomes part of the cost of doing business. I sure as hell won’t blame programmers for business decisions.
I agree with everything you said except for this. Often times, it isn’t the companies that have to bear the costs, but their customers or third parties.
Yup, this is exactly it. There are very few software systems whose failure does not impact people. Sure, it’s rare for it to kill them, but they cause people to lose large amounts of money, valuable time, or sensitive information. That money loss is always, ultimately, paid by end consumers. Even in B2B software, there are human customers of the company that bought/uses the software.
That’s why I don’t work on mission critical stuff.
If my apps fail, some Business Person doesn’t get to move some bits around.
A friend of mine worked in software at NASA. If her apps failed, some astronaut was careening through space 😬
Managers decided that by forcing people to deliver before it’s ready. It’s better for the company to have something that works but with bugs, rather than delaying projects until they are actually ready.
In most fields where people write code, writing code is just about gluing stuff together, and code quality doesn’t matter (simplicity does though).
Game programmers and other serious large app programmers are probably the only ones where it matters a lot how you write the code.
Kind of the opposite actually.
The Business™️ used to make all decisions about what to build and how to build it, shove those requirements down and hope for the best.
Then the industry moved towards Agile development where you put part of the product out and get feedback on it before you build the next part.
There’s a fine art to deciding which bugs to fix win. Most companies I’ve worked with aren’t very good at it to begin with. It’s a special skill to learn and practice
Agile is horrible though. It sounds good in theory but oh my god its so bad.
It’s usually the implementation of Agile that’s bad.
The Manifesto’s organizing principles are quite succinct and don’t include a lot of the things that teams dislike.
We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.