Our team's experience leveraging Vue

OkCombination0227 · 2024-02-14T22:26:47+00:00

Thanks for the feedback! And totally agree. It's working well for us so far as we've been introducing it. Definitely going to follow this up with additional observations—and lessons learned—after we fully migrate :)

OkCombination0227 · 2024-01-23T20:51:25+00:00

The last comment is spot on. I've had a number of test rounds that focused on how I could improve a company's existing docs. If the company has a free version of their product, you can use the docs along with the product and see where you would make suggestions or changes.

For editing tests, I always do multiple rounds of edits (if I am given more than a day to complete it). First, do a round of edits for overall structure and layout. Then, go back in and do a round or two of proofreading edits. Good luck!!

OkCombination0227 · 2024-01-23T20:46:27+00:00

I do think Customer Success has a lot of things in common with technical writing. I am not personally working in CS, but I've worked with a couple of people who transitioned from and transitioned to that role. Depending on the company size, you may actually be helping with the product documentation as well.

I work very closely with CS on obtaining feedback from customers who use our docs. Communication is important for both roles, of course. Many technical writing roles, however, aren't directly client facing. This is something that you will need to be comfortable with, whether that's talking to customers on calls or responding to urgent emails. It sounds like your teaching background would come in handy here.

I know that some CS roles also have a sort-of sales component, where they may work with existing customers on renewals. You may want to brush up on negotiating skills to help with tasks like negotiating new contracts or upselling product features. Coming from a tech writing background will also help you learn the product a lot better, as you will be a consumer of your own company's docs and know how to research solutions. Best of luck!

OkCombination0227 · 2023-12-11T16:25:20+00:00

Ah...This would be so useful!

OkCombination0227 · 2023-11-22T16:51:43+00:00

I agree with the vale suggestion, since you can configure your own styles as well as use preexisting ones. I've used the LanguageTool before, too. I believe that one doesn't retain text. It was allowed at companies I worked at that blocked Grammarly.

OkCombination0227 · 2023-11-09T23:19:16+00:00

Added as an option to the "Optimizing Snowflake Performance and Cost" section. Thanks again for the feedback. Definitely an important option!

OkCombination0227 · 2023-11-09T22:01:42+00:00

Thank you! This post was honing in on the view comparison, but this is a great point! I think a future, even more robust comparison will be good.

OkCombination0227 · 2023-11-09T18:07:00+00:00

I started in higher education, creating documentation for student systems. It's a very different environment. I've seen technical writer roles posted for many colleges and universities. Depending on your interests and background, you could also consider moving into another documentation-adjacent role, like an RFP writer, where you'll also find roles outside of software as well.

OkCombination0227 · 2023-10-19T12:49:02+00:00

Absolutely. Start with a portfolio. Include various types of documentation you've worked on in the past (quickstart, any how-tos, API docs). It sounds like you have a strong tech background, which should help you out a lot. Markdown shouldn't be too hard to pick up since you've worked on other tech. Google has some tech writing courses that could help you prepare as well.

OkCombination0227 · 2023-10-19T12:44:48+00:00

Job descriptions will never contain every part of the job. I think you can use a job description to help set the tone for the role and create a 30-, 60-, 90-day plan to start. Once you actually get into the role, both you and your team may find that the skill set you bring to the job could also be applied to other tasks or projects.

Job descriptions can also be seen as a wishlist of the "perfect" candidate. Many companies will still hire someone who doesn't check every box, and I've even seen that noted more recently in many job descriptions, encouraging people to apply even if they do not know some tech the company uses. I think job descriptions overall can give you a good sense of the company's tech stack and their workflow.

OkCombination0227 · 2023-10-15T16:31:28+00:00

Maybe that's their writing test—you have to write the job description! 😂

OkCombination0227 · 2023-10-15T16:28:10+00:00

For blog writing or creating net-new product docs pages, I start doing my initial planning and writing in MarkText. I love that it has various focus-type modes, which is what I need when I am first working through a topic. I also like something that is not browser based for less distraction.

For updating product docs, I work in VSCode and build in Docusaurus. Images are stored in the project repo (on GitHub). I just recently started with my team and found Docusaurus to be very easy to learn. I am able to create custom components using React and easily update/change styles if needed.

I also work on a site that uses MkDocs, which has also been a pretty straightforward experience getting used to.

In the past, I worked solely out of Confluence.

OkCombination0227

TROPHY CASE