In my specific case, TDD; and unit testing as religion in general. I am sure others can make similar arguments against the other two in the types of work they do. My point here is that every project is different, and that projects that do not use one or any of these techniques are not inherently buggy.
I believe strongly in manual testing and automated integration testing for the type of work I do (when executed by an experienced QA); but I have not seen unit testing save anywhere near the time or effort it requires. I am sure there are types of projects for which unit testing solves more problems than it creates, but I have not worked on that sort of project. In my experience, unit testing stops the type of bugs you wouldn't have had anyway, and doesn't do much to mitigate integration bugs (which are the vast majority of bugs I've seen). I've also seen TDD make developers overly myopic. Passing tests do however make for a conveniently reassuring metric to give to business leaders who don't care to understand what they mean or how software is built.
He/she is not narrowing to a specific type of programmer, or a specific type of programming. I am explaining why I "don't care about correctness".
Forgive me if this article is meant to be read in an academic context; I am not an academic.
I don't have time for distracting meta-work with questionable efficacy. My prime requisite is to deliver actual value, not dubious internal metrics.
One of our jobs as programmers, leads, or architects is to determine, of many strategies to solve a problem, which are (or may be) appropriate for the current context. Testing is done the same way; and parameters for testing are decided by the QA department. Any strategy that claims to be universally applicable (like anything labelled "clean" or "correct" or "best practices") is likely at least partially bullshit. Every problem is different, and every requirement requires special care to ensure what's being done is appropriate for achieving both long and short term goals within time allotted.
It's a given that the business already pushes as hard as they can on deadlines. If I have to cut effective quality assurance, or make compromises on what will and won't be done a maintainable or performance oriented manner to fit in meta-work that really doesn't matter; I'm going to pick a fight.
The development team has a finite bullshit budget, and the business has generally spent our bullshit budget before we get to your correctness bullshit.
The very notion of universal "software correctness" within a system of sufficient complexity is reductive and borderline offensive.
x86 and it's ancestors eating the markets of [iAPX 432, Itanium, i860, i960] has taught a lesson in the value of an install-base in the server and desktop market. Let's see if history repeats itself?
Apple has never seemed to really be into the concept of backward compatibility; but historically the rest of the industry has been.
The web is, at it's heart, a distributed document system with a layer of hacks on top for building applications.
You can create pure documents for the web without any code. Documents are, by nature, easily expressed declaratively; and it's not impossible to build an intuitive interface to express declarative data visually (or hide the data aspect completely in the case of a WYSIWYG interface).
Modern web pages are, in my mind, a sort of document/application hybrid (with few exceptions as of 2020). We have yet to find a better way to express an application than through textual code.
Procedural code is branching and time sequenced; how do you express that in a meaningful way visually? For some reason our imaginations find it easy to understand that the side effects of every line before this one are still around, and we're pretty good at picking up the concept of branching and jumping around the instructions; but I believe that's because the code is essentially a sequenced list of commands (and our brains are good with sequenced lists).
The attempts I've seen at visual programming remove common programming capabilities to fit more neatly within their visual medium; as long as that is the case, I don't see visual programming breaking out of being used strictly in DSLs (domain specific languages), which are often inherently limited.
I don't think a no code future is likely, as long as custom software is in demand; however I can see a future where fewer technician type roles require code. Of course that would require someone to spend a lot of money building a standard visual vocabulary of related tasks, excellent ergonomic interfaces, and extensible GUI systems; the type of things the FOSS world hasn't built much of a community for as far as I am aware.
Are you disillusioned with technology, or with the business of technology?
In my experience, the term "business" is short for "the business of exploitation". Exploitation is ugly, and I've had experiences that can be compared to yours.
Our occupation (if you're doing it right - and few are) is masochistic in nature. You suffer to grow, and you grow to suffer (sometimes quite a bit more) for greater pursuits next time. It's the definition of type 2+ fun (https://www.tetongravity.com/story/adventure/the-three-and-a...). If you did the type of things I do, it would be easy to see our primary job as the application of self-discipline to mitigate emotional and existential pain caused by consistently pushing your limits (past your fatigue plateau); and the creation of new solutions are side effects of the mental blender you are capable of holding yourself in for 8+ hours a day. If you've had family members beg you to quit jobs "for your health", you probably know what I'm talking about.
Knowing (as I do now) how the business works can change the context behind the work. Context can be the difference between being a hero, and being exploited. I like being a hero; I don't like being a victim. I will happily sacrifice of myself to make something that users will love, or something that will change the way things are done; I don't want to bleed to make some dickhead rich.
If you have the money to coast for a while, perhaps it's time to think about building a non-profit. A non-profit would be less likely to attract those looking to exploit. Boil what you want to do down to chunks that you can complete yourself, and make sure it's something you're willing to bleed for.
If I see your name again in a list of resumes someday, I'll put yours on the top.
- 21 year R&D greybeard (37 years old)