Observing Programming?!?!

[Digital Anthropology]

I just started fieldwork for my thesis which is about "creativity @ work.

It looks like i will get in touch with some IT guys working on IT for development. So there might be situations where I will observe people while they do some coding.

 A friend told me that he observed a teleworker while coding. The programmer was sitting alone in a room and just had contact with other teleworkers using internet & phone. He told me he felt very lost there because even when the programmer tries to explain what he's doing you'll get just scraps of thought.

The question is, how to make sense out of such a situation?

 

[John McCreery]

Frank, step 1 is to learn how to program— in the programming language that the person you are observing is using.  You will also need to learn a bit about the kind of problem he is working on. 

 

I am not kidding or being rude. You will need to know what the programmer is trying to do and be able to understand how he is trying to do it before you will be able to follow the cryptic remarks that are all you will get if you try to look over his shoulder while he is deep in a technical problem. The good news is that there are lots of resources on the Web for learning almost any programming language you care to tackle.

 

 

[Jacob Lee]

It seems to me that a prerequisite to ethnographic work in this context is a pretty solid background in programming and various concepts of computing (e.g. data structures). Even with enough background knowledge, an observer plopped down in the middle of a big project may very well be disoriented simply because she does not know the ins and outs of the project like the people she is observing. Also even fairly simple programming tasks may be burdensome to explain, and especially difficult when it is to someone without the requisite knowledge, because even an explanation of a small thing may involve explanation of a great many other things, assuming that the questions make sense in the first place.  I make my living explaining very basic computer science concepts to undergraduates; understanding does not come without lots of time and hard work.

 

That said, programmers are set out a goal, with certain requirements, and attempt to find programming solutions that satisfy those requirements. Sometimes it is very routine, but at other times it is very challenging, a kind of process of discovery. A programmer may not always understand what they are doing until they have got it done, and that may involve rewriting their code a few times. Scraps of thought may be all you get.

[Jacob Lee]

I have a piece of second-hand piece advice. I haven't investigated its basis in research, but my guess is that it is mostly true. Expertise comes with 10,000 hours of deliberate practice, study, and use. At 40 hours a week, 10,000 hours comes out to almost five years. Watch out though. If you know too much, and ask too many problems, you may find yourself problem-solving *with* the coders. Do that enough and you may end up just another highly paid employee. ( ;

[John McCreery]

Or, to reduce what Jacob and I have said to a maxim: Participant observation requires participation.

Programmers, chefs, jazz musicians...if what you want to understand is a practice with a substantial technical and esoteric component, you can't just look at the scene. You have to be part of it.

[Fausto dos Anjos Alvim]

While I agree with what John and Jacob said, I, think that on the practical side some things must be considered. I assume there is a timeframe here. I reckon focus isn’t on coding but on creativity @ work and not at one specific project. Learning how to program in any given language would be too time consuming and not so rewarding (although coding can become addictive). On the other hand, learning the principles of programming, its history (from machine language and assembly to the the paradigms adopted today, such as object and service oriented programming), would help you around with many different groups. You may not understand the code, but you would get a grasp on what it is all about. Better still: it would help you with a lot of the issues – sometime rather hostile –between different technologies, methodologies and ideologies. A little knowledge in legal and technical issues (hardware) would be a must too.

 

I don’t know exactly what you mean by “IT for development”. There is a category named Information and Communication Technology for Development (ICTD) that is focused on the use of ICT technologies for forwarding the development of countries. Presently I am a consultant for the United Nations Development Programme at an international public software project in ICTD. If you are interested, I would be glad to share J

 

Cheers,

 

Fausto

[John McCreery]

Frank,

Another issue to consider is the problem of overly selective focus. If you are observing only what happens in the room where the programmer is coding, you will likely be missing large swathes of the social field in which he is operating. This is something I remark on in the attached essay on creating advertising in Japan: Given the division of labor and people going off in various directions to work separately and coming together in combinations where not everyone is present, not even the managers ostensibly in charge of a project will have a panoptical view of what actually goes on. It suffices for business purposes that the project moves forward and produces work that the client is willing to pay for. How did that happen? Lots of folklore and highly edited memories, but nobody really knows.

[John McCreery]

Interesting. I wonder how many people here think of multisitedness as trying to chase people down in multiple offices, hallways, and project rooms in the same building as well as around the world, in, for example, diaspora studies. I haven't followed this literature very closely. Do you know of serious discussions of the methodological implications of short, highly focused encounters in several places instead of long immersion in one? I know that the folks involved in EPIC (Ethnographic Praxis in Corporations) talk a lot about these issues. Who else should I be looking at?

 

P.S. I hope you find the paper helpful.

[Jacob Lee]

A lot will depend upon your objectives, naturally enough, and the questions that you will be asking, or discussions you will be observing. Surely some discussions might involve nitty gritty details of the nuts and bolts of the code, but that would probably be when ever coders are working together on it. Once completed, the details of implementation do not usually matter, unless it was done poorly. For example, the object model provides an abstract interface for users to interact with the object. In general, different people will deal with the code at varying levels of abstraction.

Since you have some background in a high-level programming language, I think that is probably sufficient, unless you will be asking highly specific questions about the minute details of the programmer's work. However, a knowledge of software engineering practices would be very helpful for any higher level discussions, which probably would be of more interest. Schaum's Outline of Software Engineering would probably be helpful, although there are numerous other textbooks on this topic, some of them free and online. Here is a link to download a free textbook out of Rugers that looks pretty good (http://www.ece.rutgers.edu/~marsic/books/SE/). The readings are not too difficult, and I think give valuable background to what programmers and software engineers do at a higher level. Naturally enough most of this is prescriptive theory of what engineers ought to do, but it is but a short leap from descriptive studies evaluating various software engineering methods.

 

 

[John McCreery]

If you haven't seen it already, don't forget the absolute classic Mythical Man Month by Frederick Brooks.  See a brief description here.