Hard-to-swallow truths they won't tell you about software engineer job

Legacy vs greenfield work

• Many enjoy legacy systems: likened to archaeology, real products with customers, less “analysis paralysis.”
• Others find undocumented, brittle, testless legacy code “quicksand” and strongly prefer greenfield.
• Consensus: experience varies by management quality, team, and how well the old system was designed.

College and self-education

• Mixed views on how well CS degrees prepare you: theory often clicks years later (data structures, FP, OS, security).
• Several argue you can self‑learn the same material, but note most self‑taught devs lack the discipline to cover the full CS curriculum.
• Others say most real learning still happens “on the streets” at work; college is just a baseline and shared vocabulary.

Clean code, maintainability, and business value

• Strong disagreement with “nobody cares about your clean code.”
• Many say clarity and tests are crucial for future maintainers (including yourself), speed of change, fewer regressions, and lower support load.
• But people also note business will routinely trade cleanliness for speed, especially early on or under pressure.

Soft skills, politics, and promotion

• Broad agreement that communication, likeability, and internal visibility drive promotions more than pure technical output.
• Some describe environments where mediocre or incompetent coders become team leads by managing up, running meetings, and “selling” work.
• Others push back, saying good orgs do value technical leadership and that you can choose better companies.

Estimation and planning

• Large subthread: estimating is hard due to unknowns, changing requirements, dependencies, and organizational politics.
• Tactics mentioned: pad estimates (sometimes heavily), clearly state assumptions/risks, and continuously re-estimate with feedback.
• Some advocate refusing to give detailed estimates, or having managers own them; others view that as unrealistic.

Meetings, work–life balance, and on-call

• Many complain about excessive, low‑value meetings; some use remote meetings to multitask. Others see meetings as necessary coordination.
• Experiences with WLB diverge sharply: some report long hours, 24/7 on‑call, and inability to “switch off”; others say they can easily disconnect and work very reasonable hours.
• Visa status, company culture, product criticality, and life stage (kids, etc.) all affect this.

Competence, teams, and management

• Repeated stories of truly incompetent devs causing massive tech debt yet being retained or promoted.
• Some argue competence is a spectrum and legacy messes often come from time pressure and changing requirements, not stupidity.
• Others assert there’s a small but real fraction of developers whose removal increases team productivity.
• Management quality and incentives (speed vs quality, honest planning vs “heroics”) heavily shape how painful the job feels.

Job security, layoffs, and career arc

• Many say you’re likely to experience layoffs early; advice includes openly debriefing with peers and treating severance plus a new job as a potential net positive.
• Ageism and plateauing compensation are mentioned; specialization and soft skills seen as key to staying valuable.

Is software engineering a “dream job”?

• Some find the article overly negative, stressing: high pay, indoor work, intellectual challenge, global mobility, and good WLB relative to many professions (nursing, trucking, teaching).
• Others, especially mid‑/late‑career, express deep cynicism about politics, meaningless projects, stress, and burnout, yet still often concede it beats most alternatives.
• Common middle ground: it’s not the glamorous social‑media fantasy, but for many it’s still one of the best available careers—if you pick your company and role carefully and maintain boundaries.