I’ve had some opportunities to think back on my journey over the past five years — from student to teacher in the same classroom, from writing my first lede to building highly technical projects and systems for journalism. It’s been a long journey, but one constant has been my phrase “I am a journalist first and a programmer second”. In the past year, and particularly, the past few months, I have finally accepted myself as a programmer, equal to my identity as a journalist.
I was mystified by the power of code, and what it could help you make on the Internet. And now I know that if you’re mystified about something, you really should just embrace your journalistic “desperate curiosity” (a phrase borrowed from former editor Jonathan Stray) and go after it. Following tutorials and making something work is great, but I’m learning there’s a deeper level of pride we must take in being excellent in our technical work, and it makes us no less journalists. I now perceive myself equally as a journalist and a programmer, and it’s improved my joy in my work life infinitely.
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. This is the first, which 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. The second will address 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.
Journalists coding is too easily impressive
While I look around me and see people I consider full-fledged programmers, I never saw myself as one of them. In an industry that encompasses so many platforms, which is great, I remember constantly being applauded for any technical knowledge I showed. I certainly appreciate that, and realize that I dabble in multiple fields. But in programming, there is so much we can do. This is reflected in the number of sessions at conferences that cater to doing something “without code”. Don’t misunderstand, there is a role for that, but I would perceive it as a gateway drug. There comes a point, when one really gets serious about development, that code is no longer something to be tiptoed around, but something to be embraced and relished. Making that psychological jump is something you have to want, and to recognize that being great is more than just getting it done. A journalism degree does certainly not excuse us from the standards and best practices of programming. A mentality of “hackathons” to get something done quickly, and a mentality of “ugly code”, “don’t look at how the sausage is made!”, etc. gave me an almost indirect sense that journalistic deadlines implied getting it done so it worked, and not worrying about how the underlying code looked or acted
Conferences and resources only go so far
At special events, I enjoy learning from people who are more advanced, but the key is to apply difficult concepts. And often, that just can’t be taught in a few hours. And the difficulty often comes in applying those new concepts, which requires you to use the technique on a project. Which is an added stressor that you may not want to add on a newsroom project.
There are many blog posts online, but the ones in language (not that technical stuff!) I could understand only took me so far. The language I could understand is often the language of beginners, and there were, understandably so. And the stronger, more advanced examples used technical words I couldn’t parse. More on this in a future post, but feeling like I couldn’t understand the “real” programmers, made me feel like more of an imposter who didn’t belong. So, as an imposter, I simply wasn’t subject to all the rules. After all, it was impressive I was an English major who could make Internet things!
Hitting that pain point
All of these comments are not to excuse myself. Smart people told me the right way to do things, but I’d freak out and get stressed, and viewed the best practices as optional suggestions. Talking to others in recent months, I’ve heard that the only way to really adopt the best practices of development are to hit a wall and see that you need them. That moment has come for me recently. I call it out in case you see it in yourself. You would be afraid and frustrated to look back at something you wrote, because you wouldn’t even know where to begin to adjust something. That’s bad enough when it’s adding a new feature, but worse when trying to fix a bug. Programming is hard, but programming this way is so hard, you feel totally incompetent. You realize when trying to describe your problem that without the technical words, you use phrases like “I tried to put the thing in the other thing, and then I wanted to get a bigger thing, but instead it all broke and there were red messages”. And you realize you don’t understand what you mean, and worse, well-meaning people can’t understand you either. It makes it more difficult to share work with your peers, you can’t understand resources on the Internet that might be able to help you. And perhaps worst of all, when it comes to helping others, which I adore doing, I felt like I was teaching with an incomplete knowledge base.
I compare it to personal issues I’ve had with my health. The situation I’m describing above, as well as spending Christmas in a hospital — both were a serious wake up call. And neither my physical nor programming health was going to improve until I declared that starting right then would be a time of change. Not that I can’t do things the old way anymore, but this: I am not someone who writes that kind of code anymore. It is not acceptable to try it, and then balk in tough times. It is not an option. This is 2015. This is a career turning point, and a new way of being. It must be.
My new zeal for coding as a true professional developer, but always for journalism, would make past efforts look apathetic. I have some really smart and patient colleagues, and my editor Troy Thibodeaux is one of the smartest and dedicated, yet kindest and most patient, people I have the privilege of knowing. In fact, that’s another big epiphany here: If everyone from Derek Willis (first data journalist I met) to Troy are people I admire and see as journalists and programmers, and place in a special category of caring about the pursuit of knowledge and intellectual growth as much or more than I do, than why am I resisting committing to joining them? Of course, they are programmers. So, with my journalism mission in mind, I let go of being pretty good at programming for a journalist, and embrace being an intermediate programmer on that path. The safety net is gone, as I realize it’s less of “I could never be as great as them, I’m lucky they know my name” to “I have a lot to learn, but what they do is in my sights — I’m on my way!”
Step 1: Take pride in the quality of the code itself
Realize that being able to understand what’s going in your code is as big a deal as the accuracy of your data. Take pride in the documents you turn into the system. Remember that even if you don’t think people can see it, they can view source and see what you are doing. Remember you can make life easier for yourself. Stop thinking it’s funny to laugh off your bad code quality. Learn to recognize what good and bad code quality is. For every line in a file, understand what it does. If you don’t, research until you get it, use another strategy or ask someone.
One example is learning what’s clever vs. more readable. Condensing a conditional to a ternary operator (you’ve seen it var result = mytest ? true: false) is clear sometimes, and sometimes scrunched so small, it’s hard to understand what is going on.
The most helpful thought here for me has been that I like teaching and learning. If I’m the only one who gets what I’m doing, how will I share with others?
It’s also kind of fun to challenge yourself to write the most readable code you can — sort of like an enjoyable logic puzzle. And the more I practice, the more I enjoy it. It’s something that I never really seriously tried before, for better or worse.
Step 2: Put in the effort, and rock the functions! Organize your code so it can be reused
Again, on deadline, it can be easy to lump all the code together, but it’s hard for others to understand. I’m also learning that ideally different parts or functions of the code should be more “modular”, that is, broken up into separate parts. And as part of that ideal, these functions should take in certain inputs and output something at the end, and have the actual content of the function relatively agnostic to what exactly is passed in. The more generic the code, the easier it is to reuse elsewhere in the project, or even in a different project. Of course, making something overcomplicated to accept as many cases as possible can go to far in the other direction — google “premature optimization” for more on that. It’s a balance that’s fun to practice striking. Also, the functions should be named carefully, and only do one thing. Keeping to these rules makes the code easier to understand.
This idea has made it easier for me to identify what Kent Beck calls a “code smell”– something common to code that just seems like it could be problematic down the road. When I started pursuing these ideas, I’ll admit I made these changes to please my more advanced colleagues. I was told eventually that these “code smells” would start to bother me in my code and that of others, I would feel uncomfortable. I’ve now gotten there, so I try to modify my code, so it’s something I can believe in. And if it makes life easier for others, that’s good, too.
One other side effect of this idea is that when code is broken up into little chunks like this, I have a more concrete understanding of the big picture of what I’m trying to do. Thus, I’m getting closer to thinking in code. My French teacher often said that when you are translating each word individually, you are at one level of understanding, but when you just speak a French sentence, or dream in French, you are fluent. Likewise, perhaps a greater fluency with code means I see a problem, and can see a solution, even if I can’t articulate it. Modular code means I can write out names of functions in a notes file, reorganize them, to quickly jot that big picture architecture down as I see it in my head. Then, I can fill them in. And after I write, I pull out all the function names into a notes file, and see if it reads well. If not, some of my function names could be more specific.
Step 3: Careful with those names! They matter!
Naming is an issue here as well. All names should be descriptive, which makes code almost read like English. I find it hard to write good names on the first try, so often I’ll write down something I’m dissatisfied with, and change it later. (Quickly, before my editor sees! I mean, um, just kidding, Troy!) Seriously, it’s another thing that bothers me if I finish the day with bad variable names. Another example where I at first did it for the others, then I did it for me. Or, as us programmers like to say, I did it for my future self, who won’t remember the code, but hopefully will be able to understand more of it due to being this concerned with readability.
Step 4: Test! Not just by clicking! Automated testing!
A huge revelation to me has been automated testing, and test-driven development. Before, when I said “testing”, I thought that meant running your project in the browser, and being sure you looked at it at multiple sizes in multiple browsers. While that’s still important, that’s not what I’m talking about here. The fear of your code working, and the ultimate risk that you take when you’re concerned it might break (and I’m always concerned it will break) needs as many checks as you can get. Clicking around is good, but humans make errors. Whose to say you’re clicking the same buttons in the same order, and covering all the cases you intend to, by clicking around?
I was introduced to the idea of “test-driven development” by way of “automated testing” – -writing code that checks to see if an aspect of your code is working. You write that test first, it doesn’t work because the code it expects doesn’t exist. You then write the code, so that exists and your tests work. A little display on a webpage turns from red to green. Then, as you work, if your tests go back to red, they are breaking and you know something went wrong in the code. It helps me think about what to write next and how to structure the code more clearly, and I’m less scared to reorganize the code, because it’s not as brittle, hopefully.
Now, don’t get me wrong — testing code like this is totally frustrating. You try to use the smallest data structures you can, and put in simpler parts of the code that fake out, or mock, more complicated structures. Figuring out how to do this, or wait until a response is returned by an aspect of the code is really, really hard. There are days where I spend more time writing tests properly than actual code. But I feel better about the changes, I sleep better at night, and am only seeing the beginning of these benefits. And I — imagine this — feel more confident about my code as well as my own skills.
Already seeing the change
I realized the full extent of the transition I’m undergoing when a developer I follow tweeted asking if anyone has done testing in JavaScript. Old me would have mentioned clicking a lot in the browser. That would have been a response showing a total lack of knowledge. But with the work we’ve been doing, I was able to point her to Jasmine, the system we use at work for implementing this technique. If I walk like a developer, and talk like a developer, then maybe I can’t deny that I am one, even if I have trouble believing it.
And it’s still all for journalism, I haven’t lost the other skills. But I can use the development tools to make my work better. And I’m comfortable with that.
Hope that all was helpful to someone out there. You know, the one of you still reading. Hi, Mom!
To come soon: parts 2 and 3 exploring other aspects of growing as an intermediate developer, for the sake of journalism. Because this is only part of my thoughts on this issue.