I finally no longer feel strange when someone calls me a programmer — I have learned to own it. It’s taken me the better part of five years to feel that way, but here we are. At the end of 2011, I wrote a post lamenting my code quality, and I still feel that way, although I am more confident and doing bigger and more complicated things. Sure, I can do it, but the code isn’t as good as I want it to be. And if I rush on deadline, it’s worse.
Back then, friend of the learning process, and fellow programmer-journalist, Chris Groskopf wrote this in the comments: “…I’ll note that writing manageable code doesn’t end at the small scale, you’re going to run into several of these “ridges” in your programming career where things get inexplicably harder and it’s usually because you need a new set of abstractions in your toolkit…”
And Chris did predict the future. Even many of the helpful book suggestions that surfaced there meant something different to me then than I feel they would now. What I’ve long needed is a curriculum — a structured way to figure out where I’m trying to go, and what reading, and in what order, would be most helpful.
So, I’m beyond excited that my editor Troy Thibodeaux is helping me out with what goes in this self-study curriculum, and more importantly, we’re going to try to have weekly discussions about various readings we take on each week. So often, I find myself and those I speak to wondering what we need to learn next, and how to go about it. This provides accountability, and a knowledgable mentor to discuss abstract ideas with concrete relevance, and to make it even better, that mentor knows exactly what I’m doing on a day-to-day basis, too.
I plan to share my thoughts on our weekly readings on this blog, and also use it as a journal of sorts, as it often is. If you have helpful comments/additional questions I would love to hear them, and get more feedback from the community. Plus, as ever, I believe knowledge is cemented by sharing it.
Our first book is Refactoring by Martin Fowler. I’ll write a bit about the preface now, and Chapter 1 in a few days. (I read it a year or two ago, but ended up doing a lot of skimming, and don’t think I was quite ready. Also, its’ references to the C language scared me a lot, bringing back memories of my first attempt at computer science in college with C and Java which didn’t go well at all. But this time is different!)
Refactoring is a word I’ve heard used casually. Before reading this, I would have defined it as “Seeing how your code is messed up and hard to follow, and making it less hard to read through.” But I would have found it difficult to get more specific. Fowler writes, “In essence when you refactor you are improving the design after it has been written.” And it would seem that’s what I need.
Because I can start out with a good design idea (we are talking about design of code here, not visual design, at the moment). But then features get added, there’s a lot of stakeholders, deadlines get pushed, life happens. And soon, my good design idea is buried in a pile of…hacks. But if I think about it, maybe there’s a way to bring that organization back. Apparently I’m not the only one. “Over time the code will be modified, and the integrity of the system, its structure according to that design, gradually fades. The code slowly sinks from engineering to hacking.” YES! That exactly describes how I feel.
My original definition of refactoring is vague, which is part of my problem. I sit down, after the fact, for a block of time to “refactor”. But I stay very small-scale, change some variable names, add some comments. I worry about changing anything more significant lest I break the code. (I know, I know, testing would help.) Fowler explains the small changes build up. Move a method, break up a method, etc.
The preface makes me think that one of the goals for the readings we do in this book is to come up with two lists: a) when there is a problem that I should evaluate , not “The whole thing is horrible — ugh!” and b) types of specific tasks that can be done to change the code so it isn’t a hack, but is well engineered.
I’ll close by saying I really related to the intro, describing a consultant pushing a project team for better code quality, but other stake holders being not as motivated by changes that can’t be seen by the end user. And I mean that all to reflect on myself, and my motivations. I consider it a success if I implement the design that has been worked out, and it works in all the Internet browsers, at all the different screen sizes, who cares what the code looks like? But the “technical debt”, to use a phrase Troy taught me, but seems prevalent in the industry, too, is just not worth it. Fowler points out how one spends more time re-reading code to edit it, than writing it the first time. And that’s more true, when we build modular systems, that can be reused for multiple interactives.
I’m hoping future me can be a bit more sensitive to the fact that, as I wrote upwards of a year ago, “Hacking until it works is no longer enough”. Except this time, really mean it, and hold myself accountable. Code quality is just as important as what the code produces. I’ll just have to find a way to do both, better than I’m handling it now — that’s the next level up. Code quality is not a second, or final step, but should be a more integral part that I’m more sensitive to.
I’ve done it with breaking up functions, I’ve done it with better naming, when I have time. To paraphrase something Brian Boyer, Troy and others have all said — when it gets tough, that’s not when you dump best practices, that’s when you cling to them most tightly. I’m hoping this book, and contemplating these issues, will help me think smarter about these topics as part of my general workflow, even on deadline, not as an afterthought.