« « Answering some FAQs about Fusion Tables

Adventures in rebooting my coding practice » »

Hacking till it works is no longer enough

Posted by on Dec 25, 2011 in Blog, Uncategorized | 11 Comments

Learning to code with editorial intent has been a pet project of mine for years by now, but this week was the first time I literally found myself in tears, because I couldn’t get something to work.  My father has a great story from his educational days, about how he changed degrees because he saw the first time, he didn’t like school. So it goes with the past few days.  Something has gone wrong with my path.  There are two options: recognize this has been a fun experiment, but it’s over now (this is not an option at all, I’ve learned too much and am way too committed), or figure out the problem and move forward.

I’ve looked at the code of really good journoprogrammers, people I have been lucky to count as mentors, and in comparison, my code tends to look like a jumbled mess of horror, whereas theirs is all…neat.  This isn’t about commenting, which I also “should” do more of, but how we organize our content.  It’s just like how when we write stories, we organize our notes and think about the structure.  But I’ve been so delighted that something actually works, I’ve slacked off.  Not to mention that having to code faster than ever before in my life means I leave out what I know I should do.

(My self-practice has also dwindled while I was on chemo.  Short story: Kidney disease comes back, I treat it like any coding problem, solve the bug, it goes back into remission.  Next?)

What does “should” mean anyway?  There are so many conventions.  I know people who learned CS in school got some of these through formal education. But why should I use these conventions? It’ s easy to self-deprecate — “Oh, you should see my crappy code!  It’s so horrible, and such a mess!”  Commiseration occurs.  But this is not something to be proud of. I wait for the moment when the “real developers” stop being polite, and complain when they have to update something, and tell me I’m too far behind.

Anyway, I’ve never been one to do things people tell me, without understanding the “why”? Why shouldn’t you repeat code in a project? This won’t be a surprise to the experienced ones reading, but it’s not because it’s some requirement for no reason, not some teacher trying to add restrictions to a rubric.  It’s easier to fix bugs, make changes, understand how your program works days, weeks and months after you wrote it, if you strip it down, make it comprehensible.

I’ve been working harder than ever before at my job, and I do love it, but I am bewildered.  I remember other mentors saying a core missing piece of my knowledge was  experience building “big systems.”  I arrived at my present employer, and I was told I was going to build big systems.  And I have, and I am, and I would not attempt it if I didn’t have the support of a team and organization that believes in me, in a way I can’t even comprehend yet.

Here’s the new deal, though.  Now, I need to build better.  Not be pleasantly surprised my code works. Choice words from a current mentor: “It’s not a question of if you can get the program to work, but how, when and if it’s worth your time.”  I live in fear of not hitting the when, and I think addressing how I code, will help me feel more confident about hitting those deadlines.

The concept of organizing code, I’m told by smart people, is “modular programming.”  The idea of breaking things up into pluggable, reusable pieces.  I’m hoping that’ll make it easier to comprehend what I’m doing, and why I’m doing it.  It also seems to work with the idea of Backbone, a technology I’m learning now.  I think I relied on frameworks like Django to do a lot of organization for me. Now that I use JavaScript much, much more often, that structure needs to be replicated and enforced.

If you have any tips on how to organize work more smartly, when crafting large-scale systems (and my large-scale systems aren’t really that large…yet), point me to examples, books, screencasts, articles, what have you. This isn’t the sexiest problem I’ve ever approached, but it is no less or more important than all the mapping work I’ve pursued.

The mission of 2012: Have the confidence to know I can.  Gain the knowledge to do it right, not just do it. Appreciate beautiful code itself, see it as more than a means to an end (awesome interactive stuff).

I’m really thankful for friends, family and colleagues who believe in me.  Without all of them, I would have given up on this long ago.  It is time to acknowledge I am in some intermediate stage of learning now, and that it is time to go big or go home. I’m not going home. I can’t help but feel I’m on the cusp of something big, once I figure this next step out.

Did I really say recognizing that I can’t do this was an option, at the beginning of the post.  Yeah, did anyone actually believe that was going to happen?

Mentors of the programming-journalism world: I’m coming at you for some guidance on this. Maybe I’ll even blog about it.

« « Answering some FAQs about Fusion Tables

Adventures in rebooting my coding practice » »
  • http://lifeandcode.tumblr.com Lisa Williams

    I’m pretty far behind you, but I’m really interested to hear what you learn on this front.  Since I’m a novice, I’m still trying to learn conventions about things like indentation and commenting.  I admit, it’s been hard to find resources on that.  There seem to be plenty of style guides and grammar tutorials for written English, but I haven’t really run into something that will help me on that level with my code.  


    Michelle Minkoff Reply:

    Oh, I don’t think anyone is really “behind” anyone else — we’ve all got a ton to learn.  I don’t ay it enough, but I really enjoy the resources you post, and following your journety.

    Even really experienced people tell me they remain newbies, as the tools continue to change rapidly.

    I totally hear you on this. The one suggestion I would make, which it sounds like you’re already doing, is pay attention to this now.  Don’t be me, sitting at my desk staring at 1200 lines of code, and having to use a find command to get to any part I need to update.

    I wish I had developed better habits in this area, so I don’t have to unlearn them.  Countless people told me this, but did I listen?  Not so much.


    John Campbell Reply:

    Habits are important. I got into one at Unisys that is generally ridiculed by more serious programmers, but I find it works for me. Worlds away from ‘big systems,’ I did no ground-up coding then, but specialized in tables of Perl regular expressions to be applied to incoming wire copy.  This was concentrated arcanity, and it would have to be turned over to a journalist customer who would maintain it after the install. My self-imposed constraint was to comment EVERY LINE of code, whether it seemed necessary or not. I carried that over to stand-alone code at the newspaper, though I can’t say I stuck with it on every project. Without that constraint — leaving it up to my own judgment in the heat of the moment — I found it way too tempting to push on with the code, figuring this or that passage was self-explanatory or I’d comment it later. Later, of course, there’d be another fire to put out, and later still, I’d be staring at a block of totally uncommented code. So better to live with the 60 silly comments than to do without the 40 that will save the day later.


  • http://twitter.com/richiec Richard Cornish

    Combing through my Delicious links, here are the ones that might help you write bigger applications. My apps could be written with jQuery and some DOM manipulation, and never needed to use patterns, but sounds like you’re doing bigger work. I hope these help.

    JavaScript inheritance by example
    Simple example on using constructors to make and duplicate objects. Written by former Yahoo developer

    Essential JavaScript Design Patterns For Beginners
    Covers just about all patterns in writing modular JavaScript. Everyone seems to like Crockford’s module pattern, which creates private and public members. Everything is written to basically avoid function/variable clashes in the namespace.

    JavaScript Garden
    Covers the “quirkier” parts of the language. Good to get perspective on the shortcomings of JavaScript.

    Douglas Crockford’s code conventions
    The “father” of JavaScript’s way of doing things. Most I agree with, some not. Some of the shorthand in the name of optimization creates too much obfuscation, but a nice resource to have.


    Michelle Minkoff Reply:

    You are fantastic!  Skimmed all of these, and plan to go deeper soon.  Even knowing there is a way to conquer this is making me feel so much better.


  • http://twitter.com/palewire Ben Welsh

    It didn’t click for me until I saw James Bennett speak at DjangoCon in 2008. This talk, literally, changed my life. http://www.youtube.com/watch?v=A-S0tqpPga4


  • http://lifeandcode.tumblr.com Lisa Williams

    Hey, Richard — Those links are really useful.  Code conventions are the kind of thing I’m looking to learn.  


  • http://twitter.com/pp19dd Dino

    Best thing to do when you’ve run into a dead end is to get a spare set of eyes to look at it. Process of explaining what the problem is will often enough solve the issue by illuminating something you’re tunnel-visioned on.  Second strategy is to take a break and let the problem stew in the ye olde braine.

    But, otherwise, there are some of us who at times find spaghetti code (with occasionally repeating blocks) acceptable in a rapid prototype.  In a freeformed rapid prototype, where developers are the glue that holds pieces together, you can’t always anticipate which direction the code will go.

    A rapid prototype might generate a surprising level of interest mid-development,
    and it will get launched against your will and relaunched several times before you can respond to its needs.  I’m usually told to “cauterize wounds and ship it” since it’s my nature to over-complicate code for way too long.

    This might be a good thing – it helps you prioritize future development correctly. It’s only after you launch the prototype that you will run into its quirks and discover what needs will different users have for it.  At that point, you can cycle back and intelligently redesign the internal guts to work the right way.


    Michelle Minkoff Reply:

    That’s a really great suggestion, Dino. I’ll try applying that mentality to my side projects.


  • http://borasky-research.net/about-data-journalism-developer-studio-pricing-survey/ M. Edward (Ed) Borasky

    I’m not sure what language you’re working in, but I love Martin Fowler’s “Refactoring” for when you get stuck. http://j.mp/ylZ8JO


    Michelle Minkoff Reply:

    Thanks!  I got the same recommendation from a colleague, it’s next on my list!