I originally published this post about a week ago, on the DaedTech blog.
Apologies for my absence last week from the tech pundit-o-sphere. I was,...
For further actions, you may consider blocking this person and/or reporting abuse
What is a programmer in a professional sense?
Someone that does it as the focus of their job, with a title of "computer scientist" or "software engineer" or "developer"? Is someone in IT that uses the command line to access her routers and write scripts also a programmer? Is an accountant that writes Excel VBA scripts a programmer? Is someone that exclusively uses WYSIWYG web development tools a programmer? Is an author that writes about people who write code a programmer? Is a mathematician that writes pseudocode on paper but never enters it into a computer a programmer?
Or is a programmer simply someone that self-identifies themselves as a programmer, regardless of any actual touching of an electronic system nor writing of any code?
I suppose one could apply any of those definitions. What I was hoping to express is that there's no upside for anyone, in any of those positions, to internalize the message of "you're not a real programmer."
At best, the message would be tautological. If you tell the accountant with her macros and VBA that she's not a real programmer, because if she were, then her job title would be "programmer" and not "accountant," her response would probably be "uh, okay, I suppose you're right, but you probably didn't need to say that out loud." But, whoever is telling her that probably isn't simply a set theory buff that enjoys a little stating of the obvious, but rather someone being snide to her about what she's doing.
In the end, I think the question of "what makes someone a programmer" is an interesting one in a world where a lot of knowledge work will include at least little bits of automation. But I think the question "what makes someone a real programmer" is a much less productive one, because I don't think people using that terminology are looking for definitions as much as they are looking to feel superior to people.
First of all, "Real programmers" in xkcd is a mandatory reference for this topic.
To me is as simple as someone who write programs as a main occupation, to me you can be a programmer even if you don't earn money from it but then you're not a "professional" one.
Q:Is someone in IT that uses the command line to access her routers and write scripts also a programmer?
My A: not to me is a thing of focus, just as update my OS doesn't make me a sysadmin
Q: Is an accountant that writes Excel VBA scripts a programmer?
My A: just as before, if you develope accountaint systems yes, if you use Excel as a tool you are not a programmer just like I'm not an accountant because I manage my personal money.
Q: Is someone that exclusively uses WYSIWYG web development tools a programmer?
My A: Are you making a "program" or designing a website? if the later I would call them a designer.
Q: Is an author that writes about people who write code a programmer?
My A: Nope, s(he) is a writer
Q: Is a mathematician that writes pseudocode on paper but never enters it into a computer a programmer?
My A: Nope, pseudocode is not a computer program just like a blueprint is not a house and an architect is not a civil engineer.
To me one of the main problems with this "real programmer" is that people turns a qualitative thing in a quantitative one. Being programmer is not "better" than other profession, is just a label to describe what you do and can do. I don't call myself a lawyer being an engineer not because an lawyer is more or less that an engineer (maybe lawyer was a bad example, ew, just a joke, not sue me) is because it would be a lie, I don't do that job, and actually would be a felony in most places.
Does your IDE/text editor, make your code not run? probably not, so there is no effect in you being or not a programmer.
To play a friendly devil's advocate...
Sometimes it's good to have a bit of a 'wake up call' part-way through your career and realise that you had a really big blind-spot for a long time.
People won't necessarily tell you what you're missing. They may not be aware or they may not want to demotivate you or put you on the spot.
A big blind-spot for me was time-efficiency. It simply never occurred to me that an algorithm could get exponentially slower if its time-complexity increased disproportionately to its inputs. This actually stung me once, when writing a selector that mapped from a Redux store. So no, this isn't just theory, it can actually affect real-life development!
Still, great post, thanks for sharing!
Thanks for the kind words!
And, I wouldn't dispute anything about what you're saying here. But I feel like it'd be just as effective, or moreso, for someone to come to you and say "hey, computing Fibonacci via recursion is pretty slow -- you should read up on this O-notation thing" as opposed to "real programmers don't use recursion."
I think that latter message has little, if any benefit. It would put most people in a defensive posture, it's an oversimplification, and it's kind of a non sequitur for just about any context in which it arises. In other words, I think you can have that epiphany/wake-up call without the baggage that comes with internalizing someone's judgement.
Personally, I often have such wake-up calls stumbling through things all on my own, absent any external stimulus.
Oh, thank you for adding that Git thing. Now I can look in the mirror again...
Wow, thanks for the kind words! I'm glad if you get something out of the posts.