« « JS Design Patterns: Chapter 5 – Object Creation Patterns

Lessons from an intermediate programmer-journalist (part 3 of 3) » »

Lessons from an intermediate programmer-journalist’s journey (part 2 of 3)

Posted by on Mar 1, 2015 in Blog | No Comments

No programmer is an island. Back in grad school, I learned a journalistic tenet of avoiding specialized jargon, to make our writing more accessible for readers. But when it comes to working with technology, there is a strong role for embracing what I like to call “The Words”. While jargon can be confusing for the uninitiated at an introductory level, if you want to become a professional, and excel at something, jargon has a key role for helping us be our best, work with others and function as a team.

Several threads of thought on how budding journalists can embrace their identities as intermediate programmers, and continue to pursue growth, have become an obsession for me during recent months. There are so many thoughts that I’ll be sharing information out in three posts I’ll be releasing, will address some thoughts I have, in the hopes it might help others. The first, focuses on laying out the problem, and explaining how the way we write code, and follow standards, can inform the quality of what we do. This is the second, which addresses how intermediate concepts improve how we communicate with others, technical and not, inside and outside our organizations. And the final post will address self-acceptance, and making peace with what it means to be a programmer, and overcoming imposter syndrome through seeing one’s best technical work as non-optional.

As I alluded to in the first post, finding tutorials is one thing, but accessing the more advanced technical resources out there is another. When I think of the community, for a long time I have thought of that as the technical journalism community. And to be clear, I still very much believe in that. But when I go to a data visualization conference like EYEO, or attend a Ruby meetup in DC, I would like to be able to see that as my community as well. But to do so, I need to be able to access that technical language.

One of my greatest fears is that if I use the technical language too much, it will become more difficult for me to communicate with journalistic colleagues at other levels of coding, who may not even code at all. (Perhaps here is a good time to reiterate that while I encourage journalists to learn to code, I do not believe that everyone has to, and certainly not an advanced level.) I worry that if I start talking too much like a geek, it will be harder to access that common ground.

But likewise, when I speak with people I consider to be more real developers, on my own team even, I’m not bringing my A game until I learn the words.

The importance of embracing “The Words” — Technical jargon can actually be helpful!

I think it’s very important that I approach both these angles (the technical and the non-technical), these days, with being comfortable switching between the two types of language. That I know and use the technical words when looking things up on the Internet, talking to my programmer colleagues, but that when I talk to a reporter, I don’t geek out too much.

And when talking to developers, if they are using The Words, and I’m using my made-up vagaries, we are going to have to find a common language. And The Words, or that jargon, these are the established common conventions of a language, so it’s ultimately up to me to embrace them.

This link( http://www.cs.columbia.edu/~evs/intro/handouts/prog-glossary.html) references the types of words I mean when I say The Words, although it both includes and excludes some key words I would put in. If you ask me for an all-inclusive list, it’s hard to craft one. But if you are reading a resource on the Internet and you’re having trouble understanding its vocabulary, maybe that’s something to add to your personal list of The Words. Honestly, a lot of mine started from listening to my teammates talk, and asking or noting what unfamiliar words might mean. Same approach our fourth-grade teacher had us take when reading books if we didn’t know what a word meant — write it down, look up its definition, use it in a sentence and use that list as our weekly vocabulary exercise.

Using the language, of course, is the most important part. I still feel unconfident when I use the sentences, asking people to wait for me to “figure out how to articulate what I want to say” or pausing as if I don’t believe the words I used are actually comprehensible to a human being. I still get way too excited when I finally understand what a difficult article is telling me. A more advanced programmer told me I will have truly embraced the words when I stop calling them “The Words”, and just see them as natural language. I think there’s truth to that, but I like the idea of keeping them separated in my mind, so that I don’t forget how to turn them off.

Pair programming — Two brains are better than one!

At work, my editor Troy has introduced the concept of pair programming, which we’ve doing quite a bit of. As a somewhat social person, I enjoy the human interaction of talking through ideas with others. And two heads are better than one. The cool part is we’re distributed — so I’m working in real time, off of the same screen, with people across the country. Kind of fun! In pair programming, there are several ways to work together, but one of my favorites involves one person looking at the big picture of what the code, or section of code, should do, and describing the overall task. The driver actually does the typing, and implements that big picture — focusing on code, syntax, names, equals signs, etc. These roles are sometimes referred to as “driver” and “navigator”. I like to think of it as the navigator looking at the forest, and the driver, at the trees.

At any rate, no matter what style of pair programming one uses, it’s important to be able to speak to each other in the same language. The technical words can help with that. But even if you don’t know the words, having to articulate a plan before executing it can be extremely helpful in thinking through the organization of your code. And explaining things out loud means you can bounce ideas off of each other, and get clarification before going too far into “crazy town”, as one of my colleagues, Serdar Tumgoren, likes to put it.

Our team is distributed, and it’s the year 2015, and great tools for audio, video, screen sharing and screen control exist. It’s not unusual to write code across time zones in my daily work, and I love it. It’s actually a strange feeling for me to write code like this with someone in the same room as me, and we quickly learn not to point to things on the screen, because colleagues on the other side of the computer screen can’t physically see pointing.

In an incredibly geeky sense of enjoyment, when you get into a groove where you can express your ideas and get them amended by another smart person before going too deep, it’s a fun type of connection over programming that simply can’t be achieved when you just make up the language as you go.

It affects one’s confidence in a big way. I’ve noticed myself saying I know what I’m doing, until I realize it won’t work, as I’m explaining it. That’s different than simply not having any ideas, or being totally unable to get a check on your ideas from colleagues. I worry that sometimes I’m approaching overconfidence, and I get so excited I’m not thinking as carefully as I should. But that is a far cry from just doing what it takes to get it done, or wanting to code in a vacuum because I can’t articulate my thoughts to my colleagues.

“A rising tide lifts all boats”: The benefits of a team study group

To practice communicating with each other, and comprehending big picture ideas, interested colleagues and I, with our editor as a helpful advisor have been meeting on Fridays to discuss programming books, and more recently, practice talking through and adjusting code together. It’s amazing how applicable what we’re studying is to the work that we’re doing. Or maybe that the work we’re doing can benefit from advanced coding concepts. We’ve spent a lot of time working on Fowler’s Refactoring book, and now JavaScript Design Patterns. If you’re interested in what we’re learning in these books, I try to blog brief summaries and thoughts on these chapters as we come across them, so keep your eyes peeled for that. When we learn together, we help each other understand, and develop a common vocabulary. When I say these weekly meetings make work like a perpetual class, I mean that in the best possible way.

More to the point, the books use “The Words” that I’ve been practicing. It’s always helpful to see vocabulary used, to learn examples of how to use it. And understanding words makes these advanced concepts more accessible. Some helpful strategies are to take every opportunity to re-explain and talk through things. I’m fond of making an effort to define things out loud, even to people who I know understand the concepts, just so they can double check I’m understanding the definitions. And it feels very “programmer” to be able to read, access and discuss these books. Or as my former editor Jonathan Stray once put it: “When you can’t begin decipher the supposed “instructions,” technology can seem like an occult priesthood.”

We talk a lot about refactoring — fixing code so it reads better, is easier to understand. Both the old and new versions work the same way, but there is a beauty to making the code as beautiful as it can be. There have been whole sessions where we talk through the merits of adjusting code in a certain way, and end up changing a six-line function to a two-line one, but removing/simplifying loops/calls to other functions. Two-months ago me would have rolled my eyes.  “That’s not hitting the deadline!” But — it’s deeper than that. Spend the time to truly understand what you’re doing, and adjust it now. Be better prepared to hit the next deadline. And you can still make all the editorial points you want, as a journalist. But when you’re discussing code structure, you can talk about what methods should be public and private, and what should be attached to the prototype. And that can all be part of who you are.

Learning is a key part of the job

In the end, understanding advanced concepts, exploring new tools — I perceive these as part of my job. As I’ve said countless times, let us use our journalistic curiosity to approach how we tell stories just as much as the subjects we cover. I always meant that to mean a new charting tool that came out, but now I think it also includes computer science concepts, and a level of embracing deep programming. They help make sure we as developers are on the same page, so when we communicate with others, we have a clearer sense of what we are able to do, and how we are able to do it. If we are to truly be hybrids as programmer-journalists, our best selves embraces optimum editorial sensibilities as well as technical achievement.

Serdar said to me months ago, when giving some advice, that it seemed I was looking for when I would get to a level where I would just “get” it, and be done with the hard part. He advised me pursuing that was a bit of a pipe dream. But instead, he suggested, I would get to a level where I was comfortable with the fact that I was always learning, even concepts of this depth. I’ve often given lip service to that idea, but I just interpreted it as meaning I could execute new things. It also means approaching the overall structure of the work we do in new ways. That’s always changing. And if I think about it, of course I would never want it to stop — learning is way too much fun!

I’m just grateful that while what you “ship”, or produce, is what I ultimately want to be measured by, I live in a world that values intellectual growth and exercise, as it feeds innovative ideas, just as much. There is room for both the learning and the production, and that’s how we create the best work possible. But to do that, we have to communicate with the other programmers, and recognize that there is indeed a role for embracing the technical jargon. I wish that revelation hadn’t taken the last five years for me to arrive at, but luckily, there’s still a long career ahead to embrace these practices.

« « JS Design Patterns: Chapter 5 – Object Creation Patterns

Lessons from an intermediate programmer-journalist (part 3 of 3) » »