The engineering craft

8 questions drawn from the parts of this series. Answers here count toward each post's own quiz.

1. Question 1 of 8·IntermediateThe fix is a single line of code. Why does the post still advise keeping the "Why" section in a note?

   Because the underlying mechanism is the part you will thank yourself for later, and it helps you spot notes with a common root.Because that section is required for notes to be published.Because one line of code is too short to store.Because the "Why" section replaces the "Problem" section.
2. Question 2 of 8·StarterAccording to the post, who should you write your work notes for?

   The whole internet, so many people read them.Colleagues in the weekly review.Yourself six months later, staring at the same stack trace having forgotten how you solved it.Your manager, to prove your workload.
3. Question 3 of 8·StarterWhy does the post advise reading a PR from the big picture to the details (context, correctness, design, tests, then nits) rather than top to bottom?

   Because files at the end of the diff are usually more important than those at the startBecause nits should be skipped entirely to review fasterBecause commenting on the first thing that catches your eye (variable names, semicolons) leads to twenty trivial comments, and the real problem in the fifth file gets buried or missedBecause reading the big picture lets you skip the tests
4. Question 4 of 8·IntermediateThe team puts prefixes blocking, suggestion, nit, question at the start of comments. What is the main benefit?

   So CI can automatically block merging when there is a nit commentThe recipient immediately knows which comments to handle first and which don't block merge, reducing the "under the microscope again" feelingSo the reviewer can write fewer comments and still cover everythingSo the author may ignore every non-blocking comment without replying
5. Question 5 of 8·IntermediateWhy report "3 to 8 days, low confidence" instead of "5 days"?

   Because a wide range lets you always be right and so avoid blameBecause PMs prefer to hear a range rather than a single numberBecause an estimate is really a right-skewed distribution, and the width of the range is itself information about risk, usually prompting the question of how to narrow it (for example with a spike)Because a range lets you quote the optimistic number and still be safe
6. Question 6 of 8·IntermediateOne piece of work has too many unknowns (for example, you don't know whether a chart library is smooth with 50k data points). What is the most sensible handling?

   Run a spike with a clear question and a hard time limit, whose output is a better estimate plus throwaway experiment codeAdd 100% buffer to the estimate to be safeStart building right away and adjust the estimate laterUse the spike's code as the base for production so effort is not wasted
7. Question 7 of 8·IntermediateTicket: "Add skeleton loading to the orders list page". Which approach shows senior thinking according to the post?

   Build a polished skeleton, review carefully and merge on timeAsk why the skeleton is needed, discover the API takes 3 seconds because it is not paginated, and propose fixing the root cause, possibly still adding the skeletonRefuse the ticket because a skeleton is just a band-aidAdd the skeleton and optimise a few other components to be safe
8. Question 8 of 8·IntermediateYou get the ambiguous request "The checkout page needs to be faster". After clarifying goals and constraints, what is the key next step according to the post?

   Pick the best option and work on it for three months to deliver a complete resultWait for the PM to rewrite the requirement more clearly before startingPropose a few options with their costs, commit to one and split it into small shippable steps, each with its own valueOptimise everything possible to be sure the goal is met