Here are some examples of using the word “just” to trivialize or minimize something:
“Can you just throw together a quick prototype?”
(Implies the work is quick and simple, overlooking design, testing, or user needs.)
“Let’s just rewrite the whole thing in [language].”
(Downplays the scope, effort, and risks of a full rewrite.)
“Why don’t you just refactor the whole module?”
(Minimizes the analysis, testing, and interdependencies involved.)
“Can’t we just deploy it to production and see what happens?”
(Oversimplifies the risk, process, and potential consequences.)
“You could just add a feature flag.”
(Ignores the architectural decisions, testing, and rollout implications.)
“Can you just hop on a call and explain the whole system?”
(Minimizes the depth and complexity of the system.)
The word “just” both trivializes the work involved, and sets an expectation with other people in the conversation that any further questions or discussion are going to make them look dumb.
To avoid doing that, and to help reveal the hidden complexity in things, replace “just” with questions that validate (or more often, invalidate) your assumptions about a task’s complexity:
🔍 Code & Architecture
- “What are the side effects of this change, and how confident are we that we understand them?”
- “What systems or services consume this code?”
- “Are there any architectural decisions that this change touches or contradicts?”
- “How many places in the codebase rely on this logic?”
- “Do we understand which layer in our architecture is likely responsible for this issue?”
✅ Testing & Safety
- “What automated or manual tests will catch if this breaks?”
- “Do we have coverage for this path, or are we flying blind?”
- “If we ship this and it’s wrong, how would we find out?”
- “Is there a rollback plan or safety net in place?”
- “Are there any tests that we need to add or update based on this change?”
🔄 Dependencies & Integration
- “Are any external systems or teams depending on this behavior staying the same?”
- “Could this impact downstream services, even indirectly?”
- “Is there versioning, caching, or data migration involved?”
👥 Ownership & Process
- “Who owns this area of the code, and have they weighed in?”
- “Are there any security or compliance checks this would trigger?”
- “Is this change consistent with our design or team norms?”
🧠 Knowledge & Decision-Making
- “What unknowns still exist about the problem we’re solving?”
- “Have we seen this issue before, and what made it harder than expected then?”
- “What assumptions are we making that, if wrong, would cause this to fail?”
- “What’s the worst-case scenario if we’re wrong about how easy this is?”
🤖 Delegation & Agent Usage
- “Will the agent understand the architectural boundaries or design patterns we use here?”
- “Is this something a coding agent can attempt reliably, or does it require domain context?”
- “Is this bug a good candidate for a coding agent to take a first pass at a solution, to be followed up by an engineer’s review?”
Is there a good usage of the word “just”?
One way to use “just” is to do it with irony or sarcasm to indicate you don’t know everything’s that involved in the work. Scare quotes required.
And other meanings, such as the one related to “justice”, are unaffected by the above commentary.
