What does it mean to “grow up” to the next level of how we work? How do we take hacking to find a solution, any solution, and turn it into a purposeful, logical craft? It’s a question I’ve been trying to approach for the last year. So, when you ask me what I’m doing these days, these are the thoughts I’ve been having.
I have long seen programming as the means to an end, the end being storytelling. And I have understood the nature of “hacking” as finding clever solutions, no matter what it takes, tinkering till it works. When describing these thoughts to a friend recently, she suggested another term of MacGyver-ing. Of believing that what matters is the front-end of what you can see, and not how I get there. (Spoiler alert: By the end of this post, I’ll come to the conclusion this isn’t true.)
It is partially that belief which makes me feel terribly guilty when I call myself a “programmer”. Don’t ask me how I got to that working code, I’ll joke about just how horrible it is, but it works. I’ll believe that I can’t play with the big dogs. And when the code breaks, I’ll fix it, over and over again. And it’s okay, because the programming is secondary. But eventually, that’s not enough. The systems get bigger, and the words and processes are there for a reason.
So, my first issue I’m wrestling with here is the process of how I work. And the fact that it’s disorganized and isn’t logical enough. The second is related — it’s how I describe my work. I mean, don’t get me wrong, I know the basics of coding vocabulary. It’s not that if you’ve attended a class or session of mine, it’s incorrect. It’s just that when approaching difficult concepts, I can’t describe what I’m trying to do in the way I’d like. “This” and “thing” are common words. And if working just among myself, and at my current level, is what I wanted, one could argue that’s fine.
But I’ve never really wanted to be working in isolation, and certainly not to stagnate. I also realized that I was blocked in my self-teaching on the Internet, because the really hard and good lessons were written using words I couldn’t access, and I was blocked off from the community. This is especially problematic as I embrace myself as a developer, and look for developer-oriented resources, which are sometimes outside the journalistic community, and the words I know.
When you see me at a meetup, and you ask me what I’m doing and learning, that’s even hard for me to articulate. The answer, I suppose, is getting out of the funk that I just explained.
In the past year, I’ve focused, HARD, on starting to explore some better ways to handle this. I’ve written posts on how “hacking until it works is no longer enough”. But there’s still a part of me, the part that’s always worried I couldn’t code “fast enough”, that isn’t content slowing down enough to do things “right” when I know I could be doing it so much faster.
So sometimes people learning to code ask what’s next, once you can pretty much build anything you want to, or are asked to, build. And this is my latest answer. Working on how to articulate what you are doing. Being able to discuss the work. Understanding what best practices are, and how they can help you. And ultimately, doing the right thing, and using those practices.
These days, I’m applying this learning process specifically to the practice of automated testing. More on that another time, but let’s say I’m discovering it affects everything from double checking to your work to changing the process of how you build what you build in the first place. I have read the documentation, blog posts, resources, examples, watched the YouTube debates. I can recite off the top of my head why you should do it, and even generically how to do it. But it takes my colleagues to remind me to do it the right way. And I still don’t do it nearly as often as I should.
At first, I want to do it. Then, actually putting it into practice is hard, so I resist. Then, I get into a groove and think I know enough that I announce that it’s really going to work this time. And it doesn’t, of course. I’ve started this post every day for two weeks, waiting for the right moment. because some days, I’m tempted to write that we should keep doing it the way we’ve always done it. But that’s not what I truly believe.
I can explain techniques now that I didn’t know existed two months ago. My work is better for it. Because while I still definitely perceive myself as a journalist first, and a programmer as a means to an end, it’s not enough to be anything less than the best programmer I can be. Only then can we own the title, and bring it back to the best journalism it can be.
At ONA this week, I hope to share a major technique I’ve learned, on avoiding repeating code, or put another way, “modularity”. And after these months, I can socialize with my friends and geek out over the edge as a developer, or embrace my general online ethos and hang out with people who aren’t developers. And I love you all, because we all still share the mission. But loving all aspects of journalism doesn’t excuse me from growing up as a developer. And growing up as a developer, learning the words, doesn’t make me any less able to relate to the community as a whole.
I’ve had some unspoken fear about that and these days, I think I’m finally over it. Adapting and changing means so much more than picking up the latest code snippet. It’s adapting one’s practice and relationship with people. It’s still hacking, but with the structure that a “grown-up coder” requires. I think I get it now. Or more than I did when we last met. I look forward to swapping stories about how we’ve all grown, and am delighted I’m at a place in my life that provides me colleagues and mentors to push my knowledge in this way.