• “I want to learn programming, which language should I learn?”
• “At what school / course can I participate to learn programming?”
• “Which book can you recommend if I want to learn programming?”

These questions are in my opinion very tough but I will try to give an answer. Even though a lot of what I will say is probably true for people like me who learned programming just by curiosity while being in high school or for people who wish to make a career in IT engineering I try to aim this article for people with a university degree who already have a certain knowledge of how to approach learning and want to have programming skills as an additional skill but not for their main living.
The outline of this article will be the following.

• Why do you want to learn programming? What I will assume about you.
• What does it mean to learn programming?
• What is really necessary in order to learn programming?
• Discussing various kind of languages for certain purposes.
• Your concrete road map.

Why do you want to learn programming? What I will assume about you.

I will assume that you do not want to learn programming because you want to change your major towards IT or that you are suddenly totally interested in programming, computers, nerds and geek talk. I will rather assume that you might be a linguist who realizes that statistical natural language processing might be useful. Or you are a biologist or psychologist and need to automate some work with your experimental data from the lab. You could also be a sociologist and want to do some experiments on the web or study how people behave on the web. Maybe you ended up in a company because jobs in your major are rare and you seek for an additional qualifications. You might have similar reasons but I guess you get the gist of the article.

What does it mean to learn programming? 

Being able to program is a somewhat weird skill. Those who are able to code know clearly what they can expect from another hacker. Yet I have the feeling that people who want to learn programming often have wrong expectations what programming means. So I will try to work on your expectation management.
Know to code is a skill that exists on various levels. Being a good programmer and acquiring programming skills that are really useful for you might be a long road and might require some effort (c.f. peter norvig’s “how to learn programming in 10 years?” ). Still I have to state (in a somewhat arrogant way) that the first step is very easy (at least in theory).
The first step would probably be to learn the syntax – which are the commands or instructions of a programming language. This is simple because programming languages usually have a very small syntax. Learning the syntax and playing around with it should seriously not take you more than a view hours in total. If you consider practice and repetitions this time will be distributed over a couple of days. This is what books with titles like “how to learn XXX in YYY days” which are heavily criticized by Norvig will teach you. The same can be learnt from online courses on http://www.codecademy.com/ The main problem here is that this skill – even though at core it is all you need – seems very useless to a beginner.
In particular once you have acquired this skill you will have the feeling to know as much as before. Compare it with having the force like a Jedi knight. You might feel it but you don’t know how to use those skills yet.
In my oppinion the main problem starts now. In order to make something meaningful with your new skill you will do much more that will distract you from using or learning that skill. You will become frustrated. You will find everything complicated and you most likely will often have the feeling that you don’t know why something does not work as explained and if it finally does you might also not know why it does so at this point.
Common pitfalls for distraction are:

• Interacting with an Integrated development environment.
• The same operator in a programming language might have a different semantics depending on the context.
• Interacting with a compiler or interpreter.
• (Most likely implicitly) interacting with the operating system
• Using third party API’s and libraries.
• Interacting with an editor that has its special properties
• Doing a typo with all the new syntax receiving error messages that are not telling you “hey you forgot a semicolon here…” but rather look like total chaos.

The problem is these things are almost not documented at all and are just assumed to be learnt implicitly or while talking to people or while being in a classroom. You might want to have a look at my German screen cast where I explain how to run “hello world in c“.

The program is the most basic program and and it involves almost no programming at all it just has all the overhead that was described above. Even though the screen cast is 20 minutes I still omit so much information that you might think: “Why the hell should I learn all about this?” The point I am trying to make is that it is all the other stuff that is complex.
Taking this in mind I sometimes wonder how anyone can learn programming at all anyway? The bad news is. Books won’t tell you all the differences most of the time they don’t even help you with setting up your developing environment so they leave you lost to learn a task which – again – at its core is actually pretty simple.
I would say a subset of being able to program is actually being aware of all these things and being able to distinguish what is happening at what point in time and not becoming confused by all this “magic”.
It already needs some experience to know all of this. The good news is. Once you master these things you know about everything you need in order to move on.

What is really necessary?

Even though you just want to program a little bit I think what will help you most is to bring curiosity about computers in general and the willingness to iterate, fail and play around. Don’t get frustrated if you seem to not understand anything anymore. Abstract and structured thinking is a very helpful skill which you probably bring along when you read this article and have been able to follow until here.
Most likely you will have to move out of your comfort zone. I remember learning 10 finger typing. In the beginning I thought chatting with friends is faster with my old system. I had to move out of my comfort zone to use the new skill and I had to use it in order to get used to it. The same will hold true for programming. In the beginning you might think that stuff from your day to day job go faster the way you have always done them. Take the challange. This time using programming might take longer. But over time it will save you a hack a lot of time.
But moving out of your comfort zone will mean that you have to be open to geek culture. Computer scientists are nerds and they celebrate it. I honestly learnt stuff about hacking from xkcd comics (or similar stuff).
Having courage to try out stuff and play around will be essential but still many people seem to confuse “try and error” with meaning full testing of “what happens actually if I …” (sorry that was so important I had to bold print it and I will repeat it later…). Read the fucking manual (or documentation – even though it is often missing and badly written) will be of tremendous help for you. What you have to learn is to ask as many questions as possible. A good practice is to write down the questions and explaining your problems. While doing so you will understand your problem better and most likely solve the problem on your own. (Ask questions even to this article. I am well aware of the fact, that this article leaves open questions. Go and ask me in the comments as an exercise. (NOW (:)) In general before asking questions googeling is a great idea. This of course is another way of asking questions. Honestly it is a skill to use a search engine. I have seen so many students which are not able to properly use a search engine to solve their problems. Fact is if you want to learn programming almost all questions that you have, have already been asked on the web and are indexed by a search engine. Being aware of this fact and learning to find those answers is a large portion of what you need to become a programmer.
Fiannly you will need a lot of paticence. The complexity of programming comes from the sheer amount of technologies that play together. It will be inevitably that you will be confused. Stay focused take a deep breadth start over again and try once more.

Discussing various kind of languages for certain purposes

There are various kinds of languages which serve a certain purpose. If you are coming from the outside world you will most likely know what language you want to learn. Honestly the syntax is almost the same all the time anyway. What is different are the libraries and APIs. When gaining more experience you will realize that you use tools to remember APIs and at some point in time you have a feeling of what functions already exist in some API and you probably can guess the name or at least google for it. What I am trying to say it doesn’t really matter which language you will take for learning how to program.
Still I think there are three languages that might be particular interesting candidates. All of these language have object oriented concepts. Even though I think object oriented programming is great and probably not so difficult for you. You could probably ignore the object oriented concepts.
c/c++: This language is great for people who want to focus on the understanding part of fundamental stuff and computers. It is certainly most difficult to learn and easy to mess up things. The level of frustration will be highest but the reward will be the biggest. I learnt programming with C first and from there on I could very easily move on to other languages.
Python: I think Python has a very beautiful syntax and it minimizes the distraction elements I wrote about so broadly. Especially for people who want to use programming as an additional skill python is very quick for solving smaller tasks with few overhead on the amount of code that you need. Also the standard API that comes with python is easy to use. Python can be used in the Web, in the shell. So it is probably a very nice compromise among all scripting languages.
Java: I would say Java is one of the widest spread languages. It has many strong concepts and especially a lot of tool chain around it. I did not find any other language that has so much code completion and tools to make your life easier. Still having tools thinking for you while you did not understand something is a difficult thing.
There are other languages and excellent reasons why you would want to learn them. The only language I would not recommend is java script. This language is a mess for various reasons. So unless you want to explicitly do user interfaces on the web I see almost no reason why a non IT person should learn javascript.

Your concrete road map

Let’s finally get concrete now. How to approach this project of learning to program:
10 relatively easy tips for the first week:

1. Choose a language
2. Install the IDE, compiler, toolchain, …
3. Do it the hard way. Install linux (e.g ubuntu), use a fancy editor like emacs or vim and go for a fancy tool chain or version control system like git. Not that you need it. But as I said it forces you out of your comfort zone and brings you in a hacking mindset. This is most important. Loosing the fear of shallow water within usage of computers. You need to loose your fear of technology.
4. Learn the syntax with some random book / course about how to learn programming or your selected language in 7 days. (Again the book could nowadays also be an online course)
5. Understand that most books are didactically very bad and don’t separate between concepts, APIs, operating systems and language specific parts. 
6. Use a cheat sheet for learning the syntax. Not in order to cheat all the time. But it helps you to distinguish between what is syntax and what is all the distracting overhead. just google for “c cheat sheet” or “java cheat sheet” or “python cheat sheet”.
7. Understand the syntax and remember it by heart.
8. Try not to read the examples and remember them by heart but try to reproduce them without looking at them. If you can’t read the chapter again and iterate.
9. Most important: While working through the book / course. Play around! If something worked start asking questions. What happens if I change code here. Try to answer the question and then try it out. Even try to break the code in order to see error messages from the compiler / interpreter. don’t get confused by naming try try try and try again. 
10. Understand the concept of variable scope – this can also be done best while playing around.

Once you are here and as I said you should not need to long. Go to the next level – The transfer / experience stage.

1. Ask yourself what is a task that you frequently do by hand (on a computer or elsewhere) which IT people might automate. Try to automate it.
2. Find some open source project. Look for bugtracker, mailinglist, or IRC channel. Go an contribute. Experience, experience experience. talk to the people. almost every IT person is happy if you try to solve their problems (which they just might not find the time to solve themselves). Tell the people you are a beginner. Chances are pretty high that people will help you out.
3. Learn blackboxing (after I learned programming with 12 and creating a large scale application with 22 I started to really dig into what computers and programming languages are 4 years ago. I understood many things down to the physical process. yet still most stuff I use is a blackbox to me. It is much less of a blackbox compared to 10 years ago but still most is a blackbox!) You cannot understand everything. Sometimes it is just enogh to know “hey if I enter print(‘a’); the letter a will be outputed to the terminal.” You don’t have to understand how system i/o (input and output) really works. it will be sufficient for you to be able to use it.
4. Understand what libraries and APIs are. Understand that some instructions and commands that first seem to be typical code (or syntax) of your language are just APIs that you should use as a black box. a typical example is the above mentioned hello world program.
5. To some degree understand what an operating system is, what its purpose are.
6. Have a concrete roadmap project. Nothing is more boring that a computer scientist telling you “hey I can automatically calculate square numbers…” I once wrote an blog article explaining with the python language how to find the most frequent words in books or the longest sentence and decide how long it is… (I admit this program was probably to complex for a beginner. but you could still try)  

Finnaly the hard parts

1. As with all learning tasks find a) a sparing partner and b) as early as possible teach the stuff to others.
2. Get a feeling on what is important to know while programming.
3. Listen to the fucking nerd. We sometimes might not communicate well (guess what: Communication is a two way thing. Chances are high you are not asking well ether and not communicating your needs in a good way) But most nerds will be very happy to help you out. They might assume you have too much knowledge which you do not have. If they do, stop them or slow them down. They might loose themselves in details. If they do, try to ask them if this is still relevant to the question and going towards the right direction. Do your job on good communication. Remember your talking to someone from a different subculture (:
4. Have clear questions and clear goals.

I wish you good luck and a lot of fun while acquiring your new skills. If this article was helpful for you or changed your life please tell me in 10 years or so what kind of amazing things you have built since then. Just put the mark in your calendar right now. You don’t use an electronic calender system yet? Ohhh, much to learn young Padawan (:

2011 April: Defining the research question

Wondering about possible research topics many people told me that running a social network like metalcon and seeing so much data would be like treasure for research questions. Even though at that time our goal was just to keep metalcon running in its current state I startet thinking about what research questions could be asked. For most questions we just did not collect good data. In this sense I realized if metalcon should really give rise to research questions I would have to reimplement big parts of it.
Since metalcon also had the problems of slow page loading times I decided to efficiently recode the project. I new that running metalcon on a graph data base like neo4j would be a good idea. That is why I started wondering about how to implement a newsfeed system efficiently in a scalable manner using a graph data base.
==> A research question was formulated.

2011 Mid August: Solution to the problem was

After 3 months of hard thinking and trying out different data base designs I had a meeting with my potential supervisor Prof. Dr. Steffen Staab. He would have loved to see some prelimenary results. While summing up everything for the meeting the solution or better said the idea of Graphity was suddenly clear before my eyes.
In late august I talked about the ideas in the oberseminar and I presented a poster at the european summer school of information retrieval. I wondered about where to submit this.
Steffen thought that the idea was pretty smart and could be published in a top journal like VLDB which he suggested me to choose. He said it would be my first scientific work and VLDB has a very short reviewing cycle of less than one month that could provide me fast feedback. A pieve of advice which I did not understand and also did not follow. Well, sometimes you have to learn the hard way…
Being confident about the quality of the index also due to Steffens positive feedback and plans for VLDB my plan was rather to submit to WWW conference. I thought social networks would be a relevant topic to this conference. Steffen agreed but pointed out that he was a program chair for that conference which would mean that submissions from his own institute would not be the best idea.
Even though graphity was not implemented or evaluated yet and no related work was read we decided that the paper should be submitted to SIGMOD conference. With an upcoming deadline of only 2 months later.
By the way having these results and starting this hard work gave me founding for 3 years starting in october 2012!

2011 november: Submission to sigmod

After two months of very hard work especially together with Jonas Kunze a physicist from metalcon from whom I really learnt a lot about setting up software and evaluation frameworks the paper was submitted to sigmod. Meanwhile I tried to get an overview of the related work (which at that time was kind of the hardest part) since I really did not know how to start and my research question came from a very practical and relevant usecase but did not emerge after reading many papers.
Anyway we finished our submission just in time together with all the experiments and a – I would still say decent – text about graphity. (you can have the final copy of the sigmod publication on request)

2011 middle of November: Blogpost with best content from the paper

I talked back to my now Supervisor Steffen and asked him what he thought about blogging the results of graphity already trying to get some awareness in the community. He was a little skeptical since blogs can not really be cited and the paper was not published yet. I argued that blogs are becoming more and more importent in research. I said even if a blogpost is not publication in the scientific sense it still is a form of publication and gains visability. Steffen agreed to test this out and I have to say the idea to do this was perfect. I put the core results on my blog received very positiv feedback from people working at linkedin, microsoft and other hackers. Also I realized that the problem was currently unpublished / unsolved and relevant to many people.
Interestingly one of my co-authors tried to persue me to publish the sigmod version of the paper as a technical report. I did not get the point of doing so (he said something like, then it is officially published and no one can steal the idea…” Up to today I don’t get the point of doing this other then manipulating ones official publication count…)

2012 February: Reject from Sigmod

After all the strong feedback on my blog and via mail the reviews from SIGMOD conference where quite disappointing. Every single reviewer highly valued the idea and the relevance of the problem. But they criticized the evaluation and the related work.

• For the evaluation they criticized that using a memory disk is manipulating and the distributing and scaling behaviour could not be seen by theoretical and emperical proves of some big O notations.
• As for the related work they where missing some papers especially from the data base community and as I said related work was definately one of the weaknesses of the paper.
• Other feedback was on our notation and naming for some baselines.

The most disappointing of all the feedback was the following quote:

W1: I cannot find any strong and novel technical contribution in their algorithms. Their proposed method is too simple and straightforward. It is simply an application of using doubly linked list to graph structures.

To give an answer to this at least once: Yes the algorithm is simple and only based on double linked lists. BUT it is in the best complexity class one can imagine for the problem it scales perfectly and this was prooven. How can one throw away an answer because it is too simple if it is the best possible answer? I sense that this is one of the biggest differences between a mathematician and computer scientist. In particular the same reviewer pointed out that the problem was relevant and important.
Having this feedback we came to the conclusion that the database community might have been the wrong community for the problem. Again we would have figured this out much faster if submitting to VLDB like Steffen had suggested.

2012 February: Resubmission to hypertext

Only 1 week away from the feedback was the submission for the hypertext conference. Since one week was not really much time we decided to not implement any of the feedback and just check what another community would say. My supervisor Steffen was not really convinced of this idea but we argued that the notification of hypertext conference was only one month later and this quick and aditional feedback might be of help.

2012 late march: Reject from Hypertext

The reviews from hypertext conference have been rather strange. One strong accept but the reviewer said he was not an expert in the field. One strong reject of a person that did not understand the correctness of our top k n way merge (which was not even core to the paper) and a borderline from one reviewer who really had some interesting comments on our terminology and the related work.
Overall the paper was accepted as a poster presentation and we decided that this was not sufficient for our work so we withdraw our submission.

2012 mai resubmission to socialcom

Discussions rose up which conference we should target now. We have been sure that the style of the evaluation was for sure nothing for the data base community. On the other hand graph data bases alone would not be sufficient for semantic conferences and social is such a hype right now that we really were not sure.
Steffen would have liked to submit the paper to ISWC since this is an important community for our institue. I suggested SocialCom since the core of our paper was really lying in social networking. All reviews so far have valued the problem as important and relevant for social networks and people basically liked the idea.
We tried to find related work for the used baselines and figured out that for our strongest baseline we could not find any related work. 3 days before the submission to Socialcom Steffen argued that we should drop the name of the paper and not call it graphity anymore. He said that we just sell the work as two new indices for social news streams (which I thought was kind of reasonable since the baseline to graphity really makes sense to use) and was not presented in any related work. Also we could enhance the paper with some feedback from my blog and the neo4j mailinglist. The only downside of this strategy was that changing the title and changing the story line would yield to a complete rewrite of the paper. Something I was not to keen of doing within 3 days. My coauther and I were convinced that we should stick to our changes from working in the feedback and stick to our argument for the baseline without related work.
We talked back to Steffen. He said he left the final decission to us but would strongly recommend to change the storyline of the paper and drop the name. Even though I was not 100% convinced and my coauthor also did not want to rewrite the paper I decided to follow Steffens experience. We rewrote the story line.

2012 July accept at SocialCom

The paper was accepted as a full paper to SocialCom. So following Steffens advice was a good idea. Also not getting down by bad reviews from the wrong community and staying convinced that the work had some strong results turned out to be a good thing. I am sure that posting preliminary results on the blog was really nice. In this way we could integrate open accessable feedback from the community to our third submission. I am excited how much I will have learnt from this experience with later submissions.
I will publish the paper on the blog as soon as the camera ready version is done! Subscribe to my newsleter, RSS or twitter if you don’t want to miss the final version of the paper!