Software Engineering Fundamentals
Frameworks come and go on a five-year cycle. The fundamentals — clean code, SOLID, refactoring, honest naming, small functions — outlast every one of them. Every senior engineer worth working with has strong opinions about these topics, and every codebase you would enjoy inheriting was built by people who took them seriously. This track is the ground layer under every other track on the site: language and framework choices sit on top of it.
What this track covers
SOLID as five separate but related principles, DRY / KISS / YAGNI as heuristics with real limits, coupling vs cohesion as the metric that actually predicts change cost, composition over inheritance, naming, small functions and refactoring workflows that keep a codebase habitable as it grows.
Who this is for
Every backend engineer, at every level. Juniors learn what 'good code' means; mid-level engineers learn the vocabulary to defend decisions in reviews; seniors sharpen the intuition they already have.
Prerequisites
- Fluent in at least one language (Java, Python, C#, TypeScript — any will do)
- Have worked on a codebase larger than your own personal projects
- Willingness to change your mind about code you wrote last year
Recommended learning order
// beginner
Start with the SOLID overview and read each principle guide once. Don't try to apply them all at once — pick one code review a week and look for a single violation.
// intermediate
Move to the design-principles guide (DRY / KISS / YAGNI / coupling / cohesion) and to composition over inheritance. Start refactoring your own recent code with the SOLID vocabulary in hand — most engineers find their own code violates a principle they thought they understood.
// advanced
Read the refactoring-with-SOLID guide and apply it to a real legacy codebase, ideally one you inherited. This is the level at which the principles stop being rules and start being tools — you'll notice when they conflict, and choose deliberately.
Common mistakes to avoid
- Applying SOLID mechanically — creating five interfaces for a two-line class
- Treating DRY as an absolute — extracting a helper for two functions that just happen to look similar
- Confusing 'clean code' with 'code that looks like the book' — real cleanliness is context-dependent
- Refactoring without tests, then discovering three days later which behaviour you accidentally changed
- Ignoring cohesion because it is harder to measure than coupling — most large-codebase pain is low cohesion, not tight coupling
Career relevance
Fluency in these fundamentals is what promotion committees look for when deciding senior vs staff. It shows up in code reviews, design reviews and mentoring — the three things that senior engineers are actually measured on.