When I heard Meyer had written his memoirs, titled “Paper Route: Finding My Way to Precision Journalism”, I instantly clicked the 1-Click purchase link on Amazon.  Days later, I ripped open the package, smiled at the cover photo of a very young Meyer reading the paper with his father, but didn’t have time to push further.  And on a delightful Saturday afternoon, after soaking up inspiration at the National Portrait Gallery, I sat down in the Kogod Courtyard attached to the museum (one of my favorite places to read in DC on a snowy day) to read a few chapters.

Two hours later, I had gobbled up all 338 pages, laughing out loud, nodding enthsiastically and remembering that Meyer was one of the first of “my people”, in days my parents had not yet married, let alone had a child.

The title of this post comes from a comment he makes while sitting in a social science class and realizing the application of data analysis work to journalism. But it applies to code, and mapping and interactivity and everything I do these days. Not that a coder should do it, but “A journalist could do this!” So, whenever I doubt, I’ll remember.

The book traces Meyer’s family history, going back several generations. As one might expect, it features letters from relatives in World War II, letters from him during college to his family back home. Because if anyone knows anything about providing primary source documentation for a story, verifying anecdotes with facts, it’d be Meyer.

I was inspired by realizing that he started his career in high school journalism, much like me, and not doing the type of work he has become known for.  That came later, but it was all part of a path, or a route, as the book’s title suggests.  He discovered data work as a Nieman Fellow in the 1960s.  Perhaps naively, I didn’t realize the history of Nieman went back to the ’60s. Meyer wrote that he was past the median age for Nieman fellow applicants at that point in his life, which is to say, he wasn’t in his 20s.  And it was then he discovered the tools of precision journalism.

All of which is to say that as much as I live in fear of not living up to what I can be, I’ve got lots of time to figure it out.  And the Big Impact that I hope to make, if it comes when I’m in my 30s, 40s, 50s — that’s okay.  Perhaps it’s presumptuous, but this book tells me that our paths are not so different, because Meyer’s story was not so unusual, in its parts.  Taking advantage of opportunities as they came his way, it seems…achievable.

I believe we’ll each take our own lessons from Meyer’s story, and I encourage you to pick up a copy and read it yourself.

I’ll leave with one more anecdote, though. Meyer quotes C.S. Lewis, and his thoughts on the “inner ring”, a notion of how we often seek to be part of some group we feel outside of.  But once we get in to that group, there is but another inner group.  But ultimately, Meyer quotes Lewis as saying, “If in your working hours you make the work your end, you will presently find yourself all unawares inside the only circle in your profession that really matters. You will be one of the sound craftsman, and other sound craftsman will know it.” (Read the full essay here.)

So what does this mean? Lewis, in 1944, in a lecture at King’s College of the University of London essentially said “You will find your people on the merit of your work.” It’s a quote that perfectly encapsulates how I feel about the data and Web dev community, at AP and far beyond.  Where I am respected for my craft, and my continual growth in my craft, and my age, gender, background, everything doesn’t matter, because the work speaks for itself. And I’ll respect you for the same. I want nothing more than to be a sound craftsman, well, craftsperson (it was 1944, I’ll forgive Lewis for the gender bias.).

And thanks to knowledge and inspiration from Meyer, and others he’s inspired, I have a chance at achieving that goal. Thank you, Phil.

Explore other posts:

• April 5, 2010 -- Data Delver: Phil Meyer
• April 5, 2010 -- Women with coding skills are no Passover miracle
• February 5, 2012 -- At peace with where I am
• January 4, 2010 -- Reflections on Visualization Theory (Data viz readings, week 1)
• April 7, 2010 -- Columbia’s new joint MS: Good start, but no panacea
• January 31, 2010 -- Data Delver: Tyson Evans, NY Times Interface Engineer

How can I count how many points I currently have displayed on a Fusion Table layer of a Google Map?

This would be especially helpful when we’re using filters, to show how many points are currently displaying.

I’m not the first one to come up with this, for more on the subject, and the creators of the code this is based off of, pleas see the “Getting Data” section of Robin Kraft’s post here.

If we assume that searchString stands for the value a user inputs in a filter (look into how to use HTML forms and connect it with JavaScript elsewhere, that’s left as an exercise to the reader, and I’m pulling info from Fusion Table ID which we will call…tableid…here’s the code you would need to get that count.

(The indentation in my code samples is ugly right now, and I can’t figure out how to get this plugin to cooperate, but the code should work, and you can fix the indentation for extra credit.  Cool?)

First, set a variable which contains the beginning of a URL, which allows you to query the Google Fusion Table SQL API.

var queryUrlHead = 'http://www.google.com/fusiontables/api/query?sql=';

Now, at the end of the URL, since we are reaching across domains (from where your site lives to google.com), we need to use a technology called JSONP.

var queryUrlTail = '&jsonCallback=?';

Create a variable that has your query string, which is specified in the Google Fusion table docs. The where clause shows how you want to limit your table, search string allows user to specify what you are limiting by. Instead of selecting *, which is everything in the table, or a specific geographic data column, we select count, to count up how many rows in our Fusion Table fit this query.

var query = "SELECT COUNT() FROM " + tableid + " WHERE 'Column Name' CONTAINS IGNORING CASE '" + searchString + "'"

Then, we encode that query, so we can send it across the Web.

var queryurl = encodeURI(queryUrlHead + query + queryUrlTail);

Use jQuery’s get method to get the result of the URL. The first parameter in this function is the URL to get, which we have just constructed. The third parameter says we want to use jsonp, to go across domains. The second parameter is a function which does something with the “data” that is returned.

What this function does, in this sample, is it fills in a div with the id of “count” on the HTML page with the count of rows. We get the count of rows by digging into the returned data object. We use try/catch because the data rows will not exist if no items are returned with the query used. So, if we get an error, because there are no rows, we set the count div’s HTML equal to 0, to show that no rows are displayed. The 0 display should only occur when we have a blank map.

var jqxhr = $.get(queryurl,
function(data){
try{
$('#count').html((data.table.rows[0][0]));
}
catch(err){
$('#count').html('0')
}
},
"jsonp");


Here’s the complete code block, for copying/pasting fun:

var queryUrlHead = 'http://www.google.com/fusiontables/api/query?sql=';
var queryUrlTail = '&jsonCallback=?';
var query = "SELECT COUNT() FROM " + tableid + " WHERE 'My column' CONTAINS IGNORING CASE '" + searchString + "'"
var queryurl = encodeURI(queryUrlHead + query + queryUrlTail);
var getCount = $.get(queryurl,
function(data){
try{
$('#count').html((data.table.rows[0][0]));
}
catch(err){
$('#count').html('0');
}
},
"jsonp");


Ideally, this would be used as part of a function that uses filters to change displays on the map. Just a quick post here in case this helps others googling around — it wasn’t as easy to find this solution as I might have hoped. So, search engines, read this: How To Count Queried Rows in a Google Fusion Table and Google Map. Are you happy, SEO machine?

Explore other posts:

• January 2, 2011 -- Be the LA Times’ next “Data app producer intern”
• February 13, 2010 -- Data Delver: Mo Tamman, Wall Street Journal
• January 11, 2010 -- Importance of combining data analysis with context (reflections on readings from week two)
• July 30, 2011 -- What’s it like looking for a programmer-journalist job?
• January 18, 2010 -- Committing fact errors in visualizations
• January 18, 2009 -- How much video is too much video?

As always, I owe everything to my mentors.  I’ve been spending time thinking about how those needs have changed over time. A #wjchat this week on the subject merely strengthened my interest.  And as much as I am mentored, I’m spending more and more time mentoring others.  It helps me improve my ability to describe code, and helps broaden the pool of people doing technical journalism work.  And we need more people.

I think it bears pointing out that when I started, I wanted a lot more hand-holding. I still desperately need mentorship though, I have a lot to learn, and many high expectations for myself. The environment I have right now is truly special. It’s special enough that I would follow the people I am lucky enough to work with no matter where we worked. It wouldn’t have to be in a glamarous city, like New York or Washington.  And it wouldn’t have to be a big name place. It would be…more than enough to work with these people every day.

So, let’s get down to it. As I seek to mentor more and more, what lessons can I take from people at my current work environment?  Here’s a brainstorm:

1. Ask nicely for things, avoiding “Because I said so” syndrome. I can’t recall when I’ve ever been told that I need to do something. “Would you please” or “I thought you might enjoy” or “What do you think about” are the name of the game here.  It doesn’t matter if a deadline is close.  That’s no excuse for pulling rank, which is a last resort.

2. Give praise when something is done well. I’m thanked for almost everything I do.  Obviously, I have to do what I’m asked, but it’s nice when people are friendly about it.  Feeling respected and well-cared for is more important than any of us realize.

3. Listen. I’m pretty comfortable sharing my opinion with anyone who’ll listen, but of course, no one is obligated to give me the time of day. Take the time to pay attention to what someone else has to say. Then decide what to do about it.

4. Be patient. Sometime it takes me 30 seconds to put a coherent sentence together, when it’s technically hard. People just wait.

5. Believe in your mentee. Mentees may go through self-doubt. You wouldn’t be spending the time with them if you didn’t believe they could do it, right? Tell them they can, even when they don’t believe it. They’ll get through the dark place.

6. Say when you don’t know something. No one is omniscient. Realizing this is much like realizing one’s parents aren’t deities sent from on high (sorry Mom and Dad).  Once you realize that, you can band together to solve problems. And then you both learn.

7. Trust. When you ask someone to do something, believe they’ll get it done, or come to you for help.  No need to check in every 10 minutes, that’s just distracting. But check in on a regular basis, lest someone feel like you’re leaving them to the wolves.

8. Keep your cool. Deadline can have a lot of pressure, but freaking out helps no one. Don’t take offense when a mentee raises her voice, speaks loudly, rants, screams, says it’s not possible. Stay logical and cool, bring levity to the situation. It’ll all be okay.

Most of this doesn’t have to do with actual subject knowledge, although that helps.  It’s enough to just be a decent, kind patient human being, interested in helping. And it constantly amazes me how warm and fuzzy I feel with that kind of support at my back.

Thanks for being awesome, AP Interactive. You’re teaching me more than you can possibly know, even how to better pay it forward. There’s no way to articulate just how valuable that is.

Explore other posts:

• April 5, 2009 -- State of Healthcare Journalism
• April 5, 2009 -- NYTimes Global Edition — do people care? Should they?
• February 15, 2010 -- Visual confections are more than mere presentation
• February 12, 2012 -- “A journalist could do this!” – Reflections on Phil Meyer’s “Paper Route”
• March 8, 2010 -- Piece de resistance: Data viz wrapup
• January 2, 2011 -- Be the LA Times’ next “Data app producer intern”

Of course, the day I finished said project, I started the Next Hard Thing. I don’t really get it, but I get it more each day.  And I take great comfort in the fact that each day, I’m one step closer to understanding. New attitude: What’s the next thing I don’t know now, but am going to know soon?   I believe that I can accomplish what is asked of me.

I’ve often said I don’t want to turn into a computer scientist.  I’d like to take that back. As long as I’m still doing it in the service of journalism, it’s more than okay. I’m having a lot of fun with it. I’m even respected for my attempts. I still feel stupid trying to articulate what I’m doing, but I’m told that’s part of why I’m being made to do it. I’m really lucky to be in a place that takes my technical and emotional failings as they are, and trusts in what I can be. The least I can do is afford myself the same courtesy.

I’ve been thinking about two quotes a lot recently.  The first comes from Ira Glass, of NPR, and has circulated the Web before:

“What nobody tells people who are beginners — and I really wish someone had told this to me . . . is that all of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, and it’s just not that good. It’s trying to be good, it has potential, but it’s not.”

“But your taste, the thing that got you into the game, is still killer. And your taste is why your work disappoints you. A lot of people never get past this phase. They quit. Most people I know who do interesting, creative work went through years of this. We know our work doesn’t have this special thing that we want it to have. We all go through this. And if you are just starting out or you are still in this phase, you gotta know it’s normal and the most important thing you can do is do a lot of work.”

In other words, it’s okay that I feel like I’m not living up to my potential right now. I must not give up. The most important thing I can do is do more work.  Too bad there’s not anything to do at my job…(you know I’m kidding, right?)

And the other quote that I live my life by these days, comes from boss Jonathan himself (this should shock no one).  I’ve said it before, and I’ll say it again.  It’s made to address my issues with the balance of being a journalist and a computer scientist — but really, it’s a life motto.

“Don’t worry about what the “right” mixture is or how you describe your affiliations. Just worry about living your life in a way that changes you and the world in a way that is pleasing.”

I enjoy my work.  I enjoy what I’m learning. I enjoyed going to a museum this weekend, and I enjoyed reading my code structuring book. I enjoyed going out to brunch with friends, and I enjoyed getting enough sleep for once, and I gave myself permission to…do as I wished.

Perhaps this is the reality.  I’ve kept a certain pace — if I can only get this far this month, maybe someday I’ll land somewhere I can make that difference. I can be all I expect of myself. And once I get woken up, and realize this isn’t real, then I’ll let go. And not dream about code. And say, ‘That was some fun make-believe, Michelle.”

But there is no soon-approaching end. I’m in it for the long haul. This is real. I’m no longer a newbie five months in. So I’ve got to make sure what I do is sustainable. because the only thing worse than me not moving fast enough to achieve my potential, is burning out to such an extent that I can never achieve that potential.

And that simply cannot happen.

Explore other posts:

• March 8, 2010 -- Data Delvers: Ben Welsh & Ken Schwencke, LA Times
• February 20, 2010 -- Data Delver: MaryJo Webster, Pioneer Press
• July 30, 2011 -- What’s it like looking for a programmer-journalist job?
• December 14, 2010 -- PBS post: What Data Can’t Do For You
• January 19, 2010 -- Changes in the numbers of students majoring in programming and social sciences
• January 20, 2010 -- How to “Group By” in Excel

It’s something to do with another level I’m trying to attain in my career, a lack of balance, a frustration with not being able to do what I wish I could.  Many have tried to help me out of this funk, and just as I start to feel better, another monkey wrench is thrown my way.  My medical problems — I can deal with.  High blood pressure, take a pill. Leaking protein – take some chemo.  Fine.  But this general discomfort is hard. I don’t know the end goal, nor the path.  I’m horrible at hiding my emotions, so I say things I shouldn’t, things I don’t truly mean.  I hope the team knows that.

I enjoy working out of Washington, DC, and have long said that choosing between working with my colleagues by format or by subject matter, would lead me to choose working in person with my colleagues by subject matter.  I love the “Washingtonness” of AP.  But sometimes, the people I talk to on the phone need to be just a little bit more.  I come back from three working days in NY feeling…better.  I love seeing them in person, but miss my DC colleagues.  In DC, I miss the people in NY.  But I’ve always lived in an intersection.  After my recent trip, it would be a lie to say my ennui is fixed, but I’m starting to see a path.

I thought I would share some clarifying quotes from my colleagues, who put a bit of a skip back in my step.  I think they may be helpful to anyone learning a new skill, in any field.

“At some point, it’s not enough for me to believe you can do it.  You must believe you can do it.”

“Perhaps you are frustrated because your potential is not yet matched by your skills.”

“Asking questions about how every line works is an excellent trait for a technologist. But sometimes it’s enough to grasp the big picture, and let the rest come.”

“Are you afraid of failing? Because you haven’t yet.”

“Think of this like school. It just happens to take place in a large global news organization.” (#nobigdeal)

“I have never known you not to find a solution to a problem.”

“If you want to work on the weekend, go ahead.  If you want to do something else, do that. You have nothing to feel guilty about for not working outside of work.”

“Side projects are supposed to be fun. If it isn’t, why are you doing it?”

“Why do you refer to learning as struggling? It’s part of the process, no different than before.”

“I know that you don’t see programming as the point, but a means to an end.  But you know what? The journey is pretty fun, too.”

“At first, you will just feel like you are copying down code. But it will make more sense.”

Eventually, me:

“It’s just so hard. (later) I never really learned to code with music, it was just so, so difficult I had to concentrate…wait a minute…like it’s hard now…oh wait, I think I just had a moment of clarity–this is no worse than when I started learning Python!  I can do this! Too.”

And my favorite question:

“Do you understand this enough yet that you see how the structure can help you dream up new interactives?”

Not yet.  But that day sounds pretty darn awesome. That quote’s going on my desk.

My task last week?  Learn enough about Backbone (a Web framework that helps organize JavaScript, the language I use most often) that I could execute a major project in it due at the end of the month.  Wednesday: I had a pounding headache, and laid down my desk, almost in tears.  Thursday: I made changes to a file, and modified features. Friday: I added features of my own, with barely any supervision.  I nearly broke my face with a wide grin as a click made a shape change from one color to another.

And for the first time in years, on Saturday and Sunday, I didn’t touch a line of code. I gave myself permission to rest.  I visited with relatives. I entered a world where my biggest problem was turning down the apple turnover being pushed on me after breakfast.  I gabbed with college friends over pickles and corned beef at a NY deli. I rode back to DC, just…thinking.  The Capitol building glowed at me as I exited Union Station. I was home, but with a renewed perspective.  And it was…liberating.

I’m still in a dark place.  I don’t know where all this will lead.  I don’t know when I’ll come out of my current funk.  I hope that passing on what I do know, inside and outside my organization, may help me feel better. I don’t know how I’m going to meet my own expectations, which I’ve learned, are even higher than those of my workplace. Which is ridiculous — I’m doing well enough for AP, but not for myself. I always have been my own worst critic.

There is no wrap-up conclusion at the end of this post.  Just this: I’m in a better place now than I was on Tuesday, before I went up to NY.  And maybe for today, that’s enough. Tomorrow? That’s a question I’m not ready to address quite yet.

Explore other posts:

• January 11, 2009 -- "Alternative Storytelling"
• April 11, 2010 -- Data Delver: Paul Monies, The Oklahoman
• February 15, 2010 -- Visualizing networking: When it doesn’t work
• June 13, 2010 -- Post IRE wrap-up + shameless self-promotion
• January 12, 2010 -- Data Delver: Ted Mellnik, Charlotte Observer database editor
• September 16, 2010 -- Journ curricula’s need for transition isn’t unique

Goals are not the same thing as resolutions, and I know this.  I am making a conscious decision to set a theme which will influence goals for 2012.

1. Combating insecurity with talking too much.  I remain in an environment that is fantastically amazing.  I finally am able to name these people as colleagues, and look them in the eye.  But when I put on my “tough girl” face, I think I come on too strong.  Am I listening enough to others’ perspectives?  Would the reporters, editors, bureau chiefs pay me as much, or even more attention if I was less heavy-handed? Less “We need to do this,” less “I’m just the new kid,” more “I think this could be a good idea”.

2. Less chalking it up to being a newbie. I will forever be a student, and so I tend to think of myself as someone who has never really left school. This doesn’t help give me the confidence I need.  It also doesn’t help, when I ‘m not hitting conventions as well as I should. I have years, and I think, decades less experience than most of my colleagues. It’s possible to level up, and not be surprised things work.  Yet, I don’t want to lose my enthusiasm.  I’m still the person, who, when Jonathan explains some new tool, can’t stop herself from yelling “Really? That is SO cool!”  And then, I hurt my own ears listening to the aftershock of the screech.  Maybe I can be a little quieter. But I won’t lose that enthusiasm, and I probably won’t be able to tone it down much — this stuff is still really exciting.  I hope it’s just as exciting decades from now.

My point was, I’m too much of a newbie. This is not absolutely an asset, nor absolutely a detriment, just a fact.  I must not drag the overall work down.  The colleagues are more patient than I would be, but I must meet that patience with consistent leveling up.  Suck less.  Accept this: “I am no longer a beginning programmer.  I am at an intermediate level.”

3. Help others, but get help yourself.  I spend a lot of time paying it forward, and that’s not going anywhere, but I should spend just as much time getting the help I need.  Go back to the strategies of beginning Python, and apply them to new skills.

4. Don’t become a full-fledged computer scientist. This may seem counterintuitive, but I can feel myself getting better by leaps and bounds.  Yet, I spend my free-time reading up on closures, whereas I once would spend it keeping up on the news.  I long to do more of a certain type of work, yet I wonder if I get too bogged down trying to be an exceptional developer.  Continue to pursue what it means to code in the service of journalism, and try to strike a balance.  Problem is, I don’t yet know what the balance looks like.  Seek to find out.

5. More work/life balance. The culture at the AP has encouraged me to have more of a non-work life than I have in years (thanks!).  And I don’t feel guilty about it, because I give 200 percent at work itself.  Yet, I want more time to keep up a gym routine, practice cooking skills, visit with friends, go to the theater, pursue my other passions, and be a person, not merely the operator of a computer.  I’m the only one who can make this happen, but it will be a priority.

6. Less medical stuff. I can’t do much about this, I suppose, but I spent too much time in hospitals this past year.  People say it was impressive I maintained the pace I did, oh, and conducted a job search through chemo.  Hair is coming back, and I am feeling better than ever.  Moderation.  Take care of myself. Take those meds, eat healthy, get more sleep.  As my kidney doc says, take care of your body, it’s what enables everything else.  This year, for real.

7. Divide my intellectual pursuits, and read things that don’t relate to journalism, Web development and cartography. One thing I’ve noticed recently: really smart people pay attention not just to the field they’re in, but get to know the exceptional thinkers in other fields.  I hope to do more of this.  I will follow more diverse people on Twitter.  I will read more things.  I will try more things.  This means expanding my reading habits, and going to a more diverse group of events in the DC area.  This city is perhaps one of the best in the world for self-teaching.  Curious about astronomy? Head to the Air and Space museum?  Want to influence your designs with classical Greek art? National Gallery. I’d like to make better use of these resources, and bring them back to my work.

2011 was spectacular, in the good times and the bad.  It’d like 2012 to just be…very good on many levels.  That’s more than enough.

Explore other posts:

• November 23, 2010 -- Join the data convo at PBS NewsNav
• January 31, 2010 -- Data Delver: Tyson Evans, NY Times Interface Engineer
• March 8, 2010 -- Data Delvers: Ben Welsh & Ken Schwencke, LA Times
• January 16, 2012 -- A pilgramage to NY headquarters
• September 7, 2010 -- Hosting #wjchat — Finding the story in the data
• January 31, 2010 -- Data Delver: Matt Waite, St. Petersburg Times

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.

Explore other posts:

• November 25, 2009 -- The limitations of SQL and Access
• January 11, 2009 -- "Alternative Storytelling"
• March 8, 2010 -- Data Delver: Anthony DeBarros, USA Today
• March 8, 2010 -- Data Delvers: Ben Welsh & Ken Schwencke, LA Times
• February 5, 2012 -- Changing definitions of what it means to be mentored
• January 2, 2011 -- Be the LA Times’ next “Data app producer intern”

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.

Explore other posts:

• September 3, 2011 -- This work I do, it’s difficult, and that’s okay
• October 16, 2010 -- We must understand our news content as data
• November 8, 2010 -- Tools to help bring data to your journalism
• August 21, 2011 -- How to make a non-Flash intensity map in Fusion Tables
• July 11, 2010 -- First LAT app (or the butterfly on my windowsill)
• September 16, 2010 -- Journ curricula’s need for transition isn’t unique

Some questions paraphrased.

Can I embed something with HTML/CSS/JavaScript using the Layer Builder on my Google Sites page/page that doesn’t play well with JavaScript?

This is part of my usual argument of why it’s a good idea to host your own website.  Whenever someone does something for you, you have less responsibility and less freedom.  But…you can embed the code in a wrapper.  If you have some other space, you can host the Web page there, and then bring it in with an iframe.  If you’re using Google Sites, you can wrap all of your code in a Google Gadget.  More details here, with links!

Where can I find shapefiles in a Google Fusion Tables friendly format?

You can convert your own shapefiles (shapes of various areas you want to shade for mapping, like states, counties, etc.) using shpescape.com.  However, many already exist imported into Fusion Tables.  You can search publicly available tables for shapefiles you may want to use.  Some especially helpful examples, for state and county boundaries from Census data, are here.

Once you have a table with geographic information, you can merge this with your own table containing numerical data that determines how the various shapes should be shaded.  Use the Merge command in the right most drop down menu at the top of your Fusion Table.

How do I best organize my data to display on a Fusion Tables map?

If you’re using shapes like I was talking about above, you want to make each row for one of those shapes.  The shape should be identified by a name that is also a field in the table with the geographic information.  For states, make sure you have a column with the name written out: “Virginia”, not just “VA” or “Va.”  Each number you want to reference, or each category, should be in a separate column in that row.  Beyond that, structuring data is something I have trouble explaining rules for, other than each cell is a small cubby hole.  We don’t put two things in a cubby, we keep like things near each other.  A place for every piece of data, every piece of data in a place a program can find it.

If I’m using the API to bring in custom Google Fusion Tables layers, do I customize those pop-up bubbles in the Fusion Table itself, or using the API?

You CAN do it using the API, but I prefer to keep this bit in the actual Fusion Tables interface.  Go to Visualize –> Map, click on Edit Info Bubbles, click on Custom.  Then, you can add HTML/CSS, using attributes from columns in your Fusion Table.  These styles will propogate through the API, unless you overwrite them in the API.  As I see it, the main reason to do that would be if you want to write some sort of conditional statement.  Only show the line with this variable, if the variable is not 0…or something like that.

Basically, unless you’re getting complex, customize your info bubbles on the actual Fusion Tables site.  Same with coloring your polygons.  If the site can’t get what you want done, then move to doing it through code.

My philosophy: Code helps you get beyond the normal interface.  You don’t get extra points for making your life more difficult, unless you’re doing it to learn.

More questions/help/group puzzling also available by contacting me in methods listed on the right rail.

Explore other posts:

• December 3, 2010 -- Are time-intensive story presentations worthwhile?
• January 16, 2012 -- A pilgramage to NY headquarters
• July 11, 2010 -- Data Delver: Andy Boyle, St. Petersburg Times
• January 29, 2010 -- Data Delver: Perry Swanson, The Gazette
• April 5, 2010 -- Data Delver: Phil Meyer
• January 31, 2010 -- Data Delver: Matt Waite, St. Petersburg Times

But before you do, I’d also like to make clear that this ramble is not a comment against any particular professional organization.  I have enjoyed my speaking roles and hope to continue them, and I have been humbled to have been given the floor.  I enjoy the conferences I attend, and deeply look forward to them.  Yet, as I do in all aspects of life, I’m just trying to think about how things could be improved.  Not an attack on a person or an organization.  Cool?  Cool!

How do we push ourselves to keep learning? When we gather together as journalists, how do we ensure that we don’t just have a good time, and feel inspired, but that we *do* something about it? How can conferences help us all to get even better at what we do?

I’ve been wrestling with this question a lot recently, and as is often the case, if I think about something enough, it manifests itself as a post.

Conferences need to change — the sessions are getting complacent and easy, and they’re not making me feel dumb. That’s not okay. The Online News Association conference, which I enjoyed greatly on a social level, was a great example of this.

This will be long, as I work through this, but I think it’s something worth considering. To start, let me try to explain what it is I want from a conference panel. Because I’m not getting it.

Stupidity: The best feeling in the world

When I was a student at the Medill School of Journalism, several smart professors told me to try to get to a job where I felt stupid all the time, because that is how I would grow. I never quite believed them, but kept that in my pocket. I got a glimpse of that feeling when I was an intern at the LA Times, never quite felt it at PBS, and I feel it now, every second of every day. And I’m here to tell you that I LOVE feeling dumb.

I know I have a long way to go with my skills. I try to self-teach, but I never feel I’m going fast enough, and I feel as if I lack direction. Enter Jonathan (who, you’ll notice, has replaced poor Derek as the mentor who appears in every blog post. Doesn’t mean I respect Derek any less, it’s just a new phase in my career.) The point here is that I have a “check-in” call, in which Google figures just as prominently as Jonathan sitting on the other end of the phone. “How is that going to work?” he asks. I start typing frantically. The actual things I’m working on aren’t the point here; just know they are Complicated Projects that are, as Jeremy Bowers has put it, encouraging me to “punch above my weight.” And that, my friends, is an understatement.

One of my favorite parts of these calls is my emotions upon hanging up. I quickly go through the stages of pressing disconnect, having everything go a little fuzzy while I’m bewildered, looking at two pages of frantically typed notes, moaning and wanting to slam my head on my desk, and smiling and laughing to myself. Because I know that I’ve never attempted things this Hard, but I also know that I refuse to accept “No” for an answer. I will complete what is asked of me.

And I know that what I know by the next call will be more than I know now. I will move smarter, and faster, and better. And the next call, I’ll feel dumb about something else. I will grow. I know it will be okay, because Jonathan tells me there is an eventual mastery of this type of work when you realize ” a) I could understand anything that’s been built and b) I’d love creating in this medium forever.” So, I chip away at this seemingly insurmountable, yet finite, set of skills I seek to possess. And if the total amount of skills is x, after one call, I’m 1 unit closer to knowing all of x. It’s the best feeling in the world. Maybe only the geeky journos get it, but it’s beautiful, in its way. And it’s a blast!

But I’m lucky. I have a Jonathan, and a Julian, and a Feilding, and a Shazna, and hundreds of reporters and editors, and a whole team of other cartographers, designers, developers, every resource I could want. And before AP, I had a Ben and a Ken at the LA Times, and through it all, I had a Derek and a community called NICAR. But I remember being a student, when the community at large was all I had. I looked forward to conferences for months, not because I was presenting, not because I focused on paying it forward, but because it was my one opportunity to hound people with questions.

I didn’t know what I needed to know, but I knew I could show up to sessions, particularly at NICAR, and I would learn tangible skills that would help me be better at my job the next day. I didn’t have to come up with the questions — not yet.

To reach my next level, I want that again. I want to go to a conference, find smart people giving a session, and have them teach me cool stuff I couldn’t have dreamed of asking. All too often, I see these people come to conferences. They’ll show off cool things, the better ones will give “pep talks” inspiring you to do cool stuff, but I want tangible info. I want, as one friend puts it “to eat their brains.” (That sounds creepier than the spirit in which it’s meant.) The pep talks are fun, peppered with jokes. But it’s kind of like guilty pleasure TV. I enjoy watching The Simpsons, it makes me laugh (well, more the older episodes), but it doesn’t sustain me. Empty calories, as it were.

Give me the power, and I’ll give you tangible stuff, I swear!

So, when conference organizers make the mistake of giving me the floor, I give people what I’ve relished all along. I build things, and show how you would build them. I provide links, tutorials, everything, so you can take it back to your newsroom. And yeah, I dare to put codes on slides, and I’m too lame to pepper in awesome jokes. Different people will get different things out of it. And that’s more than okay. Because hopefully on some level, it made you feel stupid.

I mean that in the best possible way. Because, that’s the best feeling I know how to give. And if you had no clue what I was talking about at ONA, and the code freaked you out, I’m not sorry. Because I can’t make it simple. It’s hard. And you’re going to have to face it, maybe not do it yourself, but work with people who do. You’re going to have to understand it’s not magic.

Those of us coming into the field now, how long do we think not knowing how to manipulate the world in which we live is going to last? Can we get away with not coding in five years? Ten? Forty? I don’t know. I do know we’re going to have to know more than we know now, or someone else will. Saying an audience isn’t technical enough is just prolonging the inevitable.

Asking the experts how to get technical

As is usual, I’m probably being naive about my perspective. So, I decided to get the opinions of three journocoders who I respect deeply, and who give presentations that make my heart sing. And because this is The Community That Pays It Forward, they were kind enough to answer, and allow me to quote their responses. I’ll be discussing the thoughts of Jeremy Bowers, a developer at the Washington Post who uses funny gifs, fast talking and crazy enthusiasm to make his point; Matt Waite, a journalism professor and a former news developer from the St. Pete Times, who is also the most down-to-earth Pulitzer Prize winner I know, and the funniest; and of course, Derek Wilis, who needs no introduction to my two readers, except to say that his presentations are so good he convinced me to go into data journalism/Web development as a career, so it was pretty persuasive.  He also works as a Web developer for the New York Times, when he’s not too busy answering my questions.

All three of these mentors approach presentations from a more general perspective than how I’ve been thinking about. Bowers: “I was an All-American policy debater in college. My approach to presentations, then, is very similar to my approach to policy debate. I’m more or less constantly doing research/developing policy opinions in daily conversation. The presentation is just the coalescing of my latest beliefs/arguments — albeit with more funny gifs.” Pass on a general sense of what you’re thinking about, and make it more appealing. “I wouldn’t recommend this for everyone, but what usually works for me is to develop a broad outline and then during the session, choose the points that seem to fit the moment and talk about them,” wrote Derek Willis. It won’t be too overwhelming if you think about who you are talking to, I suppose.

The power of humor

I’ve been underselling the power of humor. Bowers pointed me to a study from the Journal of Experimental Psychology which says that humor improves retention. He had some great funny meme photos during his ONA talk, which had Heather Billings and I in hysterical laughter (which is all too audible since we were next to the camera doing the livestream). Bowers told me it’s a lot of payoff, for not a lot of effort. “Those funny pictures I made took about 15-20 minutes with a crappy online tool, but were worth their weight in gold. Just because you’re serious about what you do doesn’t mean you have to be serious in your presentation.” Waite had a similar sentiment, and looks at the general. ” I usually think about how can I entertain and inform, giving people something to think about and something to take home,” he wrote. Waite says he keeps the eck to titles and images, which helps with avoiding getting too geeky. I would add, it also lets Matt Waite be, well, Matt Waite, and have the freedom to amuse us all.

Can we get geeky? Please?

But here’s the issue I really wrestle with: How do we avoid getting too technical? How technical can we get? According to Bowers, not very — panels are suited to a more general theme. “My general feeling: Presentations can rarely spread detail, but excel for the transmission of broad memes and infectious ideology. Memes and ideology aren’t technical, so focusing on those can help to avoid the eye-glazingly complex presentation.”

It doesn’t seem to be a fear of showing people the guts of what we do, but panels are just a poor format. Waite calls it like it is: “A slide deck and a panel discussion is a really, really crappy way to convey technical information.” Fair enough. Then, maybe we need more options that aren’t panels.

But I’ve seen Willis get geeky, at least in lightning talks, if not panels. And he got technical enough in class, in those three-hour lectures. I see the issue, I ate it up, but others didn’t. As much as I looked forward to that class all week, some dreaded it. Willis’ advice is as matter-of-fact as his presentation style that works so well. “I think the way to do it is to have very clear expectations of what the session should cover, and try hard to stick to them. Not rocket science, but just think about the audience, the time you have and the general atmosphere, and go from there.”

Whether we stay general or start to get geeky, we’re not getting geeky enough, often enough. My boss, Jonathan Stray, has commented to me that what’s geeky for journalist has nothing on the geekiness of the technology sphere. And we can’t get away with saying it’s not our problem.  Tech will be all of our problem, if it isn’t already.

Bowers nails the problem on the head, though. “Our community is getting better and better at “Introduction to X” sessions and blog posts, but there’s a big gap between that and proficiency. In short: There’s missing support for the middle-class of news developers. This is a particularly glaring gap, because it’s the most difficult part of the incubation of the adolescent coder.” That’s a piece of it, but it’s not just the middle class, I argue, but we all need to understand the tangible nature of what we are, or aren’t, willing to learn.

Where can we go from here?

I hear all that, and it makes good sense. I don’t know where I stand right now. I know I want more, as a speaker and as a conference attendee. I want ONA to not just be a social experience for me, but push the limits of what I know, and give me tangible advice I can take to my newsroom.  More than a pep talk, more than a demo room.  And as much as I love conferences, we’re not there.  It’s not just about ONA, although I started thinking about the issue because of ONA.

Since it’s keeping me up at night, now it’s your problem, too. And if you have any thoughts, please ping me on Twitter, email or in the comments. Did you attend my presentation at ONA? Was it too much? Not enough? What journalism conference presentations have you attended and found most useful? I’d certainly appreciate all the advice I can get.

I don’t know what I’m doing, when it comes to doing the work, or teaching others about the work. All I do know is what I like to tell Jonathan: “I don’t know now, but I’ll try to know soon.”

Explore other posts:

• February 21, 2010 -- Is a flat text file or a database right for an app?
• September 16, 2010 -- Journ curricula’s need for transition isn’t unique
• January 18, 2010 -- Collaborating with computers to parse “big data”
• January 11, 2010 -- Importance of combining data analysis with context (reflections on readings from week two)
• January 31, 2010 -- Data Delver: Matt Waite, St. Petersburg Times
• March 5, 2010 -- Why we do what we do: Pursuing the sparkle