- **Epistemic status:** #seedlings When working on a task, always take small, deliberate steps and check for feedback adjusting before proceeding. You can consider the rate of feedback as a speed limit that [[Deliver the most value]] instead of working on tasks that aren't needed. Feedback can be anything that confirms or denies an action independently, such as: - Unit tests for the latest code change - Reports from your superiors - [[User Survey]] on UX On tasks that seem too big, it is a good practice to stop before proceeding and break it down to a manageable size. A big task can have requirements that require for you to provide estimates on, and this can get you past from an educated guess to a wild speculation. Often we can only see a few hours or days at most. Things that are often speculation can include: - Estimating completion dates months in the future - Plan a design for future maintenance or extensibility - Figuring out user's future needs Yes, you have to design for the future, but only as far as you can see, instead of trying to predict the future increasing the risk you can incur when you are wrong. --- ## References - Thomas, David, and Andrew Hunt. _The Pragmatic Programmer, 20th Anniversary Edition: Journey to Mastery_. Second edition. Boston: Addison-Wesley, 2019.