# About ![[me.jpg|170]] Aaron Halbert [email protected] [@MemoryDaydream](https://twitter.com/MemoryDaydream) # Experience - **Lead Technical Writer** @ Tools4ever (June 2020 - December 2023) - Created [end-user & API documentation](https://docs.helloid.com/) for HelloID identity management SaaS. - Rewrote entire documentation site and migrated it from Zendesk to Paligo. - Contributed to UX/product design, video production, and e-learning tutorials. - Mentored other team members. Built relationships with internal experts. - **Technical Writer / Direct Marketer** @ Dolch Press (July 2012 - June 2020) - Wrote and marketed [technical books](https://www.goodreads.com/author/show/7480700.Aaron_Halbert) & [romance novels](https://www.goodreads.com/author/list/15222889.Riley_Rollins) on Kindle. 25 books published & 275,000+ copies sold. - 6 books reached Kindle overall top 100 bestsellers list, including 2 in the top 20. - **Content Director** @ Hanover Research (June 2010 - July 2012) - Led B2B & B2C market research campaigns. Managed 4 direct reports. - Primary point of contact for clients. Presented to executive audiences. # Doc samples - [Sample 1 (help article)](https://drive.google.com/file/d/1EM-BOEjGqSAeeVl1bWzUb8ift3FGoONZ/view?usp=sharing) - [Sample 2 (help article)](https://drive.google.com/file/d/1bwUIgDnHOw4A8Tk_3IubNwf-tV7SEzlO/view?usp=sharing) - [Sample 3 (eBook)](https://drive.google.com/file/d/15WSHyR2AA0DDxtEhA0N8eMNSPgg4H4df/view?usp=sharing) - [Sample 4 (eBook)](https://drive.google.com/file/d/1Im3sE-0wAkSsU5A6yY1pUST0AszRaXUc/view?usp=sharing) - [Sample 5 (white paper)](https://drive.google.com/file/d/1lfszVt3jPGdUzPoCS12aK2mBPJLMPrg9/view?usp=sharing) # Side projects - **NoSurf for Reddit:** A non-addictive Reddit client for Android. 5k+ downloads. - [GitHub](https://github.com/ajh3/NoSurfForReddit) - **Chip8emu:** A CPU emulator for the Chip-8 virtual machine. - [GitHub](https://github.com/ajh3/chip8emu) - **Web design:** Landing pages. - [Sample 1](https://www.figma.com/proto/FYeG9H8SjMDQ9kXA4wtCiv/Essay-app?t=2QJAQYn80CKqAcNR-1&node-id=14-2&hide-ui=1) - **Book cover design:** For romance novels. - [Samples](https://drive.google.com/file/d/1OTONaP65gs9hV1uqiIbSVG7rNEj1jmMW/view?usp=sharing) - **Technical sales copy**: Landing pages, emails, direct mail. - [Sample 1](https://drive.google.com/file/d/1VTxF6qlAr3uSQVt4b0V7wC1DaZ3RjOW2/view) - [Sample 2](https://drive.google.com/file/d/1hDK2m_YYarSNkAOKSyBH38sTE3MBAYzX/view) - **Metamaps.io:** An interpretation of the book *Maps of Meaning*. - https://metamaps.io/ - **Mind2Tetris.org:** In-progress integration of UX design, computing, philosophy, psychology, & cognitive science. - [coming soon] | [preview](https://threadreaderapp.com/thread/1820995830897373466.html) # Skills Paligo, SnagIt, Photoshop, Figma, REST, Postman, HTML, CSS, GitHub, Markdown, C, Kotlin, Java. # My approach to docs Technical writing isn't primarily about Oxford commas or perfect grammar. Writers obsess over these details because they're easy to think & argue about. Instead, technical writing is about explanation, understanding, context, and meaning. It's about simplifying complexity (i.e., bringing order to chaos). It's about contextualizing information by putting it into an appropriate framework of relevance. Here are some principles I believe are particularly important for technical writers and other software professionals: - **Context is king:** Neglect of context is perhaps the #1 cause of confusion in software, UI, and docs. To mitigate this, we as technical writers must: - **Differentiate between what should be situationally implicit vs. explicit.** We're always, necessarily, choosing some level of abstraction to write at. Too high a level causes the "curse of knowledge." Too low a level decreases performance by drawing conscious attention to processes that should be tacit. - **Attend to the contexts in which words are used.** Words only have determinate meanings within specific, shared frames of reference. It is the job of technical writers to navigate these "horizons of understanding," and to help users alter or extend them when necessary. - **Privilege contextualized, concrete examples over decontextualized abstractions.** Examples clarify difficult concepts more than anything else, and get users started faster. Users generally act first and only revert to effortful cognition in novel or error situations. - **See the forest for the trees.** It's easy to lose perspective on what really matters when you're down in the details. Remember to occasionally zoom out to consider higher-level business goals. Validate the parts against the whole and vice versa. - **Understand the work domain:** It's impossible to explain what you don't understand. As technical writers, we must have a functional understanding of everything we write. It's a bad idea to publish things that you haven't verified in personal experience. - **Don't make users think:** Decrease cognitive load as much as possible using docs and/or visual representations in the UI. Ideally, both should be organized around meaningful possibilities/constraints relative to users' goals, *not* around artificial distinctions defined by how the code works. Whenever possible, technical writers should do the thinking for users in advance. - **Maintain a theory of mind with colleagues:** Think about the difference between what you know and what they know, and how your communication will be perceived based on that difference. - **Messy & rushed is the rule, not the exception:** "Muddling through" is the norm—not adherence to some idealized, academic process. Satisficing solutions done in an appropriate timeframe beat perfect solutions that never ship. # PDF resume [Download PDF](https://drive.google.com/file/d/1clHQq1WbAgXLN_QrGiD4rSL8EYa65lsj/view?usp=sharing)