More Than a Developer

You might remember Allen O’Neill from his interview about how he perceives advertising in our Meet the Developer series. And from that interview, you may have inferred that his participation in the CodeProject developer community means that he is also a technical author. Besides contributing to CodeProject, he is a proud contributor to ContentLab, our end-to-end expert content creation service. His start — building computers as a boy. He came back to programming by way of being a musician.

The Person Behind the Keyboard

Tell me about yourself. Where did you grow up, where do you live, where do you work, and what is your role?

I grew up in Dublin, Ireland, but only really grew up in the last 10 years. I’ve worked in Europe, Russia, and the United States. My role at the moment is general factotum and engineer. What I do that puts bread on the table is architecture — R&D and large-scale architecture for companies that are trying to get to scale on the cloud. I’m basically a hired gun. 

What got you interested in your technical career?

I built my first computer at 9 or 10 years old. Then I left that and decided to try to be a rockstar. While working abroad as a starving musician, I remembered I liked computers, and rediscovered that I was really good at [computers]. I learned my first proper programming language from an article in PC Pro (or similar). I told people that I was a programmer, and they believed me, so they paid me, and that’s how it happened. I’ve been doing it for the last 25 years now. Really, at the end of the day, it’s about solving problems, and I like solving problems. I like doing something tangible. I like tweaking processes. What got me interested is that with just a computer, I can still do those things. 

Why did you start writing about your work?

Two things. Number one, I originally learned by reading stuff that other people had written. Not textbooks, but things people just wanted to get out of their heads and put down on paper. In 1997, there were a lot of user groups that you’d hear about from a newsletter printed off someone’s printer. I got one of them, and at the bottom it said, Do you have something you’d like to share about what you’ve done? So I called, and they said, “Sure, you can write something for us, but we can’t pay you.” I said, “I’d like to give back.” So I started writing for printed media. It started with either someone asking me “How do I do X?” or me asking myself “How do I do Y?” Then, I did a brain dump.

When the internet matured, I started writing blogs. Bottom line — Writing came about because I wanted to give back. As I wrote more, it became clear to me that I was able to do it. When CodeProject emerged with features like upvoting content, the point system for engaging with the community, etc., there was a way to actually reward folks who don’t necessarily want to get paid to write — by giving peer recognition. It’s a huge thing, and that drew me into CodeProject. First, I wanted 5,000 points so I could get the star, and it just kept going. My current goal is to go for half a million points, but that’s a ways away. 

What attracted you to writing for ContentLab?

I think the main thing is that the majority of the time, when I see something that is written to promote something technical, it is tremendously transparent that they are either copying something, don’t know what they are talking about, or just putting a spin on it. And it just seems plastic.

When ContentLab came to me and said, “Can you do this?” I got excited, because it is about writing something that gives people value. Not just marketing. 

You want to write something that resonates with engineers, the influencers, the ones who have the ideas who will take them to the people who make the purchase. They are the first line of the influencers, and they need the real information — What problem it will solve, what it will do for them. For me to do that, that lifted things to a new level. Now I’m writing pieces that are helping my peers and helping a business reach their true potential in the market. I think this is something many companies miss out on greatly, because their content is too marketing-heavy, and doesn’t help the person who has to implement it at the end of the day.

What positive changes in your professional or personal life have you seen since you started writing about developing/IT work? 

What I’ve found quite interesting is the interaction that I’ve had with ContentLab clients. The marketing folk I talk to are somewhat technical, but not deeply technical. They seem to be genuinely grateful that they are talking to someone that can really understand what they are talking about and bring it down to a deeper technical level. Having worked at ContentLab, I’ve come to respect marketers and their knowledge of marketing — They just can’t do it in isolation. They need a technical translator. I’ve experienced that as quite a positive thing, to learn to appreciate what marketers do. I think throughout most industries, you tend to focus on what you do. I’ve really benefited from getting to help someone that doesn’t do what I do. I’ve quite enjoyed that. 

What written work are you most proud of?

The work I am most proud of is not necessarily what gets the most readers, but what gets the most downloads. What tickles me is when you accompany an article with something like a file with 10 lines of code. Then you see that people downloaded it because they read the article, understood the article, and were motivated to actually download code to use it. That means that this probably helped them out directly, and is part of a living ecosystem actually doing something. That’s when I’m most proud. 

What technical achievement are you most proud of?

There’s a solution I did a couple of years ago for a client where I was able to synthesize and use material I had read and researched over the years. These were technologies that weren’t necessarily connected. Then, I got a request from a client, and suddenly realized if I pulled all these disparate things I knew in a particular way, it would be magic. My code took a pretty complicated person-to-person workflow and simplified it to a 2-3 minute automated process. It combined a whole load of different moving parts, including the Internet of Things (IoT). It showed me that if you think abstractly enough and outside the box, there is always away to reduce friction. This didn’t take jobs away from people, either. It took work away from people so they were free to do higher-value tasks and expand their business. 

What interests you about client writing projects?

I think the more interesting part is being able to understand what they want, but being able to give the perspective of the end user, [and the] tech person at the same time, and then blend the two together. It can be a challenge, and it takes creativity to get an angle that reveals it as a beautiful flower in a place where it can flourish. How do you show something in its best, authentic light? 

What challenges have you encountered in technical writing that surprised you?

I think the biggest challenge is one most folks don’t think about — It’s communication. That is the biggest challenge you have in technology, too. How do you communicate with the client? How do you get a good feedback loop and move things forward? This is even more important in technical writing. The more you know, the more you assume other people know. So you have to wind things back and take the perspective of someone else’s expertise, and see if it still makes sense. This gets even more tricky in technical writing because you have to balance the level of info you are trying to get across with the level of the reader, and accidentally blocking someone who is trying to step up into your content. [It’s an] upside-down triangle — Tell them what you want to tell them, tell them, then tell them what you told them. 

That’s even more difficult in technical writing. How to make something as simple as possible but no simpler [to paraphrase Einstein].

How did you overcome them?

I’ll  answer with a joke. A tourist stopped an artist on the street and asked, “Excuse me, can you tell me how to get to Carnegie Hall?” 

The artist answered, “Practice.” 

Write and write and write. It’s a craft like anything else. You just have to do it. One of the things we’ve moved away from is trade and apprenticeships. It’s all about observation. Do the grunt work, observe, then do it again and again. And get feedback from readers, editors, etc. 

What words of wisdom would you like to share with other prospective technical authors?

Practice, practice, practice. 

What words of wisdom would you like to share with prospective clients about the content creation process?

The most important thing is to spend time upfront with your technical authors to ensure they fully understand what you are offering and the value of it (the product). If you can get that into the head of the author, you’ve got an edge. Otherwise, they will struggle to grab onto the core value and the core message. 

Also, don’t just talk about their product, but where it fits into the ecosystem. Talking about an ecosystem helps put things into context for the engineer, who can then do a better job in writing the content (and reaching that person in the audience).

Is there anything I didn’t ask you about that you’d like to share with our audience?

The importance of sharing knowledge. If knowledge is siloed, nothing goes forward. Whether it’s done for a client or a community, the most important thing is to share. If you are too shy, write. You can go up in front of an audience without having to show your face. If you are thinking about tech writing, the simplest thing is to just start. 

If you think you don’t have something to write about –– you do. Every single person has something to write about.   

The particular slant I give on something is different than yours. If I type something into a search engine with slightly different words, it gets different results. So, just because something has been written about, it hasn’t [necessarily] been written about and appreciated. 

Just write. 

For the Road

Allen’s inspiration to write is to give back. In fact, even when writing for ContentLab clients, his goal is to help companies reach developers so that they can better understand the solutions companies offer them. While encouraging prospective authors to just write, he reminds them that the only way to become an effective technical writer is to practice and receive feedback. For content customers, he suggests that the most effective way to help developers understand their product is to make sure it is written about in the context of a programming ecosystem.

Send this to a friend