Honest Reflections-That Summer When I Wanted to Become a Technical Writer
I used to be embarrassed to admit that I once wanted to become a technical writer, which definitely says more about me than it does about the field. First of all, “technical writing” is a pretty broad title — if I produce documentation for a San Francisco-based big data company alongside the software team, then I am a technical writer. If I produce manuals for a particular kind of vacuum cleaner, then I am a technical writer. If I write a technical how-to guide that eventually turns into a published book, then that also might be described as technical writing.
Second of all, it’s important work and a lot of people respect it. The pay varies, and it tends to be lower than what engineers make, but it’s a very different sort of work. Done well, and it’s a lot like teaching: You try to be clear, you try to concise, and you try to be accurate.
Someone on LinkedIn recently wrote to me to ask about my experience as a technical writer intern at Splunk. I find that when you want to know the pros and cons of a job, you typically start with a simple Google search: You find testimonials and advertisements about how perfect the position is. Next, you go to Glassdoor and search for one-star reviews: You find horror stories about how the position is terrible, and also a scam, and also a trap. In this way, you establish your upper bound and lower bound, but you feel no closer to actually deciding whether or not the position is a good fit for you.
It’s unlikely this post will be of use to her, since she probably had to make up her mind by now. Still, I hope it is helpful to anyone who wants to know my honest thoughts of Splunk, and of technical writing in general.
Disadvantage: It was never really clear to me how the game worked
Game? What “game”? The Game of Thrones? The game of Chess? Are you just trying to make some over-the-top metaphor because you’re excited about the final season of Game of Thrones?
— You, I imagine
The game of internships, I mean.
At my current company, we have software interns. For all intents and purposes, these interns are extra hands. They write code. They solve problems. They get paid less than we do and probably have less experience, but they more or less do the exact same thing. If the experience goes well, they get an offer to continue work remotely. When they finally finish school, we will be waiting for them. Even if they decide to go somewhere else, we try to be very open to the fact that we want them, fulltime, and when they have their degrees they can get the kinds of salaries we got when we started.
How did Splunk work? I really don’t know, and I think it varied from team to team. Maybe I should have asked. I don’t know if they evaluate people really carefully for return offers, and I don’t know if it’s a careful mix of circumstances like how much funding they have as well as intern performance. I don’t know if the intern program, to them, is a mutual exchange of services for payment, with no intention of turning this into a long-term, full-time offer.
I don’t know, to this day. After that summer, with no return offer, I started applying for both full-time software and full-time technical writer roles. After some unsuccessful interviews with both Palantir and Workday, I reached a turning point and applied to nothing but software positions from that point on.
Advantage: It was the most fun I ever had working anywhere, in my life
Me: Can I bring this computer home and work from there?
Manager: Yes, but try to let us know if you want to work from home during core weekday hours
Me: No, I mean if I want to do extra hours
Manager: Let me know if you ever feel that there’s pressure to work more than your week’s 40. Some companies have their employees work extra hours on weekends or after hours, but we’re not that kind of company
Seeing the facility for the first time was almost surreal. I’d heard about these kinds of facilities in videos, but to skip your college classes for one day, physically go back to San Francisco, and to just walk into a place like that…
It was motivating.
When I started my first full-time job, my new boss questioned my abilities, insulted my university, trivialized my past experiences, and then finally gave me a much-needed opportunity to transfer out of her team and find a more decent lead. When I started my internship at Splunk, my new boss took me to one of Splunk’s many free catered lunches, introduced me to someone who would become my mentor, and went on to continually check in with me and thank me for all I was doing. I heard from other interns that not every team at Splunk is like this, but it definitely seems that the majority are.
I recall that in my 12 weeks at Splunk, there were two catered meals a week, free fruit, a kayaking trip with an open bar and unlimited macarons, a bowling trip, a big conference, an intern contest opportunity, and this one sort of weird day (in my humble opinion) when we did Meals on Wheels for three hours. Don’t get me wrong, I think community service is excellent…I just thought it was a little weird how they framed it like we had never distributed food or packaged meals before.
I used to think that having a facility like this was unnecessary overhead, but now I’m not so sure. Stuck on a problem? How about trying the outside garden? Tired of sitting in the same place? How about going downstairs for a while? Want to unwind for 15 minutes or so? How about, instead of having to go back home and turn on your work computer later, you spend some time in the music room? Creativity comes at odd times, and this is true for both writing and for coding.
Actual Thoughts on Technical Writing
Whether or not you have your own technical writing team, I don’t think anyone would contest that documentation is important. I also think we can all agree that poor documentation is harmful. Have you ever looked up a command in reference documentation, then realized there were no examples? This is crazy to me, and you’re going to see it way more often on obscure, internal tools than you are on popular open source tools.
Advantages:
- I found technical writing to be fairly straightforward and predictable — when I was asked to do documentation, I generally knew how long it would take
- I think Splunk technical writers are much more respected than most technical writers, which has a lot to do with their customer relationship. Customers need to know how Splunk works. Splunk writers work closely with these customers
- If you’re coming from a non-coding background, this is a good opportunity to learn your way around things like Linux, Git, and regular expressions.
Disadvantages:
- I personally don’t think that the best way to learn about software is by writing documentation about the software
- I used to characterize technical writing as “the perfect middle ground” between coding and writing, but this cuts both ways. You’re probably not going to do any coding, and you’re also not going to get to write with a tone or a lot of creativity. Even something like this Medium post is not something I would ever produce as a technical writer
- I was into creative writing, and still am, which is kind of apples and oranges to this
- You’re not going to get the same elation finishing a technical writing product as you would solving an engineering kind of problem (personal opinion)
- Naturally, it’s harder to measure your skill level. What constitutes good technical writing? It’s somewhat subjective
Actual Thoughts on Splunk
Wikipedia describes Splunk as “software that searches, analyzes, and monitors machine-generated big data,” but from what I know I am not sure if this is completely accurate.
Splunk is definitely big data. If you pick up the trial version, run it on some sample data, and produce some charts, you will quickly realize that Splunk shines when you want to see patterns in a crazy amount of data. Naturally, things like sensors will produce quite a bit of data. So does Twitter. So does Facebook.
Coca-cola is interested in Splunk. Journalists asking for data on campaign contributions are interested in Splunk. People who need cybersecurity are interested in Splunk, people who are coordinating disaster relief efforts are interested in Splunk, and you’d better believe the military is interested in Splunk. Like most things, Splunk has many applications that many would call ethically justified, and that many would call ethically questionable. But it’s just a big data tool. They are not the only company to produce big data tools, but they still have a major stake in the market.
I don’t think their product is super easy to use, and if nothing has changed then it is also pretty expensive. You’re not going to find an independent developer who learns about Splunk from TheNewBoston and then makes an app for it on his Android…you’re going to find a team of developers who pay for an expensive licensing deal with Splunk, and they’re going to use Splunk for an insanely large portion of their data.
Even if Splunk were to go away, the market they have tapped into is not going away anytime soon. Machine learning, big data, AI…it’s all there. Some writers are going as far as to suggest that we won’t continue to be employed as software developers unless we teach ourselves new and emerging information about big data and machine learning.
Closing Thoughts
If there is anything to take away from this post, I want it to be this: If you get a computer science degree, you don’t have to become a software engineer. And some of the people at Splunk also taught me that you don’t need a computer science degree to become a software engineer, but this post is long enough as it is.
I met Splunk test engineers, a QA team, technical writers…these are all fields that intersect with and diverge from software engineering in interesting ways. It seems fairly natural that computer science people gravitate toward the jobs in which they write the most code, but not everyone wants to write code, even the people who spent four years of college writing code.
You also don’t need to be a coding person to find yourself in the tech scene of San Francisco or Silicon Valley, but I personally think I have found more fulfillment in coding than I have in technical writing.
Lastly, if you ever have the pleasure of working in my hometown…
Do it. It’s amazing. Eat lunch with a view of the Bay Bridge in the background, take a run down the pier, go bar hopping, watch a game. There are few pleasures in life greater than working in a city that you love, especially if you have the added benefit of doing it for an exciting core product that you believe in.
Find out where your passion is. Do something you’re proud of. Try to make it count.
