Saturday, August 30, 2014

Play with the big kids. End.

Graduation Caps by John Walker
This blog was started as part of a digital history class I took back in 2007. In the 7 years since I set it up, I've completed a masters degree in public history at the University of Western Ontario, and have handed in my PhD in history at King's College London.

I am one of a very early group of academics for which our scholarly development is plain to see for future readers. For the rest of my life, my students will be able to go back and read what I thought when I was a masters or PhD student. That's never really happened before. I have no idea what my PhD supervisor was like when he was a student, because his experience was ephemeral and distinctly offline.

On Monday I'll be starting a new chapter, as a lecturer of digital history at the University of Hertfordshire. I'm very grateful for the opportunity and looking forward to it immensely. Since my graduate student days are now at an end, I think it is fitting that I close this blog today, and leave it where it can act as a record to those future students who feel so inclined to see how much brighter they are than I.

But before I go, and because I'm one of the lucky ones who has found my way into an academic job, I thought I'd reflect on the one thing I learned about succeeding as a postgraduate student:

Don't forget to play with the big kids.

All of the people I worried about when I was applying for jobs (the ones I was pretty sure were better than me), were the ones I saw confidently drinking a pint in the midst of a group of senior academics at the pub. The ones sitting at the table of fellow students didn't concern me.

Fellow students can be a great source of friendships. Perhaps even life-long friendships. It's wonderful to make friends your age and I would encourage everyone to do it. But in the short term, there's only so much career advice they can offer.

The student laughing and telling stories in the middle of a group of seniors academics is learning how the academy works from the inside. He or she is picking up tips, learning what selection panels, peer reviewers, editors, examiners, and audience members are looking for. He or she is making connections with scholars at a range of schools who may become collaborators, or who may think of them when a promising student down the line is looking for a supervisor. They'll come to mind when a chapter in an edited collection needs writing, or a third speaker is needed for a panel. They'll have many experienced people to turn to that they can ask: 'would you mind reading this over and giving me your thoughts?' Or: 'What do you know about department X's teaching needs?' And they too are building friendships. Perhaps even life-long friendships.

Those relationships are not merely parasitic. They go both ways. The senior academics too learn from the student, who brings new ideas to the field, or renewed enthusiasm for old ideas. They can challenge the senior scholar to keep up to date with new methods, or to work together on projects of mutual interest. And they too are building friendships. Perhaps even life-long friendships.

Just a few days into my MA programme back in 2007, a man I'd never met named Roy Rosenzweig passed away. He had been the director of the Center for History & New Media at George Mason University. I first heard of Roy through a very thoughtful obituary written by Dan Cohen. In it, Dan commented on Roy's ability to bring people together:

I know of no one with as large an address book and as many friends as Roy. But he didn’t just collect these acquaintances superficially, for show or for his own career ends like so many people do on Facebook or LinkedIn. As his social histories of the United States also emphasize, he viewed every human being as a special resource who brings unique talents and ideas into the world, and he liked nothing more than to connect people with each other.
You may not feel that you're the type who can connect others, but you owe it to yourself to build your address book and your circle of friends. Don't let a gap in age between you and those more experienced than you keep you apart. Meet lots of people. Whenever you can. Learn from them. Listen to them. Teach them a thing or two.

Most of them are willing to talk to you, and if they're not, they're probably just jerks.

You will always not yet know the right people. So next time you're at the pub after a seminar or conference, grab your pint, walk over to the big kids' table, and say confidently, 'So, what did you think of the speaker?'

It might just land you a job, and make new a new friend.

Good luck. And thanks to all my readers over the years. It's been fun growing with you.

Saturday, August 9, 2014

Learning Python with the Programming Historian

For those humanists out there looking to learn Python to aid your research processes, the Programming Historian has a great set of lessons to get you started. The lessons are designed to teach you Python by doing the types of tasks historians might want to do. So instead of learning about managing an inventory of widgets (as is common in intro-to-programming books) you learn how to manage a set of historical sources.

The Programming Historian used to make it more obvious that these lessons were originally written sequentially, so that readers could build upon their skills slowly. It's not quite so obvious anymore because of the new way we've organised our table of contents. But for those of you interested in learning Python, or using it with students, I thought it would be helpful to post their original order here so that you can easily find your way through them.

Happy learning.

Your First Lesson

Introduction to Python


You may also like to supplement your learning with other tutorials. I found Mark Lutz, 'Learning Python' (O'Reilly) very useful. My co-editor, Fred Gibbs, is a big fan of the Code Academy. Use whatever combination works for you. Good luck.

Wednesday, April 30, 2014

How to Solve Programming Problems if you're learning Programming

Things can and will go wrong when you first start dabbling in programming. As with all new skills, you are going to get frustrated. Here are a few tips that may help you work through the frustration and solve many of your own problems.


Language Learning

Do not forget you are effectively learning a new language, or even languages. You will not be fluent in twenty minutes. But you can expect to start building your skills to the point where you can complete simple tasks, progressing into more difficult situations. When you are presented with new code, it's important that you take the time to really understand it. If you whip through a tutorial or cut and paste code snippets you find online, you may end up with a program that runs, but you will not understand it, nor will you be able to generalize the skills and write your own programs. Once you've got something that works, try making a backup copy and then changing things in your code one at a time. If you can predict the effect that your changes will have, you have a good understanding of what is going on. When you are surprised by the effect of a change, you have an opportunity to learn something new. When you've got something that doesn't work, make a backup copy and then try eliminating things that you don't understand. What is the simplest version that you can get to work? Once you have that version, you can try adding in new code, one thing at a time.


Search Engines

If you run into difficulties when writing computer code the great news is that the answer to almost any problem can be found online. Computer programmers constantly seek and give help on forums and mailing lists, and the questions and subsequent answers are readily available. This means the Internet is usually your best resource for finding help. If you run into a problem, the first thing you should do is type your problem into a search engine. More often than not someone has already asked your exact question, and other people have provided a range of answers. You might even find entire websites dedicated to solving your particular problem. When you are just starting out, it is very unlikely that you will come across a problem that no one has encountered before. Likewise, if you encounter an error message that you don't understand, cut and paste that error message into a search engine and surround it with quotation marks. Typically you will find dozens of explanations for why this error appeared and how to fix it. The more specific that you can be about your problem, the better the results you will find. Don't be discouraged if you don’t find the answer on your first search. Rephrase the search terms and try again.



If you’ve Googled it, Yahoo’d it, and tried various combinations of teas, coffees and energy drinks to no avail, you're going to need to ask for help. There are many Internet forums and mailing lists to which you can turn. At the time of writing, my favourite forum for general programming questions is Stack Overflow. There is also Tutor, a mailing list where people who are learning Python can ask questions, and people who are interested in teaching Python can answer them. At any given time there are swarms of friendly, knowledgeable people just waiting to answer your question. If you post your problem in a courteous manner, with a little bit of luck you will have a solution within a couple of hours. Keep in mind that it is bad form to post a question in more than one place in quick succession. It may not be the instant gratification we’ve come to expect, but don't forget, these people are volunteering to help you, and most probably if you're desperate enough to ask for help, you could use a few hours away from the keyboard anyway. Go for a walk, take a nap, or do something else to clear your mind and some new ideas will come to you.


Asking Good Questions

Clarity and specificity are your friends when it comes to asking for help on a forum. The FAQ page on Stack Overflow's website is great reading for anyone looking to ask a question about programming online. Even if you do not use the Stack Overflow forums, the messages here are essential. Remember, the people who read forums and offer their expertise are busy; make it easy for them by carefully thinking out your problem before you ask. Likewise, make sure you are asking a specific question to a narrowly defined problem. For example, don’t post something like: "Why won't my code work?" Instead, try: "Why am I getting a syntax error when I try to Push a value into an Object?" Always post the relevant section of your code (and only the relevant section of your code) along with your question. If possible, remove any unnecessary bits that are not immediately relevant to the question to make it easier for experts to help you solve your problem. If the answer you get does not do the trick and you are still stuck, be polite and try rephrasing the question. Remember, don’t bite the hand that feeds you; these are volunteers and they’re trying to help you!



When fixing problem code, systematically change one thing at a time and retry your program after each change. Often if you make three or four changes before retrying the program, you will solve one issue, but cause another one. This is frustrating and confusing. By changing one thing at a time and making sure it works before moving on, you will prevent a lot of confusion. It also helps to make notes of the things that you have tried, and of the solution when you find one. The more time that you spend programming and debugging, the more familiar various kinds of errors will become.

This post was originally published as part of the Programming Historian, and was co-authored by William J. Turkel. It has been reposted here without permission because all work on the Programming Historian is licensed under a CC-BY license. Photo credit: Peter Alfred Hess

Saturday, January 18, 2014