On October 2nd, 2026, I gave a talk at the AWS DMV Community Day 2026 titled, “How my brain injury and executive function disorder helped me become an effective technical writer.” I’ve been writing for years about my journey with brain injury and career, but I’ve decided to start doing talks about it last year.
The TL:DR; of the talk:
Due to my brain injury, I had severe executive function disorder (think: ADHD on crack) and memory issues. Remembering anything (especially to-dos and steps to complete tasks), and beginning or completing necessary tasks (work, school, daily life skills), were extremely difficult. I couldn’t even watch a 5 minute music video on YouTube without getting distracted, and if I were trying to read a document, I’d find myself reading the same sentence over and over again without realizing that I am reading the same sentence.
I even got multiple cavities during the few years post-surgery because I couldn’t get myself to brush my teeth because the “starting” part of my brain was dead (once I got going, I could complete the tasks, but I couldn’t get myself to begin the tasks).
My 2nd time giving a talk at AWS DMV Community Day
My first ever technical (?) talk was at AWS DMV Community Day 2025, where I gave a talk titled, “From Special Ed Major to AWS Hero.” Since that talk, I’ve had the opportunity to speak as a panelist or presenter for over half a dozen events, including a few in Tokyo, Japan!
For this year’s talk, I expanded on last year’s talk, and spoke directly about the correlation between my brain injury (sustained from brain surgery when I was 22) and my career as a technical writer.
I had brain surgery in college to remove vascular tumors from my brain, which left me with acquired brain injury. The brain injury left me with symptoms ranging from executive function disorder, sleep disorder, anxiety disorder, and short term memory issues, amongst other issues. For years, I thought that my disabilities limited me.
But as I kept pivoting through my career, I came to realize that my ability to write great technical documentation came from my need to write everything down to compensate for my “new brain.” This talk will go through the journey of learning to harness my “disabilities” as unique gifts that allow me to stand out in this environment.
Arteriovenous Malformation
I’ve written a lot about my joust with Arteriovenous Malformation (blood vessel tumor) in my brain, which caused mood disorders and seizures. I got 3 of them removed via craniotomy in 2021, and have been living with the side effects since then.
Aside from the grand mal seizures I experienced in college, I found out when I was pregnant with my first child in 2022 that I had sustained a brain bleed (stroke) when I was in high school. What a surprise! (Was anyone going to tell me??)
October is actually AVM Awareness Month! So here’s an infographic from The Aneurysm and AVM Foundation that explains what an AVM is:
This talk was an attempt to merge together my current career with the different ways I accommodated for my disabilities post brain surgery.
The talk: How my brain injury helped me become an effective technical writer
Hiroko Nishimura, AWS Community Hero
I gave a quick introduction to who I was, and what I do. As a quick recap for those of you who may not know me, I:
- Teach “Introduction to AWS for Non-Engineers” (now: “AWS Certified Cloud Practitioner Cert Prep“) on LinkedIn Learning since 2019.
- As of October, 2026, I have over 720,000 learners, and the course has been published in English, German, Portuguese, Spanish, Italian, and Polish.
- Wrote “AWS for Non-Engineers” with Manning Publications, published in 2022.
- As of October 2026, the book is available in English and Korean.
- Create jargon-free introductory Amazon Web Services resources, especially for people with non-technical backgrounds.
- Am an AWS Community Hero since 2020.
- Created AWS Newbies in 2018, and am spending 2026 rebuilding it from scratch with a lot of beginner-friendly AWS tutorials.
Surviving brain surgery at 22
And in 2021, I had brain surgery to remove 3 vascular tumors (Arteriovenous Malformations) from my brain, which left me with a myriad of disorders.
They included:
- Memory issues
- Can’t remember events, to-do’s, plans, order of operations, etc.
- Executive function disorder
- Can’t break down large projects or prioritize tasks by importance
- Easily overwhelmed
- Can’t sustain attention to work/learn/read/watch videos
- Can’t remember what I was talking about in a conversation
- Overstimulation from many daily tasks (including driving)
- Aphasia
- Can’t put thoughts into words
- Felt like my English was at 75% my pre-surgery levels, and my Japanese at 45%
As a result, I gave up my dream of becoming a Special Education teacher. I also felt that my life-long dream of becoming a writer also seemed to have disintegrated, now that I couldn’t write because of my aphasia and executive function disorder.
To make things even worse, my doctors told me that I will probably never work full-time, drive, or live independently. Right as I was getting ready to go out into the world as an independent adult, the world seemed to come crashing down around me.
Becoming my own “Special Ed Student” to re-learn how to function
As I mentioned earlier, I was studying to become a Special Education teacher before my brain surgery. My speciality was elementary education, with special interest in Autism.
When confronted with my disabilities and sudden inability to do things I had always taken for granted (including reading paragraphs, writing essays, or completing a thought), I decided to take what I’d been learning in college to create accommodations and modifications to my own life. As a result, I was able to graduate with my B.S. and M.Ed. in Special Education.
While I was able to compensate for a lot of my disabilities (like writing everything down and having a “source of truth” calendar because I couldn’t trust my memory), I don’t really believe that my disabilities ever disappeared. I’d just built my life around cues and routines that help me function semi-normally.
Once I graduated college, I moved to New York City with an unpaid internship and a 6 month sublet that I secured online (these days, it would be WAY too dangerous to do stuff like that because of all the scams going around). I chose NYC because I didn’t have to drive.
There is a model called “Social Model of Disability“:
The social model of disability emerged as a direct challenge to this. As disability scholar Tom Shakespeare describes, the social model draws a critical distinction between impairment and disability. Impairments are specific differences in bodily or mental functioning. Disability, by contrast, is structural – it is created when society fails to accommodate those with impairments. Under the social model, an impairment only becomes a disability when a person encounters a societal barrier.
In this model, disability occurs when the environment creates a “disability” because of the structural barriers it produces to limit someone with an impairment’s functions. In my case, I couldn’t drive. Not being able to drive made me “disabled” in the suburbs, because I had to drive to live independently and work (remote work wasn’t really a thing back then, and neither was Uber).
By moving to NYC, I could walk and take the train everywhere. Suddenly, I could commute, shop, and do all of my daily tasks independently despite still being impaired in the same way I was living in the suburbs.
Starting my career in IT, utilizing skills obtained from self-accommodations
I spent the next half year applying for hundreds of jobs with crickets. Finally, I managed to land a Junior IT Helpdesk Engineer role at a Japanese company, hired purely based on the fact that I was an English/Japanese bilingual person, and they needed a bilingual helpdesk engineer.
IT troubleshooting skills can be taught, they reasoned, so they were willing to gamble for my language skills.
Teaching myself how to be a “Helpdesk Engineer”
Many parts of working the day to day operations of a helpdesk engineer required me to utilize everything I’d learn about myself in the few years post-craniotomy.
- My memory issues made it imperative that I wrote everything down, including dates, how to’s, and to do’s
- When writing how-to documentations for myself, I couldn’t take for granted any prior knowledge (because I didn’t trust my brain), so the documentations were very comprehensive
- Learned how to create jargon-free documentations with emphasis on quick legibility and comprehension (because I had a job to do!)
- Realized through the whole process that I can just learn whatever I needed to learn, and create my own documentation to accommodate for my brain’s inability to retain the information
Transitioning into a Technical Writer
All of the skills I gained from learning how to work as a helpdesk engineer directly contributed to transitioning into a technical writer.
Seeing that I write helpful documentation for the team, my manager asked me to create self help articles for a brand new internal self-service center attached to our ticketing system. When someone submits a ticket, it automatically spits back a few articles with suggestions on how you might be able to self-resolve your issue.
In the process of creating documentation for other people to utilize, with focus on self-resolution, I realized that I can also begin writing and publishing tutorials on my own blog, and potentially help other people learn what I’d been learning.
Beginning my journey into content creation
I had always been a writer, and I had been making websites (mostly anime fan sites) since I was in middle school. I was always happiest when I was creating. But I’d given up most forms of creation after my brain surgery, because I felt like my creative side had been demolished.
Writing documentation afforded me an opportunity to still write and create, despite having lost my fiction-writing fuel.
The creation of awsnewbies.com
One of the first things I did once I realized that I could still write, as long as it was non-fiction, was to create awsnewbies.com, a study blog for the AWS Certified Cloud Practitioner Exam. I had 2 weeks until the exam I had scheduled, and couldn’t for the life of me figure out what any of the concepts or services were.
I spent a week creating all of the content one needs to know to pass the exam, used it myself to pass the exam, and decided to keep it up for a year, since I was hosting it on AWS Free Tier.
Being invited to create courses on LinkedIn Learning
I put a link to the website on a women in tech facebook group, sharing it as a resource. Few days later, I received DM from a content manager at LinkedIn Learning, asking if I’d be interested in creating video courses for LinkedIn Learning. I had never heard of LinkedIn Learning at the time, but it was in the process of transitioning from Lynda.com (which I had heard of) after an acquisition.
With a lot of trepidation and imposter syndrome (I made awsnewbies.com because I had no idea what was going on with AWS, after all!), I accepted and began working on my courses in fall of 2018.
As with my documentation writing, my focus was on jargon-free, “explain it to someone with absolutely 0 technical background” content. I felt like I couldn’t find any courses that explained it to me without relying on previous legacy infrastructure experience, so I wanted my courses to be truely accessible to people who had no IT background.
The four-course series, titled “Introduction to AWS for Non-Engineers” was first published in 2019. Since then, I’ve updated the courses numerous times, and they’ve also recently consolidated into 1 single course, called “AWS Certified Cloud Practitioner (CLF-C02) Cert Prep.”
The course is available in English, Spanish, Portuguese, German, Italian, and Polish, and have been taken by over 720,000 learners since 2019. Not bad for a disabled helpdesk engineer making a study blog!
Being nominated to be an AWS Hero
In end of 2020, I received word that I had been nominated to become an AWS Community Hero. Becoming an AWS Hero had been my goal ever since I learned about them, and I have had the privilege of holding the title since 2020.
Being part of the program has allowed me to meet so many cool people, take exciting opportunities, and travel extensively for events like AWS re:Invent in Las Vegas and AWS Heroes Summit in Seattle. I was taking a few years to hermit due to COVID lockdown/having 2 babies/postpartum, but I began coming back to my community work in 2025.
Writing and publishing “AWS for Non-Engineers”
In 2021, I decided to drop all of my freelance clients to focus on my health. I was diagnosed with Rheumatoid Arthritis in my late 20’s, and had been on an immunotherapy drug for years. I was at such a low dosage after moving back to the suburbs and quitting my job that my rheumatologist recommended I focus on my health and try to get into remission.
Few months after I stopped consulting, I got an email in my inbox from an editor at Manning Publications, asking if I’d be interested in writing and publishing a book with them. Timing was perfect in that I had just given myself complete freedom from work. But it was also the worst timing in that I was trying to get into remission.
Somehow, I accomplished both. AND as an added bonus, I gave birth 1 month after I submitted my manuscript in the summer of 2022. (I was unable to conceive on the chemo medication I was on, because it would have caused irreparable damage to the fetus.)
The book, “AWS for Non-Engineers,” was translated into Korean, and I had the opportunity to receive a tangible copy from a fellow AWS Hero last year.
When I dreamed of writing and publishing a book when I was a child, a technical book about cloud computing really wasn’t what I imagined… But a book is a book, and I hope this book will serve as a launching pad for potentially writing fiction in the future!
Successes becoming catalysts to begin talking about my disabilities and challenges
My courses’ success, becoming an AWS Hero, and having the opportunity to publish a book gave me enough confidence to start talking publicy about my disabilities and challenges. As a self-employed person, I no longer felt that I had to “hide” my needs or quirks to fit in or not be on the next short list for layoffs.
With a “numbers and accolades don’t lie” mentality, I was able to begin sharing about my journey, and how my disabilities actually made me uniquely competent in a field I love, instead of taking away from it.
Finding technical writing and technical instruction as a career has allowed me to flip the script on my deficits by turning them into my strongest assets.
Writing has allowed me to create an external brain when my internal brain couldn’t be “trusted” to do its job, which in turn helped hundreds of thousands of people learn AWS over the past decade.
In a perfect world, I wouldn’t have had to put so many shiny stars into my pocket before having the courage to begin speaking about how “different” can be “uniquely awesome” when it comes to finding the perfect niche between interests, skills, and effectiveness. But with decades of imposter syndrome ingrained it me, it took a while for me to start talking about it.
My hope is to become a story that someone who is going through a tough time (with a diagnosis, or sudden disability, or medical illness, or having to take time off careers) could read and realize that people like me exist, and that there is potential for whatever you are struggling with to end up becoming your most effective weapon.
When I found out that I had brain injury that caused permanent issues with my executive function and memory, I was devastated. Decade and a half later, my memory is much better, and my executive dysfunction is fairly well controlled (enough to write and publish a book, after all!). But the difficulties are still there, waiting to pounce out when I’m tired, overstimulated, or not feeling well. They are pesky creatures I’ll live with for the rest of my life.
Writing technical documentation with the reader in mind
Some quick tips/tricks/thought processes I included at the end of the presentation about technical writing.
What I think about when writing technical documentation
- Will someone look at the document and immediately get overwhelmed?
- Too much text in a paragraph? Not enough graphics? Too long? Convoluted?
- What prior knowledge does the reader need to possess in order to utilize this document?
- If there is prior technical knowledge necessary, will I provide it, or will I link to other documents?
- If there are jargons, have I defined everything?
- Am I helping someone solve their problem?
- What can I do to help them solve their problem easier? Graphics? Changing my vocabulary? Being mindful of how I organize my document?
- Am I explaining too little or too much? If too much, can I cut back and link to another article for people who are interested in the more in-depth?
Creating introductory content
- Introductory content isn’t just for beginners – it can help anyone, newbie or veteran, to begin learning about a new technology or concept
- Make sure you’re speaking the common tongue; hold off on jargons (or make sure you define them concretely), and don’t assume prior knowledge/experience
- The more accessible your content is, the bigger the potential audience for your work
- If you’re working on a product or service, the better KB documentation is created, the less work you’ll have to do (or hire people to do) to teach clients/customers with your own time (promotes “self-service”)