Harassment: ASML, addendum: prototype-specifics
Sun, May 17, 2026 ❝Elaborating on the briefly mentioned 1st team prototype.❞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 post elaborates on the prototype shortly mentioned in 1st year PO pushing features.
The immediate reason for publishing this post at this time, is the persistent violation of my rights up to this day, some 11 years later. There are several events that very, very strongly hint at my personal laptop, bought from my own money, was sabotaged from the start, some 9+ years back, while working at ASML via my employer. ASML has engaged in an absolutely ridiculous number of hostile actions against me, for no reason. That is, no reason other than an absolutely ridiculous number of lies and false accusations.
Events concerning my laptop can be traced back to several personal activities, and one meet-up at ASML where I met a friend, or maybe I should say acquaintance, who also worked at ASML at the time, after work. Later off-topic messaging via social media hinted at “.., because the laptop connected to a company network once, …”. I have very strong indications, that the laptop was sabotaged from the start, as their patterns hint at extensive malicious activity followed by some cheap “enabling” excuse. The same acquaintance later met up with my group lead, at the company.
I have strong reasons to think that there was interference and manipulation of this laptop going on while still at ASML. Among others, through “spontaneously failing” touchpad malfunctioning. There are indications that hostile actions were taken against me, personally, with the express purpose to interfere with my successful improvements to otr4j and contributions to OTRv4, by engaging in hostile actions against me. In part as an excuse of “retaliation” because of these supposed mean things I did.
After leaving ASML, I have been very aggressively attacked and harassed over supposedly “playing games during work hours (i.e. evenings in personal time)” and “stealing code supposedly from a company (my own work on otr4j in my own personal time)” and “taking other people’s work concerning otr4j as my own (again, my own work on otr4j)”, which were all complete uncomprehensible nonsense to me, unless you consider the hostile assumption that this laptop is “forcibly considered a work laptop”. There were later aggressive threats and harassment and dismissal and refusal to interact “because I supposedly worked on otr4j on my work laptop” (again, false accusations).
In case this seems far-fetched. It is not. There is by now an 11-year history of harassment, attacks, threats, false accusations, lies, and other malicious bullshit that remains unresolved.
Wafer-level control (WLC)
This started out as an experimental prototype in my first team (first year), where we tried to tackle the idea that, in a batch of some 15 wafers, the first ones would have slightly different results due to the hardware just getting warmed up, therefore resulting in minute temperature differences and similar characteristics. The idea of WLC was to discover which of those deviations were systematic among every 1st wafer of a batch, versus every say middle or last wafer of a batch. This prototype looked specifically at artifacts from (varying magnitude) of (lens) aberrations due to inconsistent temperature, where early wafers were expose under relatively colder conditions. Part of the experiment was to implement logic to influence processes on a per-wafer basis. The prototype had to be put together in roughly 2.5 weeks of development, with minimal prior design, and then a coworker would go on a customer visit for the experiment. This was very deliberately a prototype in all the ways it was intended as such: quick & dirty, in a short timespan, completely focused on one specific use-case and unsuitable – well, colloquially speaking, as there was basic exception handling as necessary – for anything else. The prototype helped to evaluate benefits of per-wafer control mechanisms.
Around the same time we implemented some logic that worked with such corrections approximated through Zernike polynomials. The overview image of Zernike polynomials in the Wikipedia article alone is already quite illustrative.
This prototype had not come farther than a stand-alone application. For a while, this prototype became a matter of conflict between PO and dev-team because of the maintenance burden. That is, with the introduction of the application-framework, this became an outlier not only in purpose but also in terms of technological choices. There was interest from customers, but no attention, or much interest for that matter, from PO. To be fair, of course PO is interested to have it be part of the portfolio as-is, because there is zero effort involved. Eventually, a decision was made to include the prototype into the official application, which means we also needed to spend effort on the prototype to raise the level of quality past “quick & dirty” prototype to a maintainable and (officially) supported application.
As an aside, as a prerequisite to wafer-level control it is necessary to measure several batches of production wafers, because we need to compare several 1st wafers of a batch, several 2nd wafers of a batch, and so forth. This would make metrology a serious time investment and bottleneck in an ongoing production process. However, considering that this approach is trying to detect and discover systematic errors, these are predominantly errors originating from hardware. One can distribute measurements over several batches, as not to require measurement of all wafers in a single batch, every batch. The systematic error inherent to hardware imperfections and process inaccuracies would be present irrespective of batch.
The results are (systematic) corrections based on a signature specific to heat-based artifacts. Each correction is specific to a wafer at a certain position in the batch. The correction for each position is independent of other positions, and the hypothesis was that there are, at least, different and possibly more pronounced corrections necessary for first wafer(s) in a batch due to hardware having just started.
Prototypes, maintenance, effort and business expectations
This prototype later spurred discussion on maturation, maintenance burden and business expectations. Basically, dev-team had concerns about a potential maintenance burden, because no decision was made on whether to throw away or include the prototype in the application-framework. The general understanding was that the prototype worked and did it’s thing. But, regardless, the prototype was not developed as a reliable quality application. It was developed as a prototype. Dropping it would mean we stop supporting actual functionality. Adopting it as official application meant bringing it up to quality standards, integrating it in the application framework, and with the emerging UX competence and their insistence there was also a pressing need to re-evaluate the program and turn it from “lots of input controls”-powertool to the format of step-by-step progression. This, as expected, means spending significant amount of effort, and this went counter to the intentions of PO. Hence the subsequent discussions as described in earlier post. This was also the moment where I pointed out that not every tools needs to be a tailored progression of steps. Sometimes, the format of a power-tool – with all controls offered to an experienced engineer for use in whichever way they deem useful – is a benefit.
PO’s ideal solution would have been to “stuff it into the application-framework and that’s it; minimal effort”.
Then, afterwards, and likely spurred on by this discussion and another matter, there was department-wide effort to improve communication and alignment between development and business. The second matter was that of select team-members needing to be informed in a timely manner of prospective upcoming efforts from business. This was important because we had only barely managed to realize previously mentioned large project in time and that time we were warned several weeks in advance to allow for some early preparation, familiarization and information gathering. The insistence on being included in the business process in a timely manner, is what helped set up some process that allowed insight in upcoming high-level topics as identified and handled by business. This is essentially where we used Jira and Epic-level issues to provide the high-level overview and as a communication mechanism between business and development.
Around the same time, this also spurred on discussions on what anyone could and should expect from a “prototype” versus a business application. Discussions would include quality-levels, expectations for unsupported or untested inputs, handling of unsupported/incorrect data whether to crash or handle properly, expectations of support, differences in maintenance burden, etc. This is also where we pointed out that when shit-hits-the-fan suddenly development-teams will have been responsible for maintenance as this involves predominantly technical concerns and maintenance effort, rather than business concerns. And, that development-teams otherwise have considerably less influence in the process, especially when a PO insist on delivering results quickly. Again, this specific prototype was at the root of earlier such discussions, concerns, and conflicts in dev-team’s technical concerns versus business’s functional concerns and “need to deliver”.
Attacks and harassment
There have been deliberate and concerted efforts to express doubt on the sincerity of my efforts and hinting/implying malicious intent on several occasions and in last months even with “targeted deliberate comments” that could be interpreted as threats by several different people from different departments. With some hints referring to early 1st-team efforts and ideas, it is not unreasonable to suspect that working late on several occasions would be interpreted as suspicious. We were asked to leave at ~22:00h by security roaming the building. One of the early occurrences was during the development of this prototype and subsequent support while senior developer traveled to a local office in South-Korea.
The collaboration with “functional domain”-coworker went okay, but from their end there might have been pressure or possibly the evenings that were a bother. By that time I was only there for a few months, and having little knowledge on how ASML operates and meeting the various coworkers only for the first time, I have little knowledge on what otherwise might have played a part, or different workings within other departments. I know they were less involved afterwards, but then they were also one of several “functional domain”-contacts. During the time I had already tried to take up more of the effort as I could, but was also very new at the company. It is also hard to take anything into account when there is no proper communication.
There were extensive efforts to claim “I was constantly complaining” and was only causing needless discussion. Interestingly, all the “needless discussion” was very much to the benefit of development team and its ability to ensure quality and to the detriment of the PO that insistent on mindlessly pushing new features. The “complaining”, in actuality were points of tension and imminent failure, that I could observe because I was part of the process. It is also worth mentioning that despite all my “complaining” I always happen to end up in “one of the best performing teams”, and if put in a “problem-team” ends up working and delivering a more-than-half-year project within the expected delivery window to consider it successful.
Changelog
This article will receive updates, if necessary.
- 2026-05-03 Initial version.