« « Hacking till it works is no longer enough

The word of 2012 — Moderation » »

Adventures in rebooting my coding practice

Posted by on Dec 28, 2011 in Blog, Uncategorized | 3 Comments

After my approach to a nervous breakdown last week, kind people in the community have helped me get back on track.  I have restructured my current big project so it no longer includes a “miscellaneous” function, and is sorted into logical pieces.  I am also seeking to learn the actual vocabulary fo what things in programming are called, because conversations like this are not really a good thing: “Then, I put it into the thing with the curly brackets, and then I tried to access the thing with the other thing, and there was an error, which mentioned another thing that I didn’t understand.”  The polite response to this is “Can I see the code?”  A more appropriate one might be “Would you get with the program and play ball like a professional coder?”

I hope it will not embarrass Jonathan Stray, who I count as a friend, manager and colleague, who has already been more than helpful with sorting out the technical issues, and providing kind reassurance that this is surmountable.  And that’s in three days, since I started this “leveling up.”  I’d be surprised, except this is in the pattern of Ben Welsh and Ken Schwencke of the LA Times, and Derek Willis of the NY Times (who also dealt with being consistently featured on the blog, so it is what it is).  I’ve thrown myself back into learning, just like I did when I decided I had to learn Python to get into this world.  I’m at a level where I can pass on some knowledge, but somehow I think I lost that I need to be working just as hard on my own education.

Some thoughts:

1. I’ve long said the programmer-journalist label doesn’t matter, but interacting with Jonathan has demonstrated the power of a CS background.  I think that’s more of why I feel so behind.  To paraphrase Jonathan, what a CS degree gives you is the ability to understand common constructs in programming. So, while the languages change, their building blocks have commonality that you have some understanding of.  For the first time, I get why that would be very powerful.  Meanwhile, I play catchup. This is not something I would have considered if not for working with someone who has that background, and works at the intersection of journalism and technology.

2. I try to think of functions as building blocks. It’s a lot like news writing — keep the chunks short and digestable, each section has a distinct purpose.  Now, my functions look more like an outline.  Small blocks, medium sized blocks combine smaller ones.

3. Things are busy in a newsroom, and I love the adrenaline rush.  But thinking it’s enough to just keep all the balls in the air causes major headaches later.  MAJOR.  As in, I didn’t understand how horrific it would be.  Slow down now so you can speed up later.

4. Don’t underestimate the power of an external CSS file.  Changing too much CSS with jQuery can cause great confusion.

5. Put in more effort to ground yourself in why you’re doing it.  I could write code all the time, but I’m paying more attention to everything else in the DC bureau, so I can be the best citizen of the newsroom I can.  You’ll always be too busy, if you let yourself.

6. I’m setting a goal of commenting every line of code.  Much like how I try to go to the gym seven days a week.  In both cases, this doesn’t happen, but with some slacking, I end up doing things just frequently enough.  The comments are for others, but more to remind me of why I did something.  Also, a great opportunity to develop a vocabulary for discussing code.  Writing out “we add the thing to the bigger thing” really hits you over the head with what you need to learn.

7. Every language has patterns that are common conventions. Other people have encountered your problem before.  It’s up to you to figure out what applies to your situation.

8. Saying you can be self-sufficient doesn’t mean suffering in silence.  It is not letting down yourself, your mentors, your community and your organization.  It is a growth process. It is not a weakness to ask for help. It is not a weakness to tell your boss you don’t know if you can do it, despite every piece of career advice you may have been given, which says young journalists should say yes to everything, and figure it out.  It is a problem if you make this proclamation a day before deadline. It is a problem if you give up. It is not a problem if you dive into trying to learn, and feel reinvigorated and challenged. It is a different type of problem when you have a bookmarks folder with 250 articles to read after three days, because of your research, and suggestions from folks within and without your place of employment.  The kind of problem that’s nice, and life-affirming. That, I can handle.

Related posts you might enjoy:

Zemanta
« « Hacking till it works is no longer enough

The word of 2012 — Moderation » »
  • Anonymous

    Michelle, it sounds like a lot of what your learning is time & stress management, which is indeed a hard thing to learn on your feet. As Brian likes to say, newsrooms are a crucible. I very nearly washed out of Tribapps in the first week when I realized the pace I needed to maintain. I think you’ll find that this is something that has more to do with your confidence in your own estimates and ability to say “no” then the idiosyncrasies of the place. Respect your own ability to plan and make sure other’s are listening, not just making requests.

    As to the technical struggles you’re having–there comes a point in every hacker’s life where ad hoc stops being supportable. A lot of good abstraction patterns can be learned from reading other people’s code and applying what you see, but at a certain point it can really help you’re thinking to crystallize if you sit down and read an expert on the subject.

    If you haven’t I would strongly recommend you pick up Code Complete (http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670 ), by Steve McConnell. It’s really *the* book on programming at the small scale and taught me innumerable things about breaking my code up into manageable pieces. It’s also extremely readable and probably won’t take you a lot of time to start putting the lessons to work. I know it can be kind of lame to recommend a book when you’re already probably kicking way too many hours into your work, but I really think this is a worthwhile investment.

    Lastly, I’ll note that writing manageable code doesn’t end at the small scale, you’re going to run into several of these “ridges” in your programming career where things get inexplicably harder and it’s usually because you need a new set of abstractions in your toolkit. I think I’ve been through 3 distinct ones, so when you get to the next one (which you will) let me know and I’ll have another book for you. :-)

    [Reply]

  • http://twitter.com/JoeGermuska Joe Germuska

    I’m not sure what Chris had in mind for vetoing #6, although maybe it’s something from “Code Complete” — but I’ll generally echo the sentiment. You can write your code so that it’s self documenting, by using meaningful variable names and extracting into a well-named functions anything which would otherwise get a comment.  Comments have their uses, but they can also be clutter.

    Regarding #7, absolutely. I hope by now you’ve found “Code Like a Pythonista” and PEP 8. I don’t know the equivalents in other languages off the top of my head, but they must be out there.

    Happy new year!

    [Reply]

  • Anonymous

    @twitter-10470:disqus : The book basically lays out what you just said. Readable code is almost always about good variable naming and sensible organization. I’ve never once read a great piece of code and thought, “Wow, that made great use of comments.” I have frequently thought, “Wow, that code was so good it didn’t need any comments.” Of course that’s not to say they are never useful–they are especially necessary when dealing with eccentricities of your dependencies. Frequently it’s other people’s code that’s ugly and you just have to document how you made it work. I like Code Complete because it codifies a lot of these ideas into digestible units of understanding. 

    [Reply]