Software Engineering — Good to Know: Rules of Thumb & Mastery Guide

Software Engineering — Good to Know: Rules of Thumb & Mastery Guide

This guide covers everything in the software discipline catalogue that doesn't get a standalone study file: the standard-practice and niche credentials, the standards and regulations you must know cold, the order-of-magnitude numbers that separate seniors from juniors, and the veteran knowledge no exam tests.

1. The standard-practice & niche credentials

Cloud certs below the flagship tier

• Microsoft Certified: Azure Administrator Associate (AZ-104) — the Azure hands-on baseline: VMs, VNets, storage accounts, Entra ID, ARM/Bicep basics. Who needs it: anyone operating Azure day-to-day. When: before AZ-305; it's the prerequisite knowledge in practice even though Microsoft removed formal prerequisites.
• Microsoft Certified: Azure Solutions Architect Expert (AZ-305) — the Azure analogue of SAP-C02 (design-focused, scenario-heavy). Who needs it: architects in Microsoft shops. When: after AZ-104 + real Azure experience. Pairs with the SAP-C02 guide's decision-theory — the trade-offs rhyme, only the service names change.
• Microsoft Certified: DevOps Engineer Expert (AZ-400) — the Azure analogue of DOP-C02: Azure DevOps/GitHub Actions pipelines, IaC with Bicep/Terraform, monitoring with Azure Monitor. Who needs it: DevOps engineers in Azure estates. When: after AZ-104 or AZ-204.
• AWS Certified Developer – Associate / SysOps Administrator – Associate (referenced as DOP-C02 pathway) — the two feeders: DVA for code-level AWS (SDKs, Lambda, DynamoDB, CI/CD), SOA for ops-level (deployments, monitoring, networking). Get the one matching your job before attempting a Professional exam.

Kubernetes family

• Certified Kubernetes Application Developer (CKAD) — the developer's CKA: pods, deployments, services, configmaps/secrets, ingress, probes, resource limits, jobs/cronjobs — all from the workload author side. Lab-based like CKA. Who needs it: app developers deploying to K8s. When: instead of (not after) CKA if you never touch the control plane.
• Certified Kubernetes Security Specialist (CKS) — the hard one: cluster hardening (CIS benchmarks, API server flags), supply-chain security (image signing, admission controllers), runtime security (seccomp/AppArmor, Falco), network policies, secrets encryption. Requires an active CKA first. Who needs it: platform/security engineers. When: after 6–12 months running CKA-level clusters in production. This is the cert that actually moves salaries in platform engineering.

Security certs (software-adjacent)

• CompTIA Security+ (SY0-701) — the entry security baseline: threats, architecture, operations, crypto basics. Who needs it: developers moving into AppSec, or anyone needing a DoD-8570-adjacent checkbox. When: before touching OSCP or security-specialist roles.
• Offensive Security Certified Professional (OSCP+) — 24-hour hands-on pentest exam (hack into machines, write the report). Brutal, respected, and the only cert here that proves you can break things. Who needs it: pentesters and serious AppSec engineers. When: after Security+ and months of lab time (HackTheBox/Proving Grounds). Note the +: OffSec's current branding.
• CISSP — covered by the canonical shared guide: ../shared/cissp-study-guide.md. Management/governance-level; take it when you're moving toward security leadership, not for hands-on engineering proof.

Process & management certs

• PMP — canonical shared guide territory (another worker's shared/pmp-study-guide.md); the heavyweight for engineers moving into program management.
• PMI-ACP — agile practitioner: Scrum, Kanban, Lean, XP practices. Lighter than PMP; useful for Scrum Masters and agile coaches, marginal for IC engineers.
• Certified ScrumMaster (CSM) — 2-day course + quiz. Signals you can run Scrum ceremonies. Honest assessment: it's a vocabulary cert; teams value having run sprints, not the badge.
• SAFe Agilist (SA) — scaled agile for enterprises. Who needs it: people working in SAFe-adopted orgs (banks, telcos, large enterprises). The framework is controversial among practitioners — know the vocabulary if your employer uses it, don't evangelize it.
• CSDP (DISCONTINUED) / CSDA — IEEE Computer Society's attempt at a software PE-equivalent. CSDP is discontinued; CSDA (associate-level, SWEBOK-based) still exists but has near-zero market recognition. The catalogue keeps them for completeness. Do not pursue these for career value — the market never adopted them, which is itself the lesson: software rejected licensure, and vendor certs won.

The meta-lesson

Software has no license to practice and no chartered title with teeth. Careers run on: (1) proof of work (shipped systems), (2) vendor/professional certs as filters (they get you past HR, they don't get you the job), (3) specialization depth. Certs have the highest ROI at career inflection points: breaking in (Associate-level), switching clouds, or moving dev→platform→security. A senior engineer with no certs and a GitHub full of production systems beats a paper-certified junior every time — but the junior with certs beats the junior without.

2. Standards & regulations mastery

ISO/IEC 25010 (SQuaRE) — know cold

The quality model: 8 product quality characteristics — functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, portability — each with sub-characteristics. What practitioners must know: it's the vocabulary for non-functional requirements. When a spec says "the system shall be reliable," 25010 forces the follow-up: which reliability? Maturity (fault avoidance), availability, fault tolerance, recoverability — each measurable differently. How compliance is demonstrated: quality requirements traced to 25010 characteristics, with metrics from 25023. Common violation: writing untestable NFRs ("fast," "user-friendly") — 25010 exists to kill exactly that.

ISO/IEC/IEEE 12207:2017 — software life cycle processes

Defines the process inventory: agreement, organizational project-enabling, technical management, and technical processes (from stakeholder needs definition through disposal). Know cold: it's a process reference model, not a methodology — it doesn't say "do Scrum," it says "whatever you do must cover these processes." Used as the backbone for process assessments and for contracts that need a defined life cycle. Demonstration: process descriptions mapped to 12207 processes, with work products as evidence.

ISO/IEC 27001:2022 + 27002 — information security management

Know cold: it's a management system standard (clauses 4–10: context, leadership, planning, support, operation, evaluation, improvement) plus Annex A controls (93 controls in 4 themes: organizational, people, physical, technological). Certification audits the ISMS, not the product. Demonstration: Statement of Applicability (which Annex A controls apply and why), risk assessment, internal audits, management review. Common violations: treating it as a firewall checklist; no risk assessment driving control selection; stale SoA. For software vendors it's increasingly a procurement gate — enterprise buyers require the certificate.

SOC 2 — know cold

Not a standard but an attestation framework (AICPA): Trust Services Criteria — security (required), availability, processing integrity, confidentiality, privacy. Type I (design at a point in time) vs Type II (operating effectiveness over 6–12 months — the one buyers want). Demonstration: auditor evidence — change tickets, access reviews, pen test reports, incident logs. Common violations: "we're SOC 2 compliant" (it's an attestation, not a certification); letting the audit drive security theater instead of actual control operation. For SaaS startups, SOC 2 Type II is the revenue unblocker for enterprise deals.

IEEE 1012 — verification & validation

V&V processes across the life cycle, with integrity levels (1–4) scaling the rigor. Know cold: verification ("did we build it right?" — reviews, static analysis, testing against specs) vs validation ("did we build the right thing?" — against stakeholder needs). Higher integrity levels demand independence (separate V&V organization). Where it bites: safety-critical and regulated software (medical, avionics-adjacent); contracts citing 1012 mean your test evidence must trace to requirements at the mandated integrity level.

SWEBOK v3 — the body of knowledge

15 knowledge areas from requirements through economics. Not certifiable — it's the reference the (failed) CSDP was built on. Know cold as vocabulary, not as a test: when someone says "software configuration management" vs "software engineering management," SWEBOK is the dictionary.

OWASP ASVS + Top 10 — know cold

ASVS is the verification standard (levels 1–3: opportunistic → standard → advanced assurance); the Top 10 is the awareness list (2021: broken access control #1 — note it outranks injection now). Know cold: ASVS Level 2 is the sane target for most web apps; map each Top 10 item to its ASVS controls. Demonstration: threat model + test plan traced to ASVS requirements; pen test or automated scan evidence. Common violations: testing only the Top 10 (it's a top-10, not a test plan); ignoring access control while chasing exotic injection.

NIST SP 800-218 (SSDF) — know cold

Four practice groups: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), Respond to Vulnerabilities (RV). Know cold: it's what US federal software procurement now expects (EO 14028 lineage) — SBOMs (NTIA minimum elements), provenance, vulnerability disclosure. Demonstration: documented secure SDLC, SBOM generation in the pipeline, vuln response SLAs. Recent change: the CRA (below) is the EU parallel with actual fines — SSDF is the "how" for both.

Section 508 + DOJ Title II rule / ADA Title III / European Accessibility Act — know cold

The accessibility stack: Section 508 (US federal procurement — the Revised 508 incorporates WCAG 2.0 AA by reference); DOJ Title II rule (state/local government digital services must meet WCAG 2.1 AA — compliance dates rolling in 2026–2027, which is now); ADA Title III (private-sector digital accessibility via case law — thousands of lawsuits/year, the "surf-by" litigation industry); European Accessibility Act (applies from June 28, 2025 — e-commerce, banking, transport, e-books sold in the EU). Know cold: WCAG 2.1/2.2 AA is the de facto global target (POUR: perceivable, operable, understandable, robust). Demonstration: accessibility conformance reports (ACR/VPAT), automated + manual testing, keyboard-only walkthroughs. Common violations: overlays/widgets claimed as fixes (they aren't), contrast ratios, missing focus indicators, dynamic content without ARIA live regions. Recent change: the DOJ Title II rule's 2026–2027 deadlines make this urgent for public-sector vendors.

GDPR — know cold (software implications)

Beyond the legal basics: data protection by design and by default (Art. 25) is an architecture requirement — data minimization, purpose limitation, and retention must be designed in, not bolted on. Know: lawful bases, DPIAs for high-risk processing, the right to erasure vs backup reality (crypto-shredding as the practical answer), breach notification (72 hours to the authority), and that fines scale to 4% of global turnover. For ML: training-data provenance and the "legitimate interest" balancing test are the live battlegrounds.

PCI DSS v4.0.1 — know cold (software implications)

Know cold: scope reduction is the whole game — the CDE (cardholder data environment) is everything in scope, so tokenization, P2PE, and hosted fields shrink it. v4.0's big shifts: customized approach (alternative to defined controls, with documentation burden), MFA everywhere for CDE access, authenticated vulnerability scans, and targeted risk analyses replacing some fixed cadences. Demonstration: SAQ or ROC, quarterly ASV scans, annual pen test. Common violations: storing full PAN "temporarily" in logs (the #1 finding), shared admin credentials, unencrypted backups containing CHD.

EU Cyber Resilience Act (Regulation (EU) 2024/2847) — know cold

Applies to products with digital elements sold in the EU: secure-by-design, SBOMs, vulnerability handling with coordinated disclosure, and incident reporting to ENISA (early notification 24h for actively exploited vulns). Fully applies from December 2027 (with earlier dates for reporting obligations). Know cold: the conformity assessment tiers (self-assessment vs notified body for important/critical products); fines up to €15M or 2.5% of turnover. Demonstration: technical documentation, SBOM per release, PSIRT process with SLAs, automatic security updates where applicable. This is the regulation that makes the DOP-C02 pipeline-security content legally mandatory in the EU.

US EAR (encryption/crypto controls) — know

Export Administration Regulations: mass-market encryption software is generally eligible for License Exception ENC with a notification/self-classification requirement (740.17). Know: open-source published encryption is generally not subject to EAR; the trap is proprietary crypto products and certain high-performance computing exports. Know it exists; call export-control counsel for specifics.

FDA SaMD — know

Software as a Medical Device: FDA regulates SaMD by risk class (I/II/III, 510(k) vs De Novo vs PMA); the PCCP (Predetermined Change Control Plan) guidance lets AI/ML devices pre-clear planned modifications. Know: IEC 62304 (software life cycle for medical devices) is the development standard counterpart; clinical validation evidence is the long pole. Call a regulatory specialist — this is not DIY territory.

3. Rules of thumb

Latency (order-of-magnitude, the numbers that should be reflexes):

• L1 cache ~1 ns, RAM ~100 ns, SSD random read ~100 µs, cross-AZ network ~0.5–2 ms, cross-region ~20–150 ms, disk seek (spinning) ~10 ms (dying breed).
• The hierarchy spans 7 orders of magnitude — every caching decision is about climbing down this ladder.
• p50 lies; p99 is the user experience; p99.9 is where your on-call lives.

Throughput & sizing:

• A single modern core does ~10k–100k simple web req/s (language-dependent, 10× spread); size from measured, not guessed.
• Rule: design for 3× headroom on steady state; autoscale handles the rest. Below 30% utilization you're burning money; above 70% sustained you're one spike from an incident.
• Database connections are the scarcest resource in most stacks — pool them (PgBouncer/RDS Proxy); a "too many connections" outage is always a pooling failure, never a traffic surprise.
• S3: ~5,500 GET/s per prefix (partition by prefix hash for more); DynamoDB: partition by key, 3,000 RCU/1,000 WCU per partition soft limits.

Cost:

• Data transfer is the silent killer: egress ~$0.09/GB adds up 10× faster than compute in data-heavy designs. Keep data near compute; use CDN for repeated reads.
• Managed-service premium is usually 20–50% over raw infra — worth it until scale makes the toil cheaper than the premium (roughly: when the service costs more than 0.5–1 FTE, reconsider).
• Commitment discounts (Savings Plans/RIs/CUDs): only commit the 24/7 baseline; the variable 30% stays on-demand/spot.

Reliability:

• 99.9% = 43.8 min/month downtime; 99.95% = 21.9; 99.99% = 4.38. Memorize.
• Every "9" costs roughly 10× the previous one. Don't buy 99.99% for a 99.9% requirement.
• MTBF is vanity; MTTR is sanity. Halving detection+mitigation time beats doubling component reliability.
• Backups you haven't restored are Schrödinger's backups. Test restores quarterly.

Estimation reflexes:

• Bandwidth-delay product: cross-region throughput needs parallel streams; a single TCP stream won't fill a 10 Gbps intercontinental link.
• Storage growth: logs grow ~10× faster than you estimate; set lifecycle policies on day one.
• Team throughput: a team ships ~1 meaningful production change per engineer per week sustained; plan capacity from that, not from sprint points.
• "It'll take a week" means three. Multiply engineer estimates by π (3.14) for planning — depressingly accurate.

4. Veteran knowledge

What exams don't test:

• Reading production incidents. The skill is pattern-matching across metrics, logs, and deploys under time pressure with incomplete data. No cert teaches it; game days and on-call do.
• Saying no to scope. The most valuable engineering decision is usually not building something. Exams test building; careers reward restraint.
• Writing for the next reader. Code is read 10× more than written. The exam never grades your commit messages; your team does, daily.
• Cost attribution. Nobody's exam asks "which team pays for this NAT gateway," but in every real company, untagged spend becomes political.

Costly beginner mistakes:

1. Premature distribution. Microservices for a 3-engineer team. Start modular-monolith; extract services when team/scale boundaries demand it, not before.
2. No idempotency. Every retry path, webhook, and queue consumer must be idempotent. "At-least-once delivery" is the default of the universe — design for it.
3. Secrets in code/env. It always leaks. Secrets manager + rotation from day one; the migration later is 100× harder.
4. Unbounded retries. A retry storm has taken down more systems than the original failures. Backoff + jitter + circuit breakers, always.
5. Treating staging as production. If staging doesn't mirror prod data-shape and traffic, the green build means nothing.
6. Ignoring the data lifecycle. GDPR erasure, log retention, backup expiry — designed on day 30, it's a rewrite on day 300.

When to call a specialist:

• Cryptography beyond TLS/libsodium: call a cryptographer. (Never roll your own — not even once, not even "just for internal use.")
• Licensing/open-source compliance at scale: call counsel + use SCA tooling (the CRA makes this operational, not theoretical).
• Accessibility litigation: call an accessibility specialist + legal; overlays don't fix lawsuits.
• Regulated domains (medical, payments, aviation): hire the compliance expertise before writing code, not after the audit letter.
• Performance pathology (GC storms, lock contention, tail latency): call the performance specialist when p99 won't move after two sprints of team effort — fresh eyes with profilers beat another month of guessing.

Original ETS reference writing, verified against public sources on 2026-09-30. Thin sourcing is flagged inline. Not legal advice — confirm current editions with the issuing body.