Okay, it can get a little more complex than that. But not much.

I’ll back up. About a week ago, I went to the DC chapter’s Online News Association meetup. It’s a once-a-month activity I really try to make as often as I can. The topics of the talks at these events vary. The rain outside was pouring so hard that I had to stop in a drugstore for some respite, and my denim jacket turned into a sopping rag.

But! this month’s topic really spoke to me. On “Algorithims and Machine Learning”, from NICARian friends Justin Myers of the Chronicle for Higher Education and Derek Willis of the New York Times (longtime readers will also recognize him as the grad school professor who really cemented the beginning of my career path).

There’s a Storify of the event here, but I also wanted to lay out some of my thoughts around what I learned.

• Justin had one of the best examples of an algorithm I’ve ever seen, demonstrating sorting order of bars in a bar charts. Is bar one bigger than two? If yes, move it to the right of bar 2? Cycle through all the bars, again and again, until no bars in the entire sequence change position. Then, you have confirmed your order is accurate.

• Machine learning, which is a term I approach with trepidation, is really just a more complex algorithm. It’s just that the rules you give the computer are more specific, and ultimately flexible, so the machine can seem to “learn” what you would like it to do. Understanding which specific instruction to give the computer becomes easier when it tries to do a task, and you see where it makes a mistake. Then, you clarify that point. This technique seems quite similar to the education of a human.

• A very common application for using these strategies is for verifying names. How do we know if John H. Smith is the same as John Smith? What repeatable strategies can we give the computer to help?

• Second time I heard the Python “dedupe” library brought up to help with this kind of work.  Also, the FEC-standardize library from friend Chase Davis also mentioned.  For more info, here’s Chase talking about the project on Source.

• Place names, particularly addresses, use similar strategies. I hadn’t thought of this before, but Derek brought up machine learning in the context of how EveryBlock works (oh, I guess it’s “worked”, now, that’s sad). Think this has a lot of geographic implication I’ll be thinking more about.

• Be careful of what steps or instructions you give the computer as it will take you very literally.

• We discussed the importance of avoiding getting overwhelmed by having all of these tools at your disposal. My contribution (I’m actually not sure why I was talking at this point, but I felt the need to answer a question, and I suppose Derek and Justin are just sort of used to my need to be vocal, maybe I just need more sleep or less caffeinated tea or something) was to write out the steps you want the computer to take. Sometimes I do that, and I always find that the process goes better when I do. Sort of like sketching a visualization, but sketching out the logic. There will always be more tools, you know.

• Lots of jokes about college interns and making them do work. Or rather, have the computer do it instead.

Or, or, be the college intern that writes the code to teach the computer to do this stuff. (Worked for me.) Learn to code and get your journalism job using tech for informing the public. Ending soapbox now…

Regardless, I think automated instructions, and machine learning at large really speak to some of my broader desires to use tech for data analysis in addition to presentation. I’ve been saying that for a while, but I think I’m approaching scratching the surface on this. Hope something big is coming…soon.

I wanted a new conference experience, as much as I love our dear journo world. As I was about to leave, a colleague asked me if I thought this would be a “gamechanger”. I couldn’t say at the time. But my thought process has been changed, so I think I’d answer “yes”.

Who attends EYEO? People who identify as “creative coders”. Think on that term for a minute. These are people who use the power of code and programming to create art. The code is not about implementing a certain feature, but telling a story. Sometimes it’s an actual story, sometimes a story of human emotion. The work was beautiful, informative, thought-provoking.

For one of the first times at a conference, I didn’t livetweet much. These presentations lose most of their meaning if you don’t look at the visual art presenters are describing.

I learned what I can’t do. An artist who makes gorgeous pieces with data as a backend, explained that the visual appeal is the primary focus, and understanding the underlying data is a hidden layer that is an added bonus. And I suppose that’s the difference between art and the journalism I seek to produce. Understanding the underlying data (or information) is the key and primary goal. The beauty, which ideally comes from both aesthectics and the fun of interaction and play, is the deeper layer. And maybe there’s two layers of understanding the intricacies of the data, but the information as a whole cannot be secondary. I feel like that’s a really clarifying point in terms of direction of innovation.

I want to create virtual worlds. A team from Design I/O showed work samples where you could manipulate a world within your iPad. The bright colors create a fun, playful space where thing seem like they belong to an impossible reality. Can we bring newsy situations to life like this? Is this possible to create?

I clarified my perspective on the importance of the D3 library for visualization, and better understanding the power of progressive enhancement. I don’t believe we can ignore those using legacy browsers, but neither can we hold ourselves back by not using the Next Big Thing.

I’ve been a fan of the work, but even more of the ideas of Golan Levin. Hearing him speak live was like a dream come true. For instance, you can tell me simple is better. Or hear Golan put it like this: “The pencil is the ultimate tool, instantly knowable and infinitely masterable.” That’s what our interactives should be, folks.

Another favorite session was the “Conversation with Toolmakers”, featuring Jer Thorp and Bill Atkinson, inventor of the HyperCard. HyperStudio was one of my first forays into computer programming as a kid, without me really thinking about it. I loved being able to express what I saw in my head on the screen, even though it wasn’t as much of a coding interface. Only at EYEO, did I start to think about how those moments translated to what I do now.

Anyway, Bill totally knocked it out of the park. Some quotes. On collaboration: “”100 people can paint a fence, but if you want to paint a portrait, someone’s got to hold the brush”. On what we owe our users: “When someone delights in a tool, it’s a success. If they feel stupid, it’s a failure.”

I had the opportunity to sit next to him at a different panel, and we chatted a bit. It was one of the highlights of my conference.

We talked tech, and while people were eager to explain, we were able to cut through the basics. I found words for things I’ve struggled to explain, a favorite was “parameterization”, one of the things coding is really good for, using repetition to create the same thing again and again, but with different attributes. This is easier to do with code than other means.

Lunches were filled with show and tells from other attendees, and it was amazing to see the breadth. One person’s first JavaScript app. Another doing real-time viz of music. Another visualizing social networking connections before and after last year’s EYEO. (Yeah, my network expanded too, but I don’t have a viz of that…yet!)

Other breaks were filled with going up to folks and asking for clarification on session topics, discussing wt we were inspired to do. A favorite moment was asking someone if they understood how the speaker structured the object in an example, and another person in the lunch group broke out a notebook and we diagrammed a data structure over corned beef sandwiches. The coding knowledge was assumed. And sometimes, that’s just…a nice feeling to have.

Something to note, a lot of folks showing examples used Processing, a fantastic visualization language, but one I don’t use much because it was originally best running as a Java applet on a local computer, not so good for deploying an app to the world. There’s now a way to port it to run in JavaScript, but my sense is that it still isn’t as strong for Web work. But it’s an amazing way to create art with code, I love playing with it. And if you just need to run it on one machine, even if that machine is in an art museum, then it’s great. But this is another example of where we can take lessons from the work, but it doesn’t necessarily work for journalism and news apps.

There’s so much more to add, and I’m focusing more on my reaction than the actual sessions, since you can (and should) see them on video, once they are posted soon. There were also mindblowing keynotes at night in the party-like venues and there’s a whole post somewhere about how much I enjoyed the city of Minneapolis, like a calmer, even greener DC, which was just such a great setting. And the conference venue of the Walker Art Center was this amazing art museum, and, and…sigh. This is getting long, even for me, so I’ll spare you that and start winding down at this point.

The EYEO 2013 conference phone application (which was very well-done and made logistics a lot easier) — described the panelists as having “technical and imaginative prowess topped off with a fearless ability to share.”

That couldn’t have been more true. A lot of that describes the NICARians as well, but I’ve got to admit — the “creative coders” had more imagination than I typically see in our industry. I want to be a creative coder and a journalist and create fun and informative experiences. I feel like what I learned here takes me closer.

Oh, we can’t do everything I saw at EYEO, not enough time, and not all of it fits the mission. But we can do more than we’re doing now. We can be more imaginative in our work. We can be as fearless about tech as the people I met there. I am better for entering this community, and I will never forget those three days. I look at the buildings differently as I roam DC. I sketch new types of ideas. I am not the same person I was before. And for that, EYEO community, I thank you from the bottom of my heart.

The Mission. Why I wake up every day. To do good work. I live in the intersection of data, journalism, technology and policy. Earlier this week, when deciding what to attack next, project-wise, I was given the following advice. “Pick something innovative, that will challenge your skillset and push this organization forward.” That is the job you want. Nothing is perfect, but I am living as close to my dream as one can.

But I’ve worked for it. Terribly hard. I’ve given up…so much. For a while, I’ve ranted/complained/brainstormed about the  ”news developer pipeline problem”. And whether it’s on the blog, to my colleagues, at 2am in a bar in St. Louis at NICAR, or during a squeezed-in dinner at the Tick Tock Diner in Hell’s Kitchen, the points remain the same.

Read my fingers: There. Is. No. Defined. Path. To. Learning. To. Be. A. Data. Journalist. Developer. It. Does. Not. Need. To. Be. This. Hard.

Read it again, and again. Learning development skills is doable with online tutorials. Journalism skills can be learned on the job. But there are a lot of pieces, and the way we do development for journalism is different than a more general programming mindset. You may need to run your own server. You may need to make custom charts. You may need to run data analysis.

In the past four years, I have received hundreds of requests about how to get the skills you need. Get a job, I’ll say. But if you don’t have the skills, how do you get a job? It’s a typical employment Catch-22, but times 1,000. So many moving pieces. So easy to self-doubt. So difficult to create the proper culture. So hard to execute on deadline.

Sure, read the tutorials. But they are not written for the journalists.

There has to be a better plan. For you, who wants to know more about how to apply computer science to our field. For you, the traditional reporter who wants to flesh out your stories. For you, the graphics department that wants to tell more localized stories. And yes, for the me of three years ago, who might have had to give up a bit less to get where she is today. For the news developer that could have been, but got off the track, because it was just too hard. Who do we develop a more-defined curriculum for?…For…Journalism.

A possible solution

For Journalism. That’s the name of this new project that I am delighted to become a part of. Dave Stanton is our leader. The idea is that we craft modules that use projects to teach code concepts. There will be nine of them, and my module would focus on “Charting and Visualization.” It’s not just about teaching you how to make a certain type of visualization, but concepts that you can apply to multiple projects. They will arm you with tools you need to understand concepts to make your own cool projects. Languages may change, but foundational building blocks will remain helpful.

Perhaps most importantly, we’ll try to give you some direction on how to “get the skillz”. I, for one, am looking forward to learning from the other instructors. Maybe Jeff Larson of ProPublica will help me finally get “Rails”. Maybe Jacqui Maher of the New York Times will help me be more of a powerhouse in terms of the systems it takes to run dev ops.

Ideally, we’ll spread this to universities as well. Lack of a solid data journalism curriculum with professors who can teach code AND give a journalistic mindset is a problem we face. Hopefully, this is a solid starting point. At least it’s an improvement on writing myriad blog posts on the issue.

We’re raising money to make these materials through Kickstarter. I’d certainly appreciate your consideration of either monetary donation, or sharing this project with your colleagues and friends. We want to help. We want to work on the news dev pipeline problem. We want to teach you, so you can join us. We want to do better at this problem…For Journalism.

Questions about the project? Get at me, or hit up @forjournalism on Twitter.

Learn more about us on both our official website and our Kickstarter site.

Then, as a community, maybe more of us can answer the call of an industry. Bring your passion, ambition and ideas. We’ll get you on the path to making those dreams a reality, for you, for me, for the industry — and most importantly, for the public we serve.

Let’s work on finding our place

That’s how we’ll move forward, when we find our footing in the journalism world. We must have the ideas of what we can change, the confidence that you can be The Awesome, and the skills to execute your vision. The first and second is squarely on you. But For Journalism, in its ideal form, will help you out on the third.

When that’s all in place, then one day, you too, may start your days humming this anthem, as I so often do, from Stephen Schwartz’s Pippin:

“So many men seem destined 
To settle for something small
But I won’t rest until I know I’ll have it all
So don’t ask where I’m going
Just listen when I’m gone
And far away you’ll hear me singing
Softly to the dawn:

Rivers belong where they can ramble
Eagles belong where they can fly
I’ve got to be where my spirit can run free
Got to find my corner of the sky.”

And of course you can! This is a fun trick I end up using quite a lot, and have been meaning to write up.

First of all, I can’t remember if I previously mentioned a wonderful JavaScript library called Underscore, which you should get well acquainted with. Lots of little utilities that you wish existed in JS, but you know, don’t. We like it enough that it’s automatically imported into all of our AP Interactive projects.

Now, Underscore has a smart little method called sortBy. Pure JavaScript sort is designed to be used on a list. ['banana', 'apple', 'grape'] –> ['apple', 'banana', 'grape'] or [4,1,3] –> [1,3,4]

But when we receive a JavaScript object, such as the JSON returned from Google spreadsheets, we receive a more complex object, like: [{fruit: 'banana'}, {fruit: 'apple'}] etc. So we need a way to sort, but tell the computer which key (or label) of each object we want to sort by.

First, you need to import the Underscore library. Download the code, place it in the same folder as the rest of your webapp, refer to it in the head of your HTML like so:

<script src=”underscore.js”></script>

ensuring the actual filename is “underscore.js”

Then…

let’s assume the json looks like this:  var fruitJSON = [{fruit: 'banana'}, {fruit: 'apple'}]

in the first line of the function referencing your json, type:

fruitJSON = _.sortBy(fruitJSON, function(item){return item.fruit})

Any references to JSON after that line will be to the sorted version of JSON.

Let’s parse out what that line of code means.

First, we assign this function call to the variable of json, so it overwrites our current data. You could also save to a new variable, to maintain both unsorted and sorted data.

We pass two arguments to _.sortBy. The first is the data that we want to sort. The second is a function.

That inner function takes one argument, which is each object (or “row) in your data. We call it “item”.

Then, in that function, we return a result that we will sort by. Here, we access the fruit member (or “column”) of a given row, which is the attribute we want to sort by. There will be a similar date member in your Google spreadsheet, if you created such a column.

Hopefully, that clears things up for Greg, and anyone else seeking to understand this fundamental and powerful data manipulation technique. Not just related to spreadsheets, but a general strategy for manipulating data structures.

And make friends with the Underscore library. You won’t regret it.

Done!

And I have fulfilled that part of the dream, as of this week. Before I go any further, I was primarily responsible for the actual Google Map component of the AP embeddable results presentation. But please know, it would be nothing, and I would have gotten nowhere, without my collaborators in NY: Nathan Griffiths and Seth Rasmussen, and my ever-present mentor and friend Troy Thibodeaux in New Orleans.

We enlisted the design chops of Roque Ruiz, and a marathon effort on generating shapefiles was executed with great skill by Phil Holm. And while I was, um, otherwise occupied, for multiple months, my DC co-conspirator Kevin Vineys held down the fort, and answered all my content questions about special cases. I’m truly fortunate to have him in my corner — literally.

And of course, my greatest coding rock of all at AP these days is Troy Thibodeaux. Physically, he may be in New Orleans, but he’s always in my head, and makes me better every day. Everyone needs a Troy in their corner (or a Jonathan or a Derek or a Ben or a Nathan or a Seth — oh, I’ve been lucky to work with some amazing minds and pure hearts.)

Now that we’ve gotten through the names, here are some things I want to document about the map, because it makes my heart swell with geeky joy and learnings.

• Spreading the good work. I adore working for AP because our stuff doesn’t just go to one place, but many. Our map was visible on NPR, the Seattle Times, CSPAN, the Detroit News, dozens of TV station websites and countless others. CSPAN even made a video clip showing how it works and calling it “a godsend for election results geeks”. Really lived my dream of bringing the interactive journalism to many places.
• Spreading the work internationally. We also had the map embedded in international clients, and translated the map’s contents into Spanish, Portugese and Chinese. Kudos to Nathan and Seth on that compelling feature! Huge gain for us!
• Cross-platform, responsive projects. As with most of the work we do, this needed to work on tablets just as well as desktops, and even have an appropriate view on phones. And whatever size a customer embeds the map, we should adjust our display accordingly. And if customer embeds it so that it can respond to the size of the user’s browser, as NPR did, so much the better. We work hard on responsive, but it’s for an additional reason than its more traditional definition. There are lots of different ways our content can be embedded by customers. When it comes to sharing projects, I think this is another level of responsive design that often isn’t carefully considered enough.
• Building a complex project. Smart people have given me the advice that to level up, I need to build more advanced projects. Some of the map templating work I’ve worked on and discussed has approached this level, but failed to go this far.
• Coding fast and meeting requirements. Much of my work is making things I see in my head, and then taking advice to make it better. If I need to push something a day or three, it’s discussable. Not so here. Certain things HAD to be done. The deadline could not be pushed. And we did finish it.
• When coding fast, my skills suffer. This was not the best code I ever wrote. At all. That’s okay. My best code is when I take time to refactor. Constantly fixing and adding features means I didn’t use those best practices. Yet, smart people tell me the best practices will make it easier to adjust code when you’re in a rush. I wish I had adhered to them more.
• Get nonjudgmental smart people in your corner. Just, a thousand thank yous to Troy who kept getting contacted with a sleep-deprived, not-at-my-best version of myself, ranting, whining, complaining, giving him messes of code asking “Now what?” I care so much, but it can make me hyper-emotional. Troy helped me work toward logical solutions, even making sure I was learning important lessons, despite of, or maybe because of, the deadlines. Tricks and tips he imparted are making my next project better. I am so grateful to have access to minds like that every day. Oh, and when I thank Troy, he replies, “I’ve got your back, you’ve got mine.” Grin. Collaborate to serve the mission. Rocking it.
• Never underestimate how hard it is to get geographic shapefiles to load. Also, if you do an election map during a redistricting year, stay on top of your House congressional districts.
• We colored our polygons as they were “leaning” toward a candidate — when any votes were in, with a light color, then a darker color was received for when AP calls a state. One argument is that the leaning color is confusing, and can be misleading, esp. when few votes are in, or votes are only in from certain counties. The other side is that a map that’s all gray until states start to get called isn’t compelling in an interactive way. I would argue that the light color is visualizing what is already in the tooltip if you click on a shape, this is just giving you insight into the story behind the click. More detail behind more clicks.But it’s an interesting issue to consider.
• Adrenaline. I’ve never built an app so tied to real-time data before. I was a theater minor in college, and I recognized the feeling Tuesday night as right before a show opening. The butterflies in the stomach, the fear something will go wrong, the knowledge that at this point, it’s too late. And the sheer thrill of watching your show, or app, just…fly. Beautiful.

Around 12:30 am, I left AP DC. On my way home, I stopped by the White House. It just so happened Romney was conceding at the same time. The emotion around me was palpable, for a very different reason. And it hit me, I live and work in the center of the action. I did it. I will do more. But some sort of test came and went on that night. And I couldn’t be prouder of my organization and my colleagues and the community at large. I am no longer a student. I am one of you, in an undeniable way.

So, two days later, when our bureau chief goes around the table at the morning meeting asking each group how things went during the election, she comes to us. “Interactive? Everything went okay with the map?” “Yes!” I say, a bit too excitedly, perhaps. And I grin widely. But not for long, because now we’re moving on. I dare not rest on any laurels. We’ve got thousands more stories to tell, millions more interactive journalism experiments to run, billions more things to learn. And I couldn’t be more elated to keep pushing toward the future.

In a typical conference wrap-up post, I like to write about the great sessions I attended, and what the panelists had to say.  Just one problem. I DIDN’T ATTEND A SINGLE ONA PANEL AS AN ATTENDEE.

Hacking the typical panel structure

Wait, what??? Did you just slip away and tour San Francisco? Maybe hit up Fisherman’s Wharf for the first time in a decade? No. Not quite.

I’ve been doing this journalism thing for three years now, and I don’t really love the status quo. Last year, at this conference, Chicago Tribune developer Heather Billings and I held a session on Django and programming in a hallway, on the floor. We tried to pitch it as an official unconference, and lost by a slim margin. I still maintain it was one of my best ONA experiences. I learned about what the struggles were in the community. I felt like we really helped and encouraged some folks, on a much smaller scale than a larger session. I proposed two official unconferences this year, and was prepared to hold them both in the hallway. (One was voted in, and held in a room, and one wasn’t, and we held it anyway.)

A few days before the conference, I learned there would be a new section called “The Midway”, a large space with booths for awesome projects (including AP’s Overview Project, which I should write about sometime), and large sprawling tables. Dear ONA, this MADE my conference! Thank you! To me, the main awesomeness here was — chairs in which to hold off-agenda sessions! No more sitting on the floor!

I’ve always said the strength of our community is the community. Panels are successful  because of good people. When all those people are in one space, that is one of the greatest things about the conference. I love the official reasons for these get-togethers, but sometimes you get what you want, you must take what you want.

So, a new type of conference began for me. I would run into someone who wanted to know about how to brainstorm data stories, I’d pick a time, tweet it, and gather some quick examples. One of my official unconfs wasn’t picked and I did the same thing. Some people couldn’t make the time, I reran the session. When I wasn’t running sessions in the midway, I would MEAN to head to a panel, but get caught in a side conversation. It literally NEVER ENDED.

Accessing panels after the fact

My friend Greg Linch streamed most of the sessions anyway, and I’ve been watching them now. While they’re meaningful, I feel I got twice as much out of the conference. I feel a little distanced from the main sessions, but am okay with that. I wish I had attended Jen LaFleur’s data session, the slides for which are unbelievably awesome, but that’s just Jen being great.  Also, I truly enjoyed soaking up Dave Wright’s design presentation. But I am content accessing this content via video.

My point here, I guess, is that in journalism school — we’re told to do things one way, and I didn’t really listen. There is a default way to do things, and a way to push the envelope. USC professor Robert Hernandez will recommend you take control of your education. No one tells you that you must go to panels when you are at a conference, but we all do. Why not bust that system open?

A number of people come up to me and ask if they should learn programming, if they are doing it the right way. I’m trying to help all of you, but as with so much, you know what’s even better than asking if you can do something? Just doing it.

Key learnings, even if vague

So, with this experience, what did I learn?

-Talking in small groups can be more effective than larger panels.

-A lot of us are struggling to figure out how to do this work.

-Often, we are given large datasets, but figuring out what the story is can be hard.

-We can and should do better at combining data and narrative.

-Heard amazing examples of how others combined data and narrative

–How to embrace crowdsourcing when it’s useful, and how not to do it for a buzzword’s sake (also brainstorming how to apply such principles across our system at AP)

-Using D3 with IE can be hard, and I learned about ten ways NOT to do it

-Small impromptu group sessions can attract a certain skillset. Explaining JavaScript libraries, but being able to say “Then I used jQuery to grab the window’s width” or “The fourth parameter passed to the function” and having a group of people nod with understanding, enables us to move forward faster. Harder to do that with a more general audience, although I love that, too.

Balancing hacking and embracing the system

Don’t get me wrong, I love ONA. But I think our organization has a great struggle. The field of digital journalism is so incredibly broad right now. And I, even at my age, have fallen into a specialized niche. Not all the sessions can serve my needs at any time. I would love to see more mainstream coverage of various aspects of data and programming at the conference. And not just in unconference sessions, or as a separate paid pre-workshop. We are no supplementary sidecar!! So, while I try to help along, and yearn for, a new day, in the meantime there are two options. I could wait, or I could grab the opportunity by its head and take it on NOW. I chose the latter.

Next year, I want to find a happy medium — I do want to make it to some panels that I’m not speaking on, but will feel free to skip to have important convos/learnings/teachable moments. I’m still learning how to manage so much, including my conference attendance.

Conferences are really about education

The primary point of the mission is to pay it forward. AP’s Social Media Editor Eric Carvin stopped me in a hallway and commented, “You’re really in your element — you love to educate!” But, of course. I learn a bunch of stuff during the year, and ONA and NICAR are my opportunities to learn and share with you. That’s what journalism is to me, a way to share knowledge with our readers and users, as we produce content, and with others, as we determine HOW to produce that content.

People of the Internets: Know this. Just because something is where it is, doesn’t mean you can’t make a difference now. In conferences or in your organizations. Because, to quote Apple’s Think Different slogan, which hangs in my bedroom in my DC apartment:

“Here’s to the crazy ones. The rebels. The troublemakers. The ones who see things differently. While some may see them as the crazy ones, we see genius. Because the people who are crazy enough to think they can change the world, are the ones who do.”

Being asked to be on a panel because I’ve moved around a lot, that’s yet another thing I never thought would happen to me. My name’s Michelle, I wear a blue hat to conferences, and I’m fiercely loyal. In high school, I was never the sports fan, but I’d be one of the loudest cheerers at the pep rallys (I always thought the real cool team was the Scholastic Bowl team I was a part of, but I don’t think that’s who most people were cheering for.) And when I discovered journalism, I just hoped someone would give me an editorial job doing something, and I’d be grateful to them, so grateful I’d never leave.

So, you see, I didn’t wake up one day and say, “This company I love, I’m going to smash it on the floor and find another one.” It’s not some sick love I have for job hunting (Receiving an offer is fun, the rest is nervewracking. My least favorite part is that horrible waiting-for-the-phone-to-ring period. Like a bad teen romance.)

But all I wanted was a place to learn and grow, to do the good work I love. Ira Glass says taste gets you into the business, but practice makes your work hit the level of the taste. Give me a place to make my work, slowly but surely, match my taste. All I wanted was a place with resources to which I could apply my fierce loyalty.

Well, the LA Times was an AMAZING experience, and the summer internship lasted six months in the end. But there was not a full-time job to be had, so I could not stay.

And PBS hired me to a site that never truly got off the ground, and it was no longer the right place for me.

Here’s the thing about when to move: Don’t move because everyone will congratulate you on Twitter, or you like the smell of new notebooks from the supply closet, or you like the bigger name. Move because you seek to grow, and you can’t make it work at your organization. Recognize that you have the right and responsibility to move if you need to, but you should try everything you can to avoid it.

In a conversation with The Associated Press’ global interactive editor Paul Cheung, we discussed how a job is like a relationship, it needs to be a good match, AP needs to love me as much as I love it. Like a relationship, just because you live together doesn’t mean you die together, and you can get divorced. Have a good reason, though.

The more times you’re divorced, the more it can start to look like a pattern. Why should I think about marrying you when you’ve divorced five people by the age of 26? What precedent does that set?

So, to determine when something isn’t working, what does work? What do I long for?

I work in a technical area, and I have many technical mentors and colleagues, who are essential. Troy Thibodeaux has stepped up to the plate as mentor, friend, confidante, reassurer and code reviewer in a significant way. Thanks! Many others, though. Sometimes, I talk about them on this blog. Or just look at some AP Interactives, and you’ll see their work. Interactives is my department.

But DC is where I live, where I go every day. I work with both the DC editorial staff and the Interactive department. And the environment in DC is a big part of what makes me feel…satisfied. So, I’d like to talk about that.

I like to learn, and while I love so many of my interactive colleagues around the globe, it’s Kevin Vineys, a true DC content expert, who has to/gets to deal with me every day, so we have a special bond. He also knows the newsroom backward and forward. Sometimes I can help him with tech, sometimes he helps me. He’s my conscience: “Did you want to do that?” or “That’s a good idea” or “What about this?” It’s a true partnership.

The reporters and editors I partner with have been working in Washington content for a while, with great experience. But they don’t hold it over me. They’re open to my ideas, and happy to answer my questions about what I don’t know. They don’t look down on me, but we operate as partners. When I get the courage to speak up, I’m rewarded by having every eye in the meeting focused on me with an intensity the likes of which I had never seen. My vision and knowledge matters. C.S. Lewis calls this the “inner circle”, where one is acknowledged on the merits of his or her work. That’s what I was searching for.

I’ve had a hard time putting this (what I’m searching for) into words. So, now it’s time to tell you about one other person who makes the DC bureau a great place for me.

Sally Buzbee, our bureau chief at the AP in Washington, DC — is the editorial leadership you want in your corner. I felt it from the second I walked in for the interview.

If you want to learn more about what I consider to be an ideal editorial role model, read this profile of her in the American Journalism Review. Serious respect.

She knows the newsroom backward and forward. She’s no stranger to new experiences having worked for the AP in multiple roles, on multiple continents. The phrase “when I was in Cairo” is dropped as cooly as “I had a turkey sandwich for lunch.” And she is all about the work and the content, and respects me for where I am in my journey. She makes me the best me I can be, at this point in my career.

She understands the importance of digital and interactive, and gives me the advice and knowledge I need and crave. She makes me believe my ideas could become reality.

This is the crux of it: When it comes to my crazy 26-year-old newsroom vision, and I start to talk about it, Buzbee will say, “We share this vision. The difference is, you have the technical skills to make it happen.” Well, I’m working on it.

So, what am I looking for? What did I want from my job searches? Well, to borrow a Buzbee phrase, my “intellectual home.” Let your brain sink into that phrase for a moment. Where you learn more about your craft, in multiple facets every day. A place you’re comfortabe enough to speak your mind, but not comfortable enough to stagnate.

Put another way, an ideal environment is…well, I’ll let Buzbee describe it again. What sort of environment does this news leader, who I work so closely with, seek to foster? Do we understand each other?

“Nothing gives me more satisfaction —  and downright thrill — than working with talented people who care passionately about the work they do. It’s the one critical thing that gives a place energy and purpose,” wrote Buzbee in an email to me.

Darn straight.

So, what was I searching for, even though I never knew it? That.

Maybe that’s helpful to you, maybe it’s not, but it’s all I know right now, and I thought I’d share.

I’m just elated, and hope that everyone can find a good match like this, where they don’t just go to work for a paycheck, but because their mission aligns with their organization.

In a cover letter I wrote more than a year ago, I said of the AP, “I’m ecstatic at the opportunity to contribute to this work and continue to push it ever forward.” That’s a sentence that’s as true today as it was back then.

Thankful for support from colleagues and leadership around the globe on the technical, design and editorial sides. They respect me for my knowledge and caliber of my work, but understand that there’s much I don’t know yet, and am still navigating. I’m learning a lot (especially for a year!), we’re making progress and I never dreamed I’d have this much of an opportunity so soon.

Time to get back to it! Here’s to Year Two!

“So is there a Strunk and White for code? I’m teaching myself, and I know things like my indentation and the like must be all screwed up, but I haven’t really found any reference that would help me out. Do the conventions vary widely from language to language?”

The answer, or what I’ve gleaned from my study so far, isn’t simple, so I’m extending this into a blog post.

It seems to me that basic principles remain the same, but how you make them happen is what differs.

Put another way, when we write, we organize our thoughts in sentences, which get grouped into paragraphs. Paragraphs are placed in order, to hopefully form some type of narrative. But if I write a news story in French, it differs from English in that it uses different words and characters. The order of words in sentences even changes: “le chat bleu” as opposed to “the blue cat”. But the principle of sentences, paragraphs and logical flow still apply. And to further push this metaphor, Strunk & White doesn’t go into detail about how to structure paragraphs, but rather what you put in the paragraphs. Same with the majority of coding references I see.

But for what it’s worth, I’m trying to learn the language of JavaScript, for example, as well as how “paragraphs” work in code. Attacking both at once is even more confusing, not to mention the fact that the last time I learned the elementary basics of structuring a document, I started in kindergarten.

Mentors of mine have suggested the books Refactoring: Improving the Design of Existing Code and Code Complete (Amazon links informational only, not meant as telling you to buy it). But frankly, I find them to be quite difficult to wrap my head around, at my current skill level. When I reread five times, I get it. They’re worthwhile, but require careful study.

Since an object {} should contain everything, there are things called JavaScript object patterns, and I imagine similar things for other languages. I’ve tried many links on this, and a favorite is the virtual “book” Learning JavaScript Design Patterns.

But before we get to all that, there are some simpler lessons I’ve taken away, that have helped me “get” it more than the rest of the resources, at least for where I am right now in my coding journey.

• Outline what you will do first, in pseudocode, that is use English to describe what you will tell the computer to do. Write it like an outline, with sections and subsections.
• Convert that into functions. Functions call other functions; you should be able to describe every function in a topic sentence. Right now, I like to write that topic sentence at the start of my functions.
• Order functions following a logical path from specific to general. The inner functions a larger function uses goes directly above it, then we move to the next set of inner functions to larger functions. A giant call to initialize the whole thing goes at the bottom.
• Write a bunch of comments to remind yourself what’s happening. Reading just the comments, from bottom to top, should read with some sort of narrrative or logical structure.

Lisa also asked about indenting, and I struggle with that too. Again, I think of it like an outline I used to make in school. If something is a part of something else (a function, an HTML element), it goes in a level. This makes it easier to see when you’ve forgotten to close something with a stray } or ). I don’t know that there’s any great resource on that other than practice, and copy editing yourself.

Of course, for me, the healthy fear of having my code reviewed keeps me honest. If I don’t indent correctly, I’ll hear about it. It’s important to have people who can review your stuff, whether inside or outside your organization.

But it’s still a lot of self teaching. In the end, it’s up to me. A quote from a reviewer when I felt guilty for messy code: “Don’t apologize to me. I’m just looking at it once. You’re the one who has to live with it.” Truth.

If anyone out there wants another set of eyes on their stuff, I’m always happy to take a look — I could use the practice. If I don’t know the answer, I’ll ask someone smarter.

Hope that helps, Lisa. That’s as much as I know now, but I’ll post more when I figure more out.

What I’m trying to improve on, is that currently I go through this cleanup every Saturday morning. I’d prefer to just…keep it organized to begin with.

So is it with code for me right now. I just rush through, trying to keep information organized into separate pieces, called functions. Then, the day before I meet with one of my “code-reviewers” at my organization, I say, “Oh, no!” and quickly reorganize everything, and fix all my indentation. “Look, it’s organized!” I say.

But recently, one of my mentors suggested pair-programming, a concept where we work together on the code and I realized my fake organization would be found out for what it is. I need to rectify that…NOW.

So, one of my new favorite tools for staying organized as I go, as I work on Big Projects, is called a “namespace.”  Jonathan Stray introduced this concept, but I don’t think I got it until Troy Thibodeaux re-explained. Not a comment on either of them, just that multiple explanations is helpful.

Side note: Having access to Jonathan, Troy (another expert coder, who actually used to work in AP DC, and is one of the smartest, most helpful and calmest people I’ve ever met over the phone, he’s at AP New Orleans) plus several others, from a coding perspective, within my organization, is an amazing opportunity. I feel myself learning even faster, and I just regret not looping Troy into my study sooner.  

Just feel pressured that if their combined force can’t get me where I want to go, I have very big problems. Can’t decide if I’m totally giddy with that kind of knowledge, or totally afraid.  I’ll go with giddy.

Anyway, the idea, if I’m explaining this right, is that you attach all of the blocks of code to execute, or functions, to a giant variable (the namespace), which is attached to the window, which represents the actual webpage, and is always available to your JavaScript.  

You also attach information you need to pass among the functions to that variable. Then, all the functions can access the information, and you don’t have to shove it around inside () as arguments.

Another great feature is you store all of the functions, but by wrapping code in functions, you have greater control over when your code is run, or executed. You’ll see in the example below, I create two functions, but only run them, by adding () after a function name, in the initialize function.

An added bonus is if you inspect this giant object in the Web Developer console, you will see all of your functions and pieces of information as you dig into the object.

I like this strategy a lot, and am trying to approach my projects this way from the start.  I will leave you with an example of short namespaced code.

1
2
3
4
5
6
7
8
9
10
11
12
13

window.myAwesomeMap;
 
myAwesomeMap.getColor = function() {
   myAwesomeMap.color = 'tomato';
}
myAwesomeMap.colorAlabama = function() {
   $('#alabama').css('background-color', myAwesomeMap.color);
}
myAwesomeMap.initialize = function() {
   myAwesomeMap.getColor();
   myAwesomeMap.colorAlabama();
}
myAwesomeMap.initialize();