When Cargo-Cult Programming Meets Intellectual-Violence

In software development, it's common to encounter two anti-patterns: cargo-cult programming and intellectual violence, which frequently trigger each other.

Cargo-cult programming involves applying patterns and techniques without understanding why they work, while intellectual violence occurs when people use jargon and literature to silence others in meetings leveraging their conceptual understanding. Both of these anti-patterns can be detrimental to software development organizations if they are not addressed with the right culture and production process.

We are in times when skills matter the most for a software developer. Developers have historically prioritized skill-based learning over conceptual learning. After all, that’s what they write in their resumes to get hired, and that’s what we ask them to do, right?

The second law of software architecture says “Why is more important than how”. Well, there are only two anyway. That’s how important it is! But they apply to software architects.

Under the pressure of delivery, playing catch-up with the rapidly evolving tech ecosystem, verification versus validation, and lack of transfer learning code reviews, leads to cargo-cult programming and no one can blame the motivation, on the contrary, we encourage “working code” over anything and let it go into production verified by some automated tests.

Skill learning is not cargo-cult programming but may lead to that unless organizations address the circumstances and the very nature of such tendencies. Otherwise, it may get addressed with intellectual violence.

To deliver quality production, architects and developers need to work together. The conflict between skill-based and conceptual learning can lead to frustration and intellectual violence, which can derail collaboration between them.

Well, don’t we design career paths so that our senior developers become software architects someday? Should we somehow enforce a reason-first approach to deal with a skill-first attitude?

Not necessarily! As long as we have the right culture and process in place that acknowledges why it happens and how it happens.

Skill-first is a valid, effective, and pragmatic way of learning. Knowing how to implement some technique in detail usually significantly helps to reason about it later. It's important to note that neither skill-based learning nor conceptual learning is inherently better or worse than the other. They complement each other, don’t necessarily co-exist in one individual, and they may and will occur at different times for different people and roles, in different order.

Don’t we ever realize why we are doing many things after years of practice when it meets with newly acquired knowledge?

Software development organizations are like universities. Just like research and teaching go hand in hand in universities for a purpose, our organizations require production and learning for better sustainability.

It’s a huge waste if there is no designed learning while something precious is being created. What’s important is to acknowledge and identify the nature of different types of learning and support the organization with a sound mentoring culture.

Mentoring should involve assessing the nature of different types of learning and supporting the production organization with sound mentoring practices. Mentors need to determine when it's time for conceptual understanding based on requirements, needs, responsibilities, delegation, curiosity, readiness, and other factors. A culture of mentoring can help individuals learn why techniques and patterns work and how to apply them effectively.

To support this mentoring culture, software development organizations should incorporate code reviews and pair programming in addition to other integration and delivery practices to avoid cargo-cult code in production. Moreover, there should be a focus on balancing skill-based and conceptual learning to ensure that developers have a well-rounded understanding of the code they are working on.