Addendums

Note - I wrote this entry about a week ago, but since my current (terrible) webhost enjoys seizing up every time I’m editing a Wordpress post, I think I got distracted by sites with actual working webservers and forgot to publish. Here it is now; new webhost in a couple months.

Since writing about Code Anthem in my last post, I’ve been catching up on a lot of posts that I’ve missed (almost all of them outstandingly good), and I’ve found myself sticking on this issue of a “good programmer” and what being able to write good code means. When I read, I agree on the “bad” programmer, management, etc. counts - but I don’t think that understanding those problems automatically makes one a quality coder, and I still wonder about where I legitimately lie on the spectrum.

See, the funny thing is that in the year that I’ve been doing team lead level work, I’ve actually been writing significantly less code than when I occupied a more junior position. I’m entrenched in a lot of “legacy” - not just code, but systems, processes, etc, and it’s actually been a great fit for developing my skills and confidence, especially with the full support of our boss to rip out all legacy and start making improvements. Unfortunately, the system-level improvements need to be ironed out before the code can be, and so goes my focus. I’ve also being doing a good amount of front-end development on top of all this legacy cleanup, but still very little backend work.

Anyhow, this week my frontend work required that I write a simple CGI script from scratch. A really easy coding task, but when I was only about 10 lines in, my good friend Paralysis spoke up: “This can’t be the best way to do this.” Which, for a short moment, stopped me completely in my tracks.

Here’s how this ties back to my internal discussions while reading Code Anthem: descriptively, I should be a good coder; I’m interested in implementing best practices and I generally loathe the “Let’s just get it working” tactic. I have had experience with the coders that Amber mentions - the ones that crank something out quickly sans documentation and leave the pain of maintenance and making sense of everything to the poor suckers that come after them. I’ve been in environments where the “get it working, fast” attitude is rewarded and it’s driven me crazy. But I feel like what I have to offer as a contrast - a strong and inflexible orientation towards quality - can be equally problematic in the most extreme of circumstances.

Without a doubt, the phenomenon of Paralysis has a lot to do with confidence (or lack thereof: fear of criticism). My own gauge of quality works in antagonistic concert with my fear of coming under the scrutiny of others’ standards. Confidence isn’t the only contributor though - a lot of this has to do with simply being realistic and self-aware - knowing that one’s knowledge probably isn’t deep or wide enough to come up with the best solution for any particular programming problem in a finite period of time. Another contributor to Paralysis is empathy: being so acquainted with the pain of maintaining bad code, I cringe at the thought of contributing something that might add to the long-problem in any way, even if it adequately resolves a short-term problem.

Paralysis ruled my first two years in industry. I could tell that my superiors (at least in my first job) didn’t think I was a bad programmer, but they also didn’t understand why I couldn’t get anything done. To my credit, I had a pathetically small amount of mentoring and training for a job I wasn’t qualified for on paper at the time (note: hiring college grads in CS because they are smart - even if they immediately lack the practical parts of the skillset - is admirable, but only if you plan on taking the time to train and mentor those grads once they’ve been hired on - otherwise they’ll flounder for a lot longer than is necessary). But the other major contributor to my lack of productivity was my pathetic dearth of confidence combined with a knowledge that what I was doing wasn’t going to be “the best”.

In the last two years I’ve been able to crawl out of the Paralysis hole a bit. The key is jumping in and writing something and getting it to work - and then refactoring and fixing it up immediately, if you aren’t already doing it as you go. Then clean up and amend the documentation (which I always write excessive amounts of as part of my code, but not in the most organized ways.) This is completely different from the coders who get their first solution working and then move on to the next problem, with a horde of maintenance issues just waiting in the wings. But taking that plunge into “just start writing!” can still be so difficult! In the day I spent on this script, I felt like I spent a couple hours standing on the ledge, looking down at the problem, convinced that whatever I was going to write was going to suck. Then I took the plunge, and big surprise, the fixes came to me as I was writing. As a result, the code I had at the end of the day wasn’t perfect, but it was a lot better and more tightly written than what I had imagined it would be at the start of the day.

I have a coworker who deals with his own version of this, and being an third party to his own paralysis struggle has been really insightful. It’s often really obvious to me when he’s sweating the small stuff, and I can apply this back to the times where I’ve been doing it myself. Learning to distinguish between the problems that do deserve my perfectionist’s hand and those where I’d be better off just applying a band-aid has been really beneficial, even if applying the band-aid is never optimal. At some point, a less-than-ideal solution is preferrable to spending infinite time scheming over the perfect solution and, as a result, never producing anything.

That balance is still really hard to find, though. I think learning to manage the Paralysis beast is going to be one of the struggles of my working life, but it’s also an area where I’ve made definite progress. In my current workplace it bites me for two reasons: 1) I work for a Perl shop and think in a far more verbose way than Perl is usually intended; as a result, I know almost everything I write can probably be expressed more tersely and (arguably) elegantly than initially comes to mind; and 2) Our process hasn’t evolved enough to support code reviews (which I love), so it’s harder to drop “I know this can be expressed more tersely” when I know that my code may not be viewed by anybody else for awhile. The pressure I put on myself to get it right on the first try is a lot higher.

To a degree, though, working with a lot of legacy code has been really good for coping with Paralysis. Whatever I replace with my own stuff, however imperfect, is still a vast improvement on what was there before, and this has allowed me to spend less time worrying and more time producing. But I still find myself a bit stuck whenever I’m writing something completely new (like I did this week), or I’m making fixes on a large enough level that I have to sit back and make some serious design decisions before moving forward.

In general, I think the humility, self-awareness, and perfectionism that guide Paralysis are qualities that manifest themselves in some degree (perhaps using less loaded descriptive terms) in the mythical “good programmer”. But the mythical “good programmer” is able to utilize the best of these qualities while keeping the negative aspects in check, and is able to move forward on a problem after the proper amount of consideration and at the proper time. That’s something I’m still working on, but it’s heartening to see that I’m doing a lot better than I was at this point a few years ago.

This post is intended as a one-off that ties up some of the things I’ve been thinking about over the past week semi-nicely (although certainly not conclusively or totally coherently!).  I thought I’d think it out loud for a few paragraphs.

My weekly catharsis for over a year now has been Baby Ketten Karaoke, which presently hosts a karaoke evening on Tuesdays at Mississippi Pizza and Wednesdays at The Woods (both in Portland, Oregon). This week I had the privilege to sing the KJ’s (Karaoke Jockey’s) daughter’s debut track, for Fever Ray’s “Triangle Walks”. The girl who put together this track is only eight, and already cooler than most people I know. Post-singing, I was talking to her dad about the cute visual effects she’d added to the track, and he mentioned how she’d suggest something crazy to him for it, he’d say “No, that’s not realistic”, and then after a few moments realize it was doable. And what a refreshing take to have on the process, to have a kid with no sense of the boundaries to stop her creatively.

It reminded me of a conversation I had quite often in the year or so surrounding my graduation from college and entry into the workforce, specifically with recruiter-types from Google. The idea in hiring good developers is that you want to hire for talent over experience (and I agree with this premise; Code Anthem’s recent post How to Find Crappy Programmers really drove that home just this weekend). I was really good at injecting my insecurity into a lot of my discussions about future jobs back then, to the degree where I got used to the “we value talent over experience” sound bite as a response. The touted perks of the talented but inexperienced developer were similar to that of my KJ’s daughter - that they (although I hate the term) “think outside the box” and will be creative in certain ways simply because, by being inexperienced, they can’t conceive of the limitations in any given project, and in that occasionally blooms magic.

I’d hear this explanation of the value of the talented and inexperienced, which I knew to some degree was being provided as a reassurance of my own potential as a developer, and yet I knew this was firmly not the case for me. I prematurely plunged myself into the world of adult realism and all the depressing limitations that come with it as a high schooler, most likely as a result of a teenaged romance with someone far more disciplined and achievement-oriented than myself (and that was saying something - as a couple, we were old and boring before our time). That romance, and my observations of the world tending to end up on the cynical side of things more often than not, quickly sucked the room for play out of my life, with regards to all of my creative interests - not just programming. (Many adults who knew me as a child would have said back then that my future was in creative writing. Since age fifteen the idea of writing fiction for fun hits an immediate mental block. It’s laughable! Classic creativity sap of adulthood!) I was aware of how quickly and suddenly it disappeared for me (adolescence is good for that), and have spent the last ten years or so trying to reclaim bits of that ambition towards creativity that flies in the face of the boundaries of reality. (It should be mentioned that karaoke nights have been great for this too - I’m surrounded by dreamers and creative types who may be poorer and less gainfully employed than me but provide a world of inspiration and insight.)

I speak of this in terms of creativity because programming - especially on one’s own time - is such a creative outlet. I could tell that I lost that “spark” for creative work long before I became a self-identified programmer, but the lack of that push to create simply for the sake of creating has been most glaringly obvious in my programming work. For years I haven’t bothered to jump into a project because “surely someone’s already done it, and better than I could.” I quickly learned that such timidity doesn’t just hurt me creatively, but it also hurts me professionally, because being firmly oriented in the reality of one’s abilities (”someone else could easily do this far better than me”) has a paralyzing effect that impacts overall productivity far worse than “reinventing the wheel”. I’ve had many programmer friends who I have admired for not facing this mental boundary, and I’ve tried to tap into their minds to understand why they aren’t held back in the same way I am.

I think I’m making progress. My mental queue of personal projects is growing, and I’m happy to feed it, even when I know that half of what I’m doing has been the personal project of countless others. I can find justification for “re-inventing the wheel” on these projects lately because (1) the project will help me develop my skills far more than extending a pre-existing product and (2) a product written by me molds perfectly to my own functional requirements. I also think I’ll have less reticence about sharing these projects with the public: although the Internet can be the source of incredibly toxic feedback, I’ve actually been surprised at the niches one can inadverently fill (like finding one of my own posts when doing a Google query on Virtualbox recently).

I’m a far cry from the sense of infinite magic that programming presented itself as when I first ran into it at around age 12, though. I became aware of the learning curve ahead of me pretty quickly, which fizzled out the sense of potential almost as soon as it had appeared. Being keenly aware of the world around me has been an incredibly helpful personal strength, but in terms of jumping into new things with abandon, my sense of the big picture has been paralyzing. Tonight’s conversation with the KJ reinforced the need to reacquaint myself with that sense of magic. Even if most of what I do is a repeat, niche knowledge introduces itself in the most unpredictable of places.

I write this mostly with the people like me in mind; those of us who feel paralyzed by a network of self-constructed boundaries. Sure, many of these boundaries have a basis in reality, and the viciousness of the Internet does a good job of reinforcing, and then skewing, our doubts. But paralysis only hurts us. As my KJ’s daughter reminded him, our perceptions of what is realistic are really just that - our perceptions - and not fact. For those of us held back by our own restraints, may we continue to challenge those self-imposed boundaries and discover the true scope of our potential.

/end ramble!

Funny: I mention a post from Code Anthem in this entry; after writing, I went to said blog and discovered today’s entry: Old Programmers vs Young Programmers. Very ironic given that this post was about how I lack the supposed key trait of a young programmer