Five Programming Lessons from a Journalism Major

Like many programmers, I had different career goals before I found programming. In my case I found programming more than halfway into getting a Bachelor's Degree in Newspaper and Online Journalism. I was writing so much code during those last two years in my last editing class, the professors had me on programming full-time for the course while everyone else edited articles.

It was a powerful sign that my career goals had shifted to something else, my professor had gone insane, or both. I never found any secret bunkers full of dog food in the school, no matter how much I looked, so it was likely the first thing.

However, there's many lessons I learned from this major that I don't want to go to waste! Five of these useful lessons are:

• You can still carry on a conversation even if the lights go out
• Never dance on the job, even if your job is currently on or near a dance floor
• Avoid playing beer pong with your attractive Features Editor at newspaper staff parties
• Ann Coulter's security detail creepily stares at her audience
• Spelling a last name wrong is punishable by death

Now here are five lessons that are actually useful to programmers!

1. Prepare for Panic #

Things went horribly wrong on just my third reporting assignment. Not wrong in a way that led to emergency cleanups and catching a dozen ferrets, I learned that much from high school. But still pretty bad.

I was assigned to cover a poetry event I thought was in a week. But from my dorm building later I found out it was that might, and started in 15 minutes. So I sprinted a mile across campus, researching on my phone as I went, and conducting my first interviews on the verge of passing out.

That stretch of time between realizing my mistake and the event's ending was one of, if not the, most panicked moments in my life. But since then I've rarely felt that much panic again, and this resistance has helped me greatly as a programmer. The best example is when urgent production bugs are reported (especially ones I may have made). It's easier to take a breath, find a solution, and open a pull request without smashing my keyboard in an anxious rage. Again.

Not every programmer can build their panic resistance through reporting, I can't just recommend people go stress themselves out to prepare themselves. But if keeping a cool head is tough, creating fake "panic situations" with activities you enjoy can help get you ready. It could be as simple as putting a self-imposed deadline on a project to get used to the rush of working while the walls close in.

However the exposure is, from sprinting to an event or interviewing strangers or bungee-jumping with a Twizzler rope, building panic resistance is great for when production code screws up. A cool head fixes it faster, better, and more reliably. Fixes by an overwhelmed, anxious programmer can cause worse issues later on.

Those issues aren't as bad as when those ferrets found the escape hatch and the drugs my high school confiscated, but still, pretty bad.

2. Independence over "Objectivity" #

In my first journalism ethics class, our instructor described an article that painted a gruesome picture of local housing. It didn't have perspectives defending how things got so bad, since everyone the journalist contacted refused to comment. Many in the class thought the article was one-sided and not objective enough to run.

Our professor then told us this article was written based entirely on public records. On second look we saw the article had no opinions, simply facts she found and gave proper context to. The professor said these were independent sources, removed from the journalist's own views, and that's what made it more truthful. It was clear and one-sided, but still reflected the truth.

That class taught us humans always have biases impossible to fully recognize and remove. Basing one's arguments on independent sources, separate from our beliefs, is the better way to avoid these biases. Independence matters more than "objectivity," since for humans objectivity doesn't really exist. Especially from people online spouting nonsense who claim they're more "objective" than others.

This lesson helped me a lot with major programming decisions, like with a company's component library. I first chose Pattern Lab due to past successes with it, which biased my "objective" decision to use it. Looking at independent sources of info, like the company's code needs and Pattern Lab's documentation, it clearly wasn't the most suitable tool. It was tough, but I later cut my losses and moved to a simpler style guide.

I've found this a good approach for almost any tech decision, especially around tooling. Accept that you will always have biases driving decisions you may not even be aware of, and base decisions on independent info instead. These can be project needs, tool or framework documentation, and advice from uninvolved third-parties. All these can paint a clear picture whether something is right or wrong for the job, no matter how you may feel. This approach is tougher, but ultimately better for one's team.

3. Explain it with a Metaphor #

Explaining things with metaphors has saved me more times than I can count while reporting. The most common situations it did were:

• Needing to explain something complicated in an article with a limited word count
• Explain something complicated in an interview question so I could get the person's thoughts on it
• Distracting campus police with new knowledge to hide the fact I'd just smoked marijuana for the first time

Metaphors were great for all these since they attach new knowledge to something people already understand as a "knowledge shortcut." It got to the point where, much like Dr. House, metaphors became my fallback way of explaining virtually anything and everything.

It also led to my rule of thumb for understanding anything new - if I can't think explain it with a metaphor, I don't know it well enough.

What metaphors would you use for the relationship between HTML and CSS? What about JavaScript functions? Good ones I've heard for these are:

• HTML and CSS in a webpage are like a human wearing fancy clothes. HTML markup is the basic human body, and CSS styling are the clothes they wear and even how they pose.
• JavaScript functions are like habits. Our brains save common actions as "habits" so we can repeat them without thinking. JavaScript functions are like a program's habits, things the code saves them for later and can repeat with little thinking.

This is also part of why I keep an online notebook of everything useful I learn, even if a page is mostly rewording what others said or wrote. As long as I can write a decent explanation in my own words, it gives me good examples or metaphors to remind myself with in case I forget it later.

I've used metaphors like this at family gatherings to explain what I do and how it relates to what they see on other sites. It quickly assured them I was a smart, functioning adult who could make a living. That right there is reason enough for anyone to learn effective metaphor use.

Proper metaphor usage improves communication, saves time, and gets you widespread family approval. Journalism taught me it's well worth the investment for all careers, not just with itself and programming.

4. Disagree with Civility #

One week in 2013 New York passed a gun control law in response to Sandy Hook, and I wanted perspective from the Democrats and Republicans on campus. They went as you'd expect - the Democrat thought it wasn't enough, and the Republican thought it was too much. In both interviews there were times I wanted to disagree, as I'd done in political talks with friends. But as a journalist that wouldn't fly, since I needed to stay on good terms with these groups. It was about finding new perspectives, not changing them. So I nodded, listened, asked my questions, sometimes strangled the air under the table, and thanked them for their time.

You may wonder how this applies to programming. Remember those Twitter "discussions" coders have had about CSS, JavaScript frameworks, or whatever else? There's been dozens of similar times I listened to a coworker ranted about design or development preferences, I was asked for my own views, and I had to respond without starting a rumble for the sake of both our jobs.

The most important thing I've found is to remind myself the goal of these conversations isn't for someone to "win." As a journalist it was about understanding a new perspective and saving my feelings for later, and it's the same principle I follow as a programmer.

Along with that, I've found a few rules of thumb that have helped me in my interviews:

• Let them drive the conversation. People enjoy talking about themselves. It's a small price to pay for keeping the relationship intact. The more they talk, the less likely you are to say something that starts a fight.
• Keep an even tone and neutral language. Otherwise you can give the impression you don't take their views seriously, regardless of your words.
• Preface all opinions with qualifiers like "my own experience with X is" or "what I've found is." This makes it clear your viewpoints come from different experience and you don't inadvertently invalidate their own.
• Don't interrupt. Language is like traffic, so don't crash while trying to push in front of them.
• If a huge disagreement on a sensitive topic is unavoidable, simply state upfront you likely won't agree and that's okay.
• Any objections should be simple, neutral, and logical. The more a counterargument is based on emotion, the riskier it is. When in doubt, don't raise it.

Could I have kept this up if I wound up interviewing the campus' white nationalists who believed in women only being homemakers or black people being subhumans? Probably not, since there's some topics it's hard to just "agree to disagree" about. With luck that'll never pop up where I or anyone reading this works.

As long as no one drops a "CSS isn't a serious programming language" bomb on me.

Every so often we see a wave of people complaining CSS is broken because it doesn’t address their exact problem the exact way they think it should using patterns they find personally familiar so I guess CSS is a real programming language after all

— Eric Meyer, CSS Nerd (@meyerweb) December 16, 2018

5. Be Selective with Your Knowledge #

Many articles I've written had lots of details I liked but had to cut. Every detail in a story must add something important. There were always good details I had to remove to make way for great ones. Over time I became pickier with what I used in articles, and started with the most important pieces before adding others as space allowed.

This trickled into my everyday memory habits. Plenty of people called me out on forgetting silly details they think I'd remember, like their age or what their "name" is. I've grown so used to taking in information, quickly looking at it's potential use in my life, then keeping or discarding it. I see my mind like a long-form article: there's only so much space and I'm always editing down what I include.

I'm not saying programmers should do this for their life, since myself, my partner, and many people I know by face and not by name wish I didn't. But there's a better case for doing so with what one learns as a programmer. Saying yes to learning one thing means saying no to many others by default. Think of your programming knowledge as an article on your career path - does this language or tool add enough to justify keeping it, or should it be edited out?

This is how I've approached my own learning, editing out deeper React and Ruby knowledge in exchange for fundamental and advanced JavaScript that will carry my career farther. I've often put aside things I'd have lots of fun learning in favor of more important topics.

If that story changes and I wind up programming something totally different, I'll break out my mental editor's pen and bring in new essential knowledge to focus on. Knowing what to learn is just as important as knowing what not to learn.

In Conclusion #

While I'm happy with my career as a programmer (so far), I still don't have any regrets for having focused on journalism. Those courses and jobs helped me develop my first real career skills, which were simple yet ever-useful - listening, learning, writing, summarizing, keeping calm, and last-minute extreme cardio. Even now I still miss parts of the job - seeing my work read and referenced by others, exposure to many differences events and people enjoying them, and the sheer joy of collapsing into bed after writing for tomorrow's paper.

I try to hold onto my journalism education both to help my career now and remind myself that all those years (and student loans) weren't a (absolute) waste despite the path I took. All the lessons I remember now do just that, even if remembering a certain article means I'll never dance at a night club with a stranger ever again.

Discounting what my therapy costs, it's a small price to pay.

• Next Post: Eevees, Quizzes, and Singletons, Oh My!
• Previous Post: The Testing Introduction I Wish I Had