Harassment: ASML, addendum: high-prio project specifics

Thu, May 21, 2026 ❝These are the specifics I originally left out, because I deemed them unnecessary for the intended story. Still, organized harassment and abuse continues.❞

Contents

This story is published thanks to on-going harassment efforts and intensified abuse in recent months, now in ~8th year as-of finishing my assignment at ASML.

This is an addendum, closer to the original description written for the introduction in 2nd team: high-prio project. I removed parts I deemed unnecessary which, at the time, unexpectedly triggered a bunch of people mumbling in the appartment above me in the middle of the night at around 04:00h, then a van driving off into the distance, which had to circle around the appartment building so I could conveniently observe through a window as it drove off. Years later the harassment and abuse is still ongoing; as meaningless, abusive and unreasonable as it was at the start, though I hadn’t realized or understood the situation at all, at that time. My good intentions and willingness to get matters resolved only constantly betrayed.

There has been, by now, for months constant harassment and abusive practices from the appartment above me with EMF emissions, targeted and strong enough to interfere with my sleep. It has now become evident that some 8 years ago, shortly after leaving ASML, this same (kind of) device was used to cause initial “sporadic” sleeping problems, then later used for very significant periods on end, possibly months, for possibly more than a year on end, to severely disturb sleep, and possibly during some days to introduce a constant “noise factor” of subtle pervasive interference. It seems I have no choice but to revisit my decision.

I say “kind of device”, because I overheard a former neighbor on one side, who had such a device aimed point-blank at my skull through the wall, brag about it being turned up on high. I do not know if there are multiple such devices being employed.

The project

This is the description to the best of my recollection.

The project focused on improving the ability to fine-tune calibration of metrology by introducing a different and customizable sample for testing purposes.

The original metrology, apparently as I hadn’t realized prior to this project, works with specialized test-wafers. These wafers have coarser features, which consequently are undoubtedly well suited for initial calibration, but insufficient for optimizations that squeeze the last attainable bit of performance out of the hardware. This project attempted to tackle exactly this problem. That is, to provide a follow-up step suitable for further optimization where all other options have been exhausted.

The starting point to using this idea is a fully set-up scanner-hardware, and calibrated metrology hardware, meaning that the scanner is able to produce specially-crafted test-wafers and the metrology set-up is far enough ahead such that these highly specific optimizations can be applied.

Metrology-to-Device (MTD)

Considering the domain, there is a need to best-as-possible fine-tune the metrology hardware. The test-wafer only accomplishes so much. There have previously already been attempts at detecting structural deficiencies of various kinds, one-off anomalies, and other such kinds of artifacts, and corrections made as possible and sensible.

With metrology test-wafers providing rather coarse samples to perform metrology calibration on, and software-based optimizations w.r.t. aberrations and other systematic anomalies corrected for – best as possible – the optimization process reached an end-point. The idea of metrology-to-device is to compose a product-wafer consisting of results that can then be used to further optimize metrology. This requires a scanner that is fully calibrated and optimized, such that a high-quality result can be produced. This result, containing very small features as the scanner can produce, could then be used to further evaluate and optimize metrology.

The idea is to produce a product-wafer that contains a series of regular (repeating) patterns. The patterns themselves, being predictable in structure, and careful selection of which patterns suit which locations on wafer and kind of artifact detection, can then be used to expose various kinds of potential/possible weaknesses in metrology. That is, you know how such a wafer is supposed to look, and although the features are extremely small, various forms of regularity and predictability do help to expose or emphasize artifacts.

In addition to the execution of this idea, it also relies on previous work, namely that of wafer-level control (WLC). Sufficient to say, wafer-level control should become available in this desktop application (and afterwards as server-components suitable for handling batch-processing) and then adopted for the additional granularity for creation of these specialized product-wafers used in deriving further optimizations for metrology-recipes.

Now, in this team, the goal is to build directly into the over-arching application-framework – as opposed to embedding an existing application in a similar fashion as an iframe – and make the core logic suitable for server-application and batch-processes. Subsequently, the MTD set-up application used in these new software-based optimizations would benefit from wafer-level control to most precisely produce a scanner-recipe with carefully selected patterns, to then produce product-quality wafers for use in metrology, to then use the same application in a subsequent step, perform measurements and evaluate metrology results being produced from measuring the freshly produced, specially-crafted wafer. The discoveries made during metrology would then be incorporated into metrology recipes to benefit metrology on actual product-wafers.

Design for application

Now, starting 2nd year, preparing for this high-prio project, there are a few key characteristics:

• Team has come to be on the critical path, due to changing customer priorities, with central role in the project which would take somewhat more than half a year of full focus, cooperation and collaboration among several teams, and alignment with a generous number of stakeholders.
• WLC proved to be feasible, adopted, and would be useful for this experiment.
• The over-arching application-framework was starting to get serious, and this project functioned as a first use-case for from-the-ground-up developing the application for inclusion.
• Adoption of JavaFX, over the course of the last 0.5+ year, allowed for more expressive, dynamic UI with fewer lines of code by generously employing “bindings”.
• UX competence started to settle in, though lacking a willingness to collaborate, they instead try to insist obsessively on ideas and in particular, consistently more than necessary.
• Main Application-team, in a one-off assisting second team role, would provide expertise in developing custom controls according to the new UI vision and capabilities.
• UX developer and me spent some time during first team to investigate how best to handle general UI, input controls, bindings and custom control designs in JavaFX for that team’s latest work. I could provide the necessary basics on JavaFX and development to start off on the right track, and avoid pitfalls of classic “Java Swing approach” which would result in significantly more effort, maintenance burden and complication. Instead the focus came to be on MVVM, strengths of JavaFX such as proper advanced use of bindings, and a solid structure for the core implementation part of the program.

Main Application-team provided us with valueable and professional support during this project. Some complications and considerations were already described and I won’t go into it again here. They predominantly, but not completely, focused on Main Application concerns and supporting with UI controls and partially provided (unofficial) expertise for UX design.

UX representative was less experienced and in more of a junior position, and although persistent they had to oppose seniors of two or sometimes three teams and an architect, thus having a harder time pushing unnecessary and unreasonable requests. This resulted in a very decent trade-off of specialized design with customized controls without going over-board, especially considering the high pressure of the project. There were the multiple steps of progression, but less of the excessively fancy demands and extra work. Where Main Application-team was transparent in using it as a stepping-stone to get the application-framework off the ground, UX competence was trying to use it like in many other occasions, as a “milking cow”, to get any amount of work done that they could get away with. (This practice later continued in 3rd team, causing a significant amount of friction in most meetings.)

I mentioned that Main Application-team provided some UX experience. That was mainly through one individual who had a background in visualization and UI design, and consequently could claim “authority” (not because of the nature of this person, but rather because of the toxic attitude of the UX Competence-members) and call out bullshit on excessive demands. Other people present could obviously recognize the bullshit, but the toxic attitude was such that there is significant push regardless.

Attacks and harassment

As mentioned previously, I got attacked over “having to prove myself” where I was harassed for years about what turned out to be some unspoken expectation that I supposedly would need to make a sample application for the slides that I had prepared. The complete and utter uselessness of this demand, some 6 years later, when the MTD Set-up application was actually structured and designed according to these suggestions and preparations, is incomprehensible to me. I also have no idea why this persistent ongoing harassment was necessary.

There were also these blatantly false claims that I would be “absent” during development. This was mentioned before, and was the case because this project and in particular this team was literally the critical path. So with architect and one other team lead, we were almost exclusively in alignment meetings and design sessions to get all matters sorted out with at least a 2-week reserve of prepared work ready for implementation, i.e. a full sprint, as not to introduce significant delays in teams. We lost this race once, somewhere past the half of the project, where we aligned with development teams to introduce a 2-week slow-down where development teams focused on bug fixing, maintenance and refactoring, while we could get a lead on our preparation. There are also false claims that I was never present, which was not only false, but also a blatant lie because we clearly communicated that we, being the team-leads and architects, were in the other dedicated project-room working on planning, architecture and design, and otherwise we had open Outlook agenda’s (I think we all did) such that people could check where we might otherwise be.

As also mentioned, it seems that the toxic attitude at the department was such that this (“my”) development team fabricated a whole swath of false and fabricated accusations and claims supposing I did all kinds of bad and evil things. Years later, there was the cheap excuse that “because I left the team immediately after this project”, there “was no time to dispell such false accusations and claims”. This seems to be a awful and rather abusive approach, but more than that is that, in the way I was later attacked based on these false suppositions, it became a matter of extreme prejudice and rather aggressive persecution over unproven and uninvestigated false accusations, of which I was never even asked to provide any feedback, before getting attacked over those for years on end.

Later, “off-hand comments” during ongoing harassment hinted at “having to prove competence” and later that I “satisfied the necessary UI demonstration” while working on a small utility-project “doclib” that I wrote for myself to manage a collection of documents on the file-system using symlinks for various tags and representations. (Something completely unrelated and not written for any other purpose.) All of these idiotic claims and unfounded demands are complete nonsense, and were never discussed.

Changelog

This article will receive updates, if necessary.

• 2026-05-03 Initial version.