The square peg problem

Every cohort has a version of this conversation: someone with a decade of clinical practice sits across from someone with a computer science degree and half their age, and assumes the comparison runs one direction.

The feeling arrives in the first week, usually in a lab session: everyone else seems to already speak the language, and you are translating every sentence before you can respond to it. This essay is about what is actually happening in that room, and why the people who feel like square pegs are often holding the sharper part of the wedge.

The comp sci cohort has a real advantage, and it is smaller than it looks

They are faster with syntax. They have already built things with a keyboard, so the tools feel less like an obstacle. That is a genuine head start in the first semester, and pretending otherwise does nobody any favours.

The gap is real in raw coding fluency for the first two terms. You will watch someone write a loop while you are still looking up what a loop is for. That is not a character flaw; it is a sequencing difference in what you were doing at age twenty.

What is actually happening in the first lab

Most of what feels like a knowledge gap is a vocabulary gap, and vocabulary closes fast.

You will learn what a foreign key is in an afternoon. You will not learn, in an afternoon, what a discharge summary needs to actually communicate to the next clinician who reads it under time pressure. That took years, and it is still yours.

The first lab is disorienting because both cohorts are pretending fluency they do not have. The CS grad knows Python syntax but may never have watched a nurse reconcile medications at bedside. The RN knows exactly when a workflow fails but may never have seen a terminal window. Everyone is performing competence in half the room.

What separates the two groups in week one is not intelligence. It is which half of the vocabulary was already installed before orientation. The install for clinical terms took a career. The install for technical terms takes a semester, sometimes less if you stop apologising and start taking notes.

What the clinical cohort has that does not show up on a syllabus

You know what breaks in practice. You know that a beautifully designed order set fails the moment a busy nurse has eleven seconds to use it. You know which workarounds a workflow will generate before it ships, because you have lived inside workflows that generated them. This is not a soft skill footnote; it is the actual constraint that most systems fail against.

You also know what done means in a care setting, which is not what done means in a sprint demo.

Done on a ward means: the next shift can safely take over, the patient knows what to do at home, the chart supports billing without a retrospective scavenger hunt, and nothing is waiting in someone's head because the system would not accept the entry. Done in a software meeting often means: the feature deployed, the ticket closed, the demo worked on staging with test patients named Alice and Bob.

Projects fail in the gap between those two definitions. Not because developers are careless, but because nobody wrote down which definition they were using until go-live week.

Where the gap is real, and where it is not

The gap is not real in judgement about which problems are worth solving. It is not real in understanding whether a proposed shortcut will create silent harm three steps downstream. Those are the parts that decide whether a project succeeds, and they do not correlate with how fast someone writes a for loop.

The pattern, stated plainly: systems built by people who never touched the workflow they are automating tend to be technically correct and operationally wrong. The square peg cohort, the ones who came from the ward, the pharmacy, the clinic floor, are disproportionately the ones who catch this before launch, not after.

That is the brand thesis in one sentence. Health informatics does not need more people who can build anything. It needs more people who can tell when the thing being built will not survive contact with Tuesday night in the ED.

A concrete project failure mode

Consider a discharge checklist app, built by a team with strong engineering and no clinical sit time. Requirements gathered in three conference-room sessions. MVP shipped on schedule.

Technically: forms render, fields validate, data persists, dashboard counts completions.

Operationally:

• The checklist lives in a tablet app separate from the EHR. Nurses document once in Epic and again in the app because the integration was "phase two."
• "Patient educated on red flags" is a checkbox with no free text. The patient who needs a specific warning about anticoagulation gets the same generic tick as everyone else.
• Completion is measured at click time, not at comprehension. Management sees 94% compliance. Frontline staff know the last three clicks happened while the patient was asleep and the cart was outside the door.

Go-live metrics look fine for ninety days. Readmission rates do not move. The project is labelled " adoption failure" and the ward is blamed for resistance.

The square peg in the room, if anyone asked them in month one, would have said: "This adds a second documentation surface during the busiest ten minutes of the stay, and compliance will measure clicks not understanding." That is not a technical objection. It is the whole project, seen accurately.

Failure modes like this are predictable. They are also boring, which is why they repeat. Someone with floor experience names them early and is told to stay high-level. Six months later the same person is invited to a retrospective and asked why nobody spoke up.

The part nobody tells you

The gap closes faster than the anxiety about the gap does. Most students find that by the second year, the conversation has quietly inverted: the comp sci cohort is asking them what actually happens on a unit at 3 a.m., because that is the part the syllabus never covered, and it turns out to matter more than anyone let on.

You are not waiting to become technical enough to contribute. You are waiting to become bilingual. The second language is learnable. The first one took a decade and cannot be downloaded from a repo.

What to do with this if it is you

Stop treating your clinical background as the thing you are behind despite. It is the thing the comp sci cohort spends years trying to acquire secondhand, through shadowing and stakeholder interviews, and you already have it.

Learn the syntax. Keep the instinct. Do not trade one for the other.

Practical moves, not pep talk:

• Say the operational failure mode out loud once, early, in writing. Email is fine. "Second documentation surface during discharge" is a sentence future you can point to.
• Ask to sit one real shift before signing off on workflow diagrams. One shift converts abstract boxes into remembered faces.
• Keep a glossary. Your technical terms will accumulate faster than you think. So will your credibility when you use them correctly in the same sentence as a ward example.
• Do not perform ignorance of clinical reality to fit in with engineers, and do not perform ignorance of engineering to fit in with clinicians. The job is the intersection. Both rooms need you literate enough to translate.

The square peg problem is not that clinical people do not belong in informatics. It is that the field keeps hiring round holes and acting surprised when the pegs mark the frame. The marks are the point. They show where the design actually touches the building.

If you came from practice, you are not behind. You are early to a different part of the problem, the part that decides whether any of the code survives contact with real patients. Learn the keyboard. Trust the instinct you earned before you knew what FHIR stood for. The cohort needs both, in the same person, and you are already halfway there.