Frozen scratchpad software#
Frozen scratchpad code#

This is a scratchpad project that has the kitchen sink, from persistence on up to the GUI.

It might be lack of experience, lack of curiosity, or lack of interest, but I’d view this as most likely a lack of something. I’d be leery of a programmer with no scratchpad.

Frozen scratchpad code#

I mean, lacking a playpen and tests, what else can you really do? It’s all well and good to ask a coworker or read something on stack overflow, but at some point an implementation has to happen, and when it does, it’s going to be in the production code and it’s probably going to be copy-pasted in as a matter of faith. The reason I say this is that this person’s natural reaction to a lack of understanding of some facet of code will most likely be to try it in the production code, fire up the application, and hope it works. In either case, they’re lacking a place that they can go in and just throw some code around to see what happens.Įxtrapolating out to the way a person with no scratchpad works, it seems very likely that you will observe a lot of “debugger driven development” and “programming by coincidence”. (One possible exception is that they experiment in a project’s unit tests, which is actually a pretty reasonable thing to do, and an example of a reason for my “broad strokes” caveat). The lack of such a playpen project implies that they either don’t experiment or that they experiment in production code, which is pretty low rent and sloppy.

If someone doesn’t have something like this, they’re quite likely either not very seasoned as a developer or else not very inquisitive when it comes to understanding their craft. I’ll describe the “arsenal” of scratchpads further down. In the examples below that describe a single type of scratchpad, please note that I’m referring to situations where this is the primary or only scratchpad that the developer uses. So, please read the following while bearing in mind the caveat that there will, of course, be exceptions to the ‘rules’ that I’m describing. I’ll say in advance that I’m going to paint with some broad strokes here. In fact, I believe strongly enough in this that I see a lot of value in the interview question “tell me about your scratchpad and how you use it.” This is a very useful practice but, more interestingly for the purposes of this post, I think the makeup of this scratchpad (I’m using this term because it’s what I name mine) can tell you a lot about the developer using it. If you get very used to setting up experiments in this fashion, it tends to be almost as quick as a search, and there’s less potential for wrong or misleading information. And, if they wind up doing this enough times, they start creating a project or project(s) with titles like “dummy”, “scratchpad”, “throwaway”, “junk”, etc - you get the idea.Īs this practice grows and flourishes, it starts to replace google searches and ask a coworker to a degree, even when those things might be quicker. When you have a question like “what exception is thrown when I try to convert a long that is too big to an integer” or “what is the difference in performance between iterating over a list or a dictionary converted to a list” what do you do? Google it? Phone a friend? Open up an instance of your IDE and give it a try? I think that sooner or later, most developers ‘graduate’ to the latter, particularly for things that can’t be answered with a quick search or question of a coworker.

Frozen scratchpad software#

Category: Language Agnostic, Uncategorized Tags: Software Engineering, Unit Testing What is a Scratchpad?