You Can Tell a Lot About Developers From Their Scratchpads

What is a Scratchpad?

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. 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.

As 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. 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. 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. 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.”

I’ll say in advance that I’m going to paint with some broad strokes here. 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. 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. I’ll describe the “arsenal” of scratchpads further down.

No Scratchpad

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. 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. (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). In either case, they’re lacking a place that they can go in and just throw some code around to see what happens.

Extrapolating 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”. 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. 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.

I’d be leery of a programmer with no scratchpad. 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.

Application Scratchpad

This is a scratchpad project that has the kitchen sink, from persistence on up to the GUI. In shops/groups that make a single product, it may be as simple as a duplicate of that project. In shops with more projects, it may be one of them or a composite of them. But, whatever it is, it’s a full fledged application.

Extra points here for being clever enough to have a consequence-free, dummy environment and for recognizing the value of experimentation. This is usually a sign of an inquisitive developer who wants to take things apart and poke at them, or at least a conscientious one who wants to try things out in dress-rehearsal before going live. I’d take some points away, however, for the monolithic approach here, assuming that this is the primary scratchpad and not an auxiliary or temporary approach. The reason I’m not such a fan of this is that it’s indicative of someone who hasn’t yet learned to think of an application in seams, components, modules, units, etc.

I mean, think about how this goes. “I wonder what happens if I use a string array instead of a string list here” leads to trying out the change and then firing up an entire application, complete with GUI bells and whistles, database access, file reads/writes, loggers, etc. This represents a view of the software that essentially says “it’s all or nothing, baby — here we go.” Good on them for the experimentation, but we can certainly do better.

Console Based Scratchpad

The console scratchpad (and this is a little Visual Studio specific, though it’s applicable to other IDE/environments as well) is one in which the main running application is one that writes to and reads from the console. If you wanted to time stuff you’d be doing so using a lot of System.out.println() or Console.WriteLine() or whatever the equivalent in your choice of language.

This correlates with the good characteristics of the GUI/application scratchpad (curiosity, judiciousness) but adds a bit more sophistication. A developer with a console based scratchpad understands how to decompose and abstract concepts and how to isolate problems. I think that this is potentially indicative of a competent and potentially great developer perhaps ready for a push.

Class Library Scratchpad

The most sophisticated scratchpad, in my mind, is the class library scratchpad. This is a scratchpad that has no program output of any sort and cannot be run independently. What this means is that the developer is used to reasoning about units and experimenting in very small, isolated fast feedback loops. Someone doing things this way clearly understands that increasingly complex applications are assembled from solutions to manageable problems rather than with some kind of irreducibly complex, inter-connected gestalt. Someone with this style of scratchpad is almost certainly a unit tester and most likely a practitioner of TDD (I certainly recognize my own bias here). But the most important thing here is the ultra fast and simple feedback loop, where answers to “how does this work” are provided right in the IDE itself (and extra points for anyone running a continuous integration tool like NCrunch.

Monolithic Scratchpad

A monolithic scratchpad is one that tends to be a developer’s only scratchpad. I think that this tends to be indicative of an architecturally minded developer capable of thinking in significant abstractions. The monolithic scratchpad is one that encompasses all of the projects above in one. It has test projects for fast feedback. It has a persistence model or two and a domain of sorts. It has a web front end and a desktop front end and mobile front end. In short, the developer organically evolves this scratchpad to suit whatever experimentation needs arise, demonstrating an ability to grow an application in response to whatever needs arise. Someone with this sort of scratchpad setup is someone I’d keep my eye on as a potential architect.

Arsenal of Scratchpads

An arsenal of scratchpads is indicative of a developer seasoned enough to understand that different questions call for different environments, but someone more silo-oriented and, perhaps, very well organized in a sense. While it may not occur to this person to blend scratchpad needs into an ad-hoc, decently architected application, the work nevertheless exists in such a way that it’s easy to find, access, and use. Since the response to new situations is new scratchpads, the critical fast feedback loop is there since they never get very big. I think that this practice is indicative of someone who might excel in small to medium sized picture development work or, who might do well on the path to project management. A monolith scratchpadder and an arsenal scratchpadder could probably form a pretty good leadership tandem on a project.

What Does your Scratchpad Look Like?

I’d like to reemphasize that this is a fairly lighthearted post that I fully acknowledge may completely miss the mark in categorizing some people. But, I do think there’s a grain of truth to it, and I stand by my assertion that this would make for an excellent interview question. If you have one of these types of scratchpads and either reinforce or poke holes in my premise, please weigh in. Same if you have a scratchpad setup I hadn’t thought of.

  • http://genehughson.wordpress.com/ Gene Hughson

    I like the multi-pronged approach…quick research to see what approaches people have taken and then the arsenal scratchpad (depending on whether it involves web, WinForms, console or services) to apply one or more ideas to my specific scenario.

  • http://www.daedtech.com/blog Erik Dietrich

    I like the arsenal too. I’ve kind of evolved to a hybrid of monolith/arsenal over time, where I have one main scratchpad and then others that I create as I need them in a pinch. And, once they’re created and used, why not keep them around…?

  • http://tqcblog.com/ Tom Clarkson

    I stopped using scratchpad projects years ago. Pretty much any question that comes up is related to a specific context, so it is easiest to either modify the actual code or put in a breakpoint and change the parameters.

    Experimenting on the real codebase is not a bad practice if you are using DVCS branching properly and have a reliable build/test environment set up. I might even suggest that preferring to use a scratchpad is a bad sign, as it indicates that your build/test process is either untrusted or too slow.

  • http://www.daedtech.com/blog Erik Dietrich

    That’s interesting. I find that a good portion of things I wonder about aren’t context specific or that I can re-create the context needed in a vacuum (as in they aren’t really domain or project specific). As for experimenting in the production code base, my strong criticism of that was mainly based in the fact that I wouldn’t want to do something where missing an edited file during a checkin had me checking in code never intended for production. Sure, rolling back is no problem… once we figure out that I did that. But, your point is taken in that source control could easily be used for say the export function or creating a clone branch or something.

    I’m also intrigued by your point about the project feedback time, which would suggest that perhaps I’ve underrated the practice of doing experimentation in your unit test code. I think that’s a fair practice. However, I don’t know that I could go so far as to agree that scratch-padding is a bad sign. There may well be plenty of scenarios where you’re working and don’t have control over the build/test time (large team, distributed team, legacy project, and policies not allowing you to change things easily). So, I’d say it might be a bad sign about your *project* but not about the developer. My take, anyway — YMMV.

  • http://tqcblog.com/ Tom Clarkson

    Personal working style probably does come into it a bit – I tend to learn new stuff by having a specific task to solve and exploring the system around that rather than studying the system directly.

    The risk of inappropriate code making it to production is always there as soon as you give a developer write access to the codebase – the only way to prevent it is an adequate testing setup. Having a separate project for experiments may reduce that risk slightly, but it also adds complexity and the risk of getting something wrong when you copy working code from the scratchpad project to the real codebase.

    I agree that issues with the project are not necessarily developer problems. That said, there is a lot you can do to work around the limitations of the official environment – getting the complete code running in an environment you control isn’t always easy, but gives a much better result.

  • http://genehughson.wordpress.com/ Gene Hughson

    Of course, when working on the design of a brand new feature (or even a brand new app), there’s no existing code base to experiment on.

  • http://tqcblog.com/ Tom Clarkson

    In that case, just set up a new app properly – it isn’t really any more work, and is a lot easier to make production ready if it works out.

  • kamranayub

    I think it depends on context; I use jsFiddle a lot for a Javascript scratchpad, LINQPad for a lot of C#/.NET-based stuff, and unit tests for specific projects (assuming they have any…). I will create separate junk projects if I want to test something out on a specific application type (MVC, Web Forms, Web API, whatever), but I’d definitely say LINQPad gets the bulk of my scratches.

  • http://genehughson.wordpress.com/ Gene Hughson

    I would question your definition of “properly” if you really think that it’s no more effort to set up an app “properly” versus creating a quick proof of concept of one isolated aspect of that app.

  • http://tqcblog.com/ Tom Clarkson

    Having the right templates available makes a big difference – that part takes a bit more effort, but only needs to be done once.

  • http://genehughson.wordpress.com/ Gene Hughson

    So, if I’m investigating whether ClickOnce makes sense for a sometimes-connected app, I should create the entire app just to validate that one aspect? Same for trying out serialize to file vs local db for that same sometimes-connected app? Same for proving out how easily a particular service can be consumed, etc. etc. etc.

    I would suggest that the range of use cases for this particular technique is broader than those that are just relevant to what you do. I would further suggest that you might want to consider that just because something is outside of your needs/experience, it isn’t necessarily a “bad sign”.

  • http://www.daedtech.com/blog Erik Dietrich

    One thing that I would say is generally true about my scratch-padding (and work in general) is that I won’t copy it from there to a production code base. It’s truly a place for throw-away code or prototyping. If it were to go into production code, I’d manually re-introduce it following TDD.

    And getting a version of the codebase I’m working on going in a playpen environment is something I do as well when I need to. When I find myself wanting that, I usually port the module I want and a bare minimum of dependencies, which cuts down on feedback time and complexity and has the added benefit of helping me understand the dependency graph of the application better.

    I think there’s a decent amount of overlap in the way we approach things, and I as I address comments and think more on this, I’m realizing that I’m more of a scratchpad jack-of-all trades than I first thought. I’ve seen LinqPad mentioned here and on twitter, and I use tools like that as well from time to time.

  • Pingback: Introduction to Unit Testing Part 2: Let’s Write a Test | DaedTech

  • Pingback: Intro to Unit Testing 9: Tips and Tricks | DaedTech