Complexity is the natural consequence of software becoming more efficient, addressing more use cases and avoiding edge cases. It's not problematic intrinsically, it's just hard, because the problem space is hard.
> Ironically, I've found that using weaker tools can help with complexity. It's hard to write a complicated C program because it can't do very much.
Perhaps. The problem space's difficulty can bring some inherent complexity, yes... but I often hear that fact used to justify adding complexity that isn't actually necessary.
Biggest example I've seen: wanting to use Java for a web server where a 10-line node server did wonderfully. Or similarly, wanting to use async/await in Rust when threads are more than sufficient.
Sometimes I think we make our problems unnecessarily complex by chasing efficiency perfection.
Ugh, Java for small, dirt simple microservices is such a pain. They always seem to take too long to start up, use too much memory, and have horrible logs. And the containers are large because of the jvm.
Some complexity is unavoidable when creating software that does complex things—this is a tautology that goes without saying.
Unnecessary complexity is largely caused by software developers who are currently in the middle of the bell curve of experience, who think that programming computers is all about finding the most clever way to solve a problem, usually by utilizing the most advanced language features they've learned about and/or by making systems as generic as possible, as opposed to writing instructions for the computer to operate on data as simply and efficiently as possible.
In my experience, every good software developer goes through an "adolescent" phase where they get caught up in doing things as "cleverly" as possible, completely blind to the unnecessary complexity they're creating in the process. There may be somebody out there who has avoided this phase of learning the craft, but if there is, I haven't met them. Part of me thinks that "getting it out of your system" is an important part of learning to get better at the craft.
Complexity is a fact of life, especially in software. One way out seems to be avoiding premature optimization and resisting attempts to out smart the future … be humble, as Edgar Dijkstra shared in his Turing Lecture in 1972 …
Why does Google make many of their new tools, such as the Speech-to-Text API, so complex? As a user, I simply want to submit an audio file and receive text in return.
However, with Google, you need to provide additional information along with the audio file, such as the encoding type, sample rate, and channel count. This is something that Google should be able to determine on its own or make an educated guess if the information is not available.
Most applications that process audio files allow you to specify these parameters, but they can also usually figure out this information using well-known libraries like ffmpeg.
It seems like Google is currently prioritizing engineering complexity over user simplicity, as if to showcase their technical knowledge (e.g., "Look how much we know about sample rates!") when all the customer really wants is the converted text.
2. Agree with the title and that cleverness should be avoided.
3. Do not agree with the last sentence: “Instead, my lesson has been: write Python code like it was C.”
Python should be written like Python.