Поздравляем — capstone proект почти готов. Этот финальный урок — как оформить результат, чтобы он максимально работал на вас. Раздел portfolio engineering — часто overlooked, но крайне важно для visibility.
В этом уроке:
Финальный чек-лист для каждого пути (A/B/C).
GitHub repo structure — что должно быть, как организовать.
□ Forked dbt-core на GitHub□ Issue выбран и approved (commented "I'll work on this")□ Reproduction шаги verified locally□ Failing test written и committed□ Implementation готов и tests pass□ Linting passes□ CHANGELOG entry добавлен□ PR opened с descriptive title□ PR description follows template□ Responded на review feedback (если есть)□ (Stretch) PR merged
Путь B (Свой adapter)
□ Target warehouse выбран (SQLite/pglite/etc.)□ Project structure setup (cookiecutter)□ Credentials class implemented□ ConnectionManager implemented (open, get_response, cancel, exception_handler)□ Adapter implementation (impl.py)□ Relation class□ Required macros (минимум 15-20)□ Profile template□ dbt-tests-adapter — core tests pass: □ BaseSimpleMaterializations □ BaseEmpty □ BaseSingularTests □ BaseGenericTests□ pyproject.toml configured for install□ README с setup, usage, known limitations□ GitHub repo public□ pip install works (locally tested)□ (Stretch) PyPI published□ (Stretch) Trusted Adapter Program application
Путь C (Optimization)
□ Synthetic project generated (или real project with permission)□ Baseline measurements documented в BENCHMARK.md□ Optimization 1: partial parsing tuning applied + measured□ Optimization 2: threads tuning applied + measured□ Optimization 3: state-based selection applied + measured□ Optimization 4: defer для CI applied + measured□ Optimization 5: microbatch (если time-series) applied + measured□ Optimization 6: materialization review applied + measured□ Combined results summarized□ Reproducibility scripts (shell или python) written□ GitHub repo public□ BENCHMARK.md complete□ README explaining project□ (Stretch) Visualizations / charts□ (Stretch) Blog post
GitHub repo structure
Visitors form impressions в first 10 seconds. Repo structure matters.
Universal expectations
your-capstone-repo/├── README.md # ← MOST IMPORTANT├── LICENSE # Apache 2.0 или MIT typically├── .github/│ ├── workflows/ # CI/CD if applicable│ └── ISSUE_TEMPLATE/ # if accepting issues├── docs/ # detailed documentation├── tests/ # tests if applicable└── (source code organized clearly)
Path A specific
If forked dbt-core — your repo is essentially the PR itself (don’t host fork as portfolio piece — link к PR в dbt-core/dbt-core directly).
Portfolio piece: link к merged PR в your resume/GitHub.
**Format tips**:- Use shields/badges (build status, license, etc.) — visual impact.- Quick Start at top — what people care about first.- Real code examples, не pseudo-code.- Honest about limitations — builds credibility.- Acknowledgements — community context.---## Resume bullet points### For Path A (Contribute)**Senior level**:> Contributed multiple bug fixes к dbt-core (open source, 1500+ GitHub stars). Authored merged PR #XXXXX fixing error message location reporting. Worked closely с dbt Labs maintainers через review process. Skills: Python, pytest, OSS workflow, code review.**Junior level**:> Made first contribution к dbt-core open source project. Submitted PR fixing error message clarity in source parser (PR #XXXXX, ready for review).### For Path B (Adapter)**Senior level**:> Designed и implemented dbt-sqlite adapter from scratch — full Credentials, ConnectionManager, 25+ adapter macros, passes core dbt-tests-adapter suite. Apache 2.0 open source (github.com/yourname/dbt-sqlite). Published к PyPI с 1000+ downloads (если applicable). Demonstrates deep understanding of dbt internals, Python OOP, DBAPI 2.0, database driver development.**Junior level**:> Built functional dbt adapter for SQLite from scratch as part of dbt III course capstone. Implements core adapter API (Credentials, ConnectionManager, 25+ macros). Passes 27/35 dbt-tests-adapter integration tests. Documented limitations и architecture. github.com/yourname/dbt-sqlite.### For Path C (Optimization)**Senior level**:> Optimized 1500-моделей dbt project performance — reduced parse time 4x, CI runs 11x (Slim CI), production runs 3.6x through partial parsing tuning, threads optimization, state-based selection, defer для CI, microbatch incremental, и materialization review. Documented methodology в reproducible benchmark suite. github.com/yourname/synthetic-dbt-perf.**Junior level**:> As part of dbt III capstone, applied three performance optimization techniques к synthetic dbt project: Slim CI (8x faster CI), materialization tuning (10x faster dev iteration), и threads tuning (3.6x production). Documented benchmarks. github.com/yourname/dbt-perf-optimization.---## Talking points для собеседованияInterviewers will ask: "Tell me about your capstone."Prepare 3 levels of depth:### Level 1: Elevator pitch (30 seconds)"In my dbt III capstone я [chose path: built adapter / optimized project / contributed к dbt-core]. The main outcome was [specific result]. I learned about [key takeaway]."Example:"In my dbt III capstone я optimized a 1500-моделей synthetic dbt project. Through 6 performance techniques — partial parsing, threads tuning, slim CI, defer, microbatch, и materialization review — я got 8x average improvement. Reproducible benchmarks documented. Most importantly, я learned how to translate methodology к real production systems."### Level 2: Deep dive (2-3 minutes)If interviewer follows up: "What specific challenge did you face?"Prepare 2-3 stories:**Story A — Technical complexity**:"Когда applying microbatch к our time-series fact table, the existing incremental strategy did full-table scans. After switching к microbatch:- Initial config с lookback=2 caused duplicates.- Investigated: turn out batch_size + lookback combination edge case.- Solution: set lookback=1, validated с unit tests на specific batch boundaries.Result: 12x daily run improvement. Lesson: incremental strategies need careful unit testing на batch transitions."**Story B — Architectural decision**:"For state-based selection setup, я could either:- Store manifest в shared S3 bucket.- Use GitHub Actions cache.Tradeoffs:- S3 — persistent, but requires AWS credentials, infrastructure.- GH cache — easy setup, но limited retention (7 days).For this capstone, я chose GH cache. For production environment, я'd recommend S3 для long-term reliability. Lesson: tradeoff context-dependent."**Story C — Learning curve**:"Before this capstone, я didn't really understand defer. Reading docs, code-tracing through dbt-core showed me: defer reads upstream from production manifest, so CI doesn't have to rebuild full DAG. Combined с state-based selection — 11x CI speedup. Lesson: combination of techniques often > each individually."### Level 3: Discussion (5+ minutes)For senior interviews: "Walk me through your benchmark methodology."Be prepared for:- "How would you transfer к production?"- "What about cost implications?"- "How does this compare к Fusion?"- "What's next iteration?"Prepare answers с numbers и nuance, not just claims.---## Bonus: Blog postWriting a blog post about your capstone significantly amplifies reach:### Where to publish- **dev.to** — easy, free, good community.- **Medium** — bigger audience, но monetization not relevant.- **Personal blog** — full control, harder to discover.- **Company blog** (if employer supports) — best reach.- **LinkedIn article** — professional network.### Outline для capstone blog post```markdown# Title: "I Built/Optimized/Contributed X — Here's What I Learned"## TL;DR- Did X- Got result Y- Key takeaway Z## Why I did this- Personal motivation- Course context- Career goals## What I built (the work)[Technical details, but accessible]## Challenges and solutions[2-3 concrete examples]## Results[Numbers, charts, before/after]## What I learned[Personal reflections — most engaging часть для readers]## What's next[Future work, links к related projects]## Acknowledgements[Course, mentors, community]
Length: 1500-3000 words is sweet spot. Long enough для depth, short enough к читать.
Tip: include screenshots, code snippets, diagrams. Visual posts perform much better.
Showcasing strategically
LinkedIn post (when capstone done)
Excited к share my dbt III course capstone! After 25 hours of work, я [accomplished X].Key results:[x] [Specific number 1][x] [Specific number 2][x] [Specific number 3]GitHub: https://github.com/yourname/capstone-projectTop learnings:1. [Insight 1]2. [Insight 2]3. [Insight 3]Special thanks к [community / mentor / course].What dbt project would you optimize next? #dataengineering #dbt #opensource
Twitter / X thread
Capstone делится на 5-7 tweets:
1/ I just finished my dbt III capstone optimizing 1500-моделей project. Reduced parse time 4x, CI 11x, prod runs 3.6x. Thread 2/ Setup: synthetic dbt project с 1500 models, DuckDB warehouse для simplicity. github.com/yourname/synthetic-dbt-perf3/ Optimization 1: partial parsing tuning. Removed dynamic vars in models, replaced с env_var() в profiles.yml. Result: parse 6s -> 1.5s.4/ Optimization 2: state-based selection (Slim CI). Stored baseline manifest, used `--select state:modified+`. Result: CI 45s -> 4s.5/ Optimization 3: ...[continue]7/ Full benchmarks + reproducibility scripts: github.com/yourname/synthetic-dbt-perf. Learn from my mistakes!
Resume customization
Tailor capstone bullet к each role:
For “dbt engineer” role: emphasize dbt-specific deliverable.
For “data platform engineer” role: emphasize infrastructure, scaling.
For “tech lead” role: emphasize methodology, decision-making, mentoring potential.
What if capstone не perfect?
It’s OK. Few capstones are perfect. Examples:
Path A: PR opened but не merged yet. OK — link к PR shows work, even pending review.
Path B: Adapter passes only 60% of tests. OK — document what works, what doesn’t, lessons learned.
Path C: Got only 3x improvement, не 8x. OK — honest documentation of methodology, exact numbers.
What matters:
Honest documentation.
Reproducible methodology.
Clear understanding (you can explain it).
Lessons learned.
What doesn’t matter as much:
Perfection.
Massive scale.
Specific big numbers.
Senior engineers value: thoughtfulness > heroism. Better to do small thing well than big thing sloppily.
Проверка знанийKnowledge check
Junior finished path C capstone (8x improvement), но boss spotted: 'this is using synthetic data. Show me you can apply к our real project.' Что delivered next?
ОтветAnswer
Это classic transition from "course capstone" к "real production work". Boss right к ask. Junior должен deliver thoughtfully.
**Phase 1: Honest scope acknowledgement (1 hour).**
Don't deny boss's concern. Acknowledge:
"You're right — synthetic project doesn't fully reflect production complexity. Synthetic showed methodology works, but applying к our actual 800-model project requires investigation, не direct copy of numbers."
Different from defensive ("but my methodology is sound!").
**Phase 2: Audit real project (2-4 hours).**
Understand actual baseline first. Profile current state:
```bash
# Current state
dbt parse --profile # get timing details
dbt build --profile # get run timing details
# Look at run_results.json — what takes time?
cat target/run_results.json | jq '.results[] | {model: .unique_id, time: .execution_time}' \
| jq -s 'sort_by(.time) | reverse' \
| head -20
# Top 20 slowest models
```
Map к ours synthetic findings:
- Slow parse? Likely партial parsing not optimal.
- Slow CI runs? State-based selection may help.
- Slow dev iteration? Materialization tuning.
- Slow daily runs? Threads tuning + microbatch.
This discovery phase tells you which optimizations relevant.
**Phase 3: Pick highest-leverage technique (1-2 hours).**
From audit, identify biggest bottleneck. Most teams: slow CI loops. So **Slim CI** typically biggest win first.
Don't try all 6 techniques на real project at once. **Phased approach**:
Phase A: Slim CI (Week 1).
Phase B: Materialization review (Week 2).
Phase C: Threads tuning (Week 3).
Phase D: Microbatch (Week 4, если time-series).
Each phase = clear deliverable.
**Phase 4: Implement Phase A on real project (1 week).**
For Slim CI on real project:
**Step 1: Decide manifest storage.**
- S3? GCS? Azure Blob?
- GitHub Actions cache?
- Other?
Depends на existing infrastructure. Match к team setup.
**Step 2: Setup secure access.**
Production credentials, IAM roles, etc. This is **infrastructure work** не just dbt config.
**Step 3: CI workflow integration.**
Modify GitHub Actions / GitLab CI / Jenkins config. Coordinate с DevOps if separate team.
**Step 4: Test on PR.**
Open test PR. Verify state-based selection works:
- Modified 1 model -> CI builds modified + downstream только.
- Verify не breaks anything.
**Step 5: Roll out gradually.**
Don't switch all PRs immediately. Per project / team:
- Week 1: optional flag. Engineers opt в.
- Week 2: default для most PRs. Opt-out option.
- Week 3: required.
Communication critical: explain to team what's changing.
**Phase 5: Measure real improvements.**
Document before/after for real project:
```markdown
# Real project Slim CI rollout — results
## Before
- CI per PR (average across 50 recent PRs): 8.5 minutes.
- Cost per CI run: $X compute time + warehouse cost.
- Developer waiting time: 8 min × 50 PRs/week × 10 engineers = 67 hrs/week.
## After (Slim CI enabled)
- CI per PR (average across 50 PRs): 1.2 minutes.
- Cost per CI run: $Y (significantly less).
- Developer waiting time: 1 min × 50 PRs × 10 engineers = 8 hrs/week.
## Savings
- 59 hrs/week developer time savings.
- At $120/hr = $7,080/week savings.
- Annual: ~$370K.
## Trade-offs
- Setup complexity: 12 hours engineering.
- Manifest storage cost: $X/month.
- Net ROI: ~$370K/year.
```
Real numbers, real value.
**Phase 6: Communicate к stakeholders.**
**To boss:**
"Implemented Slim CI on our production dbt project. CI time reduced from 8.5 min -> 1.2 min (7x improvement, similar к synthetic predictions). Annual savings ~$370K в developer time. Next phase: materialization review для dev iteration speedup."
**To team:**
Slack post / wiki page:
"Slim CI now enabled. Your PRs will be faster (~7x). Setup details: [link]. Concerns or issues — DM me."
**To engineering leadership:**
Few lines в weekly report. Quantified impact.
**Phase 7: Continue iteration.**
With Phase A success, proceed к Phase B (materialization review):
- Different work — code changes, не infrastructure.
- May take 2-3 weeks (touching many models).
- Documented improvements add к Phase A numbers.
Gradual rollout, careful measurement.
**Phase 8: Document journey.**
For portfolio (and personal growth):
Update capstone GitHub README:
```markdown
# Update: Real-world application
Applied capstone methodology к production 800-model dbt project (with permission from employer).
## Phase 1: Slim CI (Completed)
- Setup: 12 engineering hours.
- Result: CI 8.5min -> 1.2min (7x).
- Savings: ~$370K/year.
## Phase 2: Materialization review (In progress)
- Expected completion: Week of XX.
## Phase 3-4: Threads tuning + microbatch (Planned).
## Lessons learned
- Synthetic benchmarks indicate orders of magnitude, real numbers vary.
- Infrastructure setup (manifest storage, IAM) takes significant time.
- Communication к team critical для adoption.
- Phased rollout reduces risk vs big-bang change.
```
This transforms capstone from "demo project" к "real engineering accomplishment".
**For LinkedIn / Twitter:**
New post:
"Applied my dbt III capstone methodology к our production dbt project. Slim CI rollout: CI time 8.5min -> 1.2min (7x). Annual savings: $370K developer time. Next phase: materialization tuning.
Real-world data engineering > synthetic benchmarks. Methodology validated."
Visibility компании, peers, future employers.
**For resume update:**
Replace synthetic capstone bullet с real one:
Before: "Optimized 1500-моделей synthetic dbt project, 8x average improvement."
After: "Led dbt performance optimization project на production 800-model project. Implemented Slim CI (7x CI speedup, $370K annual savings), materialization tuning (10x dev iteration), и threads optimization (3x prod runs). Authored team-wide methodology documentation. Phased rollout coordinated с DevOps и engineering managers."
Much stronger.
**What if boss says: "don't implement, just propose"?**
Deliver proposal:
```markdown
# Proposal: dbt Project Performance Optimization
## Current State (audited)
- CI time per PR: 8.5 minutes.
- Developer waiting time: 67 hrs/week.
- Annual cost: ~$1.5M in developer hours.
## Proposed Optimizations
[3-4 techniques, scope, expected results]
## Required Investment
- Engineering time: ~40 hours.
- Infrastructure cost: $50/month (manifest storage).
- Risk: low, phased rollout.
## Expected ROI
- Annual savings: ~$500K developer time + warehouse cost.
- Payback: менее 1 month.
## Timeline
- Phase 1 (Slim CI): 2 weeks.
- Phase 2 (Materialization): 2 weeks.
- Phase 3 (Threads): 1 week.
- Phase 4 (Microbatch): 2 weeks (if applicable).
- Total: 7 weeks.
## Risks и Mitigations
[List]
## Recommendation
Proceed с Phase 1 next sprint.
```
Professional, evidence-based, action-oriented. Boss can decide ROI/Risk.
**Главный урок:** **Capstone к production transition** = applying methodology, не copying numbers. Audit real baseline, pick highest leverage, implement phased, measure, communicate, document. This **demonstrates senior engineering thinking** much more than synthetic capstone alone.
The synthetic project shows you understand techniques. Real project application shows you can deliver value. Both важны для career growth.
Проверка знанийKnowledge check
Capstone complete, проект на GitHub, но месяц прошёл — никто не заметил. Что делать?
ОтветAnswer
Это classic "build it and they will come" myth. They won't come unless you tell them. Marketing your work — important skill.
**Audit ваш current state:**
1. **GitHub repo activity:**
- Stars: 0?
- Forks: 0?
- Issues: 0?
- PRs: 0?
- Views: how many?
If all zeros except your commits — repo не discovered yet. Normal default state.
2. **Where mentioned:**
- LinkedIn? Twitter? dev.to?
- Personal blog?
- Conference talks?
If никто не told — никто не knows.
**Why probably no traction:**
- Discoverability problem. GitHub search doesn't surface random repos.
- No promotion. You haven't communicated work.
- Content gap. Maybe README не engaging, или topic too niche for audience.
- Timing. New things take time к attract attention.
**Action plan:**
**Step 1: Audit README (1 hour).**
Is your README:
- Clear within 10 seconds (what is this)?
- Visual (screenshots, badges)?
- Action-oriented (quick start command)?
- Honest (limitations documented)?
If not — improve.
Example improvements:
```markdown
# Before (boring)
## dbt-sqlite
This is dbt adapter for SQLite. To install, pip install dbt-sqlite.
# After (engaging)
# dbt-sqlite
> Lightweight dbt adapter for SQLite — perfect для local dev, learning, embedded scenarios.
[Badges]
## Quick start (30 seconds)
\`\`\`bash
pip install dbt-sqlite
dbt init my_project --adapter sqlite
dbt run
\`\`\`
## Use cases
- Local development без warehouse setup
- Learning dbt with simple, embedded database
- Demos и training environments
## Features
- Full dbt-tests-adapter support
- Materializations: table, view, incremental, ephemeral
- Snapshots и singular tests
## Performance benchmark
[Chart showing dbt-sqlite vs dbt-duckdb on simple workloads]
[Continue ...]
```
Emojis (if user's audience), visual hierarchy, action-oriented, clear использование cases.
**Step 2: LinkedIn announce (2 hours).**
Carefully crafted LinkedIn post:
```
Proud к share my dbt III course capstone: dbt-sqlite.
A lightweight dbt adapter для SQLite — perfect for local dev и learning environments.
Key takeaways from building this from scratch:
-> Implementing Credentials, ConnectionManager, и 25+ adapter macros taught me dbt internals deeply.
-> dbt-tests-adapter suite is excellent — it caught dozens of edge cases I would have missed.
-> SQLite limitations make adapter development trickier than expected (no ALTER TABLE ADD COLUMN NOT NULL, etc.).
-> Open source software needs honest documentation про limitations — builds trust.
Repo: https://github.com/yourname/dbt-sqlite
If you're learning dbt, или need simple dev environment, please try. Feedback welcome!
#dbt #dataengineering #python #opensource #dbtcommunity
```
Key elements:
- Specific, не generic.
- Personal angle ("what I learned").
- Visual (could include screenshot of working tests).
- Call к action (try, give feedback).
- Hashtags (discoverability).
Post timing: Tuesday-Thursday morning. Avoid Monday (busy) и Friday (weekend mode).
**Step 3: Twitter/X thread (1 hour).**
7-tweet thread breaking down project:
```
1/ I built dbt-sqlite from scratch — full dbt adapter for SQLite. 25+ macros, passes core test suite, learnings
2/ Why dbt-sqlite? Local dev без warehouse setup. Learning dbt в an embedded environment. Reduces friction.
3/ Architecture: Credentials class, ConnectionManager wrapping sqlite3, Relation class adapted для no-schema model, 25+ macros for adapter-specific behavior.
4/ Biggest challenge: SQLite не support ALTER TABLE ADD COLUMN NOT NULL. Had к implement table rebuilding (expensive but works).
5/ dbt-tests-adapter — incredible test suite. Caught многих edge cases я would have missed. Saved months of debugging.
6/ Lesson: honest documentation about limitations builds trust. README explains exactly what works, what doesn't.
7/ Try it: github.com/yourname/dbt-sqlite. Feedback / contributions welcome.
```
Pin thread на your profile.
**Step 4: Submit к dbt community (1 hour).**
- **dbt Slack** (`#i-made-this` channel): announce project.
- **dbt Discourse** (community forum): create post.
- **dbt Office Hours**: можно apply к present project.
These channels see by **people who care about dbt** — your direct audience.
Slack message:
```
Hey team!
Last week я finished building dbt-sqlite adapter as part of my dbt III course capstone.
It's intended для local dev, learning, embedded scenarios. Passes core dbt-tests-adapter.
Key features:
- SQLite database support
- All basic materializations
- 25+ adapter macros
Would love feedback от community! github.com/yourname/dbt-sqlite
#i-made-this
```
Genuine, community-oriented. Don't spam — single quality post.
**Step 5: dev.to / blog post (3-4 hours).**
Long-form content:
```markdown
# I Built a dbt Adapter from Scratch — Here's What I Learned
Thumbnail image: дешевый mockup of installation flow.
## TL;DR
Built dbt-sqlite from scratch over 30 hours. Learned:
- dbt internals deeply.
- Database driver development.
- Open source software development.
- Test-driven development.
GitHub: ...
## Why I did this
[Personal motivation]
## The project
[Technical overview]
## Challenges
[3-4 specific stories]
## Results
[Numbers, screenshots]
## Lessons
[5-10 lessons, generalizable]
## What's next
[Future plans]
## Acknowledgements
[Course, community]
```
Post к dev.to (good для dev audience), также cross-post к personal blog.
Distribute:
- Tweet announcing blog post.
- LinkedIn share blog post.
- dbt Slack mention blog post.
**Step 6: Hacker News (если applicable).**
For exceptional capstones — Show HN или Submit к Hacker News:
Title: "Show HN: I built dbt-sqlite from scratch (open source)"
Description:
```
A lightweight dbt adapter для SQLite. Built from scratch как learning project — implements core adapter API, passes dbt-tests-adapter suite. Intended для local dev и learning. Apache 2.0.
GitHub: ...
```
Time submission Tuesday-Thursday 8-10am PST для best visibility. Engage in comments если discussion happens.
**Step 7: Iterate based on response.**
Week 1 after announcements: monitor:
- GitHub stars / forks count.
- LinkedIn / Twitter engagement.
- dev.to views / reactions.
- Any feedback / issues opened.
Week 2-4: respond к feedback. Fix issues. Add features people request. Iterate.
**Step 8: For ongoing visibility.**
Monthly:
- Update README с new features.
- Cross-post blog к new platforms.
- Mention в comments on related projects.
- Tweet new milestones (100 stars, etc.).
In a few months, capstone может accumulate stars, contributors, mentions. Become standard reference в dbt community.
**What if still no traction после all this?**
It's OK. Reality:
- Many great projects never get traction. Topic not trendy, audience hard к reach, timing off.
- Even 100 stars after a year — solid achievement.
- Even 0 stars — capstone still personal accomplishment. Portfolio piece. Learning value.
Don't compare к unicorn open source projects (React, dbt itself). Those took years and teams.
**Alternative metrics of success:**
- Did learnings articulate в blog post? Win.
- Did 1 person use it и give feedback? Win.
- Did employer ask о it в interview? Big win.
- Did это lead к conversation с senior engineer? Win.
Reach matters less than impact.
**Главный урок:** **Capstone сами по себе rarely виже unless you market**. Quality work + visibility = real impact. Quality work alone — hidden gem на dusty shelf. Spend hours building? Spend hours promoting. Both critical для creating opportunities.
Not promoting сам project is **biggest mistake** post-capstone. Take dollar за дollar — promotion часто higher ROI than additional code work.
Итого
Финальный чек-лист для each path — verify everything done.
GitHub repo structure — clear organization, README center stage.
README writing: badges, quick start, real examples, honest limitations.
Resume bullets specific к each path. Numbers + impact.
Talking points — prepare 30-second elevator pitch + 2-3 deep stories.
Blog post значительно amplifies reach. 1500-3000 words sweet spot.
LinkedIn / Twitter announcements — visibility crucial для traction.
dbt community channels — Slack, Discourse — direct audience.
For real production application: phased approach, audit baseline, pick highest leverage, measure, communicate, document.
Promotion matters as much as work quality. Не “build it and they come” — proactively visible.
Что после capstone
Поздравляем — вы прошли весь dbt III course. На что обратить внимание далее:
Apply learnings к real work. Каждый день, на каждом dbt project.
Contribute back к community. Open issues, write blog posts, help newcomers.