Sean Goedecke is a software engineer and writer known for his pragmatic, often contrarian advice on engineering careers, tech politics, and system design. His writing typically focuses on the "unwritten rules" of large tech companies.

On Career Strategy & "Dangerous Advice"

  1. "Most career advice is fake: written to avoid liability, or to impress people."[1]
  2. "Strong engineers crave dangerous advice, for the same reason they crave sharp tools."[1]
  3. "Make your own decisions about what to work on. Deliberately break written company rules sometimes."
  4. "If you’re serious about getting things done, you’ll end up doing some of these things because they’re obviously helpful."
  5. "Managers will almost never give you dangerous advice, even if it’s what you need to hear."[1]
  6. "One month of grinding in the spotlight is worth one year of grinding in the dark."
  7. "If you’re not working on anything in the company’s top priorities, the company is going to (probably) reward you less for it."[2]
  8. "The only way to reliably avoid being laid off is to (a) be competent... and (b) attach yourself to profit centers in the company."
  9. "Don't spend unpaid, extra-hours time on invisible work."
  10. "Habits that got you rewarded during [the 2010s] may be actively harmful now."
  11. "It can be deeply alienating to know things don't work the way they officially should, but to have nobody to talk about it with."
  12. "Identify as a bit of a 'grifter'... take strong positions even when you're uncertain."

On Office Politics & Power

  1. "Software engineers are tools in the political game being played at large companies, not players in their own right."
  2. "Only a crisis—actual or perceived—produces real change."
  3. "When that crisis occurs, the actions that are taken depend on the ideas that are lying around."
  4. "Your basic function is to develop alternatives to existing policies, to keep them alive... until the politically impossible becomes politically inevitable."
  5. "Large tech companies are full of predators: people who want to extract uncompensated work from competent engineers."
  6. "Helping other parts of the org is not your main job. Delivering projects is your main job."
  7. "Predators aren't in a position to reward you (i.e. they're not in your management chain)."
  8. "When you break rules, only the results matter. When you follow the rules, you have something to point to when things go wrong."
  9. "Rules exist to constrain engineers with bad judgment, not to bind the ones with good judgment."
  10. "Plausible deniability is part of the system."
  11. "Tech companies leadership often views engineers as useful idiots. Managers are expected to be professionals."

On Engineering & Shipping

  1. "Shipping in a big tech company is a very different skill to writing code, and lots of people who are great at writing code are terrible at shipping."
  2. "Remember that an un-celebrated launch is not a ship!"
  3. "If you ship something users hate and makes no money, but your leadership team is happy, you still shipped."
  4. "The best way to anticipate problems is to deploy early."
  5. "Obsessing over UX is praiseworthy behaviour when you are an engineer on the team, but a blunder if you are leading the project."
  6. "Obvious things are the most important. If you get the obvious things right, it's OK to get some of the more tricky things wrong."
  7. "Being good at shipping covers a multitude of sins in tech companies."
  8. "Even if something seems obvious to you, other people might not know it."
  9. "Expertise in software is the mastery of invariants: beliefs about how software works that are true 99.99% of the time."
  10. "The opposite of thinking clearly is frantically trying different things until the problem goes away."
  11. "Slow down! To think clearly, think slowly."

On System & API Design

  1. "Paradoxically, good design is self-effacing: bad design is often more impressive than good."
  2. "I'm always suspicious of impressive-looking systems."
  3. "If software design is how you assemble lines of code, system design is how you assemble services."
  4. "You should try and minimize the amount of stateful components in any system... stateful components can get into a bad state."
  5. "As a maintainer of an API, you have something like a sacred duty to avoid harming your downstream consumers."
  6. "A technically-great API can't save a product that nobody wants to use."
  7. "API design is about finding a balance between... the simplest API possible [and] flexibility long-term."
  8. "Don't break userspace."

On "Legibility" & Organizational Theory

  1. "Modern organizations exert control by maximising 'legibility': by altering the system so that all parts of it can be measured."
  2. "Illegible work is everything else: asking for and giving favors, using tacit knowledge... and drawing on interpersonal relationships."
  3. "Engineer-driven work doesn't need to be translated into something that makes sense... it can just be done."
  4. "If you announce publicly that you're getting a piece of work done through backchannels... you will be punished."
  5. "Sociopaths use [the illegible] world to climb the ladder, while losers use it to carve out a cosy low-effort niche."
  6. "The 'clueless' are only engaged with legible processes."

General Wisdom

  1. "I prefer iterating fast on an 80% solution than spending a lot of time to slowly polish a 100% solution."
  2. "A job where reliability and performance is important, at scale." (Describing his ideal engineering environment)

On Staff & Principal Engineering

  1. "You do not get to staff by being a great mentor... you get to staff by delivering value for the company."[1]
  2. "My mission as a staff engineer is to provide technical clarity to the organization."
  3. "Senior engineers are graded on execution.[1] Staff engineers are graded on results."
  4. "If you do solid technical work but the project fails for non-technical reasons... that is your fault."
  5. "An engineer who answers most questions with 'well, I can't be sure' is useless as an advisor."
  6. "Scheming takes practice and power, and neither of those things are available to software engineers."[3]
  7. "The default state of a project is to fail. Projects only succeed because people drag them kicking and screaming to the finish line."
  8. "One demo of 'hey look at this thing working' can cut through weeks of conversation."

On Technical Writing & Communication

  1. "To get better at technical writing, lower your expectations. Your readers will typically read the first sentence, skim the next, and stop."
  2. "If you can communicate your idea in a single sentence, do that."
  3. "Omit subtle details. This is the biggest difference between technical writing and code."
  4. "You should frontload all important information. If you spend a paragraph throat-clearing, you've lost them."
  5. "Good technical writing helps people trust you, even if they're still confused."

On Code Review & Quality

  1. "Most of the highest-impact code review comments have very little to do with the diff at all."
  2. "Don't just review the diff. Consider what code isn't being written."
  3. "A good code review shouldn't contain more than five or six comments."
  4. "If you want to block, leave a blocking review. Don't be passive-aggressive."
  5. "Code review is not the time for you to impose your personal taste on a colleague."
  6. "Consistency is the cardinal value in large established codebases."

On AI & The Future of Coding

  1. "Vibe coding is basically coding without touching the keyboard... growing a codebase without seeing any of the lines."
  2. "I use AI agents to write most of my front-end stuff... but for Go code, I often have to do it by hand because the agent isn't quite there yet."
  3. "There is going to be a new set of engineering values... how much engineers need to manually review AI work is still up in the air."
  4. "LLMs can think in a way that is useful to engineers, but they don't think as well as a strong engineer."

Specific Technical Opinions

  1. "I'm more excited by maintenance than rewrites."
  2. "Good APIs are boring. An API that's interesting is a bad API."
  3. "You should never make a change to an API just because it'd be neater."
  4. "I don't like GraphQL very much... it's completely impenetrable to non-engineers."
  5. "A complex system usually reflects an absence of good design."
  6. "Do the simplest thing that could possibly work. It's surprising how far you can take this advice."
  7. "You can't iterate your way inside constraints, you have to start there."

Sources

  1. seangoedecke.com
  2. seangoedecke.com
  3. seangoedecke.com
  4. seangoedecke.com
  5. seangoedecke.com
  6. seangoedecke.com
  7. seangoedecke.com
  8. seangoedecke.com
  9. seangoedecke.com
  10. seangoedecke.com
  11. seangoedecke.com
  12. seangoedecke.com
  13. seangoedecke.com
  14. seangoedecke.com
  15. seangoedecke.com
  16. seangoedecke.com
  17. youtube.com
  18. seangoedecke.com
  19. youtube.com
  20. seangoedecke.com
  21. seangoedecke.com