Hardest problems I've solved
Technical Writer
36% page reduction from new IA
Nium -- Revamped the information architecture, reduced dev pages by 36%, and made navigation easier
| Before (May 2024) | After (July 2025) |
|---|---|
| PROBLEM: Short pages were hastily written by engineers who used more pages than needed Total of 50 pages | MY SOLUTION: I revamped and streamlined the information architecture to improve the flow and group related topics. Total of 32 pages |
![]() | ![]() |
2x onboarding; 75% fewer issues
Nium -- Doubled the number of people onboarded per month with 75% fewer issues
| Before (Oct 2022) | After (Dec 2022) |
|---|---|
| PROBLEM: New clients were unable to onboard themselves due to the unclear method to them–-and even to Nium. Each region (AU, EU, HK, SG, UK, US) contains five very complex spreadsheets describing various steps of onboarding for various client types and situations: | MY SOLUTION: I created sections of customers with sub-pages for common onboarding steps and for region-specific parameter and example pages. Immediately saw twice as many customers onboarded and only a quarter of the Helpdesk requests for onboarding |
![]() | ![]() |
#1 in a cybersecurity challenge
Yahoo -- Among 2,733 Python developers, I was ranked as #1 in the Cybersecurity Code Warrior Challenge
| Before (May 2020) | After (May 2020) |
|---|---|
| PROBLEM: 1. Find the 28 vulnerability types in 28 separate Python programs. 2. Then choose the best fix to block the vulnerability among 4 choices. 3. Incorrect guesses = fewer points. I had never taken a cybersecurity course but had read many articles related to it. | MY SOLUTION: - Since there was no time limit on the vulnerability questions, I had plenty of time to read and understand the code. - I was able to imagine what might cause a problem and then how to block it. |
![]() | ![]() |
| I was #1 among 2,733 developers ... ... two weeks later, I was #42 among 7,624 |
40% fewer pages; auto-reminders
Yahoo -- Reduced obsolete pages by 40% and added automation to prevent obsolete pages
| Before (May 2019) | After (Dec 2019) |
|---|---|
| PROBLEM: Too many obsolete and disorganized document pages. - Going to have an audit on all documentation pages. - Most in Confluence, needing to be in Markdown. - Many pages were obsolete but not clear which ones. - Many pages were not in easily discoverable places. - Many related pages/topics could be combined. - Moving forward, how to prevent "stale" pages? | MY SOLUTION: Implement reminders to review unmodified pages of a specified number of days. - I reviewed pages with SMEs - Archived obsolete pages - Merged similar pages - Organized pages by product - Migrated them to Markdown in Yahoo's GitHub - I suggested a system of tags on every page: - Owner, LastModified, DaysTillStale - A daily script looks for pages that haven't been edited in that page's time limit and sends an email to the owner (or owner's manager) of that page to review it. |
| - Total number of pages reduced by 40%. - Automated a timely reminder to page owners. |
0 help from engineers
Couchbase -- Needed to install a pre-QA version to document it while no engineer was available to help
| Before (Apr 2018) | After (Apr 2018) |
|---|---|
| PROBLEM: Need to document features before testing is done. - Couchbase Server v6.0 was still being coded. - Less than half of v6.0 had completed QA testing. - Documentation was needed for an event. - There wasn't an installed instance I could use. | MY SOLUTION: Install the Alpha version to use it and document it. (it was like installing Linux in 1996 before Google) 1. Find an unused server I could reformat. 2. Download and install Ubuntu 18.0. 3. Find, download, and install dependency files. 4. Find, download, and compile CB v6.0 source code. 5. Run Couchbase Server and create queries that use the new ANSI indexing and other new features. |
| I was able to document pre-QA features in time for an event without help from the software developers. |
80% time saved on new process
Couchbase -- Reduced the writing process of a new feature from 4-6 weeks to 4-5 days
| Before (Mar 2017) | After (Aug 2017) |
|---|---|
| PROBLEM: Turnaround time to add features took way too long. 1. Writers authored a feature in Oxygen. (2-3d) 2. Webpage staged for engineer review. (2-3h) 3. Engineers eventually gave feedback. (3-5d) 4. Webpage updated. (1-2d) Time for iteration: 6-13d x 2-4 iterations (going to Step 2) ======================== Total of 4 - 6 weeks per feature | MY SOLUTION: Google Docs for synchronous writing/editing. 1. I authored a single feature in Google Docs and shared it with all engineers involved. (2-3d) 2. While engineers discussed how the feature will be finalized, I started on the next feature. 3. After the engineers finalized a feature's text, I imported it in Oxygen and staged it only once. (2-3h) ====================== Total of 4 - 5 days per feature |
| Average time saved: 5 weeks → 1 week (80%) |
30% fewer helpdesk tickets
Couchbase -- Reduced the number of helpdesk tickets by 30% per week
| Before (Mar 2017) | After (Aug 2017) |
|---|---|
| PROBLEM: Customer Support had 200+ tickets to get through. The existing documentation: - didn't have examples - didn't explain in-depth enough | MY SOLUTION: I added: - many examples with Couchbase's sample database - more-detailed explanations to many concepts |
| Helpdesk said the number of support tickets noticebly reduced by about 30% each week. |
50% less time; 50% fewer errors
Boston VA Medical Center -- Reduced time to create clinical trials by 50% with 50% fewer errors
| Before (Feb 2012) | After (Apr 2012) |
|---|---|
| PROBLEM: PMs complained that they needed to enter long, complex eDC expressions that were hard-to-read and very error prone. | MY SOLUTION: I suggested to the engineers to separate each element into dropdown boxes with human-readable values that automatically matched the level of parenthesis. |
For example: NOT((intAge<="35") OR (ynSmoke !="1")) | ![]() |
1/3rd the time to edit eDC forms
Boston VA Medical Center -- Reduced the time needed to make any changes to a clinical trial to one-third.
| Before (Aug 2011) | After (Dec 2011) |
|---|---|
| PROBLEM: There was no clear approval path when changing any part of a clinical trial's process or database or questionnaire. To add or modify a feature or request to their complex eDC system: - It went through a maze of approvals - Various people in 7 departments There was no clear path or order of who to talk with next when each step is approved or rejected. | MY SOLUTION: Over two months, - I talked with 20+ people - I refined a 7-department swimlane diagram - I made a 100-step complex-yet-clear flowchart that all department managers agreed on. The average time to make an edit to an eDC form went from 3 weeks to 1 week. |
#1 in a Green campaign
HP -- Awarded 1st place in HP's Green Environment Campaign for my ideas that save 20-30% of paper used worldwide
| Before (Jan 2008) | After (Feb 2008) |
|---|---|
| PROBLEM: HP wants to reduce the amount of paper and ink used to be more "green". HP's Word DEFAULT.DOC file settings were: - 1.5” left, right, top, and bottom margins - 12pt font - Printers print singled-sided by default | MY SOLUTION: Slightly smaller margins and fonts. Change the DEFAULT.DOC file settings to: - 0.5" left, right, top, and bottom margins - 10pt font - Print double-sided by default |
| Example submitted: HP’s Orientation Table with URLs written out, printed on 14 pieces of paper | Became 2 pages (1 piece of paper) since: - 34% more print area (49.5 to 75 in2) - 17% more words per page (12pt to 10pt) - Saved 20-30% of paper printed |
| Cost to implement: 1 hour of administrator's time | Was 1 of 5 winners from 1,800+ submissions |
UX/UI Consultant
25% increase in players and sales
Mica Games -- Suggested changes to his games that resulted in 25% more players and revenue
| Before (Mar 1998) | After (Apr 2013) |
|---|---|
| PROBLEM: Brilliant word games were largely unknown because of clumsy UX/UI: - WordZap - Cricklers | MY SOLUTION: 31 ideas to improve the UX/UI, gameplay, settings, and other aspects. |
![]() | ![]() |
Software Engineer
DB saved >50% of time, effort
ADP Payroll -- Made a database to automate reports; saved >50% of the employees' time and effort
| Before (Mar 2009) | After (Aug 2009) |
|---|---|
| PROBLEM: Payroll Specialists had very manual and labor-intensive reports to create. They had everything in various spreadsheets and documents, which took a long time to sift through when compiling data needed for weekly reports. | MY SOLUTION: Use a database to unify and create reports. 1. I created a Microsoft Access database to connect all of their spreadsheets and documents into one cohesive place. 2. I made reports that ran automatically on the schedule they needed them. |
| This new system freed up at least 50% of their time which allowed them to do other things. |








