Some interesting observations by a young journalism developer.
===================================
Tom Johnson - Inst. for Analytic Journalism
Santa Fe, NM
SPJ Region 9 Director
[email protected] 505-473-9646
===================================
---------- Forwarded message ----------
From: "Michelle Minkoff" <[email protected]>
Date: Feb 14, 2015 8:18 AM
Subject: Michelle Minkoff
To: <[email protected]>
Cc:
Michelle Minkoff <http://michelleminkoff.com>
------------------------------
Lessons from an intermediate journo-programmer’s journey (Part 1 of 3)
<http://feedproxy.google.com/~r/michelleminkofffeed/~3/zrlCIn5OqBc/?utm_source=feedburner&utm_medium=email>
Posted: 13 Feb 2015 04:05 PM PST
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 developer.
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” <http://martinfowler.com/bliki/CodeSmell.html>– 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 <http://martinfowler.com/articles/is-tdd-dead/>. 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
<http://jasmine.github.io/2.0/introduction.html>, 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.
Related posts you might enjoy:
- March 24, 2011 My Role at PBS: Datavangelizing to Local Stations
<http://michelleminkoff.com/2011/03/24/my-role-at-pbs-datavangelizing-to-local-stations/>
- February 4, 2011 News apps: Are we doing it right?
<http://michelleminkoff.com/2011/02/04/news-apps-are-we-doing-it-right/>
- August 21, 2011 How to combine multiple Fusion Tables into one map
<http://michelleminkoff.com/2011/08/21/how-to-combine-multiple-fusion-tables-into-one-map/>
- July 29, 2011 The Associated Press: Next stop on the journey
<http://michelleminkoff.com/2011/07/29/the-associated-press-next-stop-on-the-journey/>
- February 5, 2012 At peace with where I am
<http://michelleminkoff.com/2012/02/05/at-peace-with-where-i-am/>
- December 25, 2011 Hacking till it works is no longer enough
<http://michelleminkoff.com/2011/12/25/hacking-till-it-works-is-no-longer-enough/>
Zemanta <http://www.zemanta.com/?wp-related-posts>
You are subscribed to email updates from Michelle Minkoff
<http://michelleminkoff.com>
To stop receiving these emails, you may unsubscribe now
<https://feedburner.google.com/fb/a/mailunsubscribe?k=x1VS1XJh0p_I4Y9k9QpeEPuVNhY>
. Email delivery powered by Google Google Inc., 1600 Amphitheatre Parkway,
Mountain View, CA 94043, United States
============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
