Programming culture problems — Robin Wils's website

Last modified: Tue, Aug 16, 2022

Table of Contents

It is all in the details

People complain about the smallest things in programming. Ha, you don’t format your code like this, and you don’t use the “cloud”. You must be a bad programmer.

A newspaper with a picture of angry Grampa Simpson who yells at a cloud in the air. The headline of this newspaper is 'OLD MAN YELLS AT CLOUD'.

Figure 1: Image from Episode 13, Season 13 of The Simpsons.

All those small things add up. It becomes annoying. People spread a lot of nonsense about programming. There isn’t just is one right way. People make that stuff up, but you almost never see any proof.

Some things are a bit better as others, but there is no one true way. You are not superior when you use some technology. It is probably good to find the right tool for the job, but the best tool can be something else for someone else.

The perfect programming language

It just has to work

People just want to get a tool that works in the end. Think about the product which you want to make. It might even be good to think about you audience.

You might like a programming language a lot, but remember that it is not the best language for every purpose or everyone. There is no one perfect programming language.


Some languages are indeed faster or easier for some jobs, but that does not mean that everyone likes the syntax of that language. Syntax can make a language more easy to use, so it is something that matters.

What fits your goal?

Which programming languages fit your goals? Compare them, and see what you like. The difficulty to learn the language can be an important factor if you want others to help with a project.

Modern technology

Modern languages are often better, because it is more modern underneath. It is often more performant, because it has learned from others their mistakes.

Not all new technology is better though. A simple webpage can ask for a lot of resources. Those resources might be used for tracking. Many companies see collecting personal data as a good thing. Selling personal data can give insight on what they should improve. It can cost companies a couple of users. Not everyone finds it ethical. Asking users for feedback is likely a better way.

Software quality

There are a few important factors to reach software quality:

The problems


Buzzwords are often words which people use to seem smarter than they are. Many intelligent people are great at explaining complex things in simple understandable ways without many buzzwords. People often don’t even understand the meaning of a buzzword they use. Buzzwords often don’t have a clear meaning. Use a different word instead if you can.

Buzzwords often help with marketing ideas or products. We often use them without realizing it. They often just make things harder to understand. Buzzwords are everywhere. It isn’t specific to the programming culture.

Design patterns

Some basic code structure is helpful to navigate and understand code, but most design patterns are overrated. Experience is way more important. It will teach you when to use which “pattern”.

Same concepts

A lot of design patterns have different names, but are actually the same concept (MVC, MVP, MVA,…). The “MVC-pattern” focuses on the smallest, simplest part of the application. It just shoves everything else that is more important outside the pattern. These “patterns” and “concepts” are a bad joke. They solve the easy problem, and throw the hard problem over the fence.


Design patterns are often overengineered, and hard to understand for people who don’t know the pattern. Implementing and seeking the correct patterns costs energy which is often not worth it. Design patterns are often “hacks”.

If “other people” aren’t disciplined enough to program properly, they will screw things up with or without design flexibility. Improve them or remove them. Patterns can give you benefits, but they are overrated. A factory-pattern for example can be useful, and makes sense in some code.

Design patterns are anti-patterns

It is easy to land into an anti-pattern called “analysis paralysis” if you focus much on design patterns. Analysis paralysis is when a project is stuck in the analysis phase of development. There really are stupid buzzwords for everything.

Design patterns, ironically are often anti-patterns. Like design patterns, only some of them are useful. Most programming knowledge comes from experience. Most “design patterns”, and “principles” are just buzzwords for nerds. A lot of that crap costs more energy and time than what you get out of it.


Most methodologies change after a few years. Much great software has been developed without your “perfect” methodology. I am not saying that it is bad to follow one. It might help some people, but it is not essential, and it isn’t a strict thing. Some people follow some of these things to the details, which can waste more time instead of getting things done. Design patterns are guilty of that same problem. It is the same old buzzwords mess.

Examples of problems with methodologies


Article: Problems with TDD - dalke scientific

The above link is old, but it does contain some interesting problems with TDD. There are things which you can’t solve with TDD alone. Take for example a shopping website with coupons. People can try to add as many coupons, so that they get things free. This is probably something which you don’t want.

It is very possible that you don’t reach a fix for a problem by using TDD. Thinking like a user which tries to cause harm can help to make your program more secure. This is often not needed in TDD. Good manual testing is often a good idea and can prevent such problems. TDD can help, but never trust methodologies completely. They are not perfect.


" The word “agile” has become sloganized; meaningless at best, jingoist at worst. We have large swaths of people doing “flaccid agile,” a half-hearted 7 attempt at following a few select software development practices, poorly. We have scads of vocal agile zealots—as per the definition that a zealot is one who redoubles their effort after they’ve forgotten their aim. "

" And worst of all, agile methods themselves have not been agile. Now there is an irony for you. "

— Andy Hunt, one of the founders of The Agile Manifesto

Article: The Failure of Agile

I don’t agree with his opinion. Following something strict can be great, but following it too strict can be a problem as well. It can cause fights over things which might not really matter. It is good to have discussions, but try to use good reasons in a discussion.

Related article

A programming job

A programming job might not be what it seems. Doing it as a job usually means that you can’t choose what you create. It is hyped up by teachers by saying that you can make a computer do everything you want, but you usually can’t do that in a company. It is an unrealistic promise.

Companies can limit what you can learn and create by using policies. They can force you to use a specific programming language. The project which you have to work on can be something that you aren’t interested in at all.

It can be a fun job, but it depends on more than one factor. Dare to talk about the downsides when you say that it is a fun job. It isn’t uncommon for programmers to work longer hours. It can feel that you are in a “All Work No Play” cycle which is just looking at code.

Working all day on a project which does not interest you likely won’t improve your life quality. I work as a “Test Engineer” and I enjoy it. Work can be different than it seems. It is fun if you work in the right company. The fun thing about test automation is that you see the result soon. In other jobs you often stare at code long before you see it in action. It feels less rewarding.

Good things about programming

Just keep in mind that every culture has some problems or things which you don’t like. This is just an opinion.

What others think

Xah Lee is a pretty well-known GNU Emacs user. His Why Software Suck page contains his opinion about the programming culture.