DaedTech

Stories about Software

By

Chess TDD 15

Prompted by comments from a few people, I’ve decided to see if I like using Trello for keeping track of the TODOs instead of Excel. Also, learning from past feedback, I’ve defaulted Trello to being really big when recording so everything is legible, and I copied everything over from Excel. Hopefully I like it as I go, but please let me know if it’s more pleasing to view as compared with the Excel spreadsheet, if it matters to you one way or the other.

Also, a meta-note. I apologize for the time between posts in the series and for the lack of posting in general, but I’ve been traveling nonstop and am pretty much living out of hotels, meaning my life is one of 3G-ish wifi and sub-optimal setups. Luckily, I’m driving everywhere and lugging my boom mic, desktop and monitors with me so I can still record in the hotel. :)

Here’s what I accomplish in this clip:

  • Make the “blocked” algorithm for horizontal/vertical less dumb.
  • Start the implementation for “blocked” diagonal.
  • Inadvertently create a potential solution for the problem of knight’s oddball movement.

Here are lessons to take away:

  • Even little things matter when it comes to readability.  For instance, at 0:40 I noticed that my test class name ended in should but the methods started with “returns.”  So, I took the time to fix this.  My advice is to get in the habit of avoiding sloppiness and inattention to detail at any level of code.
  • Bear in mind that changing prod code is fine while green in TDD, provided you’re not looking to introduce new behaviors.  It’s a refactoring if your goal is continue satisfying existing test cases in a different way.
  • A little before 10:00, I refactored a bit of a test while red for the sake of readability.  I shouldn’t have.  My bad.  Lesson is, no matter how much TDD you do, sometimes you flub it.
  • Sometimes a great way to get things passing when the implementation is getting hairy is to tease out a conditional that only applies to your new case and do something obtuse.  Use with discretion because it can lead you into blind alleys and cause problems, but there are times when getting to green can provide an aha! moment.
  • You’ll notice I refactored to a different method signature, changed some stuff around, and then refactored back.  This kind of waffling is fine.  With TDD, you’ll get used to fearlessly refactoring and slinging stuff around until you settle on something you like (or at least thing is the least bad, for now).
  • Get it working ugly now, make it pretty later.  It’s sometimes amazing how an algorithm will suddenly make itself obvious after a bit of brute forcing and futzing around.

By

TDD Chess Game Part 2

Alright, welcome to the inaugural video post from my blog. Due to several requests over twitter, comments, etc, I decided to use my Pluralsight recording setup to record myself actually coding for this series instead of just posting a lot of snippets of code. It was actually a good bit of fun and sort of surreal to do. I just coded for the series as I normally would, except that I turned the screen capture on while I was coding. A few days later, I watched the video and recorded narration for it as I watched it, which is why you’ll hear me sometimes struggling to recall exactly what I did.

The Pluraslight recordings are obviously a lot more polished — I tend to script those out to varying degrees and re-record until I have pretty good takes. This was a different animal; I just watched myself code and kind of narrated what I was doing, pauses, stupid mistakes, and all. My goal is that it will feel like we’re pair programming with me driving and explaining as I go: informal, conversational, etc.

Here’s what I accomplish in this particular video, not necessarily in order:

  • Eliminated magic numbers in Board class.
  • Got rid of x coordinate/y coordinate arguments in favor of an immutable type called BoardCoordinate.
  • Cleaned up a unit test with two asserts.
  • Got rid of the ‘cheating’ approach of returning a tuple of int, int.
  • Made the GetPossibleMoves method return an enumeration of moves instead of a single move.

And, here are some lessons to take away from this, both instructional from me and by watching me make mistakes:

  • Passing the same primitive/value types around your code everywhere (e.g. xCoordinate, yCoordinate) is a code smell called “primitive obsession” and it often indicates that you have something that should be a type in your domain. Don’t let this infect your code.
  • You can’t initialize properties in a non-default constructor (I looked up the whys and wherefores here after not remembering exactly why while recording audio and video).
  • Having lots of value type parameter and return values instead of domain concepts leads to constant small confusions that add up to lots of wasted time. Eliminate these as early in your design as possible to minimize this.
  • Sometimes you’ll create a failing test and then try something to make it pass that doesn’t work. This indicates that you’re not clear on what’s going on with the code, and it’s good that you’re following TDD so you catch your confusion as early as possible.
  • If you write some code to get a red test to pass, and it doesn’t work, and then you discover the problem was with your test rather than the production code, don’t leave the changes you made to the production code in there, even if the test is green. That code wasn’t necessary, and you should never have so much as a single line of code in your code base that you didn’t put in for reasons you can clearly explain. “Meh, it’s green, so whatever” is unacceptable. At every moment you should know exactly why your tests are red if they’re red, green if they’re green, or not compiling if the code doesn’t compile. If you’ve written code that you don’t understand, research it or delete it.
  • No matter how long you’ve been doing this, you’re still going to do dumb things. Accept it, and optimize your process to minimize the amount of wasted time your mistakes cause (TDD is an excellent way to do this).

So, here’s the video. Enjoy!

A couple of housekeeping notes. First, you should watch the video in full screen, 1080p, ideally (click the little “gear” icon between “CC” and “YouTube” at the bottom of the video screen . 720 will work but may be a touch blurry. Lower resolutions and you won’t see what’s going on. Second, if there’s interest, I can keep the source for this on github as I work on it. The videos will lag behind the source though (for instance, I’ve already done the coding for part 3 in the series — just not the audio or the post, yet). Drop me a comment or tweet at me or something if you’d like to see the code as it emerges also — adding it to github isn’t exactly difficult, but I won’t bother unless there’s interest.

By

Meetings and Introverts: Strangers in Strange Lands

I’ll admit as I type the first sentence of this post that I don’t know whether this will conclude a two-part “mini-series” or whether I’ll feel compelled to write further posts. But I wanted to write the follow up that I hinted at to the post I wrote about introversion for programmers (well, specifically me). Tl;dr refresher of that post is that social situations are exhausting for me because of their inherent unpredictability as compared to something like the feedback loop of a program that I’m writing (or even the easily curated, asynchronous interaction of a social media vehicle like Twitter). The subjects I left for this post were “Erik as a problem solver and pattern matcher,” consensus meetings, and two exceptional social situations that I don’t find tiring. The challenge will be spinning these things into a coherent narrative, but I’ll take a crack at it.

Whenever I look in my Outlook calendar and see something like “Meeting to Discuss Issue Escalation Strategy,” I am struck with a surprisingly profound feeling that life is filled with senseless waste, the way one might look in dismay at his sunglasses floating down a river he accidentally dropped them into. I see an hour or two of my life drifting away with no immediately obvious reclamation strategy. My hypothesis is that this is the sort of standard introvert take on what I’ll call “consensus meetings” rather than what many programmers seem to think of as a programmer take on them. As Paul Graham points out in one of my all time favorite posts, “when you’re operating on [a programmer’s] schedule, meetings are a disaster.” But I’m not really a maker these days anymore; for the time being, I’m a manager. And I still find these meetings to be a disaster.

Extroverts draw energy from social situations and become invigorated, while introverts spend energy and become exhausted. And, when I’m talking about social situations, I mean drinks and bowling with a group of friends. Introverts like me enjoy these nights but find them tiring. Now, apply this same sort of thinking to adversarial situations that are veritable clinics in bike-shedding. A bunch of introverts and extroverts gather together and set about deciding what the organizational flow chart of issue escalation should look like. Should it start at Tier 1 support and be escalated to the manager of that group, then over to internal operations and on up to Bill in DevOps? Or should it go through Susan in Accounting because she used to work in DevOps and and really has her finger on the pulse? Maybe we do that for 2 months and then go to Bill because that’s not really sustainable in the long term, but it’s good for now. And, we should probably have everyone send out a quick email any time it affects the Initrode account. And… ugh, I can’t type anymore.

So here sit a bunch of extroverts and me. The extroverts love this. People in general love having opinions and telling people their opinions. (I’m not above this — you’ve been reading my rants here for years, so there’s clearly no high ground for me to claim.) But it’s the extroverts that draw energy from this exchange and work themselves into a lather to leave their marks on the eventual end-product via this back and forth. The more this conversation draws on, the more they want to interject with their opinions, wisdom and knowledge. The more trivial and detailed the discussion becomes, the more they get their adrenaline up and enjoy the thrill of the hunt.

I on the other hand, check out almost immediately. From an organizational realpolitik perspective, these meetings are typically full of sound and fury, signifying nothing. The initial meeting organizer turns on the firehose and then quickly loses control of it as the entire affair devolves into a cartoonish torrent of ideas being sprayed around the room as the hose snakes, thrashes, and contorts with no guiding hand. Nobody is really capturing all of this, so the extroverts leave the meeting flush with the satisfaction of shouting their opinions at each other, but most likely having neglected to agree on anything. But, my inclination to check out goes deeper than the fact that nothing is particularly likely to be accomplished; it’s that neither the forum, nor the ideas and the opinions are interesting or important to me.

scan0003

I earnestly apologize if this sounds arrogant or stand-offish, but it’s the honest truth. And this is where the part about me being an introverted problem solver and pattern-matcher comes in. The meeting I want to have is one where I come prepared with statistical analysis and data about the most efficient flows of information in triage scenarios. I want performance records and response times for Bill and Susan, including in her former role in the case of the latter. I want to have synthesized that data looking for patterns that coincide with issue types and resolution rates, and I want to make a recommendation on the basis of all of that. To me, those are table stakes to the meeting. Whoever has the best such analysis should clearly have his or her plan implemented.

But that’s not what happens in extrovert meetings. As soon as the meeting organizer loses control of the firehose, we’ve entered the realm of utter unpredictability. I start to present my case study and the patterns I’ve noticed, and then someone interrupts to ask if I captured that data using the new or old ticketing system. And, by the way, what power point template am I using because it’s really snazzy. And, anyway, the thing about Susan is that she’s really not as much of a people person, but Doug kind of is. Now the extroverts are firmly in command. All prior analysis goes out the window, and, as people start jabbering over one another reasoned analysis and facts are quite irrevocably replaced with opinions, speculation, gossip, and non sequitur in general. The conversation floats gently down stream and washes up on a distant shore when everyone decides that it’s time for lunch. All of the analysis… unconsidered and largely ignored.

And that, the extroverts taking over and leaving me to space out, is the best case scenario. In the worst case scenario, they start peppering me with a series of off-topic, gotcha questions to which I have to reply, “I don’t know off the top of my head, but I can look into it later.” This puts me at a huge disadvantage because extroverts, buoyed by the rush of the occasion, have no qualms about guessing, fudging, hand-waving, or otherwise manufacturing ‘analysis’ out of thin air. When things take this kind of turn, and someone else “wins the meeting,” it’s even more exhausting.

Regardless of which kind of meeting it is though, the result is usually the same. After lunch and everyone has a chance to forget the particulars of the discussion, it becomes time to email the real decision maker or chat one on one with that person, and re-present the analysis for consideration. Usually at that time, the analysis wins the day or at least heavily informs the decision. The meeting robbed me of an hour of my life to accomplish nothing, as I knew it would, when I looked sadly at my Outlook calendar that morning.

There are two kinds of meeting that have no chance to fit this pattern, however (I’m omitting from consideration meetings that are actually policed reasonably by a moderator to keep things on-agenda, since these are far more rare than they should be). These are meetings where I’m passively listening to a single presenter, or actively presenting to the group. It’s not especially interesting that I’d find the former kind of meeting not to be exhausting since it’s somewhat akin to watching a movie, but the latter is, apparently, somewhat interesting. Presenting is not exhausting to me the way that a night out at a party is exhausting. There are sometimes pre-speech/talk jitters depending on the venue, but the talk is entirely predictable to me. I control exactly what’s going to be said and shown, and the speed at which I’ll progress. There is a mild element of unpredictability during the Q&A, but as the MC for the talk, you’re usually pretty well in control of that, too. So, that is the reason I find typical corporate meetings more exhausting than presenting in front of groups.

A strange thing, that. But I think in this light it’s somewhat understandable. Having reasoned analysis, cogent arguments, and a plan is the way to bring as much predictability (and, in my opinion, potential for being productive) to the table as possible. For me, it’s also the way most likely to keep the day’s meetings from sucking the life and productivity right out of you.

By

Wherefore Thou Shalt Fail at Software Requirements

On Being Deliberately Unclear

For whatever reason lately, I’ve been drawing a lot of inspiration from Programmers’ Stack Exchange, and today brings another such post. However, unlike other questions, reading this one seriously made me sad. The questions, the answers, its existence… all of it made me sad in the same kind of way that it’s vaguely depressing to think of how many hours of our lives we lose to traffic jams.

I had a conversation with a coworker once that involved a good-natured disagreement over the role of legalese in our lives. My (cynical) contention was that legalese has evolved in purpose–has even self-bastardized over the years–to go from something designed to clarify communication to something that is specifically used to hinder communication. To put it another way, by freezing the language of law in pedantic and flowery period-speak from the 18th century, lawyers have effectively created a throwback to the feudal practice of having a language for the nobles and a different language for the commoners. This language of the lawmaking nobles builds a bit of social job security in a way that writers of inscrutable code have picked up on–if you make it so no one understands your work and yet everyone depends on your work, then they have no choice but to keep you around. (Lawyers also have the benefit of being able to make laws to force you to need lawyers, which never hurts.)

My colleague appropriately pointed out that the nature of jurisprudence is such that it makes sense for lawyers to phrase things in documents in such a way that they can point to decided case law as precedent for what they’re doing. In other words, it’s ironically pragmatic to use language that no one understands because the alternative is that you write it in language less than 200 years old but then have to systematically re-defend every paragraph in various lawsuits later. I conceded this as a fair point, but thought it pointed to a more systemic flaw. It seems to me that any framework for bargaining between two parties that inherently makes communication harder is, ipso facto, something of a failure. He disagreed, being of the opinion that this old language is actually more precise and clear than today’s language. At this point, we agreed to disagree. I’ve since pondered the subject of language rules, language evolution, and precision. (As an aside, this bit of back-story is how the conversation went to the best of my recollection, so the details may be a little rough around the edges. It is not my intention to misrepresent anyone’s positions.)

Requirement Shock and Awe

Because of this pondering, my strange brain immediately linked the SE post with this conversation from some months back. I worked for a company once where the project manager thunderously plopped down some kind of 200-page Word document, in outline form, that contained probably 17,000 eerily and boringly similar statements:

  • 1.17.94.6b The system shall display an icon of color pink at such time as the button of color red button is clicked with the pointing device commonly known as a “mouse.”
  • 1.17.94.6c The system shall display an icon of color pink at such time as the button of color red is clicked with the pointing device commonly known as a “mouse,” 1st planet from Sol, Mercury, spins in retrograde, and the utilizer utilizes the menu option numbering 12.
  • 1.17.94.6d The system shall display an icon of color mauve at such time as the button of color purple is clicked with the pointing device commonly known as a “mouse.”
  • 1.17.94.6e The system shall require utilizers to change their underwear every half hour.
  • 1.17.94.6f The system shall require utilizers to wear underwear on the outside of their pants so that it can check.
  • 1.17.94.6g The system shall guarantee that all children under the age of 16 are now… 16.
  • 1.17.94.6h The system shalt not make graven images.

YeRequirements2A week later, when I asked a clarifying question about some point in a meeting, he furrowed his brow in disappointment and asked if I had read the functional-requirement-elaboration-dohickey-spec-200-pager, to which I replied that I had done my best, but, much like the dictionary, I had failed at complete memorization. I stated furthermore that expecting anyone to gain a good working understanding of the prospective software from this thing was silly since people don’t picture hypothetical software at that level of granularity. And besides, the document will be woefully wrong by the time the actual software is written anyway.

While I was at it with the unpopular opinions, I later told the project manager (who wasn’t the one that wrote this behemoth–just the messenger) that the purpose of this document seemed not to be clarity at all, but a mimicking of legalese. I gathered that the author was interested primarily in creating some kind of “heads I win, tails you lose” situation. This juggernaut of an artifact assured that everyone just kind of winged it with software development, but that when the barrel crashed at the bottom of the Waterfall, the document author could accuse the devs of not fulfilling their end of the bargain. Really, the document was so mind-numbing and confusing as to make understanding it a relative matter of opinion anyway. Having gotten that out in the open, I proceeded to write software for the release that was ahead of schedule and accepted, and I never looked at the intimidating requirements encyclopedia again. I doubt anyone ever did or will if they’re not looking for evidentiary support in some kind of blame game.

Well, time went by, and I filed that bit of silliness under “lol @ waterfall.” But there had been a coworker who was party to this conversation that mentioned something about the RFCs, or at least the notion of common definition, when I had been on my soapbox. That is, “shall” was used because it meant something specific, say, as compared to “will” or “might” or “should.” And because those specific meanings, apparently defined for eternity in the hallowed and dusty annals of the RFC, will live on beyond the English language or even the human race, it is those meanings we shall (should? might? must?) use. I mention these RFCs because the accepted answer to that dreadful Stack Exchange question mentioned them, clearing up once and for all and to all, including Bill Clinton, what the definition of “is” is (at least in the case of future tenses simple, perfect, continuous, and perfect continuous).

The only problem is that the RFCs weren’t the first place that someone had trotted out a bit of self-important window-dressing when it came to simple verb usage. Lawyers had beaten them to the punch:

First, lawyers regularly misuse it to mean something other than “has a duty to.” It has become so corrupted by misuse that it has no firm meaning. Second—and related to the first—it breeds litigation. There are 76 pages in “Words and Phrases” (a legal reference) that summarize hundreds of cases interpreting “shall.” Third, nobody uses “shall” in common speech. It’s one more example of unnecessary lawyer talk. Nobody says, “You shall finish the project in a week.” For all these reasons, “must” is a better choice, and the change has already started to take place. The new Federal Rules of Appellate Procedure, for instance, use “must,” not “shall.”

“Shall” isn’t plain English… But legal drafters use “shall” incessantly. They learn it by osmosis in law school, and the lesson is fortified in law practice.

Ask a drafter what “shall” means, and you’ll hear that it’s a mandatory word—opposed to the permissive “may”. Although this isn’t a lie, it’s a gross inaccuracy… Often, it’s true, “shall” is mandatory… Yet the word frequently bears other meanings—sometimes even masquerading as a synonym of “may”… In just about every jurisdiction, courts have held that “shall” can mean not just “must” and “may”, but also “will” and “is”. Increasingly, official drafting bodies are recognizing the problem… Many… drafters have adopted the “shall-less” style… You should do the same.

Bringing things back full circle, we have lawyers misusing a variant of “to be”–one of the most basic imaginable concepts in the English language–in order to sound more official and to confuse and intimidate readers. We have the world’s middle manager, pointy-haired types wanting to get in on that self-important action and adopting this language to stack the deck in CYA poker. And, mercifully, we have a group defining the new Federal Rules of Appellate Procedure who seems to value clarity over bombastic shows of rhetorical force designed to overpower objections and confuse skeptics. On the whole, we have a whole lot of people using language to impress, confuse, and intimidate, and a stalwart few trying to be precise.

A Failure of Both Clarity and Modernity

But believe it or not, the point of this post isn’t specifically to rag on people for substituting the odd “utilize” for “use,” sports-announcer-style, to try to sound smart. From academia to corporate meetings to dating sites (and courtrooms and requirements documents), that sort of thing is far too widespread for me to take it as a personal crusade. It might make me a hypocrite anyway to try. My point here is a more subtle one than that, and a more subtle one than pointing out the inherent, RFC futility of trying to get the world to agree to some made up definitions of various tense forms of “to be.”

The meat of the issue is that using slightly different variants of common words to emphasize things is a very dated way of defining requirements. Think of this kind of nonsense: “well… shall means that it’s the developer’s responsibility, but shalt means that it’s an act of God, and will means that project management has to help, and optional means optional and blah, blah blah…” What’s really going on here? I’d say what’s happening is some half-baked attempt to define concepts like “priority” and “responsible party” and “dependency.” You know, the kind of things that would do well, in, say, a database as fields. Pointy-haireds come for the semantic quibbling and they stay for the trumped-up buzz speak, so it winds up being harder than it should be to move away from a system where you get to bust out the fine verbal china and say impressive sounding things like “shall.”

The real problem here is that this silliness is a holdover from days when requirements were captured on Word Documents (or typewriters) as long, flowery prose and evaluated as a gestalt. But with modern ALM systems, work items, traceability tools, etc., this is colossal helping of fail. Imagine a requirement phrased as “when a user clicks the submit button, a JSON message is sent to the server.” That string can sit in a database along with a boolean that’s set to true when this accurately describes the world and false when it doesn’t. You want priority? How about an integer instead of bickering over whether it should be “JSON message {shall, will, ought to, might, mayhap, by-Jove-it-had-better, shalt, may, etc.} sent to the server”? When you’re coding, it’s an anti-pattern to parse giant chunks of text in a database field, so why isn’t it considered one to do it during requirements definition?

We have far better tools for capturing and managing requirements than word processors, pointless arguments over misappropriated grammar, standards used to define ARPANET in the 60’s, and polyester bell-bottoms. It’s 2013, so let’s not define and track requirements like it’s 1999… or 1969. Ditch the RFCs, the waterfall, the BS Bingo talk, and the whole nine yards if you want to get things done. But if you’d prefer just to focus on figuring out who to blame when you fail, then you should/shall/will/must/might/shalt not change a thing.

By

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.