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
Top comments (8)
Counter-argument : A good question for stack overflow is the polar opposite of a good question in general.
Good questions are naive, open questions with not clear answers on topics you are unfamiliar with.
I don't think so for more technical problems.
If you get an error and simply says "doesn't work, how do I make this work?", how can I possibly help you?
In these type of situations, that framework for asking questions will certainly go a long way.
The mark of a great question is that it opens an interesting conversation
What you describe is a very different thing, it's essentially a JIRA ticket.
And the mark of a JIRA ticket is that it's boring and you want to close it as fast as possible.
What I have noticed is that devs are skilled at writing JIRA tickets
and therefore are not skilled at both asking and answering open questions.
Being afraid to ask a question is very very common
Too much pride, too much ego, too much shame
I see multiple communities that have a channel
#no-dumb-questionsAnd at some point you have to wonder: why is it necessary to say that in the first place ?
The issue is that devs and people in general have internalized super high standards of what "smart questions" are
Problem is that if you don't meet the requireemnts, by definition you are kind of dumb. And you don't want to be dumb, do you?
So you stay with your ego and your misery and stay with you unanswered questions, go in the internet, enter a rabbit hole, and do the same mistakes as everyone else.
I think this is a really toxic culture.
The most important questions in life are naive, are when you start, you don't even know how to formulate it properly.
Ask, just ask.
There’s no shame in asking a vague or incomplete question. That’s what questions are for. They’re to learn. So start with what you know to ask, and go from there.
The problem is not dumb questions, the problem who rush to give a quick answewr
I understand the point, but you're missing the context.
The context for that was the error messages. People want their thing to work and in that case they don't want a conversation, they want a fix.
At other times? Sure, we don't need more tickets and sparking a conversation can bring unexpected results.
Happy world programmers day!
I'm not sure I understand what you mean in item 2? Users for sure care about the software they are using!
I see a lot of people doing a lot of unnecessary steps to do something that should be simpler just because no one ever said: "hey, we usually do it this way, can't you change it to help us?"
Some people are just content with it, they use it everyday and probably every now and then curse the developers, but they never raise the issue that this hinders their work.
Yeah it's definitely easier to raise an issue when you understand how to, and that something can be fixed.
Apps like Storygraph are great for getting features and feedback from the user community (by putting that access behind a paywall, it's part of their premium service 😅) but it is a cool app anyway
This is actually a good way to put into words what I was thinking.
Really, understanding and knowing what and if it can be fixed or improved makes the difference.