Blueprinting

Before you write any code, spend some time describing a blueprint of what you want your code to achieve. Code can be hard to grasp, especially densely written logic. Keeping track of nested loops, variables, and interim tables will test the RAM of even the most experienced of coders! It is easy to feel lost even when reviewing code you have written yourself, especially if returning to it after a break.

I recommend writing code in a sequence of scripts (or discrete blocks with clearly demarcated functionality), and the first in that sequence is a plain-english description of what each script is intending to accomplish. Ordered bullet lists work better than descriptions in paragraph form. The simple exercise of writing down the functionality and it’s connection to the overall purpose of the predictive modeling exercise not only helps improve documentation, it can help write organized, streamlined, better – code.

Prototyping

Especially when dealing with large data sets, it can be extremely inefficient to write & test code on the target data. Try to find a clean data entry point into your code-flow. And then write & test your code simultaneously by allowing a small amount of target data through. For example, use only the top (or random) one-thousand rows of data, rather than millions, in order to complete your code development. Prototype your solution with small amounts of data, and once satisfied, run the whole thing through it. This will help you develop error-free code quickly.

Yep, told you the ideas don’t look like they deserve calling out in so many words. However, many that are new to coding especially in data-rich environments tend to overlook these. I promise you, these two simple concepts can save you hours if not days of re-work!

The post Blueprinting & Prototyping appeared first on Predictive Modeler.

The design spares the user pain by already segmenting the chocolate into neat little bite-sized squares. I am delighted by my purchase, even before I have eaten anything!

Great design is around us, and also poor design. Both offer valuable lessons to you, as a predictive modeler. Delight the user even before they get the results of the modeling. Do something unexpected in the design of your solution that makes it easier, faster, or more convenient for the user to consume your work.

The effectiveness of a solution goes beyond performance. Many times I have opted against a more complex solution in favor of one that was simpler. I understood that I am not merely a consumer of a solution. I am that, and much more. I am human. Yes, I need to create a predictive model today, in the next 30 minutes. I have tennis in the afternoon and then a date with my wife. I don’t have time for a learning curve, and would much rather have a solution that just works, than one that works better if I spent time massaging it. I don’t serve your solution, your solution needs to serve me – the user.

Chocolate squares that are pre-cut in the perfect size 🙂

The post German Engineering appeared first on Predictive Modeler.