You can follow a solution line by line, yet an empty editor gets you nowhere. That is normal, and it does not mean you are bad at programming. Reading code and writing code are different skills. Reading checks whether what you see makes sense; writing makes you produce every piece yourself, in the right order, from memory. The fix is to practice producing code, in small steps, with a plan.<\/p>\n
When you read code, every line is in front of you as a cue. You only have to judge “does this look right?” When you write, nothing is in front of you. You have to retrieve the syntax, the method names and the shape of the solution. Psychologists have long found that recognizing something is easier than recalling it, which is why a multiple-choice test feels easier than a short-answer test on the same material.<\/p>\n
That is also why a tutorial can feel like learning while you are watching and then vanish when you close it. If you want a name for the trap, it is the one described in tutorial hell<\/a>: lots of recognition, little retrieval.<\/p>\n A finished solution is smooth. Each step follows from the last, and you nod along. What you do not see are the dead ends the author dropped, the decisions they made, and the reason each line is there. So you may understand what<\/em> the code does without knowing why it was built that way<\/em> or how to arrive at it. Writing exposes that gap immediately.<\/p>\n Working memory is small; common estimates put it at around four chunks of information at a time. When you write a function from nothing you are juggling the problem, your plan, the language syntax, variable names and edge cases together. A beginner has to think about each of these individually, so the load is high. An experienced programmer has chunked the common pieces (a loop over an array, a dictionary lookup, a two-pointer scan) into single units, which leaves room for the actual problem. This is the main thing practice buys you.<\/p>\n Much of “writing from scratch” is recognizing which familiar pattern the problem is an instance of, then adapting it. If you have seen a few dozen problems solved with a hash map, a sliding window or binary search, you start from a template. If you have seen the solutions but never produced them, the templates are not available to you when you need them.<\/p>\n After studying a solution, close it and write it again from memory. Do not worry about getting it perfect. Then compare, and note exactly what you missed (a base case, an off-by-one, a method name). Repeat the same problem a day later, then a few days later. Spacing the repetitions makes the retrieval harder, and that difficulty is what makes it stick.<\/p>\n The key rule: struggle for a few minutes before you look. If you look at the answer the moment you are stuck, you are back to recognition.<\/p>\n Do not start with syntax. Write the steps as comments or pseudocode, then fill in code under each. This separates “what should happen” from “how do I spell it”, so you carry one load at a time. The post on writing code from scratch by starting with pseudocode<\/a> goes into this in more detail, and if you freeze at the very first line, breaking the blank page barrier<\/a> has tactics for that.<\/p>\n Get the smallest version running, then extend it. Run the code after every few lines. If you write 40 lines and then run them, you will have several bugs tangled together and nothing to tell you which line caused which. Small steps keep the load low and give you feedback early.<\/p>\n Write three or four inputs with expected outputs before the code: a typical case, an empty input, a single element, and the boundaries. Examples also tell you whether you understood the problem, which is often the actual blocker.<\/p>\n A good bridge between reading and writing is modification. Take working code and change the requirement. Make it return the last match instead of the first. Make it work on strings. Make it handle duplicates. Each change forces you to understand why the original lines are there.<\/p>\n Say you have read a binary search and can follow it. Here is how to move from that to producing a variant yourself. The task: given a sorted list, return the index of the first<\/em> occurrence of a target, or -1 if absent.<\/p>\n Step 1: examples.<\/strong><\/p>\n Step 2: plan in words.<\/strong><\/p>\n The point of the “otherwise” rule is that you do not stop when you find the target; you keep narrowing left, which is what finds the first<\/em> one.<\/p>\n Step 3: code, one comment at a time.<\/strong><\/p>\n Step 4: run the examples.<\/strong> All seven examples were run; each returned the expected value, for instance Step 5: the memory test.<\/strong> The next day, close this page and write it again from the examples and your three-line plan. If you get stuck, note where: usually it is the half-open range There is no honest universal number. What changes with practice is that more of the common pieces become automatic, so you stop spending attention on them. You will notice it in small ways: you stop looking up how to loop over a dictionary, then you stop needing a plan for simple problems, then you start recognizing the pattern from the problem statement. A realistic target for a week is one or two problems you can solve, from nothing, twice in a row on different days.<\/p>\nFluent reading feels like understanding<\/h3>\n
Writing means holding many things at once<\/h3>\n
You are missing the patterns, not the intelligence<\/h3>\n
A routine that closes the gap<\/h2>\n
1. Retrieve before you look<\/h3>\n
2. Plan in plain language first<\/h3>\n
3. Build in small, working steps<\/h3>\n
4. Write the tests first, or at least the examples<\/h3>\n
5. Change solutions you have seen<\/h3>\n
Worked example: binary search, written in stages<\/h2>\n
[] target 3 -> -1\n[3] target 3 -> 0\n[3] target 4 -> -1\n[1, 2, 2, 2, 5] target 2 -> 1\n[1, 2, 3, 4, 5] target 5 -> 4\n[1, 2, 3, 4, 5] target 0 -> -1\n[1, 2, 3, 4, 5] target 6 -> -1\n<\/code><\/pre>\n\n
def first_index(nums, target):\n \"\"\"Index of the first occurrence of target in sorted nums, or -1.\"\"\"\n lo, hi = 0, len(nums) # search in [lo, hi)\n while lo < hi:\n mid = (lo + hi) \/\/ 2\n if nums[mid] < target:\n lo = mid + 1\n else:\n hi = mid\n if lo < len(nums) and nums[lo] == target:\n return lo\n return -1\n<\/code><\/pre>\n[1, 2, 2, 2, 5]<\/code> with target 2 gives 1 and the empty list gives -1.<\/p>\n[lo, hi)<\/code> and whether to write hi = mid<\/code> or hi = mid - 1<\/code>. That exact spot is what to practice. The AlgoCademy lower bound<\/a> lesson is this same problem, and binary search<\/a> is the base version if you want to start there.<\/p>\nMistakes that keep the gap open<\/h2>\n
\n
How long it takes<\/h2>\n