data subTLDR W43 2026 - Weekly summaries of r/dataengineering, r/sql and r/machinelearning

Sentiment is mixed, leaning frustrated. Many data engineers feel AI is automating the pipeline work they enjoyed and shifting their jobs toward repetitive semantic-layer and chatbot integrations. Some see that work as valuable and intellectually engaging, while others view it as dull or worry about shrinking engineering roles. The shift may also reflect career choices—such as moving into management—rather than an industry-wide transformation; commenters caution against treating AI-driven change as universal or inevitable. Others argue semantic layers were always needed and AI could help build them. Overall, engineers are adapting to changing work, but differ on whether the new focus is a welcome evolution or a loss.

Sentiment is broadly discouraged, though not uniformly: many people feel the market’s poor odds, noisy recruiter outreach, and demanding interview prep make pursuing a move hard to justify—especially when their current job is acceptable. Some still take recruiter calls but avoid applications, while others recommend setting a firm limit on interview rounds and walking away from lengthy processes. A recurring alternative to cold applications is relying on former colleagues and employers, making professional relationships worth maintaining. Overall, people want clearer hiring signals and faster decisions before investing substantial time.

The project was warmly received as a practical, valuable way to learn data engineering hands-on, with a complete local stack seen as more useful than theory alone for keeping skills sharp. The response was especially relevant to people seeking work or building experience. Overall sentiment was positive, though the small number of comments offered little detailed feedback or suggestions.

The booklet’s concise coverage of SQL basics remains surprisingly useful, and commenters broadly praised Oracle’s database documentation, both historical and current. Its age shows in missing modern features: it predates standard JOIN syntax and window functions, with CTEs also beyond its scope. Overall sentiment is appreciative and nostalgic, with a clear distinction between a solid introduction to foundational SQL and a complete guide to today’s capabilities.

SQL skill produces numbers; analysis requires connecting them to how the business works and what decisions the metrics inform. Start by clarifying success criteria, metric definitions, data-generating processes, and business rules. Before querying, write down expectations and hypotheses; when results differ, investigate plausible causes, including operational changes, outages, holidays, or data issues. Apply a “so what?” test: who cares, and what decision could change? Talk with metric owners to build context, then test explanations against evidence and communicate actionable conclusions. Practice with realistic case studies and decision-focused projects; business judgment develops through repeated investigation, not syntax alone. Overall sentiment is constructive and practical.

`COUNT()` is evaluated after grouping, so it gives the number of pizzas in each hour. `SUM(COUNT(*)) OVER ()` then sums those hourly counts across the full result set, without further grouping, giving the overall total. Dividing each hourly count by that total yields the hour’s share of all pizzas. The key is that window functions run after `GROUP BY`; adding a `PARTITION BY` would calculate separate totals within each partition. To understand complex expressions, display the grouped count and window total as separate columns. Some readers also found “volume” ambiguous, but the intended measure is order count, not pizza size.