Stop Wasting Time – Start Thinking Small


A frequent mistake I find junior coders making is that they try to solve big, complex problems. They soak in detailed customer requirements, probably taking excellent notes, then hop right into Visual Studio (or whatever fuels your 20x dev speed) and start coding. Big mistake! They’ve just lost hours, days, or sometimes weeks by taking this approach. In fact, occasionally a dev will never finish the task. In this case, the power of thinking small improves performance by an infinite amount – going from an infinite amount of time down to pretty darn fast. Ok, enough selling, here’s how you think small.

Big Problem, Think Big Picture
This step is probably the easiest and most impactful of all steps of the process. Pretty much all complex programming assignments that I’ve ever had are able to be broken down into 5-10 steps (give or take). As important as your IDE is to the development process, it has no place at this stage. A piece of paper or notepad.exe are your best options. Think through the process, and break your big process down into 10 steps – logical steps, please. Your complex problem is now an order of magnitude smaller. Now break down each of your 10 steps into sub-steps. I’m telling you, this is basic, but “smart” developers skip this all the time.

Don’t let the name fool you into thinking this is a fake part of the process. The big steps you were breaking down above are going to get so basic that you find yourself writing a task that represents 5-10 lines of code. It’s at this point that you can open up your coding tool of choice. I’ve got good news though. Now that you’re in your IDE, you’re gonna fly. Using the breakout outline you did above, you’ve now likely laid out your classes, functions, child functions, etc. Because you wrote your plan in plain English (making an assumption about my blog readers here), you’ve got near-perfect function names. Take out the spaces and you’re set. Your final level of tasks can be comment headers, so stick a // , — , ‘ , /* , REM or whatever you need to in front of your lowest level comments.

Tempting Hammy, Very Tempting
You may think the right answer from here is perform a foreach(pseudoCodeBlock) { writeCode(); }
You’d be wrong. Ok, backing off my type A a bit here, you may be able to do it. You’re just a lot less likely to finish coding as fast as the way I’m about to divulge.

Minimum Verifiable Product
Yes, I just made that up, but the concept is solid. As fast as you can, get to the point where you can verify something, ANYTHING. At this point, your functions (at least most of them) should be in place. Maybe it makes the most sense to log something. Maybe it’s changing a color. Don’t care, it should just prove that you’ve got the basics down, and that you’re ready to move on to the next step.

At this point, I usually pick the easiest place to see results and code a function. Then I test and fix (notice I didn’t say refactor – if you thought refactor was the right word, look it up). Then I code another function, and another. Then I get adventurous and code a part where I can’t see results without coding a parent and a child function. Here’s the part that you’ll never hit with this technique – a logical brick wall. I’ll admit that there will still be brick walls occasionally because you don’t know the technology, but it’s not because you don’t understand what you’re going to do with your code.

Mixing In Source Control
As part of my coding and testing in small increments, as I get to a major victory point where I think I may want to return, I commmit to source control. How often I commit is proportional to the likelihood of breaking something in the next hour. I think of it like a game save point. If I may want to start from this state again, I’ll make a save point.

Full Disclosure
I’ve used this technique to the point where I can usually perform a number of these steps in my head (using a similar technique, I frequently got marked down on my physics homework). Here’s the deal. If you can save time by not methodically performing every last step I’ve outlined, that’s awesome. This works as a way to train your brain how to think like a 20x’r. Once you’re trained, move on to the doing part.

Keeping My Post Smaller
Since a ridiculously long blog post about keeping things smaller seems shady to me, I’m going to cut short on some of the other ways you should keep your start-to-finish dev process small. The final takeaway here is that in order to get faster, you’ve got to short circuit your craving to do more and force yourself to make micro-changes. Your code will look different, your final product will be more solid, and your boss will be happy to see how fast you start cranking out quality code.

One thought on “Stop Wasting Time – Start Thinking Small

  1. Pradeep says:

    its always good idea to think about CRUD , operations while developers do coding.
    What should happen during create, Read , Update and delete. Often i see that most developers stick to whats written in design document and forget to take care different scenarios related to CRUD.

Leave a Reply

Your email address will not be published. Required fields are marked *