10 лет преподавания

Main ideas / lessons (what the video argues)

• Teaching has shifted over 10 years:

  • From teaching frameworks/languages (knowing “how the tool works”)
  • To teaching how to build and maintain full, production-grade systems (engineering maturity).

• What “a good graduation project” looks like has changed:

  • ~10 years ago: relatively “primitive” but realistic systems, such as:
    • DBs like MySQL
    • S3 storage
    • basic REST API
    • Swagger/codegen
    • Spring Boot/Security
    • Docker/test containers
    • migrations/tests
  • Now: student-level final projects are expected to resemble real microservice ecosystems, including:
    • Observability stacks (e.g., OpenTelemetry, Grafana stack, Prometheus/Loki/Tempo/Mimir, alerts)
    • Eventing/integration patterns
    • Multiple data stores (e.g., relational + NoSQL like Cassandra/ClickHouse, plus caching)
    • API gateways (e.g., Spring Cloud Gateway)
    • Authentication/authorization and role management (e.g., Keycloak)
    • Unit/integration/load tests
    • Performance/operational readiness

• Market needs now require “system support,” not just code writing:

  • Developers must understand:
    • where code runs
    • how it breaks
    • what to do when it breaks
  • They must understand the consequences of decisions on:
    • latency, consistency, data rights, load, and release cadence
  • They must validate requirements, design (diagrams/architecture artifacts), implement, test, and monitor in production.

• Avoid falling behind:

  • Even experienced developers (including “middle” engineers) can become outdated if they keep doing only “typical” work for years.
  • Re-entering the market can reveal a skills gap that is costly emotionally and financially.

• Mass courses don’t keep up:

  • Mass training typically lags behind market change because teaching requires real, current production experience.
  • Mass formats mostly transfer information, but they don’t build engineering habits (deep skill) because they don’t include enough human feedback and iteration.

• Education should be built as a full engineering cycle with feedback loops:

  • Learn by producing artifacts (code, diagrams, ADRs, etc.).
  • Then undergo individual review of those artifacts.
  • Iterate until mistakes are closed and the learner reaches a higher level.

• Three “aspects of engineering development” (a triangle model):

  1. Manual capability (“hands-on”): can I implement the behavior manually and understand it through tested execution?
  2. System design understanding (guarantees/compromises): do I understand boundaries, consistency, trade-offs, cost, and risks?
  3. End-to-end delivery through modern pre-production gates (requirements → tests/evidence → release): can I carry changes through the controlled pipeline to production reliably?

• Methodology evolution for teachers:

  • Teachers should no longer only demonstrate technology or explain frameworks.
  • They must help learners become engineers who can support systems with hands, judgment, and delivery competence.
  • Pre-recorded lectures are viewed as ineffective; live, practice-driven sessions and active review are emphasized.

• AI is positioned as an accelerator, not a replacement for control:

  • AI-assisted workflows (called AI-CDLC in the video) can help automate parts of design/coding/testing/release workflows.
  • But the process must still use evidence/gates and maintain controllability, including:
    • requirements tracking (FRD → tasks → release)
    • risk-based test selection
    • canaries/rollbacks
    • observable proof that changes work in production
  • The goal is improving the existing CDLC (controlled development lifecycle), not relying on “secret prompts” or randomness.

---

Methodology / instruction-style content (detailed bullet list)

A) What an “effective modern education process” should include

• Teach engineering maturity in a loop, not as isolated topics:

  • validate requirements
  • translate requirements into design artifacts
  • implement the system
  • cover code with tests
  • integrate release/deployment process
  • monitor behavior in production and handle failures
  • iterate

• Use a gradual, staged increase in complexity:

  • start from simpler scope (one system/object at a time)
  • slowly add integrations and harder interactions
  • ensure each new capability creates new problems (because in real life it always does)
  • end with verification that the system evolves correctly

• Require “proof” criteria (not just completion):

  • demonstrate why the decomposition/design is correct (boundaries)
  • show guarantees to user/business during failures or delays
  • prove observability:
    • what metrics and traces confirm correctness
  • provide a transition/migration plan:
    • chip away piece-by-piece without rewriting everything at once

---

B) The three-format model (as described)

The speaker describes three formats that cover complementary parts of engineering maturity:

• 1) “Our code” (manual engineering capability)

  • Train learners to implement manually end-to-end:
    • create artifacts (code)
    • integrate with other systems
    • work with data
    • handle load
    • handle failures
  • Core requirement: the learner must understand that the artifact behavior can be tested and explained.

• 2) “System design”

  • Teach learners to “see the entire system”:
    • boundaries and interactions
    • cost/trade-offs of distributed solutions
    • compromises and risk understanding
  • Emphasis: applied design, not “draw Netflix/YouTube in 30 minutes.”

• 3) AI-CDLC (end-to-end controlled delivery)

  • Teach how to make changes through the full pipeline:
    • requirements → tasks → tests → evidence → release
  • AI role:
    • help accelerate extraction/structuring of requirements
    • generate code/design within constraints
    • select risk-based tests
    • still maintain gates, evidence, and operational safety (canary/rollback)
  • Core principle: AI must not replace controlled release practices.

---

C) How review/iteration should work (anti-mass-production approach)

• Learner attempts something → produces an artifact (code/diagrams/ADR/etc.)
• Then comes individual review by a real active developer/instructor:
  • open the person’s work
  • run/read it
  • record line-by-line feedback: what is good/bad/wild and what must be strengthened
• Repeat the cycle:
  • artifact → review → corrections
  • multiple routes (2–4 iterations mentioned)
• Learner only advances after closing mistakes.
• Target group size suggested: approximately 10–12 people for maximum engagement/effectiveness.

---

D) What a “modern final system” should include (expected capabilities)

• microservices-level interactions
• synchronous and asynchronous patterns:
  • GRPC
  • message brokers (e.g., Kafka/RabbitMQ-like)
• observability stack:
  • metrics/traces/logs and alerting
• security (e.g., Keycloak-style)
• caching
• robust data layer examples (e.g., ClickHouse/Cassandra)
• operational correctness:
  • understand idempotency
  • retries, backpressure
  • reliability under failure conditions

---

Speakers / sources featured

• Evgeny Suleimanov — speaker; referenced as the source of the methodology and experience.

No other specific speakers or organizations are presented as featured “speakers.” (Tools are mentioned, but not as speakers.)