work – Page 4 – codefork.com

I’m Back

I’m way overdue for an update!

It’s been nearly a year since I wrote about returning to grad school. So what’s happened? Well, I didn’t finish my dissertation. It felt nice to work on my research project again, but after a few months, I fell into the same depressive slump. I don’t want to go into it here, but it should suffice to say that, for me, the various burdens of academic life far outweigh its advantages. Though it would have been wonderful to get the psychological closure of finishing my degree before moving on to other things, that just hasn’t been possible. So “ABD” I will have to be….

There have been a lot of other changes in my life as well. I’ve moved to West Philadelphia, one of the most remarkable places I have ever lived. I am also writing code again to earn a living. It is a full-time position, and so far, it’s pretty great. Life is good, for now, anyway.

Working on software again has been sparking a lot of thoughts I haven’t had the time or energy to blog about, but hopefully that will change.

Lessons Learned

After about 5 months, I’ve decided that it’s time to move on to another gig. I’ve learned a few things, and I’m posting them here in the hopes that the lessons might be helpful to other programmers and techies-at-large.

Working in a small business as the sole do-it-all technology person has its unique challenges. It can be very fulfilling to be the sole expert and “enabler,” if that turns you on. But the flip side is that management might not really understand or care that much about their technology. Is there a reasonable budget for what they’re trying to accomplish? Do they understand, at a high level, your projects and how they contribute to the mission? Are technology projects considered a burdensome mystery or something valuable and embraced by the company? Question the reasons why there’s only one tech guy/girl and whether that seems right.

Another thing to assess is whether you can deal with taking over the existing codebase. I’ve taken over other code before with success, retaining what was good and doing clean up as necessary. At this past gig, things looked reasonably tidy at a first glance, but as time progressed, I realized a ton of abstractions weren’t in place, and those that did exist didn’t make sense. Some refactoring might have been interesting to do, but this endeavor wasn’t valued when I proposed it as a project.

Lastly, I think it’s important to be wary of promises about the future. Even with the best of intentions, things change quickly at small businesses. The projects I was initially excited about got perpetually deferred for various reasons, and I found myself preoccupied with doing maintenance code fixes, making cosmetic tweaks, performing server administration, and providing support for third party software (which I really don’t like to do). The company needed these things done, so I did them with as much cheer as I could muster, hoping we’d eventually get to a place where some solid new development could occur (and I could sneak in some refactoring)—that’s what floats my boat. But it became to clear to me that wasn’t going to happen anytime soon.

So that’s that. It’s a shame it didn’t work out, especially since I actually liked everyone I worked with. At least it’s an amicable departure, and I hope to be involved in hiring a replacement who might be a better fit for their current needs than I am.

The new gig? Java. Been catching up on it, since it’s been a few years. Oh, it feels so nice to have package namespaces, real data types, full-featured APIs, and real object-orientedness again. Like coming home.

The Small Business Subconscious

Small businesses can be challenging places to work. You often have to make do with few resources, play several roles at once, and be flexible enough to deal with loose/nonexistent company organization. If everything magically clicks, as it sometimes does, it can be a beautiful thing. But more often than not, that simply doesn’t happen.

As I talked about this with friends who have had similar experiences, they observed that there’s often a common mistake made in small businesses: since every employee is precious, the organization tries to extract as much value as possible by encouraging everyone to contribute in as many ways as possible. It bills itself as a democracy, as an environment that genuinely listens to its employees.

The problem, of course, is that when people aren’t in sync about the mission, or about specific project goals, you end up with a frustrating mess of conflicting directions. The business (somewhat desperately?) tries to latch onto everything at once, and there’s a lack of decisiveness in moving forward. Projects get fragmented. People believe they’re collaborating but they’re actually not. Confusion ensues. Little gets done.

Leadership is even more key in small businesses than in larger ones, I’d wager. Because if you have few resources, you need to choose your projects very carefully, dedicate resources accordingly, and make absolutely sure they go to completion quickly. There’s not much room for failure. But instead, small businesses seem prone to being wishy-washy. The insidious and tragic aspect of this is that when projects move at a snail’s pace or even fail, the accountability falls back on the individuals. Because management failed to lead, it can remain blame-free. It’s a formula for endless frustration.

In this unfortunate strategy, the small business is structured like the subconscious and its conflicts. Its desire is vague and repressed, and though seemingly absent, it’s actually very much the motive force for its existence. Like a human being, the small business can’t decide upon its identity, which remains in flux. And just like a human being, this repressed desire can lash out violently when it isn’t fulfilled.

Amateur thoughts and ambitions

One of the better things I’ve stumbled across this past year is Larry Lessig’s talk, How creativity is being strangled by the law.

The piece makes his usual argument that copyright law stifles innovation in the age of new media. Most striking to me, though, was the part where he uses the phrase “amateur culture.” He explains, “…I don’t mean amateurish culture, I mean culture where people produce for the love of what they’re doing and not for the money.” He uses the term to describe the activity of “kids” (?) creating their own remixes from existing media.

I can remember another amateur culture that’s now largely disappeared. Back in my teens, modem-based bulletin board systems (BBSes) fostered a rich “read-write” culture for amateur programmers. Most of us did not work in technology; after all, the commercial Internet hadn’t been born yet, so the computing industry was much smaller and more obscure. A career as a programmer seemed like a mysterious and rarefied thing to me back then. The coders you met on BBSes were often people who simply liked to do programming in their spare time.

These systems allowed us to circulate public domain source code for fun games and useful applications written in BASIC, Pascal, C, even assembler. We hacked on existing code to get it to do what we wanted, trying to figure out ways to push the limits of our little 8086 processors and 640K of RAM. We mingled regardless of our level of knowledge, beginners and experts alike. We had friendly user meetings in diners in Brooklyn and Manhattan (I lived in NY at the time), where we chatted about home-grown upgrades and discussed how to link up to the nation-wide discussion networks that existed then.

It was amateur culture at its best: lots of exchange, circulation, and cooperation happened all the time. But it was definitely not amateurish. Many were extremely capable and knowledgeable coders.

Today, there are still people who code just because they enjoy it, but the amateur culture and its community hardly exist anymore. Beginners on web forums are more interested in what they need to know in order to land a job, rather than in coding itself. Even open source projects tend to be dominated by career professionals; read any public mailing list and you’ll see how unhelpful they often are to amateurs who want to get involved. One reason I like python is that the project makes a genuine effort to connect to the sensibilities of amateurs. But even its forums are littered with snarky individuals.

All of this is largely due, I think, to the ideology of professionalism, which convinces us that having a stable career is the pinnacle of achievement. It damagingly equates amateurs with dilettantes. That’s why one of the first things we ask in this country when meeting a stranger is, “So what do you do?” By which we really mean, “Tell me what you do for a living so I can know who you are and whether you’re worth talking to.”

In 2008, I resolve to be more wary of this ideology and its negative effects. I want to embrace being an amateur in the various things that I do. I want to think less about careers and focus more on how to best spend my time doing what’s important to me. And I want to find more amateurs to hang out with as well.

Thoughts at the Beginning of Something New (well, sort of new)

A few months ago, I decided not to finish my PhD in literature, and instead return to my prior career as a programmer. It was a huge decision. Since then, I’ve been freelancing and job hunting, with varying degrees of effort and success.

My biggest concern was to avoid repeating my experiences in the Bay Area dot-coms. Ah, those days of youthful innocence! Back then, getting paid to write code seemed like the most incredible thing ever. What more could you want? Needless to say, I burnt out quickly. The industry and people were insane, code quality was subordinate to unreasonable deadlines, and most important of all, I didn’t feel invested in the project ideas I worked on.

I’ve learned that mission is very important to me. It’s why I’ve enjoyed grad school and and teaching, and why I’ve been good at them: I could get behind what I was doing. When I left, it was because I decided the profession and the current market weren’t right for me, not because I stopped believing in education, literature, and critical thinking.

So this time around, I’ve sent out resumes very selectively. Sadly, finding interesting companies was harder than I expected. And the companies I did want to work for had stringent requirements for certain credentials. Over time, my standards fell. I interviewed at a company working on mobile phone and web integration, and they made me an attractive offer. Though it wasn’t perfect, there were many good things about it, and I could see myself there for the next few years.

Then I got an email out of the blue. A friend had mentioned me to Crosscut, “a guide to local and Northwest news, a place to report and discuss local news, and a platform for new tools to convey local news.” They’re a group of established journalists thinking creatively about using the web while maintaining high standards of quality for regional coverage. Wow, I thought. New technology + socially important writing. Cool.

I’ll be starting a part-time position there next week.

Oh, there are aspects of the job that could be better. But it felt right to sign on to a project that I thought was worthy and important, even if I’m not making an insanely high salary or using the absolute coolest technology (read: python). How serendipitous that Giles Bowkett (whose blog I read regularly) should write today about “The Job I Want Next“: “Alternating between work and art was a mistake. I want to address my artistic interests in a consistent, dedicated way, and that includes programming.”

I’d like to keep as many of my interests consistently in my life as well, instead of jumping back and forth. It’s a good way to guarantee waking up each morning excited about the day. Sadly, it’s not easy to achieve. But I feel like I’m getting a little bit closer to it.