Dangerous advice for software engineers

Risk, rules, and beginners

  • Several commenters argue that for true beginners, “dangerous” is already the default: they don’t know the rules well enough to know when they’re breaking them, so encouraging rule‑breaking is irresponsible.
  • Safely bending rules requires deep understanding of why they exist (a Chesterton’s‑fence point); novices generally lack this.
  • Cultural differences matter: in some countries people naturally test or ignore rules; in others they’re overly cautious and may need reassurance—but generic internet advice can’t target the right audience.

Safety analogies: chainsaws, carpentry, and software

  • A long subthread disputes the claim that expert arborists remove all chainsaw safety guards. Many say real professionals keep safety gear and PPE; it’s often the reckless or lowest‑tier contractors who bypass safety for speed.
  • Multiple anecdotes illustrate how small deviations plus overconfidence can cause serious injury, even when “being careful.” Humans are bad at low‑probability risk assessment, both before and after accidents.
  • Others emphasize there is a time–money–health trade‑off, especially for self‑employed tradespeople who may rationally accept higher physical risk for higher lifetime earnings.
  • Parallels to software: “safe” languages and guardrails (backups, access controls, processes) can dramatically reduce catastrophic outcomes; intentionally bypassing them should be a conscious, high‑stakes decision, not a default.

Rule‑breaking and “dangerous advice” at work

  • Many managers in the thread strongly object to advice like “deliberately break rules” and “choose your own work.” They say:
    • Everyone, including executives, has mandates tied to business needs.
    • Quietly ignoring policy or going off‑road on pet projects can cause real downstream damage and career blowback, especially for juniors.
    • If you have a better idea, you should sell it, get buy‑in, and then execute.
  • Some nuance: small, tactical rule‑bending (e.g., self‑approving a low‑risk PR, cutting red tape with your manager’s tacit blessing) can be appropriate once you’re trusted and competent.
  • Multiple commenters warn that advice like “take strong positions even if unsure” easily turns into overconfident, wrong engineers derailing teams; better to do homework, expose uncertainty, and use process to catch errors.

Context, competence, and audience fit

  • A recurring criticism is that the article implicitly assumes “you are right and the org is wrong,” which flatters certain personalities and fuels confirmation bias.
  • Several note that career advice is highly context‑dependent: org health, industry, seniority, and personal skill all change whether “dangerous” tactics are wise.
  • A common refrain: if you need generic internet encouragement to break rules or go rogue, you’re probably not yet the person who should.