Addendums

I’ll be honest - I don’t read a lot of tech blogs. I’m not big on the newest gadget, I still don’t know how i feel about the DailyWTF, and I have very little interest in the day-to-day activities of big-name tech companies. Too many tech blogs exude a lot of the elitism and machismo that make me feel more like an alien in tech culture than a participant. There are some exceptions to this that I’d like to read more, like the excellent Silcon Florist, which follows the Portland tech industry. But as I’m just starting to engage myself with building and strengthening the Portland tech community on a business level, I revisit it less than I should.

There are a couple tech blogs that really draw me in, though, and I love them because reading them makes me feel strongly in alignment with my identity as a technologist. These blogs can be especially helpful to read on days where I need to write some code and can’t get my head in the right space, or the (blessedly infrequent, lately) times where I can’t remember why I ever liked programming in the first place.

I covered the first amazing tech blog, Geek Feminism, in this post, and I think I’ve linked back to it in almost every entry I’ve written since then.

The newest blog to earn my endless praise is Code Anthem.

I actually found Code Anthem through Geek Feminism. GF wrote a small entry on why requiring open source contributions from a job candidate can be sexist, with a post from Code Anthem as the starter material for the discussion: “Don’t Judge a Developer By Open Source”. This topic really interests me - because I’m interested in the open source ethos, increasingly use open source technologies, and have an interest in open source development - but the environment still seems incredibly hostile to me, with a high barrier to entry. As a result, I am still in the “incubation” stage of doing open source work, and it sucks to know that I could be falsely written off as a crappy coder because of my lack of involvement thus far.

The Open Source post led me to Code Anthem’s How to Hire Crappy Programmers, and since reading that post I’ve been hooked.

See, here’s why Code Anthem is awesome: since I started working in industry, I’ve felt like there’s an odd mismatch between the way most companies hire developers and the way developers actually evaluate their own skillsets and otherwise behave. When I was in college, trying to port the skills I was learning while acquiring my Bachelor’s in Computer Science to the job postings that appeared on our department mailing list was basically impossible. What was especially shocking to me about most of these companies submitting the postings was that the way they were trying to market themselves to applicants made me, as a programmer, not want to work with them. Even though I’ve struggled with confidence throughout my lifetime as a programmer, I also know enough about my own smarts to see these job postings and say “if this is the blunt hammer they’re going to apply to resume screening, they’re probably going to filter out a lot of decent applicants (like myself).” Unfortunately, this seems to be what 98% of job postings, at least in Oregon, look like. I’ve ended up coping with this weird reality in two ways: one, I’ve gotten comfortable applying for jobs where I’m not qualified “on paper”, because I’ve come to accept that hardly anybody else applying for these positions can be, either. Two, I’ve written this all off as a symptom of an immature industry that has adopted a stupid standard practice because it hasn’t been around long enough to have an actual tested and established best practice in place.

What a treat to see the How to Hire Crappy Programmers post addressing just this issue. And to see the wide-ranging consensus in the comments! I especially loved the folks who reported on the job postings that require x number of years in a technology that has existed for less than x years. This stuff really happens, and I’ve honestly been surprised to not see anybody ranting about it until the comments section of that entry.

With that personal introduction out of the way, Code Anthem is all about this issue of programming talent and how we evaluate it. How do we hire for it? What is a programmer worth? How can companies effectively market themselves to good programmers, and in turn, how can they (fairly) determine that applicants are indeed qualified? These are really difficult questions precisely because we’re in such an immature industry, but also because this industry is rife with really unique challenges that really complicate the evaluation of an excellent coder (for instance, I’m in the camp that an excellent coder who’s also an asshole isn’t actually an excellent coder, because they can’t work with people - others would disagree).

To my knowledge, Joel on Software has been the go-to for this kind of input in the past, but I ran into a problem a few years ago when reading Joel while doing interview training at Google. His writing seemed thoroughly immersed in programming culture as it currently exists and not programming culture as it could / should be (to start out with, more diverse), and as a result a lot of what I read seemed incredibly male-centric and elitist. I consider myself a conscientious and hopefully constantly-improving programmer - I at least bring some unique strengths to my position - but I didn’t think Joel was talking about people like me when he spoke about good programmers (not just in terms of skillset, but also the social experiences that color one’s identity as a programmer). So I take a lot of his advice with a grain of salt - I think it’s really solid, but a lot of the time I wonder if it’s also perpetuating a lot of what’s wrong with the technological community, not in terms of code quality but in terms of social dynamics and diversity - and those latter two do have an ultimate impact on code and product quality.

I’ll admit some of my preference for Code Anthem is probably based on sharing the same gender identity as Amber, its author. I immediately don’t feel left out of the conversation if the person starting this discussion is a woman - because I know (and she has proven, with the open source post and others) that she’s considering a lot of the nuances which men / privileged groups in the field often overlook or don’t have to think about. This doesn’t seem to be to the detriment of the men reading the blog, either, so in my book everybody wins. Gender dynamics aside, I feel like Code Anthem is different “in a good way” because the blog focuses on the infrastructure / ecosystem of the tech industry as the source of poor-quality work more than the programmers themselves. Most of what I’ve read before this has focused disproportionately on the poor-quality programmers. Sure, bad coders are part of the puzzle here, but focusing solely on them won’t solve the overl

The hyper-focus on bad programmers is problematic in a couple of ways. First, a subset of good coders will read these entries and falsely evaluate themselves as a “bad coder” - simply due to their personalities or social conditioning (read: a lot of women). I know I struggle with Impostor Syndrome and until I became lead on my current team I wondered if I was a “bad coder” myself anytime I read a post lamenting their existence. Then there’s the second problem: the “bad coders” themselves don’t realize that they’re bad. They read along with these posts about bad coders and associate themselves with the “good coders’” group and therefore take none of the content to heart (see the Dunning-Kruger effect.) So in my mind, it’s time to stop focusing on the issue of bad coders and instead focus on the entire ecosystem. Code Anthem keeps doing this, entry after entry, and I can tell I love it because I then want to pass on / retweet each and every entry, to technologists and non-technologists alike.

Here are a few posts that I’ve read in the last few days and finally inspired me to post here. I swear, every entry in this blog is rock-solid and addresses one of these tricky ecosystem issues that really merit more attention.

Take a peek at:

Death By Recruiters - why recruiters are generally bad for industry

How to Get a (Programmer) Job In This Economy - I actually went through almost exactly this same thing two years ago, at the start of the recession

Just Technical Enough to Be Dangerous - how to handle the people who over-evaluate their skills and do risky things because of it (been there)

256x Better than a Resume - the reasons why the standard criteria provided by resumes aren’t beneficial for finding good programmers, and some exploration of, “Well, what’s the good criteria, then?” I agree on the “programmer test” route as part of the solution even though the idea of having to draft one up for my own company at some point petrifies me.

Go read! I love Code Anthem because I am passionate seeing these inefficiencies in industry go away. They make the entire practice of hiring and evaluating programmers a lot more painful and unwelcoming than it needs to be. It’s great to see a blog that’s also calling these things out for the crap they are, and discussing good alternatives. The more this discussion is disseminated, the better for any programmer who wants to see a difference.

My ability to get a technical blog going has been hampered by my inability to stick to any habit lately; it’s something that I’m working on, but I think the trickiest thing is identifying the habit I want to train myself into that’s the biggest priority (the queue is about 20+ “new habits to adopt” long). Try to do too many at once and you’re doomed to fail.

Tumult in my work and personal life has of course added to my inability to focus technically. In particular, I haven’t been doing a lot of coding since I last posted (in May). Instead, I’ve been doing a lot of internationalization work on a very nuts-and-bolts level; climbing full-bore into the creepy abyss that is the overlap between sys work and developer work; taking on the interpersonal drama that is characteristic to any developing job but rarely makes its way into the job description.

I’d like to say I have some interesting insights on internationalization work or on adapting a git-based deploy infrastructure to a multi-system scale, but as I’m still mucking about I don’t think my thoughts are all there.

I’ve hardly written code in the last few months, let alone this year at all, which probably has a lot to do with my enthusiasm for tech being so unfocused. I finally had the opportunity to crack into some Perl code this weekend, which - it being Perl - only reminded me of how quickly my mood can plummet from 100 to zero looking at the stuff. I’d like to overcome the gag reflex, though, so I’ve tried to persist - currently reading the “Symbol Tables and Typeglobs” entry in Mastering Perl, and digging around a bit in Perl Design Patterns.

Right now, my biggest issue with using object-oriented design patterns in Perl is how ugly the implementation is in comparison to other OO languages (it doesn’t help that Perl is an OO language as an add-on). I’m finding that grasping these concepts requires digging into additional advanced concepts that can be really daunting. I understand that the point of design patterns is for code readability / maintainability, but if advanced Perl mastery is required to make sense of code that uses these patterns, then only those initiated to such practices will actually find the code readable. At work, only a small portion of our code base uses some of these concepts, so my hope is to augment this code with comments directing our developers to the documentation where these concepts are covered. In a world where we all have pre-existing advanced knowledge, leaving notes like “the concept being used here is x” is probably redundant, but that seems to be unrealistic. Finding a happy medium between elegant code and clues for those who don’t yet grasp the voodoo seems to be an important, albeit tricky, step.

Socially, recently, the big tech community events have been:

• Open Source Bridge in June - met and interacted with tech friends old and new; delighted myself by discovering that I actually found a lot of the tech talks super interesting, not just the social ones (until now, I don’t think I had enough of a technical foundation in industry to take on a new topic out of the blue). I also happened to meet our newest dev hire at work for OS Bridge, and so it’s been beneficial on a workplace level too.
• I presented at Code N Splode for the first time in August - on puzzles, coding competitions, and puzzle hunting - the edges of the geek world that have drawn me more than free-time coding projects (although I’d like to do more of those).
• I competed with three other local programmers (Maria, Reid, and Igal) in the Playdash event, a puzzle hunt put on by now-local puzzlehunting aficionados Team Snout. Looking forward to seeing Portland become a puzzlehunting city.

Now that I feel like I’ve caught up a bit - hopefully I’ll try to get back into the habit by throwing out some small bits and pieces - in particular, “RTing” things that I’ve found interesting on other tech blogs, on the days I happen to stumble upon them.

In the meantime, I have unpublished my long rambling post from post-barcamp, mostly because I was embarassed at how long and rambling it was.  I am aiming to be more like the fantastic female tech bloggers I get to see online every day, and they’re pretty good with saying it right concisely.