On Interns
A hypothetical intern or very junior/first-time programmer comes up a lot in discussion of design patterns. “Sure,” pattern advocates say. “Deciding what to do on a case-by-case basis informed by pragmatism and experience is swell, but what about someone who is too early in their career to have either of those things? We need to give the masses opiates come up with a set of hard-and-fast rules people can follow without understanding them first, to get them productive quickly. They can grow into the subjective/squishy decisionmaking later”.
Okay, first of all, patronising. Plenty of bright first-timers–hell, plenty of first-time programming students–can acquire fairly match-grade levels of pragmatism and assessment in just a few weeks. The pragmatism/decisionmaking bit can, surprisingly, develop at a totally orthogonal rate to the actual technical chops of programming in whatever language or stack.
Whether they do or not has a lot more to do with their mentorship and environment than some British-boarding-school “these things just take time” trope (in other words: if your folks aren’t growing those skills in short order, they probably never will and the issue probably extends a lot further than your junior staff–it may extend all the way into your mirror).
We’re really not talking “memorized enterprise architecture textbooks” here, either: for a junior, good design heuristics start with “OK, unfamiliar code. Should I follow a ‘when in rome’ approach? Or do these romans smell somewhat funny? I guess I should probably ask if all these open street latrines are a normal practice in the streets of Rome, or if that’s something regrettable practiced only in this area…"-type stuff.
Second of all, if your interns need to be rushed into the productivity grind so quickly that you can’t front-load a few months (1)Fortunately for your deadlines, “months” is rarely contiguous up-front: someone shows up to their first day on the job, spends a few weeks learning the very basics, spends a day being productive (easy first feature or doc change or whatnot) and 4-5 days learning more, then spends 2-3 productive days, 2-3 learning days, and so on until most of their time is spent being productive. And besides, that 2-3 days on/2-3 days off rhythm? Some people follow that for their entire career. We have a word for those people: “architects” (I jest, I jest). of developing them into actually competent decisionmakers, your interns should seek better employment.
Third, let’s back up a little. Programmers are substantially overpaid at this moment in history–s/substantially/astronomically/ in the United States–so the hypothetical intern or entry-level person we’re talking about here is making a dandy chunk of change, junior or not. Do you really want a design-pattern-following, unthinking feature-factory cookie-cutting automaton for that kind of money? You don’t. If you think you do, repeat the words “professional ethics” over and over to yourself in a mirror. They will require you to make your mouth into some strange shapes. That’s expected behaviour.
Rather, we are paid enough, and trusted enough with users’ data and day-to-day experiences, that we should be making hard judgement calls to justify that cash value.
If you want a pattern-matching feature factory, have ChatGPT write the damn signup flow.