Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The Benefits of Coding Offline: On Encapsulated Codebases and Headspaces

DZone's Guide to

The Benefits of Coding Offline: On Encapsulated Codebases and Headspaces

Sometimes your brain does something cool when it's just you and the code.

· Java Zone
Free Resource

Make it happen: rapid app development on Kubernetes as a managed service.

Last weekend I spent an afternoon at a coffee shop with no wifi in order to solve a problem that I thought should have been simple (automatic de-duping) but which had stumped me for weeks. (I was getting false positives in a pattern I couldn't figure out.)

It took me less than an hour to solve the problem. Turns out I had been counting on one number (but really a string) being very unlikely to collide with other numbers for more than a few digits, when in fact that number -- for domain-specific reasons -- was supposed to share lots of n-grams with other numbers. Dead-simple fix, once I figured this out..and felt stupid for not noticing it before.

So as I stewed about being such an idiot I began to think of why the solution came so easily this time. Also noticed that my brain seemed to be focusing on this problem much more laser-like. (So much for Stack-Overflow-driven-development.) Here's what I came up with..curious to see if others have had similar experiences.

  1. The keywords you use to find others' solutions are an early-stage diagnosis that might also be wrong (and lousy first hops in search trees are just unfortunate). In my case, the problem wasn't that I wasn't applying generally useful fuzzy de-duping methods, but rather that the de-duping methods I was applying were irrelevant for domain reasons. Okay, normally, if I'm SODD/Google tackling a coding problem, I get around this by including some domain keywords too..but that feels significantly less satisfying, too pre-packaged.
  2. Using someone else's solution might mean you haven't really understood it. Sure, there's a difference between blindly pasting someone else's code (which none of us ever do, not even for exception handling or other mostly-decoupled activities, no sir) and sifting through it carefully to understand how it works. But it seems intuitive (to me) that there's a third level of understanding: you'll internalize an algorithm much better by coming up with it completely on your own, raw, with no Stack Overflow or Stony Brook safety net. 

    There's always a short-term/long-term trade-off here, of course. Save time by standing on the shoulders of giants, sure, but if you invest more time growing (your coding muscles, or your knowledge of some platform, or even just your head-coupling to the current codebase) then next time you stand on the same giant's shoulders you'll see farther still. 

    (Of course in some perfectly SRP+DesignPatterns world copypaste across codebases should work just fine, especially for those annoying problems that you don't want to bother solving from scratch because you know a thousand other developers have already solved basically the same problem. Then again I don't know many JavaScript developers who would actually defend the whole  left-pad hilarity from a few months back.  npm-ing it up to this excessive degree feels a little too DRY-ideological to me, like rejecting all if-statements in favor of Decorators [which, to be fair, the article linked doesn't exactly do].)

  3. Just knowing that someone else's solution is accessible might make you a little lazy. This probably depends a bit on personality type -- for example, a hyper-competitive person might actually be motivated by the availability of others' solutions -- but some problems just don't feel worth competing over. (Seriously, de-duping account information is not sexy. Well, maybe others feel otherwise, I don't know.) Not 'habitually lazy', of course, but 'optimizing brainpower lazy', the desirable sense of 'programmer lazy'. But StackOverflow-happy-lazy is a breadth-first optimization, and the SO/Google tree can be very wide (depending on topic)..and probably everyone already applies a little pressure toward depth-searching when initial SO scan doesn't work. But after that initial scan your brain is already in BFS mode, and maybe subconsciously...

  4. Keeping some of your brain in a SO/Google search tree keeps that part of your brain out of the codebase you're actually working on. Even if you end up using no code from someone else, your headspace and your codebase have come a little apart, and, even if nobody checks, your search history is a little like something  public  that didn't need to be. Coding offline felt like encapsulating the code (the data) together with my mind (the functions) and leaving no SODD set  methods dangling.

  5. Besides, if others' solutions are just inaccessible, then you might as well be solving the problem for the first time -- which is seriously more satisfying, the kind of satisfying that makes coding feel worthwhile. And it doesn't really feel as satisfying if you're just deliberately avoiding others' solutions, because then the solutions space accessible to you does already contain the solution you're looking for, which means you're not really discovering it yourself.

(Side note: the focus I felt this time may have been caused partly by previous use of the particular location -- this is the coffee shop where I did all my major writing in grad school -- so I probably benefited from an additional context-setting that put my brain into the 'concentrate on the problem that only you can solve' headspace. Physical (bodily, sensorial, extra-IDE) development environments is a whole nother can of worms...)

Tutorial: WordPress as distributed microservices on Kubernetes.

Topics:
headspace ,programming ,sodd ,discovery

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}