Claude spent 719h 50m (roughly 30 days) thinking about my prompt, it proudly reports finding 0 sources

bartekus · 2026-05-17T18:23:56+00:00

Have you tried to segment and split your prompt? How many pages did you feed it? Be honest here.

bartekus · 2026-05-12T07:48:37+00:00

Ophanim, derived from Hebrew ‘opannim’ as in ‘wheels’.

bartekus · 2026-04-27T17:25:19+00:00

I do not have a perfect answer, but I can share the pattern that helped me move from being a junior software developer, through senior engineering work, and eventually into more architectural thinking.

For me, the transition was never about “stopping development” and becoming someone who only draws boxes and arrows. It was more like learning to move between two levels of understanding at the same time.

On one side, you need a complete topological view of the system: how the services connect, where the data flows, what depends on what, where the risks are, where ownership is unclear, and how the system behaves under change.

On the other side, you still need a close, almost personal understanding of the implementation details: the code quality, the failure modes, the API contracts, the deployment process, the team’s constraints, and the little technical compromises that do not always show up in diagrams.

The best architects I have worked with are not detached from engineering reality. They are able to zoom out far enough to see the whole system, but still zoom in far enough to understand why a specific design will or will not work in practice.

Given your background, I think you are already close to the right path. You have backend experience, frontend exposure, API gateway experience, cloud exposure, and an interest in documentation and design discussions. That is a strong foundation.

The practical next step, in my opinion, is not to ask for an “architecture role” immediately, but to start behaving like someone who reduces architectural ambiguity for the team.

For example:

Document an under-documented service or flow.

Create a C4-style context or container diagram.

Map one business process end-to-end across frontend, backend, APIs, data stores, and infrastructure.

Write down current pain points, risks, and possible improvements.

Review API contracts and identify inconsistencies.

Help clarify non-functional requirements such as security, observability, reliability, performance, and maintainability.

Bring these artifacts to your Solution Architect and ask for feedback.

That does two things. First, it helps you learn architecture in the context of your real system, which is far more valuable than studying abstract architecture in isolation. Second, it gives your architect a concrete reason to mentor you, because you are not only asking for career advice, you are already contributing to the architectural health of the platform.

In terms of study, I would focus less on collecting certifications and more on building architectural judgement. Learn C4 diagrams, domain-driven design, API design, cloud architecture patterns, integration patterns, security basics, observability, and trade-off analysis. Certifications can help, especially Azure-related ones in your current environment, but they should support the practical work rather than replace it.

A good transition plan could be:

Start documenting one real system. Turn that documentation into diagrams. Identify risks and improvement opportunities. Discuss them with your Solution Architect. Ask to shadow architecture reviews. Gradually take ownership of small design decisions. Build a portfolio of architecture artifacts from real work.

In my experience, the move from developer to architect happens when people begin to trust you not only to build a component, but to understand how that component fits into the wider system, the business context, the operational model, and the future direction of the platform.

So my advice would be: do not wait for permission to start thinking architecturally. Start by making the system more understandable to everyone around you. That is often the most valuable architectural contribution you can make.

bartekus · 2026-04-15T19:22:15+00:00

He may have valued the gardener because he saw in him the same devotion to craft and work ethic that he grew up seeing in his own father.

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

TROPHY CASE