Programming culture problems — Robin Wils's website

Last modified: Sat, Jan 28, 2023

Table of Contents

There is no one right way

People tend to complain about programming languages and techniques. There is no such thing as the best tool. It is more important to have the correct people rather than the best technology. The tool which someone prefers is different for everyone. Just put the effort and work in.

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.

Modern tools and languages are often better optimized, quicker to develop with, and have learned from past mistakes. Although it is good to keep in mind that modern is not always better. There are always multiple options to consider. Rewriting legacy code can be worth the time, but it highly depends on the situation.

A similar issue occurs with programming styles. The formatting of code, and the design patterns someone uses. Experience is way more important. Yes, certain things have more benefits, but trying new things does not hurt. Seek the right people.

Software quality

Software quality comes down to finding the correct people. At the end of the day your job is to make a working product. The following factors are important:

Try to avoid

Avoid complaining about the smallest things. You don’t format your code like this? You don’t use the “cloud”. You must be a bad programmer. Enough! It is common for people to spread nonsense about programming. Often without good arguments. You are not superior because you use a certain technology. Idealism is pathetic.

It is not a miracle that methodologies are filled with nonsense. They are often pushed by people who haven’t written code themselves. What do they know about development? Planning methodologies shouldn’t be treated like a religion! Having a plan and a goal is great. But a plan should be optimized for your team.

Using difficult words can make communication with the team harder. Buzzwords are often used to look smarter. It actually can make people look dumber. They are often used wrong, and misunderstood. Terminology should ideally be clear to everyone in the team. Words do create a personal style, but difficult words should be used in the right context, towards certain people. Buzzwords do have a place in marketing though.

Specific criticisms

Design patterns

A bit of code structure can be helpful to navigate and understand code. But it does not hold a candle against experience. Experience will teach you your own patterns, and which pattern you should use in which situation.

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 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.


Methodologies are never “perfect”. It is not bad to use one, but we should be careful to not make it seem like rules. It are guidelines. Many people see these guidelines as hard rules, and try to follow those rules to the details. It can waste more time instead of getting things done. Design patterns are guilty of that same problem.

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 for 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 too strict can be a problem. 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.

Certain people try to push Scrum to prevent operating in bubbles. Meaning that they want people to be able to do every job. Scrum does not always prevent working in bubbles. More often than not companies have very specific jobs which are not easy to learn for every new person in a team. Certain jobs are only possible by people who have worked in a company for a long time.

Scrum can result in having more meetings rather than doing actual work. Following it by the book is not worth it. Create your own methodology which works for your organization. Experiment, fail and learn.

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. Certain people claim that you can make a computer do everything you want, but you usually can’t do that in a company. Besides that, it is an unrealistic, idealistic 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. You have to work for yourself if you don’t want limitations. This is the case in many jobs.

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, because they want to finish a task. It can feel that you are in a “All Work No Play” cycle. To me programming doesn’t feel that creative. It is rather logic focused.

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. College to me – wasn’t that fun, but Ι did have some important life experiences during. I learned more in highschool. I got lots of freedom there, and it was fun. It depends on the teachers and culture.

Good things about programming

Keep in mind that every culture has 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.