Interview with Alex Ball

Alex is a technical writer who has worked for over 20 years writing for both hardware and software, and he has spent 13 years of that time working freelance.

Key takeaways

  • It’s worth it to take a risk on a new experience every once in a while.
  • Freelance work is like owning a business, and it’s important to raise your rates as you become more skilled.

How did you find technical writing?

I got into technical writing, kind of just like everyone else, by accident. When I was in university I started off as a French and German major. But I had always been involved in computer science, and my dad completely stumbled into an STC (Society for Technical Communication) meeting that was happening in the building he lived in. He came home from this and he called me saying, “Hey, I stumbled on this meeting. It was really cool. I’ve never heard of technical writing before. I think it’s something you might want to investigate.”

He had also met a guy there and was talking to him and said, “Yeah, this guy seems really interesting. Here’s his contact info. Give him a call.” That guy turned out to own a tech writing consulting company and the rest, as they say, is history. He gave me my first tech writing summer job pretty much on spec, and he is 100% responsible for me getting my start as a tech writer.

Alex then went on to work at a number of different companies writing software and hardware and hardware documentation. Among other jobs, he worked at Midway Arcade Games writing hardware documentation, and he worked at a small software startup documenting their API.

I eventually discovered the cable TV industry as a temp job and spent the next 15 years working mostly in cable tv. And I was mostly bouncing around between companies with some repeat offenders. The first place I worked at was the cable TV’s standards body, called CableLabs. I worked there for close to a year. Then I worked for a small company that provides software for the cable TV industry for about 4 years, and that was probably the longest I’ve worked anywhere other than working for myself.

I then quit that job because of some misogynist remarks made by the new CEO at the time, and I essentially became freelance that day. That was kind of a sink or swim adventure. I was fortunate to have a friend who was planning her maternity leave and said, “Oh, you’re available? Come fill in for me when I go on leave.” So that turned into my first freelance contract.

What made you continue working freelance instead of trying to find another full time job?

I enjoyed working from home, when I was at that previous job. And I discovered I could do more of that as a freelancer. I also really enjoyed not having to deal with the employee related stuff. Working freelance, there was now added logistics of owning a company, but it was really nice to be outside of the culture of whatever company I worked with. I found I got a lot more done as a freelancer, and I had a lot more freedom to say things that I would not necessarily have felt able to say as an employee who might be more invested in the company itself. I like being in the position where you can come in, solve a problem, and then take off.

Is there a specific domain, hardware or software, that you specifically write for?

I’ve written mainly for software with the exception of CableLabs, which is generally hardware. I’ve done considerably more software documentation than hardware documentation in my career. But when I do hardware documentation, it’s generally at a very low level. I documented ages ago a video chip for one of the big graphics manufacturers. And this particular chip was going in cable set top boxes, among other things. And chip documentation is register level stuff.

How do you learn to write for all of these different types of projects?

They’re often not short term projects, because the volume is so large. For that video chip, I don’t even remember how many pages that documentation was, but I’d guess it was over 1,000. So it took us a while. But my approach for different projects is to try and find similarities to other things I’ve done in the past, otherwise, fake it till you make it. I’m a big fan of learning as you go.

Do you tend to work on multiple projects at once, or are you going from one project to the next?

It depends. Right now, it’s multiple. Over the years, it has varied. When I am doing multiple projects, it tends to be with a couple of different clients. With that you have to do some time slicing. Client A might get Tuesdays and Wednesdays. Client B would get Thursdays and Fridays. I try when I can to keep them relatively separated in time, so that I can devote the mental energy to one context at a time.

What lessons have you learned doing freelance, working for yourself?

Two big ones are to push back on the low value clients and also figure out how to periodically raise your rates. It’s very difficult to say no to a potential client, particularly when you don’t have a whole lot going on. But taking a really low value or high maintenance client rarely works out well. One thing I like to do rather than just refuse a client is to try and find someone more suited to their needs. If it’s a project I don’t want to take on, either it’s because it’s not interesting or they can’t afford to pay for me, I try to find someone who can help them out. That way I can at least get a referral. Or if that doesn’t work out, they’ll come back and say, “Ok, now we need you.” And they’re more willing to pay for it after they’ve tried elsewhere.

What advice do you have for new writers getting into technical writing?

What has helped me the most in my career have been completely non IT related and completely non-writing related. I volunteered for 10 years at a volunteer technical rescue agency and learned all kinds of firefighting, emergency medicine, and technical rescue skills there. And I spent a couple of years working as an emergency medical technician in an ambulance, still doing freelance writing on the side. That experience in emergency services completely shifted my experience on work and working with people. I will very happily look at someone at a company, who is jumping up and down, convinced that the world is on fire, and say, “This is not an emergency.” Nobody is going to die if this project doesn’t happen. It was a really nice perspective shift.

I also learned working on the ambulance that the more stressful things got, and the more critical a situation became, the more polite and the more explicit we became. When everybody is under incredible stress, they’re not thinking as clearly as they could be. And they’re susceptible to misinformation and jumping to conclusions. So the more polite and clear you are as things get worse, the more likely the situation will turn out better, I’ve found.

And I’m really glad that I’ve been willing, a number of times, to just take a flier, to just do something and see what happens. I decided to become an EMT on the spot one day. I decided to become freelance when the new CEO at my company turned out to be a terrible human being, and that worked out well. There are a number of decisions in the moment that I’m glad I was willing to take a risk.

Alex goes by Alex Ball on the Write the Docs Slack group. You can find him in the vancouver_bc and docs-as-code channels, among others.