The problem with Test-Driven Development is that you have to think about what you want the code to do before you write it. And that ruins the surprise.
Another classic rookie mistake many developers make is seeking permission to do things like writing unit tests and refactoring code when it's needed. https://youtu.be/aCxCEHePepc
You night conclude that, if you're on a team of 10, there's a pretty good chance that at least one other developer will be competent. But developers tend to cluster by ability. So some teams "corner the market" while for others its a desert out there.
If you interview 1,000 software developers at random (which is probably about the number I have), you discover that maybe 100 of them are competent, and maybe 10 are actually great.
The 100 who are competent tend to know they're not great, and the 10 who are great often believe they're one of the 100, and the remaining 900 often believe they're one of the 10.
"The private sector is where all the innovation happens", he posted using a protocol developed at CERN built on top of communications technology developed by ARPA, on a device powered by technology created for the US Air Force and NASA in the 1960s.
An important lesson I had to learn early in my career is that analysis and design have diminishing returns. There comes a point when you just have to take the shot and play the ball where it lands. Recognising when you've reached that point is the hard part. I call it "The point of no new information".
Here's my take on generative transformers: they're a one-shot deal. GPT-4 was trained largely on a pre-LLM Web. The 'I' in its 'A.I.' is actual human intelligence and creativity. Later iterations will be trained mostly on the output of earlier iterations. To use @jezhiggins metaphor, the LLM equivalent of Mad Cow Disease is the likely long-term outcome.
Before you delete those temporary debugging print statements from your code*, ask yourself what you put them in there to check, and consider whether that should be an automated test. Then - and this is my favourite part - ask yourself if they could have been automated tests in the first place, and whether the thing you were checking for could have been made more easily accessible (e.g., in its own function).
With everything you do in software development, ask yourself "Why am I doing this?" If the answer is "I don't know", stop doing it. If there really is a good reason, it will present itself in due course.
If you believe the tech industry's over-regulated, I highly recommend spending some time working in ANY OTHER INDUSTRY to get some perspective on that.