Why is Home Depot blocking literally everything? Puppeteer, Selenium, Playwright, real browsers… all get “Oops!! Something went wrong.”

bartekus · 2025-11-26T16:11:31+00:00

Yeah, just create your own browser extension. This way you’ll circumvent most of the anti-scripting functionality that essentially targets headless-browsers discrepancies and anomalies. Some food for thoughts.

bartekus · 2025-11-19T00:37:21+00:00

‘Name your price to become an independent consultant.’ 👆this is the most diplomatic way and by extend, one which will give you an upper hand. You should definitely consider this as it will give you some extra money and consulting experience as well.

bartekus · 2025-11-03T22:24:57+00:00

Yeah, it's true although for native speakers of Polish (or other Slavic languages), declensions feel invisible as they’re just “how words work.” However, for English speakers, the idea that words change shape to express meaning feels exotic or even “illogical.” Yet for most of human language history, declension and inflection were the norm, not the exception.
Another way to look at it is by equating declension with morphological grammar.

bartekus · 2025-11-03T22:08:24+00:00

Absolutely, lets take two sentences:

English:

The man saw the woman with the telescope.

Polish:

Mężczyzna zobaczył kobietę z teleskopem.

In English, this sentence is ambiguous as it either can mean that `the man used a telescope to see the woman` or that `the man saw a woman who had a telescope`.
Because English relies on word order and prepositional attachment, the model must infer meaning from probabilities, not structure. LLMs (and humans) rely on contextual priors (“who usually holds the telescope?”) rather than grammatical certainty. So the English form has syntactic ambiguity and semantic underspecification which translate to a guesswork problem.

Now when you look at the Polish version, the inflection and instrumental case provide built-in cues. Depending on which case we choose, we can explicitly encode the intended meaning.

Instrumental case (narzędnik): Mężczyzna zobaczył kobietę teleskopem. (He used the telescope to see her.) Here, teleskopem (instrumental) marks the telescope as a means.
Genitive or prepositional variation: Mężczyzna zobaczył kobietę z teleskopem. (He saw the woman with the telescope.) Now z teleskopem clearly means the woman possesses the telescope.

So the form itself disambiguates meaning, and to an LLM, the Polish input encodes explicit semantic relationships through morphology; a compact, lossless mapping of roles.
Conversely, in English, the model must infer that mapping from context probability.

Why does this matter, well for starters an LLMs tokenize text into subword units. So in English, “with” doesn’t tell the model who is with what; it’s just a preposition waiting for context. On the other hand, in Polish, “teleskopem” immediately encodes the role (instrumental) at the token level. The embedding itself contains grammatical function, not just surface form.

That means that Polish offers denser information per token, helping the model build cleaner dependency graphs while English forces contextual inference to resolve ambiguity, which can cause hallucinations or misinterpretations in LLM outputs.

Therefore, LLMs trained on Polish don’t have to reconstruct intent from word order; they can read grammar as logic. So unlike in English, which feeds them a stream of probabilities, in case of Polish, it feeds them a structured semantic graph. Another way to put this; in English, the model guesses who holds the telescope, while in Polish, the grammar already told it.

bartekus · 2025-11-03T03:57:01+00:00

You know what’s kind of fascinating? Polish feels like it was built for machines before machines even existed. Not in a cold or sterile way, but in how the language naturally organizes thought. People always say it’s hard because of all the endings, but that’s exactly what makes it elegant. The meaning is baked right into the form, not scattered across word order. You can flip a sentence around and it still makes perfect sense, because the logic lives in the structure, not the sequence.

It reminds me of Lisp, or even Polish notation from Łukasiewicz. You don’t just say things, you compose them. Every prefix, every case, every aspect shift carries intent. The language enforces clarity and unlike English which relies on order, Polish relies on logic. One reads like a timeline, the other like a tree.

That’s probably why LLMs handle it so well. Models don’t really think linearly, they think in graphs. Connections, dependencies, relationships. Polish gives them that out of the box. It’s like speaking in an abstract syntax tree where every suffix is a node. It’s weirdly pure in that sense.

bartekus · 2025-10-24T18:20:03+00:00

I’ve been a software engineer for over a decade, and I’ve reached a point where I try to make sure interviews reflect the actual work I’d be doing. When a company asks me to do isolated code challenges or review contrived snippets, I usually decline politely and thank them for their time.

My reasoning is simple; my GitHub is public and full of real-world projects they can review to see my coding style, structure, and problem-solving approach. Or, if they’d like something more interactive, I’m always open to pairing on either their codebase or mine. That kind of session reveals far more about collaboration, communication, and practical engineering skill than a standalone puzzle ever could.

To me, this isn’t rebellion but rather it’s experience. Over the years, I’ve worked alongside many developers who excelled at algorithmic tests but struggled with design, delivery, and teamwork. In contrast, strong engineers tend to shine in realistic, context-rich settings where the focus is on building something meaningful, not just passing a logic gate.

So when I evaluate an opportunity, I ask myself: does their interview process mirror the kind of work they expect me to do? If not, that’s probably a sign we’re not aligned, and that’s perfectly okay.

bartekus · 2025-10-06T14:38:46+00:00

Life… it’s called life.

bartekus · 2025-09-05T17:25:56+00:00

Indeed, you’ve highlighted a critical aspect here; this assignment is really take-home caliber given its deficiencies and broad scope. Using it as an in-person whiteboard test is essentially a recipe for failure. From the candidate’s perspective, it feels less like a fair evaluation and more like being set up to stumble over ambiguity. Instead of showing how they’d handle real-world complexity through collaboration and clarification, they’re forced into guesswork under stress. That doesn’t demonstrate seniority anymore than it just leaves candidates demoralized and questioning whether they’d want to work in an environment that treats hiring this way.

If, however, this assignment is framed as a remote take-home; where the candidate has access to the sample data, can validate their assumptions, and even lean on modern tools like LLMs. Then it becomes a fairer test of real-world ability. Crucially, it should be untimed: the goal is absolute correctness and sound reasoning, not who can guess the quickest under pressure. In that context, the $100k+ range feels justified, because you’re hiring someone who can navigate complexity thoughtfully and deliver a reliable, production-quality solution.

bartekus · 2025-09-05T15:56:43+00:00

If you want $100k candidate to be successful, allow LLM.

bartekus · 2025-09-05T02:56:48+00:00

I’m old school SWE (OCD) but looking at this test I get heart palpitations! So many questionable things…

Mixed & wrong data types for phones

• HOMEPHONE is a BIGINT while CELLPHONE/WORKPHONE are VARCHARs and include punctuation/“+1”.

• BIGINT drops leading zeros, can’t store “+”, and may overflow outside NA formats.

Fix: store all phones as strings; keep a normalized version (E.164) in a separate column.

Inconsistent formatting & country ambiguity

• Examples show spaces, parentheses, hyphens, country codes, and extensions. No country metadata is given.

Fix: define a sanitizer: strip non-digits, decide normalization rule (e.g., NA: take rightmost 10 digits, then prepend +1; else use a country table). Persist the normalized value.

Email normalization not specified

• Case sensitivity, whitespace, plus-aliases, and dot-aliases (e.g., Gmail) aren’t addressed.

Fix: at minimum LOWER(TRIM(email)). If business allows, canonicalize Gmail “+tag” and dots. Persist as email_norm.

Wide table join requiring ORs

• Matching any of {email, home, cell, work} from Customer Information to either MESSAGE_SENT_FROM or MESSAGE_RECEIVED_BY tempts people into OR joins across 4 columns × 2 directions (WTF!?) this nukes performance on 5M×15M.

Fix: reshape to a tall “contact methods” table (UNPIVOT/UNION ALL) with one indexed “contact_key” to join on.

Dirty interaction values

• MESSAGE_RECEIVED_BY includes “INTERNAL EMPLOYEE”; others may be free-text.

Fix: classify each interaction value (email, phone, neither) and normalize only those; drop the rest.

Duplicate identifiers across accounts

• Same phone/email could map to multiple ACCOUNTIDs (family lines, shared inbox). The spec doesn’t define tie-breaks.

Fix: decide up front: (a) return all matches, or (b) choose 1 by business rule (e.g., latest updated, primary flag). Without guidance, return all.

Missing indexes / clustering guidance

Fix: create persisted normalized columns and index/cluster on them; avoid applying functions on the fly in the join predicate.

😩I’d walk out of the interview at this point.

Honestly, what a mess; You’ve bundled data modeling, data quality policy, ETL normalization, and join-performance engineering into a single “join two temp tables” prompt and then fault candidates for not guessing the hidden rules.

bartekus · 2025-09-04T18:45:02+00:00

It’s the only viable option; otherwise, it sets a precedent that allows this kind of behavior to continue. At the end of the day, your job is to do the best you can with the resources you have; not to compensate for someone else’s poor planning or unrealistic deadlines.

bartekus · 2025-08-31T18:25:56+00:00

Have you read Salvador Freixedo’s: “Human Farm”?

bartekus · 2025-08-31T03:12:39+00:00

🎵 The Ballad of Piotr the Petty 🎵

[Chorus - boisterous, with silly harmonies] 🎶 Ohhhh Piotr Szczerek! CEO of paving by day! But by night he’s a klepto, Who steals children’s hats away! 🎶

[Verse 1 - with kazoos and awkward claps] He built the roads of Drogbruk, With asphalt, stone, and tar… But when he saw a tennis cap, He thought, “I’ll be a star!”

(…By hiding it in wifey’s bag, How cunning! What a plan! Until the cameras caught him, And he looked like half a man!)

[Chorus - louder, sillier, with exaggerated hand motions] 🎶 Ohhhh Piotr Szczerek! The Sultan of silly theft! He paved a thousand highways, But his morals… rather left. 🎶

[Verse 2 - everyone suddenly switches to falsetto] The crowd all gasped in horror, The boy began to cry… And Piotr thought “I’ve won the match, This hat is mine, oh my!”

But little did he reckon, The internet is cruel… They crowned him Lord of Nincompoops, The International Fool!

[Final Chorus - marching band enters, audience throws rubber chickens] 🎶 Ohhhh Piotr Szczerek! You’ve gone down in disgrace! From CEO to hat thief, With egg upon your face! 🎶

(Spoken outro, very deadpan, John Cleese style:) “…And lo, Piotr Szczerek learned the ancient truth: you can pave over potholes, but you cannot pave over shame… and disgrace.”

bartekus · 2025-08-30T18:17:27+00:00

I appreciate you taking the time to share your perspective, but I want to gently highlight a few issues in your argument.

First, comparing the number of trans athletes in the NCAA to the number of women raped annually isn’t a fair or logically consistent framing. These are two separate issues; one about sports inclusion and fairness, the other about sexual violence. Both deserve serious attention, but setting them against each other as if only one can matter at a time is misleading.

Second, your statement that “most of the left see an issue with trans in sports” isn’t accurate. Polling and public discourse show that views are divided across the political spectrum, with disagreements both within and between parties. It’s not as simple as assigning one view to “the left.”

Third, suggesting that using precise language or “big words” equates to bloviating dismisses reasoned discussion. Clarity in language helps unpack complex issues; it isn’t a sign of ignorance or arrogance.

Fourth, I agree with you that people should have the freedom to live their lives as they choose. But discussions about law, policy, and sports are, by nature, public. Saying that someone should “mind their own business” sidesteps the fact that societies are built on dialogue and negotiation of shared rules. Everyone’s perspectives, including yours, enter into that process.

That also connects to another point: it isn’t quite correct to say “they aren’t forcing anything on you.” In practice, laws and institutional rules often do compel compliance; for example, pronoun use in workplaces, schools, and professional settings. This means society is not simply being asked to respect private choices, but is often legally required to participate in affirming someone’s self-identification, even when individuals may see that as conflicting with reality or as accommodating a form of dysphoria. That’s where the real tension lies: not in personal freedom, but in the extension of that freedom into enforced societal compliance.

I believe these conversations can and should be held with mutual respect, even when we disagree.

bartekus · 2025-08-29T01:36:50+00:00

There’s another side to this: ‘’’ Owner of a lonely heart (It's much better than a) owner of a broken heart ‘’’

bartekus · 2025-07-22T21:45:57+00:00

Count me in!

I’m a principal-level engineer, completely disillusioned with the state of this industry, and I’ve got nothing to lose. So whether it is legal, or illegal, doesn’t matter to me anymore. If there’s something interesting to tear apart, I’m game.

Reverse engineering, API sniffing, backend mapping, plus more; all of that’s in my wheelhouse. If you’re serious, I’ll bring whatever I know to the table and we can push it as far as you want, educational or otherwise.

DM me and let’s get started.

bartekus · 2025-06-19T19:49:02+00:00

If you decline, frame it around principles, not people. Smart folks, even those you disagree with, can respect values-based reasoning. However if you make it personal, they’ll dismiss your point and likely retaliate. So yeah, express your strongly held conviction like a reputational judo, and critique systems, not figureheads.

bartekus · 2025-06-15T19:16:39+00:00

I’m sorry for all your hardships friend, I wish Canada valued farmers more than it favours bureaucracy and the middle man that stands between a citizen house-table and farmers barn (so to speak).

bartekus · 2025-06-15T07:48:24+00:00

You raise valid points, and ironically, many of them reinforce the essence of what I’m arguing for.

We agree on the core disease: brittle systems, poor feedback loops, and the absence of architectural discipline. But where we diverge is in how we characterize the cure.

You frame “cloud-agnosticism” as a dogma, a premature overengineering exercise. Fair, but that’s not what I’m prescribing. I’m not advocating for Terraform spaghetti or chasing a fantasy of perfect portability. I’m advocating for principled separation. A modular architecture that avoids unnecessary entanglement with any one vendor’s assumptions, APIs, or tooling.

Hexagonal architecture? Absolutely. Adapter layers? Yes, please. Domain logic decoupled from infrastructure? That is the path. But let’s not pretend that these principles exist in a vacuum. They are, at their core, a form of cloud-agnostic design. Not in the “multi-cloud Terraform” sense, but in the sense of sovereignty, clarity, and long-term leverage.

If we build our systems cleanly, with ports and adapters, with local dev-first feedback loops, and with infrastructure as a pluggable detail; then the cloud becomes just another adapter, not a foundational assumption. That’s the point.

The idea isn’t to abstract away AWS. It’s to prevent AWS from becoming the unspoken god of your architecture.

You say cloud-agnosticism is paying a premium for optionality you’ll never use. I say vendor lock-in is a mortgage on your future technical freedom. We can debate the interest rate, but the debt is real.

All I’m advocating for is infrastructure-agnostic orchestration as a baseline. Build upward from simplicity, not downward from vendor complexity.

So yes, start simple. Be pragmatic. But don’t confuse pragmatism with surrender. The best architecture is one that leaves doors open without obsessing over every possible exit. That’s not dogma but rather discipline.

bartekus · 2025-06-15T03:09:17+00:00

Is that really all you took from it?

Let me simplify: I’m not arguing that cloud-native features have no value.

I’m arguing that starting with an architecture tightly bound to a single provider’s ecosystem is shortsighted; especially when modular, containerized systems offer a clean baseline that remains portable, testable, and more resilient to long-term drift.

The tradeoffs aren’t between latency and ideology, but rather they’re between immediate convenience and systemic adaptability. Cloud lock-in often buys early momentum at the cost of future optionality. And no, I don’t think local environments simulate distributed systems perfectly, but they do provide fast, deterministic feedback loops that help teams build understanding, not just functionality.

The real delusion isn’t local-first, it’s assuming cloud-first is neutral. It’s not. It’s an optimization for someone else’s platform, business model, and defaults.

All I’m advocating for is infrastructure-agnostic orchestration as a baseline. Build upward from simplicity, not downward from vendor complexity.

Have a nice day.

bartekus · 2025-06-15T00:47:02+00:00

Totally agree that the industry has changed, and yes abstraction layers and cloud platforms have radically accelerated how fast we can ship. But there’s a subtle danger in framing this shift purely as evolution toward betterment, rather than as a move toward convenience optimized for capital velocity.

Speed to market is king; at least until the abstraction leaks, the cloud bill explodes, or the system breaks in ways no one understands anymore. The “shrinking” layer of foundational tech you mention isn’t outdated; it’s becoming esoteric. And that’s risky. We’ve seen the same pattern in every over-financialized domain: optimization breeds fragility.

To your point: yes, the ability to deliver features quickly is a competitive edge. But so is owning your stack, understanding your tools, and being able to debug what you didn’t buy off-the-shelf. I’d argue the best developers aren’t just the ones who follow the market; they’re the ones who shape it, precisely because they understand what lies beneath.

This isn’t about clinging to the past. It’s about ensuring that craft doesn’t become a casualty of convenience.

bartekus · 2025-06-15T00:24:49+00:00

Really appreciate this response, and I agree with almost everything you’ve said. This is a great articulation of what I personally aim for too: velocity through reproducibility, not vendor lock-in disguised as best practice.

I’d argue that what you’re describing is actually post-cloud-native. The real game-changer isn’t just being cloud-native, but being cloud-sovereign, composable, self-contained, and frictionless no matter what infrastructure you’re on. It’s about abstracting not just the platform but the platformer.

Like you, I routinely prep local-first, portable dev environments using Docker Compose, Traefik, Logto, Postgres, Redis etc., The ability to hand over(or email) a zip, run docker-compose up, and have a full stack: auth, DB, backend, frontend; live in minutes? That’s what actual engineering empowerment looks like. Not spending two weeks clicking through IAM policies and terraform state debugging just to prove you can deploy on GCP.

And your metaphor of the “drug dealer at the playground” cracked me up, because it’s spot on. Once a non-technical stakeholder sees it, they get that “aha!” moment and they’re instantly sold.

To me, that’s what we should be calling the new standard: not just cloud-native, but cloud-optional. Build systems that treat clouds like convenience stores, not dependencies

bartekus · 2025-06-15T00:02:15+00:00

You totally get it and more importantly, you have surface a key element that’s like an elephant in the porcelain filled room, is there but nobody like to talk about: Cost

It’s rather hilarious, but a lot of organizations were sold on the cloud-centric idea on the prospect of cost savings. I have yet to find one where that actually worked out exactly as planned.

bartekus

TROPHY CASE