2023/09/13 is the 256 day of the year or in other words, Programmer’s Day.

Take this chance to congratulate yourself, your colleagues, or a programmer friend.

Disclaimer: the author take no responsibility for the trip to the nearest dark place your programmer friend might be in.

Programmer or user?

In other years ([2022, 2021]) I’ve talked about things that make you a Programmer, but this time around I enumerated a few things that might show that you might not be a programmer, but (suspense noises) just a user.

Please note that everyone is a user of something, that is not a problem. But if you say you’re a programmer, but all you do is be a user, then you have a TypeError: User is not of type Programmer.

1. You don't read error messages

I’ve worked a lot with digitally illiterate people of many levels and the one thing that stood out was how fast they would click an error message out of view.

Then there I went, did what they were doing, actually read the error message, and magic! solved the problem.

I saw “programmers” who do something similar, choosing to ignore any error messages, trying to run whatever they’re doing again, and, of course, failing.

Sometimes, all it takes is just reading the error messages. Other times, you read, google it, open the first link, and follow the instructions. Presto!

Other times, you have to bang your two neurons a little harder, tracing the steps of the software to pinpoint the exact point of failure, and then facepalm yourself hard enough because it was something so simple.

Finally, a few times you read the error, then backtraced the problem and still you and ChatGPT have no idea how to solve it. So, you read the How do I ask a good question? page from StackOverflow and wherever you usually do a good question so people can easily help you.

2. You’re content with software

The more junior you are the more you probably think: “I can do it better”.

On the other side, the more senior you get, probably the more pissed you get with badly written websites and apps. You also probably appreciate good interactions a lot more.

This is if you’re a programmer, but when you’re a user… You just don’t care.

You might think you can just jump the hoops and loops and all those problems are nothing to get worked over. You’re complacent and only the very worst will make you complain or abandon it.

No matter who you are, we always end up drawing a line where from one point forward we are programmers but the rest we are users. The question is where did you draw yours?

The language? The framework? The meta framework? The libs? Just whatever you’re doing?

Some people might never have thought about actually influencing the things and tools they use every day. You might not have time or skill to actually fix something, but you see something you use and feel like it could be improved with something or you have the same problem over and over… have you ever tried opening an Issue in the project repo?

Maybe more people have the same problem or more people would enjoy the improvements of your idea, someone might jump into implementing that if only they see your Issue. But when you just don’t care enough, then nothing will happen.

3. You’re superstitious (it’s how it was always done)

This one touches the other ones. The superstitious “programmer” (or user) is someone who does things because “it was how it was always done”.

I can argue that you don’t actually know what in the name of binary you’re doing, because you just copy and paste code, change things here and there, and hope it works. I’ve met that kind of “programmer” and nowadays one of its names is ChatGPT.

ChatGPT is a grand example because it doesn't know anything. It just saw enough it can just spill enough bullshit that sometimes it actually makes sense and works.

jQuery still works to this day, but is it the best way of doing things today? While jumping at the newest framework would definitely make you a programmer, it’s not something sustainable.

A programmer has to evaluate both ends and find the one that is the best choice for today and for the foreseeable future, always considering where they are coming from.

In a new project, this is easier, but in a legacy project this might be a rewrite or more likely, adding a new way of doing things where you don’t need to rewrite things already working, but gives you a better tool to migrate crucial parts and create new features.

Cover Photo by ThisisEngineering RAEng on Unsplash