Magazine article Computers in Libraries

Fighting through Whatever Blocks You: If You're Taking on a Technical Task and Find Yourself Stuck, Here Are Some Positive Approaches You Can Try to Get Yourself Unblocked

Magazine article Computers in Libraries

Fighting through Whatever Blocks You: If You're Taking on a Technical Task and Find Yourself Stuck, Here Are Some Positive Approaches You Can Try to Get Yourself Unblocked

Article excerpt

A year ago in this column, I wrote about an old web application of mine, "unalog," that I'd started to rewrite but at that time had failed to complete. It's a year later, and it still isn't done. The site I ran with it is still down. The handful of people I considered my best users have all moved on. Its whole product niche, "social bookmarking," is nearly forgotten at this point, with Twitter and Facebook filling in the link-sharing function unalog provided as its primary feature. Last year I wrote about how I was stuck in the middle of that rewrite, why software rewrites are usually a bad idea, and how when you think it'll take a few hours it'll really take a day, or if you think it'll take a day it'll really take a week. I joked that I needed "just 1 more month, tops" to finish it all up.

Apparently, if you think it'll take "just 1 month," it really takes a year. In the past few weeks I've finally revived and revved up my rewritten code and blasted through most of the mental blocks and tricky bits that were keeping me from finishing. I still hold that rewriting mature applications from scratch is usually a bad idea, but sometimes it pays off in the long run. Now that it's almost done, I realize how much I missed the application. Having it running here on my desktop makes me glad I stuck with it, and it's encouraging me to finish and to get it deployed soon.

Confidence and Blocks

You know what the best thing about finishing this project up is, though? The rush of confidence I'm getting now that I can see the finish line is awesome. It's embarrassing as heck that it took me so long, that the site has been down so long, and that it ever went down in the first place. But in a few days (well, probably a week or two!) it'll be back up and running, and that will feel great. A monkey off my back. A burden put down. A load taken away. A fun and useful application I can use again.

A big stumbling block blasted into little bits!

The idea of "blocks" is something of an obsession for me. I've met or worked with many librarians who want to know more about the technical side of our work but for one reason or another haven't learned as much as they want to learn. I must've met hundreds of people who've said to me, "I really want to get involved in the code, but I just don't know where to start," or "Every time I try I just get blocked when it doesn't work, and I realize I must be missing some kind of magic knowledge you have."

I can tell you definitively that there is no magic knowledge. I used to think the experienced reference staff at my first job had magic knowledge, the way they could answer questions off the top of their heads, knew the intricacies of coaxing gems out of our mid-1990s-era search interfaces, and knew just which reference source to reach for and where it was on the shelf. Then I worked at the reference desk with them for a year, and I learned a lot of that same stuff. It was overwhelming at first, but I got the hang of it. I knew I'd never be as good as they were, but I could provide competent service, and I could always reach out to my colleagues for help with difficult questions. Once I had confidence in my ability, I started asking my colleagues less and less because I knew I could usually find the answers myself.

Learning to understand how software works well enough to make your own is similar. It might look daunting at first, but with friendly guidance, some experience, and the occasional call for help, you can learn a lot in just a few months. And when you start getting things working, you start building confidence. There's a problem that everybody has to work through first, though--a problem you don't run into when doing many other kind of library jobs. Computers and computer software have an infuriating way of not doing what you want them to do. We've all experienced that. It's that much worse when it's your own software, though. There are any number of things that can go wrong. …

Search by... Author
Show... All Results Primary Sources Peer-reviewed

Oops!

An unknown error has occurred. Please click the button below to reload the page. If the problem persists, please try again in a little while.