Coolness I’ve Learned At The Chicago Tribune, Part One

by Andy Boyle.


Seeing as it’s been almost a year since I last updated this blog, I thought I’d write about my time so far on the Chicago Tribune News Apps Team. This will be the first blog post of a handful, so once I’ve got them all done, I’ll include links to the bottom of this main post.

My almost 11 months at the Chicago Tribune have so far been awesome. My coworkers are brilliant, fun to be around and a daily inspiration. We get to work on some of the coolest projects in journalism, from journalism-heavy projects to business-y solutions that’ll help sustain our daily journalism. I’m proud they let me be a part of their team.

Starting Sk1llz

It’s only fair that I reflect on where I am compared to where I was when I started. When I got here, I was somehow able to build production-level Django apps (but hadn’t done that at all at my previous gig at the Boston Globe), using Django and server foo as taught to me by Messrs. Jeremy Bowers and Matt Waite (with some occasional Derek Willis help). I had built a few things with JavaScript at the Boston Globe, but I was still quite scared of it.

Now I’m much more proficient than ever in Python, having worked on scripts that scraped web sites, pulled data from spreadsheets into databases, cronjobs that hit APIs to write emails, baked out flat files from templates onto Amazon S3, pulled in user content and more. I’ve learned so much it’s almost ridiculous to think they hired me before I had as much experience as I have now.

In the world of JavaScript, I’ve become much less of a newbie. I’ve worked on apps using Backbone.js, Underscore.js and require.js. I’m better pals with jQuery than I was before, too. Not to mention I understand so much more about what is actually happening in the browser when pages load my code. So many problems require that sort of nitty gritty knowledge, and I’m glad I work on a team with so many talented folks who are just so much smarter than me.

I’ve aso gotten much better at debugging problems than before. Part of this, I think, is because I have much better programming chops thanks to my coworkers’ tutelage. My days are less, “Crap, I don’t know what to DO!” and more, “Ah, what if I just tried this? Okay, lemme Google and see what else there is.” I actually READ DOCUMENTATION. Sometimes I even understand it!

Crazy, I know.

And I’ve also started to really dig test-driven development. So much of what our team does lives on our own server architecture, so we’re able to properly test things from our local machines to our staging servers and production. Along the way, because of package management using virtual environments, we should be able to test everything, in Python-driven apps as well as JavaScript ones, to make sure it works before hitting production.

Not to mention I’ve gotten much better at using git, which I hadn’t used for work projects since my time at The New York Times Regional Media Group. We put a lot of our code live, which I’m a big fan of. Show your work, people.

Biggest Takeaways

The first big thing I was taught was how to actually follow and debug your own code. I know, this sounds like I should’ve already been good at this, right? I’ve made projects that are somehow STILL RUNNING three years later online. I’ll tell you straight-up: I sometimes didn’t know how my code did what it did.

Yeah. I know.

Thankfully, probably mostly because of the many times the codemaster Joe Germuska sat next to me and made me read code aloud to him, saying what each line did, in my first few months at the Tribune, I started to actually understand how code works, how it flows, how to follow it from one function to the next. Nothing’s magic. And although the roadmap may be sometimes difficult to follow, code does have a roadmap.

When I was a reporter at the formerly-named St. Petersburg Times, I used to analyze stories written by my colleagues, such as Michael Kruse and Ben Montgomery, trying to figure out how they crafted phrases, set scenes and engaged the reader. And I now have fun checking out what people put on github, following the code and trying to see what they do.

If there’s another one big thing I’ve learned at this job, it’s about deleting code. I used to leave excess code on the page, with comments all over the place, while trying to solve a problem. I was afraid that if I deleted something somehow I would never find the solution again.

Now I know I can just use git to store previous versions of code. Also, my confidence is much higher. If I can figure out how to do it once, I’ll definitely be able to figure it out again. I’m glad my colleagues have helped me in this area, too.

Lastly, I’d like to point out how lucky I am. I get to work with an awesome team, with a happy work environment, solving interesting problems at one of the largest media outlets in the country. We get to make most of our own technology decisions and it’s an incredibly collaborative environment. I’m a pretty happy dude.

Coming Next

Over the next few days, I’ll be posting some links to projects I’ve worked on and a few key points I learned during building them. Hopefully this will help other folks building internet-y things, as I hope others won’t have to suffer the same mistakes I’ve made.

Coming up next: I’ll discuss the Chicago Tribune’s Weather page I helped build.