There are a lot of ways of building software, there are many languages you could choose to build it with, many libraries to rely on, many frameworks to leverage, many architectural approaches, many platforms to choose, many paradigms of daily operations to follow.
It takes years to get in-depth experience with just one permutation of these options.
I’ve been programming for over twenty years, only half the time professionally, but that is how long I’ve been building software. I’ve built about twelve applications in my twenty years of development, of varying size and complexity.
This has granted me in-depth experience with three programming languages out of dozens, a few dozen libraries out of thousands, a few architectural principles, two operating systems, three source control systems, two operations paradigms.
I have seen approaches coincide with problems, and I’ve seen approaches coincide with success, but usually only one or two times; from this I can’t actually know if the failures and successes were accidental to approach.
I could have hopped languages and stacks more often, and I have indeed dabbled in many more, but not enough to actually judge their merits. Doing this, I would have cause to be even less certain.
I think this is fairly representative. No matter how long you’ve been working with this, I don’t think a human being exists that have actually tried everything so extensively as to be able to say whether it works, especially so with the fractalline explosion of libraries and frameworks and languages that have emerged the last few years. How could anyone judge which of these is the best, given nobody can have experience with them all?
Still when I go talk to other programmers, I find very strong and confident opinions about what is the best way of building software, of why this-and-that is the superior approach to all others.
Putting aside judgements about whether this is good or bad, and just evaluating the discourse for what it is, here is a fascinating question: Given there isn’t enough human lifetime that this actually can come from experience, where do all these confident opinions about building software actually come from?
Dunning-Kruger may spring to some people’s minds, but let’s quickly dismiss that notion, as the public conception of D-K isn’t actually how it works, and the effect may not even exist.
Do we merely parrot other people’s seemingly confident opinions? This seems insufficient, there still must be a source for these parroted opinions somewhere.
Maybe if you’re a cloud provider or if you’ve developed a project or you’re a consultant selling services, maybe then you have a vested interest in promoting your way of doing it, of promoting using your tools.
Is it all self-promotion? Is this what we’re all parroting?
This could be it, but where does that actually leave programmers, where does that leave the discussion? Is it just a pointless tug-of-war between who can most successfully recruit people to shill their product?
A lot of large software projects fail fairly spectacularly. Many successful projects started experimentally as some guy hacking on something, despite not having armies of seasoned consultants and top of the line architects with all the right certifications.
I think it would be beneficial to start thinking about programming more from personal experience, and less from theoretical models because these theoretical models don’t seem particularly well founded in reality.
It’s funny how many in engineering consider themselves skeptics, but they often extend this skepticism only toward what they already doubted, rarely to what they take for granted (which is where it would actually do good).
What do I know? This is the question, not “what is regarded as true”.
I don’t know how to build software.