+
+
+ 15 years of professional writing experience
+
+
+
-
+
+
+
+
+
+
Senior Technical Writer
+
MAMBU 2021 to 2023
+
Promoted to team lead; managing a team of three technical writers.
+
+
Documented the Mambu ecosystem
+
Documented integrations, such as payment and compliance services, and the low-code orchestrator that clients used for their flows.
+
Documented a command-line interface
+
Documented the Mambu CLI for external engineers to connect to the backend directly.
+
Assumed leadership role
+
Promoted to team lead, which shifted the role into more managerial responsibilities on top of working on documentation.
+
+
+
+
+
+
Documentation Engineer
+
SPREAD 2024 to 2026
+
Hired as the first Technical Writer to establish the documentation function.
+
+
Built a docs-as-code publishing pipeline
+
Built a pipeline that used GitHub Actions to build the documentation site, Vale to lint content, Docker to deploy the site, and shell scripting.
+
Established the documentation function
+
Socialized the rest of the company to documentation processes and workings; this included onboarding colleagues to edit and use docs.
+
Documented the full product range
+
Documented the full product range within two quarters. Kept the documentation up to date through two product refreshes.
+
+
+
+
+
-
+
+
+
+
+
+ Technical
+
+
+
+ Writing
+
+
+
+ Process
+
+
+
-
+
+
+
+
+ HTML for content and structure
+
+
+ JavaScript for interactivity
+
+
+ CSS for text running out of boxes
+
+
+ Internet Explorer ... huh?
+
+
+
-
+
+
+
+
+
+
+
Questions and Answers
+
Why did you resign from your last job?
+
Grey / Gray
+
Do you need visa support? Do you have the right to work in Germany?
+
Sesame seed
+
Do you need visa support? Do you have the right to work in Germany (and the EU)?
+
Can you work remotely?
+
Are you able to work on your own?
+
When can you start?
+
diff --git a/content/resume/pcvue.md b/content/resume/pcvue.md
deleted file mode 100755
index 344bb4c..0000000
--- a/content/resume/pcvue.md
+++ /dev/null
@@ -1,130 +0,0 @@
----
-title: PcVue assessment
-description: An assessment of the documentation provided by PcVue.
-hide:
- # - toc
- - navigation
- - search
----
-
-
-
-> ### Brief
->
-> **October 2025**
-> Briefly assess the quality of the [product documentation](https://www.pcvue.com/ProductHelp/PcVue/en/Content/AboutHelp/Welcome_PubWeb.php) of PcVue.
-
-{ height=300px }
-
-## Content clarity
-
-**Acronyms and technical jargon**: The documentation generally assumes familiarity with acronyms like HMI and SCADA. It would benefit from brief explanations in these areas. For example, this is from the first paragraph of an [overview page](https://www.pcvue.com/ProductHelp/PcVue/en/Content/HMI/Overview.php):
-
----
-_The HMI (1) for your project is composed of mimics. Mimics (2) are easily and quickly developed to form menus, overviews, process diagrams, trend viewers and so on..._
-{ .annotate }
-
-1. Even if the acronym has been written out elsewhere it needs to be re-introduced on every new page.
-2. Mimics are a new concept as well, and the way this is written assumes the reader already knows what they are.
-
----
-
-**Assumed knowledge**: Many pages presuppose a significant amount of technical knowledge, which could confuse readers - especially those new to the industry. The first principle of technical writing is that every page is page one and the reader should find all the context they need on the page (or linked on the page).
-
-This is especially jarring on the landing page of the Product Documentation: PcVue has the description HMI/SCADA, FrontVue has the description Light HMI, and EmVue has the description Energy Monitoring. Of those, only EmVue is understandable to a new user. Using full blurbs that describe what the documentation set contains would be better for understanding.
-
-**Use-cases**: The absence of real-world use cases leaves a gap in understanding how the software works in practice. There are marketing use-cases on the main website, but they would do more to give product documentation clarity.
-
----
-
-## User experience
-
-**User experience**: Any documentation set that needs meta-documentation - like the [About this documentation](https://www.pcvue.com/ProductHelp/PcVue/en/Content/AboutHelp/HowToSearch_PubWeb.php) section - is signalling that it is not intuitive enough to use. A reader should not have to know about logical operators to use search functionality and interpret icons to understand their meaning. Good intuitive documentation sets don't need meta-documentation to understand how to use the documentation.
-
-**Search functionality**: The search feature needs enhancement to accommodate natural language queries rather than expecting users to know logical operators or regular expressions. Every reader's expectation is a search experience as good as Google; especially as the main way to navigate a large documentation set is through the search box.
-
-
-
- The search function is slow, fragmented, and can't handle questions
-
-
-**Getting Started section**: Preferably you need a Getting Started or QuickStart section. The installation minutiae gets in the way of someone who just wants the golden path. Notably, the main installation instructions are listed as the sixth item in the menu under the installation section.
-
----
-
-## Information architecture
-
-**Linking examples with theory**: Examples should be integrated with related theoretical content instead of being isolated, like in the Application Architect section, where the [Examples](https://www.pcvue.com/ProductHelp/PcVue/en/Content/AA/Example_keyword.php) section is separate. This approach reinforces learning through immediate application.
-
-**Content types**: The content needs to be divided into content types more clearly: theory content, tutorial content, and reference content. There is an inconsistency in how the sections are organized. For example, the Application Architect section has a glossary, but the others do not. The [Diátaxis](https://diataxis.fr/) for technical writing explains content types and where they are applicable in more depth.
-
-**Headings and page structure**: Headings are an indicator of page structure for search engines and for AI answer engines. Headings like "Example 1", "The secondary navigation tree pop-up menu", "For the LAN Manager", and similar mean nothing in isolation - which is how engines parse a website.
-
-**Interlinking**: The content is light on internal links. There are **See more** boxes, but the linking between pages is relatively absent for documentation describing one product. Internal linking helps readers make sense of the product as a whole and are critical for Search Engine Optimization (SEO).
-
----
-
-## Design and technical
-
-**Page load times**: PHP, the language that MadCap Flare outputs content to, is slow and the documentation site has a noticeable lag when navigating pages and using search. A server-side language is good for dynamic content, but hamstrings static content - which is mainly how documentation is presented.
-
-**Print layout**: The print layout when using the print button is not well-styled for PDFs or physical printing. The text is too small, the spacing and styling is a facsimile of the web view when it should be simplified for the print view. Some compliance functions need good PDF functionality to prove that content was made available at a certain time for auditing purposes.
-
-
-
-**Lists and tables**: When to use a table, a list, or another element should be clearer. There were instances were a table would have been better than a list and vise-versa. The formatting of both needs attention: lists are too spaced out and tables contain multiple header rows in the same table.
-
-**Diagrams and images**: Diagrams are a great tool for getting information across visually, particularly to illustrate complex processes and concepts. There are no diagrams in the documentation. Tools like Mermaid allow you to create diagrams dynamically, without using image editing application. The general quality of the screenshots and images is low, and there are no captions. Captions are important for SEO and for accessibility for visually impaired readers. Having images under **Show pictures** dropdowns is a suboptimal user experience. It's an additional click for little gain.
-
-**Font and presentation layer**: The font on the main site is more legible and overall styling is more visually appealing compared to the documentation site. Presentation matters, even for highly technical audiences.
-
-**Admonition overuse**: Excessive use of admonitions can diminish their impact. There are multiple pages with more than five admonitions per page. If everything is important, nothing is important. It’s essential to limit their frequency to maintain emphasis.
-
----
-
-## General
-
-The documentation is arranged around how the company views the software and not how users use it. A compliance and audit professional would benefit from a user flow designed for their needs and understanding, same for an integration or process engineer.
-
-The documentation is written like a book, with the expectation that readers will read from top to bottom. This is not how people read documentation. Documentation is primarily driven by search and read in snippets. Readers come with questions and expect answers with full context in a nutshell.
-
-The language scores highly on the [Flesch-Kincaid Grade Level](https://en.wikipedia.org/wiki/Flesch%E2%80%93Kincaid_readability_tests), indicating that it can be improved for clarity and flow. This would need a full review of the content to set standards that make it more readable and understandable.
-
-As a reader I get the sense the chapters have been written by different people and the documentation set does not work together.
-
-**My general recommendation would be an overhaul, starting with the information architecture, a technical infrastructure review, and then a general language and style standards review.**
-
----
-
-
diff --git a/content/test.md b/content/test.md
new file mode 100755
index 0000000..f506814
--- /dev/null
+++ b/content/test.md
@@ -0,0 +1,29 @@
+---
+title: test
+---
+
+The HTML specification is maintained by the W3C.
+
+
+- :fontawesome-brands-html5: __HTML__ for content and structure
+- :fontawesome-brands-js: __JavaScript__ for interactivity
+- :fontawesome-brands-css3: __CSS__ for text running out of boxes
+- :fontawesome-brands-internet-explorer: __Internet Explorer__ ... huh?
+
+ 
+ 
+ 
+ 
- 
+ 
+ 
+