That is not how programmers work!

What is this about?

While I try to stay away from social media as much as possible, I tend to read posts and articles shared by fellow programmers, just so that I can find new and interesting things.

Usually, it is of mediocre stuff, but occasionally, I get some gems like sxmo, but I'm not going to write about a cool project this time, but instead, I want to rant about posts that are demeaning programmers. It is almost always a harmless and funny post that's taken too seriously by management or higher level people.

So what am I talking about? There is an old meme that keeps cropping around on the internet, it's a picture of a pipe built around a rock, with often with the title They pay me to build pipes, not to move rocks.

What is wrong with this picture? Well, not much if you understand it's just a funny prank. But it can be related to by many professions, including programmers, especially when a legacy program needs maintenance, so this get's circulated in almost every profession.

The reality

I am going to nitpick on just the tech community postings as that's what I work with, but I guess what I am saying here is true almost everywhere.

The image is though provoking, and reminds me of times I left a complex piece of code untouched due to time constraints. Occasionally, my refactor would not get merged as the team didn't have enough time to ensure that the logic was the same due to deadlines.

Sadly, this has happened in all the companies that I have worked for. But in both scenarios, we create technical-debts, which does get addressed when we find time to do things, unlike the technical-debt black hole you read in other articles.

What I do not like is when the image goes from haha, funny! to this is because developers don't do X, Y, and Z, we need to reform how things are done by devs. The thing about software development is that, the way we program changes over time, so the older a project is, the messier the code is.

Another type of complex and messy code you encounter is when it is written by a young graduate, or by a person new to the language or framework. We should be fine with these too, as it is a necessary step to get better later.

How do the programmers work?

When we programmers see a code that we don't understand, it is in our nature to try to make sense of it, and rewrite it to be cleaner and readable. But that doesn't always happen, sometimes a block of code just works, and we would rather not touch it. This is more true when the code in question is a business critical core logic that has been working for many years without any problem.

However, that doesn't stop us from documenting. If a block of code is confusing, we would at least add some comments above it to make sense of it, or add a note to refactor it in the future.

The real reason why a confusing code block is not rewritten is almost always out of fear of the time constraints, and not because refactoring is not in the scope. So if you want to blame someone, the blame should lie on the business that forced the programmers to go against their nature.

An exception to my above statement is when the person working on that code now is unfamiliar with the program, they could be new to the language/framework, or they just took ownership of that program/project.

Once a complex program is understood, and we have found some time to refactor it, we will refactor it. It may not be perfect, but we will try our best.

The picture above was edited by me using GIMP, it took me some time to do it. As I am not an artist, it is not perfect (you can see smudges everywhere on the pipe and the surroundings), but I guess my point is clear, programmers will not do workarounds unless doing things straight way take too long.

What should we do?

Do we really want to work this way? Pushing the deadlines out is becoming a norm. Even with the modern tools and languages, the amount of time we wait for things to build and test functionalities has not changed, in fact, most of the cloud environments just make it slower. As long as we continue to do resume-driven development, this will never end.

These are some things the business can do to fix this behaviour, it's mostly to stop following what other business is doing.

• Hire people for their talent instead of the framework experience.
• Listen to the developers and give them:
  • More time to clean up the technical-debts.
  • More time to optimize existing tools for speed and resource usage.
  • Good work-life balance so they can work happily.
• Listen to the customers (unless the customer is a business, in that case, listen to the developers and convince the business).
• Take more time to create a quality product instead of giving empty and exaggerated promises to the customers.

We have reached a point in the computing where the hardware works at unimaginable efficiency, but the software and tools are getting slower and bloated.

It is time for a change, time for optimizations, time for bug-free software, and it is time for the users to enjoy what the hardware can do for them.

• Let us do true native app development instead of the slow and bloated JavaScript and web wrappers or running them in Virtual machines.
• Let us create more native cross-platform frameworks that work for everyone!
• Let us make software with accessibility in mind for everyone to enjoy.
• Let us make more programs that are not tied to servers so they can be used everywhere!
• Let us make our programs have reproducible builds so we can port and work on them easily.
• Let us make our programs free-software.

What I wrote above would seem like a software utopia, but it is achievable with the current tools, we just need to make them mainstream.