I am not a programmer.
Spend a few minutes in a place where software users interact with software developers – support forums, dev trackers, face-to-face team meetings – and you’re bound to hear this phrase used (or one of its relatives: I am not [a geek|a developer|a coder|tech-savvy], etc). It’s a statement of fact, and a useful statement at that, since the kind of help offered to a “programmer” is obviously quite different from what’s offered to someone who’s not.
But The Phrase is so much more than that. It’s a strategic move in a social game. Its uses fall into roughly two categories: a cry for empathy, and a deflection of responsibility.
A cry for empathy
I am not a programmer often means Go easy on me. Ask yourself: Why would someone go out of their way to ask for empathy in this way?
Sometimes it’s a way for a n00b to test the waters. Newcomers to a software community don’t always know the community conventions for asking for help. Labeling oneself as “not a programmer” is a gentle way of gauging how others react to new folks.
More frequently, in my experience, I am not a programmer is used by people who have been burned in the past. Maybe the user once asked a question and got an answer that was over her head. Maybe the discussion turned sour when the developers looked down their noses at someone who couldn’t understand a few lines of code. When this happens, I am not a programmer is a shield, a preemptive attempt to guard against the abuse that the asker rightly or wrongly expects to receive.
I wrote a post a while back on how this looks from the developer’s point of view. The gist, so far as this use of The Phrase is concerned, is that developers should be as empathetic as possible in these situations. For one thing, treating people with kindness is just the right thing to do. Beyond that, it’s important to the future of the community to extend a hand to potential contributors.
A deflection of responsibility
The other common use of I am not a programmer is something like: I’m not technical, so don’t even try to get me to crack the hood, which often amounts to I refuse to make an honest attempt. Do it for me.
This phenomenon is, in part, a side effect of the fact that I work with WordPress. WP is unusual among free software projects in that “ease of use” has always been central to its development strategy. The Dashboard, the inline updater, the plugin installer, the five-minute install – all are the result of a conscious effort by WP devs to make the barrier for entry as low as possible. And it’s worked. Without touching so much as a semi-colon of code, you can set up a beautiful and powerful website using WP and the some of the thousands of readily available plugins and themes.
On balance, this is a Very Good Thing. But it also sets up, in the mind of the average user, a certain (incorrect) understanding and set of (unreasonable) expectations about how free software works. In the world of commercial software, the development process is deliberately shrouded from end users. Apple (to take an example) has support forums. But the solutions offered here are always “click here” and “type this”, never “change this code” or “hack this” – if for no other reason than that the software is designed to be un-hack-friendly. In the case of open source software, the source code is available. Thus there is no enforced distinction between those who write the code and those who use it. For users of free software who are accustomed to the proprietary model, it’s hard to get your head around the idea that you can – and should! – be hacking it as part of the troubleshooting process.
Moreover, people who are accustomed to paying for software are used to getting a minimal level of functionality and support in exchange for their license fees. Free software has no license fees. But there persists a sense, in the minds of some users, of “How could you release something that is not 100% working?”. They approach support as a consumer transaction; the idea that troubleshooting could be a collaborative endeavor between users and devs, and that this troubleshooting is part of a larger arc of software development, is totally foreign to them. This seems especially true in the case of WordPress, which is so easy to use that it sets user expectations very high.
It’s perfectly understandable that the move from proprietary to free software would be jarring for users. But it’s not OK for these users to attempt to force their commercial expectations on a non-commercial community. The blurring of the line between user and developer, where users occasionally take a deep breath and crack open the hood, is a crucial part of the way free software is developed. It’s how bugs get fixed, and it’s how new devs emerge from the larger community. I am not a programmer, when it means I refuse to step outside my comfort zone, does active harm to the software project. It’s not that everyone has to become a “programmer” – it’s perfectly fine if you have no desire to get technical. But to deflect the issue altogether – especially with incredulity or anger, as if it’s totally unbelievable that you may be asked to do something technical – is a violation of the free software ethos.
So, next time you see a support request prefaced with “I am not a programmer…”, show a little empathy – but not too much 🙂
Reminds me of the words of advice to Britomart (thinking of Britomart as the user): “Be Bold, Be Bold (but not too bold)”
In general, when a support request comes in and I can see that they’ve already been bold, that’s a good sign that we’ll be able to resolve the issue quickly, and that we’ll both learn something from the process.
It could also be a rejection of programmer’s values; to say, they do not believe hands-on coding is a workable solution to a problem, because it is inscrutable and impractical to all but a few gifted individuals. In that sense, it’s not a cry for help nor a deflection of responsibility. It might just be a statement that, “This solution doesn’t work for me.”
That’s not a very good approach to dealing with WordPress issues.
But it’s not like it’s an entirely unfounded sentiment, either.
——
In any case, I thought this post was going to be about IT workers and hobbyists who shy away from being labeled as a “programmer” because they have a level of technical expertise at which they are comfortable, but it is not at the level of writing entire standalone applications and it does not follow that they are comfortable jumping into something like the WordPress core. The idea is that THESE people socially have to back away from the “senior programmer” types who neither sympathize nor mentor enough to build functional relationships among lesser coders. This is why all of the top-tier coders have their pick of projects, jobs (always top-end) go unfilled for months, and there are tens of thousands of “lesser” coders trying to figure out how to make their skills work in this economy. Management has been convinced by a few infamous books written decades ago that there is no point in hiring a “lesser” coder. It’s hard to believe that leaving critical positions open is a better plan than providing a structured learning environment for those who just need to catch up a bit.
This problem is sort of related to the problem that you mention. The best programmers out there have ways of making all kinds of people on the interactive media food chain, from newbies to WP template developers, feel intimidated and unworthy. The hero worship of startups doesn’t help this problem.
Since the bulk of my day is now spent in support, I see this a lot. 😀 Usually with other plaintive wails for help. Behind it, I think is some fear.
Fear the site will blow up and all the work will be lost. (they need reassurance)
Fear that it will be hard. (learning is hard, right?)
Fear they might learn something. (No, I don’t want to learn today!)
And if they do this, then, there is a sense of empowerment and *freedom* that is downright scary. For if they do learn how to jump into some code, and God Forbid – start understanding it, then there is this cavernous hole of programer/developer where once they have this knowledge they have to be responsible and stuff. GAH! Scary!
And yes – I do also see this from people who were hired by clients to, you know, develop a site for them, so we have to break it to those people that yes – by definition they are now a developer. 😉
So like a good parent we cajole, we educate, we be as nice as we can – but we also be firm in our answers.
I see the second case often on WordPress Stack Exchange. The site is for developers and administrators, and there are some people who see themselves as administrators but not as programmers. They ask for plugins or – worse – for someone writing a complete, working solution.
As a moderator I have to handle these cases, and that’s sometimes very difficult. The golden rule (for me) is to stay calm and polite even when I run out of patience. 🙂
But the problem remains that these questions are boring for other supporters, they tend to drive away contributors.