Cargo cult programming (2020)(blog.bitgloss.ro)
blog.bitgloss.ro
Cargo cult programming (2020)
https://blog.bitgloss.ro/2020/08/cargo-cult-programming/
49 comments
Agreed. According to the article, if I didn't write a factory class with the knowledge that it was described in the GoF book, then I'm cargo culting, regardless of whether I understand its value as a creational pattern or not. If I also wrote that class using TDD and have never read Kent Beck or Bob C. Martin, then I'm also cargo culting.
You can learn better programming by literally everything — just like you can learn worse programming by literally everything.
Maybe it isn't the case that books work better in making people better programmers, maybe it is the case that those who are more dedicated to learning programming properly, tend to be the same people who grab programming books.
Maybe it isn't the case that books work better in making people better programmers, maybe it is the case that those who are more dedicated to learning programming properly, tend to be the same people who grab programming books.
Book vs Blog is an arbitrary distinction. There are low quality books and extremely high quality blogs, and they both target different readers (blog often serves as an introduction to a subject).
What's funny in tech is corporate cargo culting. You'll see it quite often. Things like "we're a tech company" but there's no distinction between Software Engineering and IT. Or they still see both as a cost center.
Even better, "we're like Google" except they give you a blank stare where you ask about the 20% time, free food, compensation or where they hire from. Turns out it's all bootcamp/local wages no stock, no 20% time. But hey, they have beanbag chairs!
What's funny in tech is corporate cargo culting. You'll see it quite often. Things like "we're a tech company" but there's no distinction between Software Engineering and IT. Or they still see both as a cost center.
Even better, "we're like Google" except they give you a blank stare where you ask about the 20% time, free food, compensation or where they hire from. Turns out it's all bootcamp/local wages no stock, no 20% time. But hey, they have beanbag chairs!
Exactly. You can just as easily learn cargo cult programming from a book. Design Patterns anyone?
I mean, they're great when applied correctly, but someone looking specifically to apply design patterns will often end up CCPing.
I mean, they're great when applied correctly, but someone looking specifically to apply design patterns will often end up CCPing.
My attention span for books is very small i learn better from Blogs, articles and small videos. I have finished very few technical books yet i have learnt a ton of languages only by looking at blogs and docs.
Cargo culting is basically doing something you don't understand, hoping that it'll accomplish your goals.
You can see this heavily in the Clojure community, at least in the hn/reddit/slack circles. It gets annoying seeing others think they have some kind of superpower because they use Clojure. I blame Rich Hickey videos since they are heavily in the style of a good salesman.
You can see this heavily in the Clojure community, at least in the hn/reddit/slack circles. It gets annoying seeing others think they have some kind of superpower because they use Clojure. I blame Rich Hickey videos since they are heavily in the style of a good salesman.
Its a culture clash.
The Java people have the ISO9000 engineers who are extremely proud of their documented and approved 175 page procedure explaining every detailed step of how its an enormous amount of extra work but technically possible to remove replace and reinstall a 400 Hz power converter.
The Clojure people have the simplicate and add lightness aerospace engineer people who proudly re-engineered the plane's electrical system to not require a 400 Hz power converter anymore, resulting in a lighter, faster, cheaper, more reliable, simpler aircraft. Follow the money... can't sell replacement parts if the plane doesn't use them, so you can guess what corporate thinks of "simplicate and add lightness" designs. Much like in software there's an expanding gap between software people try to sell you vs software you paid to develop for yourself.
The cognitive load on the dev is higher, but its technically possible to write lispy functional style programs in Java if you follow rules about versions and if you drag all the other required complexity of Java into it ... its just simpler to write in Clojure.
The Java people have the ISO9000 engineers who are extremely proud of their documented and approved 175 page procedure explaining every detailed step of how its an enormous amount of extra work but technically possible to remove replace and reinstall a 400 Hz power converter.
The Clojure people have the simplicate and add lightness aerospace engineer people who proudly re-engineered the plane's electrical system to not require a 400 Hz power converter anymore, resulting in a lighter, faster, cheaper, more reliable, simpler aircraft. Follow the money... can't sell replacement parts if the plane doesn't use them, so you can guess what corporate thinks of "simplicate and add lightness" designs. Much like in software there's an expanding gap between software people try to sell you vs software you paid to develop for yourself.
The cognitive load on the dev is higher, but its technically possible to write lispy functional style programs in Java if you follow rules about versions and if you drag all the other required complexity of Java into it ... its just simpler to write in Clojure.
I'll try to empathize with the original author by providing an example "from real life" or from my life anyway LOL.
Blog posts are too small to provide a lot of information. So in 2021 if you're programming a STM32 you're probably doing something complicated so if its license compatible blah blah etc you're probably/possibly pulling in the whole MBED OS along with include rtos.h and doing everything in separate threads etc.
Which is good for real world projects that are complex enough to benefit from a full featured RTOS.
But its cargo culting if you're literally blinking a LED for a kids toy or similar level of complexity.
The world is full of microcontrollers that do little more than act as timers or do protocol conversion. If you implement a car transmission microcontroller that needs to convert a quadrature motion input to a single canbus thing, if you do it as a raspi with full Debian linux including GUI and 5 layers of middlewear you have seemingly infinite security surface and reliability surface and will never be able to prove its unhackable or even reliable. But if you do a quadrature encoder and canbus interface in, I donno, 50 or so lines of commented C that handle various error conditions and sensor failure conditions, its going to be very easy to prove it works reliably and very difficult if not impossible to hack as one of the 375 microprocessors supposedly installed in every new car. On the other hand the GUI and 5 layers of middlewear might unfortunately be the best way to implement the stereotypically hypercomplicated GUI that new car buyers have come to expect/dread.
Blog posts are too small to provide a lot of information. So in 2021 if you're programming a STM32 you're probably doing something complicated so if its license compatible blah blah etc you're probably/possibly pulling in the whole MBED OS along with include rtos.h and doing everything in separate threads etc.
Which is good for real world projects that are complex enough to benefit from a full featured RTOS.
But its cargo culting if you're literally blinking a LED for a kids toy or similar level of complexity.
The world is full of microcontrollers that do little more than act as timers or do protocol conversion. If you implement a car transmission microcontroller that needs to convert a quadrature motion input to a single canbus thing, if you do it as a raspi with full Debian linux including GUI and 5 layers of middlewear you have seemingly infinite security surface and reliability surface and will never be able to prove its unhackable or even reliable. But if you do a quadrature encoder and canbus interface in, I donno, 50 or so lines of commented C that handle various error conditions and sensor failure conditions, its going to be very easy to prove it works reliably and very difficult if not impossible to hack as one of the 375 microprocessors supposedly installed in every new car. On the other hand the GUI and 5 layers of middlewear might unfortunately be the best way to implement the stereotypically hypercomplicated GUI that new car buyers have come to expect/dread.
Asserting for no reason but unvarnished elitism that books are the only valid form of knowledge transfer, while also accusing people of blindly following advice they don't understand, is *chef's kiss*.
I'm not sure that this author knows what "Cargo culting" is. It does not mean being unable to explain in detail every motivating factor of every piece of a complex system. It means including structures that aren't necessary because you don't know if they're necessary or not.
"cargo cult programming" is entirely contained within the concept of "Deep Magic". There always comes a time when you must use a system that you don't fully understand, and so you rely on the understanding of others to figure out what to do.
That's how expertise is supposed to work, it's a good thing. If everybody could fully understand every concept at all levels of complexity, nobody would need to specialize. Applying expertise incorrectly is a bad thing, but for the most part not that harmful.
I'm not sure that this author knows what "Cargo culting" is. It does not mean being unable to explain in detail every motivating factor of every piece of a complex system. It means including structures that aren't necessary because you don't know if they're necessary or not.
"cargo cult programming" is entirely contained within the concept of "Deep Magic". There always comes a time when you must use a system that you don't fully understand, and so you rely on the understanding of others to figure out what to do.
That's how expertise is supposed to work, it's a good thing. If everybody could fully understand every concept at all levels of complexity, nobody would need to specialize. Applying expertise incorrectly is a bad thing, but for the most part not that harmful.
I guess I do a lot of cargo cult programming by the metrics in the article: if someone approaches me and demands a detailed explanation of the design principles involved in some minor function I wrote months ago, plus a list of the programming books I consulted (printed books -- no online resources, please!), I will probably score poorly in "eloquence" since I'll just be standing there slack-jawed and bewildered.
Who remembers their sources anyway? Once you learn a concept or a principle, the source of that knowledge fades away pretty fast while the concept remains.
Though if you do copy some code blindly from Stackoverflow, it might be a good idea to include a comment linking to the answer you got it from.
I tend to use my commit messages for things like this.
The advantage of having it in a comment vs in a commit message is that the source is immediately available to another developer browsing the code. Otherwise they will have to use git blame (or equivalent) to see why you did it that way.
The advantage of having it in a commit message vs a comment is that there's no chance of the comment just hanging around once it inevitably becomes irrelevant. Once it's irrelevant it's anti-productive to leave it in. Since there is no direct link between a comment and the code it applies to (it could be at the top of the function or class, for example), it's also really easy to forget removing it once it is no longer relevant.
Commits are forever, comments could be deleted by someone 'cleaning up'.
I started keeping a list. Each time I discover a game changing concept I add it to my resource list on my personal website. After doing this I found having such a list invaluable to both myself and others.
Getting a bit off topic but I definitely have some strong associations between concepts and the time & place or people I learned them from.
For some concepts, yes. Radical new approaches to things that give you an "Aha!" moment will be memorable.
But often you synthesize ideas too. You take your body of knowledge and produce a good idea from it. Some concepts are "obvious" when you've learned other, related concepts.
In those cases you wouldn't have an external source. After years on the job, you should have a lot of things like that. They may not be original ideas, people have come up with the same ideas before, but nobody told them to you.
But often you synthesize ideas too. You take your body of knowledge and produce a good idea from it. Some concepts are "obvious" when you've learned other, related concepts.
In those cases you wouldn't have an external source. After years on the job, you should have a lot of things like that. They may not be original ideas, people have come up with the same ideas before, but nobody told them to you.
I have this only for concepts on radically different topics.
If it's something about history, I probably learned it from Revolutions, because I don't read a lot of history otherwise.
If it's about cryptography, I probably learned it from The Code Book, because I don't read a lot about cryptography otherwise.
If it's about language features in Python, heck if I know where I got it from, I watch, read, hear about, and find new stuff about python all the time, it's my job.
If it's something about history, I probably learned it from Revolutions, because I don't read a lot of history otherwise.
If it's about cryptography, I probably learned it from The Code Book, because I don't read a lot about cryptography otherwise.
If it's about language features in Python, heck if I know where I got it from, I watch, read, hear about, and find new stuff about python all the time, it's my job.
> What you need to hear is books and good authors (e.g. Kent Beck, Robert C. Martin, Martin Fowler, Michael Feathers and many more).
A former coworker is obsessed with some of these authors, particularly with the concept of clean architecture.
It doesn't seem that bad until you read the Java-looking Python monstrosities he writes.
A former coworker is obsessed with some of these authors, particularly with the concept of clean architecture.
It doesn't seem that bad until you read the Java-looking Python monstrosities he writes.
Yeah, dogmatically following the teachings of one of these "prophets" (e.g. Uncle Bob's "Clean Code" bible) can also be a cult. And if you don't really understand why you're doing it, it's some kind of cargo cult too...
Plus some of these authorities, while well versed in some topics, are not reliable in others. For example, Uncle Bob is a minefield -- knowledgeable in some topics, but also very stubborn and tends to preach about topics he knows little about, like functional programming (preach against in this particular case, with a heavy dose of strawmanning).
Not enough evidence or reasoning to make an interesting argument. "Doing something everyone else is doing only because everyone else is doing it is bad" is obvious already. This article leaves a lot to be desired..
Cargo cult programming, as defined in the Wikipedia article referenced in the blog[1], is bad.
The blog post asserts ways to identify cargo cult programming but, unfortunately, they are probably even worse. Forcing code authors to eloquently describe code that they may have written long ago, then judging the code based on that eloquence, strikes me as a cargo cult method all by itself.
[1] https://en.wikipedia.org/wiki/Cargo_cult_programming
The blog post asserts ways to identify cargo cult programming but, unfortunately, they are probably even worse. Forcing code authors to eloquently describe code that they may have written long ago, then judging the code based on that eloquence, strikes me as a cargo cult method all by itself.
[1] https://en.wikipedia.org/wiki/Cargo_cult_programming
Other comments are going off on this article because it would require our poor senior programmer to understand in detail every piece of the code. Of course, they have a point.... However, as a test of CCP it is not that bad. But I would restrict the question to asking about a piece of the code where they have done something in the not to distant past.
The more questionable statement in this post is that the ideas should come from reputable authors. This by itself is not at all enough to avoid CCP. It is quite possible to take the ideas of these authors, interpret them in the most clumsy way possible and go do some CCP with them. One can do TTD by attempting to test every indivdual class separately and mocking everything else. The problem with this is that one is testing implementation details that are very much subject to change and also that testing single methods often ends up very trivial things like 'is the standard library of my language still capable of adding an element to a container'. A more skillful way of doing TDD tests some number of classes together and test for properties of the code that perhaps the client could recognize as something they value.
Actually, avoiding CCP requires sound judgement. If one does not have that but is convinced that one is a smart programmer then one is not going to learn anything and nothing that anyone says can help. Reading good authors might actually not help either..... or perhaps it sometimes does.... YMMV.
The more questionable statement in this post is that the ideas should come from reputable authors. This by itself is not at all enough to avoid CCP. It is quite possible to take the ideas of these authors, interpret them in the most clumsy way possible and go do some CCP with them. One can do TTD by attempting to test every indivdual class separately and mocking everything else. The problem with this is that one is testing implementation details that are very much subject to change and also that testing single methods often ends up very trivial things like 'is the standard library of my language still capable of adding an element to a container'. A more skillful way of doing TDD tests some number of classes together and test for properties of the code that perhaps the client could recognize as something they value.
Actually, avoiding CCP requires sound judgement. If one does not have that but is convinced that one is a smart programmer then one is not going to learn anything and nothing that anyone says can help. Reading good authors might actually not help either..... or perhaps it sometimes does.... YMMV.
Best practices are explainable, a senior programmer can surely explain what exactly makes a best practice as such.
They're not used as an hand wavy answer - "oh it's a best practice and that's that."
They're not used as an hand wavy answer - "oh it's a best practice and that's that."
If every programmer doesn't understand the nuance of any random section of code in their product they are bad...
For me the article reads like something between a bunch of truisms and outright straw man bashing.
I half expected the author to tell me that waterfall is bad[0].
Last but not least, the interesting programs quite often aren't written with perfect knowledge of the domain. You often have to push forward even though the uncertainty is there. "Why did you write it this way?" "Because I didn't know how to write it and I needed to write something to move forward." "Ah-ha! Cargo cult! I am so smart!"
[0] Waterfall is also a bit of a straw man https://ultimatesdlc.com/father-waterfall/
I half expected the author to tell me that waterfall is bad[0].
Last but not least, the interesting programs quite often aren't written with perfect knowledge of the domain. You often have to push forward even though the uncertainty is there. "Why did you write it this way?" "Because I didn't know how to write it and I needed to write something to move forward." "Ah-ha! Cargo cult! I am so smart!"
[0] Waterfall is also a bit of a straw man https://ultimatesdlc.com/father-waterfall/
> Everything is explainable in layman’s terms… if you understand what you explain, that is
IMO that's at the heart. Popper, Feynman, Evans and on and on.
But it's unsexy, it makes the experts look like you and me. Talking greek makes them appear enlightened, however, and will save them questions. What shall the economically thinking expert do, one might ask. So beware of them.
And to the laypersons: Demand comprehensible conversations bare technical jargon but in your domain language. Don't trust in and pay for what you don't truely understand.
The root is, where the money comes from.
IMO that's at the heart. Popper, Feynman, Evans and on and on.
But it's unsexy, it makes the experts look like you and me. Talking greek makes them appear enlightened, however, and will save them questions. What shall the economically thinking expert do, one might ask. So beware of them.
And to the laypersons: Demand comprehensible conversations bare technical jargon but in your domain language. Don't trust in and pay for what you don't truely understand.
The root is, where the money comes from.
... that's it? That's the article?
Books are not inherently superior, especially given how easy it is to self publish. And a surprisingly small number of them (in my experience) are actually both up to date and deal with architecture in any meaningful way.
I'm all for making sure you understand what you build, which seems to be what the article is trying to say, but never discount blogs from reputable sources. They tend to be on the bleeding edge of software architecture, and under the right circumstances offer an edge over published sources.
Books are not inherently superior, especially given how easy it is to self publish. And a surprisingly small number of them (in my experience) are actually both up to date and deal with architecture in any meaningful way.
I'm all for making sure you understand what you build, which seems to be what the article is trying to say, but never discount blogs from reputable sources. They tend to be on the bleeding edge of software architecture, and under the right circumstances offer an edge over published sources.
Legit Critique:
"This is exactly where cargo cult programming (CCP henceforth – it would have been funny to have another C in there, before the P) stems from."
Cargo Cult Computer Programming CCCP is the joke that's been around longer than I've been programming and I started in '81
You know you're old when there's middle aged people born after the USSR no longer existed. Like when I was young adult in the Army (although not for much longer), the USSR was not a LARP or nostalgia, it was like, an active thing.
"This is exactly where cargo cult programming (CCP henceforth – it would have been funny to have another C in there, before the P) stems from."
Cargo Cult Computer Programming CCCP is the joke that's been around longer than I've been programming and I started in '81
You know you're old when there's middle aged people born after the USSR no longer existed. Like when I was young adult in the Army (although not for much longer), the USSR was not a LARP or nostalgia, it was like, an active thing.
Adopting REST terminology when discussing JSON APIs was and remains the ultimate cargo cult in web development.
FizzBuzz Enterprise Edition comes to mind: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
The overall idea of learning from reliable sources over the evergrowing heap of clickbait is sound. However that shouldn't mean avoiding blogs - they can still be excellent sources of correct deep technical information.
[deleted]
>> (CCP henceforth – it would have been funny to have another C in there, before the P)
Cargo Cult Computer Programming: CCCP.
You're welcome.
Cargo Cult Computer Programming: CCCP.
You're welcome.
Its the antithesis to "design patterns", "best practices" and whatever other buzzword comes along.
"Ask them to explain in detail, a small part of the product. Yes! In detail! ... Everything is explainable in layman’s terms…" - so now you dependent on the teaching/explaining talent rather than code.
It's more accurate to say you depend on the teaching/explaining talent in addition to code talent. Why is that a problem?
I've never heard anything as helpful for learning as the Feynman technique: https://fs.blog/2021/02/feynman-learning-technique/
The article's mention of "best practices" rings incredible true. If it's a "best practice" you should be able to easily list a half dozen reasons why. Otherwise you don't really understand what you're talking about.
I've never heard anything as helpful for learning as the Feynman technique: https://fs.blog/2021/02/feynman-learning-technique/
The article's mention of "best practices" rings incredible true. If it's a "best practice" you should be able to easily list a half dozen reasons why. Otherwise you don't really understand what you're talking about.
From the man himself:
> Feynman was a truly great teacher. He prided himself on being able to devise ways to explain even the most profound ideas to beginning students. Once, I said to him, “Dick, explain to me, so that I can understand it, why spin one-half particles obey Fermi-Dirac statistics.” Sizing up his audience perfectly, Feynman said, “I’ll prepare a freshman lecture on it.” But he came back a few days later to say, “I couldn’t do it. I couldn’t reduce it to the freshman level. That means we don’t really understand it.”
https://kottke.org/17/06/if-you-cant-explain-something-in-si...
> Feynman was a truly great teacher. He prided himself on being able to devise ways to explain even the most profound ideas to beginning students. Once, I said to him, “Dick, explain to me, so that I can understand it, why spin one-half particles obey Fermi-Dirac statistics.” Sizing up his audience perfectly, Feynman said, “I’ll prepare a freshman lecture on it.” But he came back a few days later to say, “I couldn’t do it. I couldn’t reduce it to the freshman level. That means we don’t really understand it.”
https://kottke.org/17/06/if-you-cant-explain-something-in-si...
If you go with physicists, it is said that Landau was kind of bad lecturer. Feynman was good, Landau was bad. But one can't say he did't understand what is going on. "Best practices" should be real and achievable. What you are trying to emphasize sounds like a maximalist bullshit
To the extent physics is objective and observable and computer engineering is subjective and ephemeral, I would argue the relative value of skills as a lecturer/practitioner are almost perfectly inverted in the two disciplines.
Forget about CCP (don't confuse it with Chinese Communist Party). Mr. Nicolici just wants you to download his unfinished "Dr. Programming" booklet.
Following this person's advice to not learn from blogs and articles, and instead only learn from books, sounds like cargo culting to me.
The source of the information doesn't matter. What matters is learning new concepts, knowing how to apply them, and understanding the reasons for applying them. You can learn that from anywhere: a book, a blog, a leprechaun, inspiration from above, something written on a cake, etc.
Edit: some of those may be better sources of information than the others, but I think you get my point.