Cargo cult programming (2020)
blog.bitgloss.ro
blog.bitgloss.ro
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.
I mean, they're great when applied correctly, but someone looking specifically to apply design patterns will often end up CCPing.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
They're not used as an hand wavy answer - "oh it's a best practice and that's that."
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/
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.
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.
"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.
Cargo Cult Computer Programming: CCCP.
You're welcome.
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.
> 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...