How non-programmers can fit into free software

Off the Beat: Bruce Byfield's Blog

Jun 12, 2015 GMT
Bruce Byfield

I have made a living as a non-programmer for twenty years. By that, I mean that I work around programmers without being one myself. Oh, I can manage BASH scripts, and I've dabbled in Python and Perl, but I lack the affinity for code that would make writing it a true satisfaction rather than a necessity or an intellectual exercise. Instead, I have done work that supports programming, such as writing, graphic design, usability, and product management. So, after over seventy contracts and full-time positions, I think I can speak with some experience about how non-programmers become accepted as part of a development team.

This issue is becoming increasingly important as free software becomes more widely used and more professional. However, it is hardly new. I first became aware of the issue when I transitioned from a university English instructor to a technical writer. At the time -- and probably still -- you couldn't hang around technical writers without hearing a steady stream of jokes and complaints about not being treated with respect by technical writers.

Why, my new colleagues were always asking, did programmers not respect technical writers? By that, they meant that programmers should treat technical writers as fellow professionals with their own body of expertise.

I already knew one answer: because everybody learns how to write a basic paragraph, many people under-estimate the skill needed to write a software manual or a how-to. However, I soon realized that the problem was more complicated than the obvious.

You see, technical writers are essentially outsiders coming into an existing clique. A software manual or help file takes time to write, so they started work with nothing to prove their competence. That left the other half of their job title --  the technical part -- to make an impression.

Yet, to my surprise, as many as two-thirds of technical writers dismissed the idea that they needed technical knowledge. With this attitude, they knew little about their topics, and relied entirely programmers for accurate knowledge. Inevitably, the result would be technical documents that were of limited use, and encouraged programmers to dismiss the writers. The technical writers were left to nurse their self-esteem by commiserating with each other about the villainy of programmers, and developing ever-more complicated exercises for their work, such as writing character profiles of their imaginary readers.

At first, I joined in the technical writers' complaints because I wanted to fit in. However, increasingly, the attitude puzzled me. Books about writing are always telling wannabes to write about what they know, and the advice seemed to apply to FAQs as much as short stories.

How, I wonder, could anyone write well without knowing their subject matter? They might not know the subject when they started, but unless they understood it as thoroughly as possible, how could they organize their material? Know what to emphasize? Figure what users needed to know, and in what order?

I could thing of only one answer to these questions. The ability to write was only the basic skill that technical writers brought to their work.  For their work to be actually useful, they needed to learn as much about their subject matter as the deadlines permitted.

Finding the way in
I had approached my first contracts with the sensitive pride that senior writers insisted was appropriate. Predictably, I had been met by the same hostility from programmers that the senior writers had suffered.

However, once I had concluded that I needed to become an expert to do work that met my own standards, a strange thing happened. For the most part, programmers stopped being hostile and became friendly. They started to include me in planning sessions, and to keep their appoints with me needing to track them down or complain to their supervisors. With a little encouragement, they even started consulting me about interface designs and inviting me to test their beta releases. In a matter of weeks, I no longer had to struggle to win the information I needed to do my job. Perhaps just as importantly, I started feeling like a member of the team, although at times a probationary one.

True, some programmers remained condescending. However, I discovered that the next best thing to possessing technical knowledge was showing a determination to gain it. The myth of meritocracy of programmers is biased in half a dozen obvious ways, but it is true enough that many programmers respect someone who is trying to educate themselves.

Besides, asking someone to talk about their work is an implied compliment to anyone. Do it at their convenience and honestly listen, and the average person may go out of their way to help you.

Still, working out the relationship usually required some effort on my part. Most programmers have encountered technical writers who are proudly non-technical, and acquired a justified prejudice against the whole profession. With each new contract, I would have to prove myself all over again.

Near the end of my time as a technical writer, the fact that I was writing articles about free software helped to speed the process -- even when the contract had nothing to do with free software -- but the need to prove myself never disappeared altogether.

I simply had to endure the situation and trust that it would improve. And, in fact, I cannot remember a single situation which didn't improve, although some contracts were more enjoyable than others.

Competence, not self-esteem
In other kinds of work, I faced the same challenge to a lesser degree. I now believe that it is a natural process when becoming a member of any group. Of course, sexism and other biases can complicate or block the process, but no matter what credentials an outsider brings, they are always going to have to show a willingness to accept a group's standards and to prove their competence in matters that the group considers important. To expect otherwise seems naive at best and arrogant at worse.

Naturally, the process of acceptance is full of anxiety for the outsider. However, to blame the group for acting like a group seems a digression from the main purpose. Except as a temporary relief, so, too, is seeking reassurances from others who understand your position, or taking seminars about Impostor Syndrome that assure you that the anxiety is not your fault. After all, you still have to overcome the anxiety.

Instead, if you are a non-programmer, you should have two goals. First, you should show a willingness to learn -- which amounts to a willingness to fit in. This willingness might include the finding of a formal or informal mentor, but if possible, your mentor should command respect from as much of the group as possible. Otherwise, you might complicate your situation by becoming identified with a faction.

Second, you should find ways to prove your competence as soon as possible. Completing some small but useful project as soon as possible will help, or simply exhibiting a number of skills that demonstrate your usefulness. Offering opinions on subjects you have some knowledge of can also help.

What you should not do is complain or hold grudges. Once you are established, you may be able to help other newcomers, but to do that you need to be accepted first. However, if you focus too much on nursing your wounded self-esteem, you might end up in the same situation as the non-technical technical writers, doing your job poorly and making your temporary anxiety permanent.

comments powered by Disqus

Issue 242/2021

Buy this issue as a PDF

Digital Issue: Price $12.99
(incl. VAT)