I don't know how to build software

Today, my opinion is that software is grown, not built.

You start with a small thing that mostly works, then throw away what isn't good and add what is missing. In this process, you learn more, so it is iterative.

The main reason projects fail is not technological. The real killers are lack of analysis and lack of communication. Both are a lot easyer with 1 enthousiast doing the whole project.

It’s a mistake to think that there is a singular optimum perfect way to build software that will work for all people in all contexts. The reality is that there are many wonderful and different ways to build software that all works for some developers in some contexts. The general lack of understanding of this fundamental truth is what leads to useless flame wars and claims about X being a better way to build software than Y. Figure out what works for you and your team. Experiment with changes to see if that improves your productivity. Keep what works. Repeat. That’s the Way.

> Most of the critics of waterfall haven't actually worked in such a project.

I wouldn't say that's true.

> Most of the critics of either C or javascript haven't actually built anything noteworthy with it.

That's oddly out-of-place gatekeeping. I've built large things in C 25 years ago that didn't get finished or weren't put in production. That's enough to learn about C, at the time.

> Most of the critics of OOP don't have much practical experience with it

I wouldn't say that's true.

I read a collection of thoughts that feels like a combination of imposter syndrome (20 applications in 20 years? yeesh, that's sparse) and blanket characterization through arbitrary gatekeeping. I understand what they are getting at.

This sort of critique about software development practice critique was better covered in "What We Think We Know About Software Development and Why We Believe it’s True."[1] - https://www.youtube.com/watch?v=I0Pt9Lf9JzQ

[1] About 18 months ~ 2yrs ago, all copies of this keynote were scrubbed from the internet as part of Greg Wilson capitalizing on his geek-fame with an Oreilly book and appearances. Recently, there has been an explosion of Greg Wilson videos on youtube. Not sure how long it will last. Similar information is presented in this updated, broad presentation that Greg Wilson put up: https://www.youtube.com/watch?v=HrVtA-ue-x0 and there's a PDF and a dry, stale version of the keynote presentation that I can't find again.

When I first got into Linux it was circumstantial. I was 11 and trying to figure out how to put "free games" (homebrew) on my console and that got me into installing Linux.

Back in those days (20 years ago) we didn't have the rich package managing ecosystems of today or fast internet access. I bought a Linux CD from a local computer store (though I called it Unix, magically the guy who sold it to me knew what I meant).

I remember trying to learn how to install things like the packages or software I wanted and being told if there isn't an .rpm then you have to try "compiling" it.

Naively, my world view was that there was a structured process for everything - the steps for compiling something would be the same for everything, one could simply learn those steps.

In my mind I imagined it was as simple as typing "make" and an install wizard would appear in a terminal.

When it wasn't that, I would go onto IRC channels and naively ask "how do I compile things". People tried to help and I guess they thought I was an adult with the comprehension of a child so people got pretty frustrated.

Makes me laugh to think of how structured I thought the world was; thinking there was a uniform and consistent way to compile software.

Even as I sit here with experience as a software engineer, compiling someone's random github project can be mind bending - especially with some of the objectively simpler yet also more complicated methods of producing binaries from within docker containers tailored to compilation.

Coding is not building software. Programmers program. If you want to build software, you don't have to code. Just get the source.

     >$  ./configure
     >$  make
     >$  sudo make install #not war!

And that is how you build software. Let's stop confusing people by stealing words and trying to make them mean something else.

I encounter people in this industry all the time who so confidently assert their way is best. This manifests itself in code reviews that insist on their way.

I have a mind to forward this article to them when I encounter them, but I don't think it would be useful and probably would be counterproductive. They would just be dismissive or offended.

I'm glad someone has written this down. I've often felt this way.

But also I've met and read some truly brilliant programmers and can't help but think they might know more than me.

None of us do, but we're stubborn enough to try.