{"id":4470,"date":"2026-11-11T19:35:00","date_gmt":"2026-11-11T19:35:00","guid":{"rendered":"https:\/\/dataopsschool.com\/blog\/?p=4470"},"modified":"2026-11-11T19:35:00","modified_gmt":"2026-11-11T19:35:00","slug":"data-practice-faq-focused-drills","status":"publish","type":"post","link":"https:\/\/dataopsschool.com\/blog\/data-practice-faq-focused-drills\/","title":{"rendered":"Data Engineering Practice FAQ: Why Daily Work Isn&#8217;t Enough"},"content":{"rendered":"<p>Questions about getting better at data work land in our inbox all the time, and most of them share a worry: &#8220;I write queries and fix pipelines every day, so why do I still feel slow?&#8221; The honest answer is that daily work and <strong>deliberate practice for data engineers<\/strong> are different things. What follows are the questions that come up most, answered without jargon, plus a routine you can begin before the week is out.<\/p>\n<h2>Why doesn&#8217;t a full week of tickets make me better at SQL?<\/h2>\n<p>Because tickets ask you to finish things, not to improve at them. Once you have a comfortable way to write a join or a window function, you reuse it. That is efficient for delivery and nearly useless for growth, since the hard parts of the skill never get stretched.<\/p>\n<p>Picture a pianist who plays the same easy piece every evening. After a year the piece sounds smooth, and the pianist is no better. Improvement began only when someone picked out the awkward four bars and played them slowly, again and again, until they stopped being awkward.<\/p>\n<h2>What does a &#8220;focused drill&#8221; look like for data work?<\/h2>\n<p>A focused drill takes one narrow pattern and rehearses it in isolation. For example:<\/p>\n<ul>\n<li>Writing a query that keeps only the latest row per customer, three different ways.<\/li>\n<li>Spotting duplicated keys in a table without looking at a previous solution.<\/li>\n<li>Reading a failed job log and naming the first failing step in under two minutes.<\/li>\n<li>Writing a transformation test for a single column rule, such as &#8220;this field is never empty&#8221;.<\/li>\n<\/ul>\n<p>Each item is small, finishes in minutes, and has a clear pass or fail. If the exercise cannot be marked right or wrong, shrink it until it can.<\/p>\n<h2>How do I pick the right weakness?<\/h2>\n<p>Look at where you hesitate. Over a week, jot down every moment when you copied an old snippet, searched for the same syntax again, or asked someone for a hand with the same kind of problem. Repeats are signals. If you looked up how to deduplicate rows three times, that is your drill for next Tuesday.<\/p>\n<p>A second source is review comments. If your pull requests keep coming back with the same remark about naming or missing tests, you have a free list of weak spots that someone else already wrote down.<\/p>\n<h2>Where does feedback come from if I work alone?<\/h2>\n<p>You have more options than you might expect.<\/p>\n<ol>\n<li><strong>Known answers.<\/strong> Build a tiny dataset where you already know the right result, then check your output against it.<\/li>\n<li><strong>Automated checks.<\/strong> Write a test for your own query. If it fails, the failure is the feedback, and it arrives instantly.<\/li>\n<li><strong>A colleague&#8217;s glance.<\/strong> Five minutes of someone reading your approach and saying what they would do differently.<\/li>\n<li><strong>Your own earlier attempt.<\/strong> Solve the same small problem again a week later and compare speed and clarity.<\/li>\n<\/ol>\n<p>The thread running through all four is that the response is quick and specific. A vague sense of &#8220;that went okay&#8221; is the enemy here.<\/p>\n<h2>How long should each practice session be?<\/h2>\n<p>A session of roughly a quarter to a third of an hour works well. Concentration drops faster than people think, and sloppy repetition at minute forty teaches you sloppy habits. Two short sessions across a week typically beat one long session on a Saturday. Stop while you still have energy and jot a short note on the adjustment for next round.<\/p>\n<h2>Can you give me an example from a transformation workflow?<\/h2>\n<p>Certainly. Suppose your weak spot is writing clean, testable transformation models. Your drill could be: take one messy source table, write a model that standardises dates and trims text, then add exactly two tests, and ask a teammate to try to break it with a bad row. If they succeed, you learn which assumption you made without noticing. Fix it, make a note, and run a similar drill next week on a different table.<\/p>\n<p>If you are working with a transformation tool, our overview of <a href=\"https:\/\/dataopsschool.com\/blog\/master-data-transformations-with-dbt-in-modern-dataops-pipelines\/\">building models and tests with a popular transformation framework<\/a> pairs well with this kind of exercise, because it shows the structure your small drills can slot into.<\/p>\n<h2>Will this help me read pipeline failures faster?<\/h2>\n<p>Making sense of a failed run improves quickly when you rehearse it on purpose.<\/p>\n<p>Yes, and failure reading is one of the best things to practise. Take a failed run from your history, hide the resolution notes, and give yourself five minutes to state the failing stage, the likely cause, and the first thing you would check. Then compare with what actually happened. Over a few weeks you will notice the same few causes recurring, such as schema changes upstream or late-arriving files, and your guesses will get sharper.<\/p>\n<p>For the monitoring side of the same skill, the walkthrough on <a href=\"https:\/\/dataopsschool.com\/blog\/the-ultimate-guide-to-monitoring-dataops-pipelines-for-beginners\/\">watching your pipelines as a newcomer<\/a> gives you a vocabulary for what to look at first when something breaks.<\/p>\n<h2>Do I need a trainer or coach for this?<\/h2>\n<p>Not at the beginning. A notebook, a timer and one honest teammate go a long way. A coach becomes useful when you hit a ceiling you cannot diagnose alone, because they notice patterns in how you work that you do not see. If you reach that point, the directory at <a href=\"https:\/\/www.devopstrainer.in\/\">DevOpsTrainer<\/a> is one place to search for trainers and coaches in DevOps-related fields, with DataOps as one of the domains it covers. As with any search, ask what specific feedback you would get and how it will work for your level.<\/p>\n<h2>What if I feel I am not making progress?<\/h2>\n<p>It happens to nearly everyone around week three, when the early gains flatten and the drills start to feel routine.<\/p>\n<p>Check the size of your target first. Most stalled routines are too broad: &#8220;get better at pipelines&#8221; gives you nothing to measure. Narrow it to something you can fail at in ten minutes. Second, check the quality of your feedback. If you are only confirming what you already believe, change the source. Third, check that you are changing one thing at a time between attempts; changing five makes it impossible to learn which adjustment helped.<\/p>\n<p>It also helps to keep a simple log of dates, drills and results. Seeing three weeks of notes show your deduplication drill dropping from twelve minutes to six is motivating in a way that general impressions never are. Our piece on <a href=\"https:\/\/dataopsschool.com\/blog\/understanding-dataops-training-for-smarter-pipeline-development\/\">how structured learning supports better pipeline building<\/a> covers some of the wider context if you are deciding what to study alongside your drills.<\/p>\n<h2>Where do I begin right now?<\/h2>\n<p>Pick one thing you looked up twice this week. Write a small problem around it that has a known answer. Set a timer for fifteen minutes, solve it without notes, and check your result. Note a single change for the next attempt. That is a complete cycle of deliberate practice, and you can finish it before lunch. Repeat it on a schedule and the skill you have been circling will begin to feel less like a guess and more like a habit you control. Good drills are boring on purpose: the same narrow task, the same short clock, the same honest check, and a different small tweak each time. Boredom here is a sign that the exercise is isolating the right thing, because you are no longer distracted by everything else that data work throws at you.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Answers to the questions data engineers ask about improving: how to choose a weak spot, run a fifteen-minute drill, and get honest feedback while working alone.<\/p>\n","protected":false},"author":6,"featured_media":4471,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[814],"tags":[],"class_list":["post-4470","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-dataops"],"_links":{"self":[{"href":"https:\/\/dataopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/4470","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dataopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dataopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dataopsschool.com\/blog\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/dataopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=4470"}],"version-history":[{"count":1,"href":"https:\/\/dataopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/4470\/revisions"}],"predecessor-version":[{"id":4528,"href":"https:\/\/dataopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/4470\/revisions\/4528"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/dataopsschool.com\/blog\/wp-json\/wp\/v2\/media\/4471"}],"wp:attachment":[{"href":"https:\/\/dataopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=4470"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dataopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=4470"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dataopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=4470"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}