Great effort!, this stuff is hard to do - so applause for getting something shipped! popped an issue into you issues list.
I sometimes find these tools crash hard when pushed via large memory items, huge blobs of code, long base64 strings etc. Even chrome dev tools crash hard on large WS Messages.
Also perhaps post the video near the top instead of hiding it in the origin paper :), kids like videos these days.
Thank you! And thanks for opening the issue - handling very large memory objects is definitely an area of improvement for Wirebrowser. It’s something I plan to harden as the tool matures.
Good point about the video ;) I’ll surface it more prominently, the whitepaper ended up a bit dense, so having the visual demo earlier probably helps a lot.
I once had a banking app that reported the wrong transaction amounts (downloading the statements resulted in a different balance than what was shown in my account -- this isn't the US, so it should show the correct amount). When I reported the bug, they changed the values on my statements instead of fixing the app -- so now, it didn't reflect my receipts.
It was a fun time. They eventually fixed it in the app to show my true balance and fixed my statements back to what it was. But holy shit, the fact that an engineer would think that would be the proper fix is wild... this is pre-llms, otherwise, I'd think they'd been vibe-coding.
I tend to avoid auto-cashiers. It's mostly because I find they don't save any time, and just exist to fire cashiers.
One place that they basically force you to use it, is my local drug store (big chain, that I won't call out by name).
Their auto-cashier absolutely sucks. It's almost impossible to avoid having an issue that requires you waiting around for the poor schulb to come over and fix.
They recently set up touchscreens, at the prescription counter.
I have not once had success with the touchscreen. It can never find me, or my wife. They always have to just take my information manually.
I suspect that the backend (the algorithm and main engine) is good. I think almost all the problems are with shoddy frontend stuff. For example, I think the touchscreen issue is capitalization, and the old system cut off our surnames, so I actually have to type in about half my name, in all caps, to have it find my prescription.
I feel personally offended, when I encounter stuff like that.
I have never used these auto-cashiers or whatever they are called. It might be due to anxiety, which is weird because social encounters should be more anxiety-inducing. I just feel like I would mess something up.
Oh, and here real cashiers usually scam you by scanning the items twice and so forth (not sure if intentionally or not), it happened a couple of times to my parents (not considered elderly yet) in the past few months I would say.
Personally have had great experience in high throughput, complex paas / saas webapps by rigourously only adding things when it was clearly needed.
Recommend you try to start with webcomponents + a well thought out design system -> move on from there and you're pretty sure to have a solid base from which you can always add react, lit, vue or whatever else cooks your noodle.
read some books about how to deal with people on the spectrum - which is what you're really asking about.
Usual acronyms of Asbergers, ADHD, ADD, PDA etc. "difficult engineers" is not something that exits in this world.
There are difficult people, sometimes highly ordered jobs (like programming) attract people who like order -> many of which are on "the spectrum".
Be human, Be Kind and understand how to communicate effectively with several types of people.
You advise to be human and kind but automatically categorize "difficult people" as being on the spectrum? And no worry, some engineers don't need to be on the spectrum to be difficult. Conversely, people on the spectrum are not inherently difficult either.
But I do agree: communication is key. Craftpeople can have trouble taking the team or the business priorities into account. Being the manager, you have to take the other parties' side and talk about the non-technical problems: time to implement (= money and unavailability of the engineer), additional complexity, fragility, making changes more difficult... Convincing is always better but if you argued to no avail, you have to impose your decision – being careful not to be the asshat in the mix.
The point is that "people"'s behaviour is on a bell curve and none of us are "normal"
-> some lie at the edges when they are pressured but are fine when they are relaxed.
-> Some gravitate towards the center - but may slide to either side depending on specific circumstances and situations.
The true fallacy is to think there is anything "normal" at all!
-> rather we have "permissable / accepted" behaviour and "impermissible / unaccepted" and a very very large grayzone in between.
And educating yourself on the edges of that bell curve gives you the tools and acceptance needed to better deal with most of the stuff happening on that curve.
> You advise to be human and kind but automatically categorize "difficult people" as being on the spectrum?
Perhaps like me they reject the people referred to are "difficult people" but believe the behaviors listed refer to people on the spectrum or otherwise neurodivergent.
exactly - all people are normal, all people are difficult, no person is normal, some people are more often challenged that others.
Judging for normalcy is a fallacy
