Paddy McCarthy but any fool can code. At least if we take the etymology of the word since fools don't have to be dumb. And maybe it's because I'm not an native english speaker I perceive the word differently since I have to look them up and not use them from childhood in my cultural context.

In my culture we have a very famous fool (till eulenspiegel) who is famous for his wit.

But back to the general ability: if we take developers.google.com/blockly I think any fool can drag those blocks and write a program with it.

The quote is an attack towards our own arrogance within our elitism. At least to me the point of the first part is to make us realize that we are the fools, if we don't write readable code. we're not special because we can write code.

It's not directed towards the general ability of a person or their interest.

We can deconstruct this quote on many levels .... the question is why? does it not transport the general meaning of its intention? or are we just sensitive on certain word used based on our own cultural, social or personal perception?

I am way more concerned with the quote 'humans can understand' because that can mean so many things and it needs extra context ... which humans? is it semantic? functional? syntactic? cultural? .... but that doesn't make the quote bad to me, it just means those parts confuse me and leave space for to many religious idioms of how people think humans should read :) ....

I personally understand your reasoning. I just have a different perspective, maybe it resonates with you.

Hey!

Since this is very related to a book I recently read and really love (probably one of the best software-engineering related books I read in the last few years, and I do read a lot): 'A Philosophy of Software Design' by John Ousterhout

All the point of that quote/joke really is that it's much harder to write good code which we - as human - will have to maintain than code that just run.

Designing good code really comes down to managing the code complexity. (The more complex is becomes, the more difficult it becomes to maintain, expand, learn, ...)

Complexity is more apparent to readers than writers. If you write a piece of code and it seems simple to you, but other people think it is complex, then it is complex. When you find yourself in situations like this, it's worth probing the other developers to find out why the code seems complex to them; there are probably some interesting lessons to learn from the disconnect between your opinion and theirs. Your job as a developer is not just to create code that you can work with easily, but to create others can also work with easily.

This is taken from the very beginning of the book: 'The Nature of Complexity' (Chapter 2), and all the next chapters drill down in what creates complexity, how to mitigate it, which red flags let you easily identify complex code (i.e. code which a computer will understand without any problem, but which a human will have trouble working with easily), and so on and so forth. Definitely a recommended reading! (I'd like to write a book review about it in the next few days, as soon as I have some spare time)

Hey Paddy McCarthy, sorry to hear that you didn't like that one. Different people have different opinions, and I'll do my best to find one that you'll like next time 🙂