Note: This file has moved to notablog.

Learning To Program In C A technical writer asked for advice about learning to program in C: > --> I don't have any plans to change careers and become a C programmer. > I DO plan to acquire enough programming knowledge and skills to be a > better technical writer. > > --> I chose C because the programmers I work with use C. > > --> I also chose C because I want to focus on concepts and > structures, which is something that C has in spades. > > I know it's a hard language to learn, but I'm willing to start with it. These are all valid reasons; I think one of the reasons I had a better time communicating with the engineers at one of my first "real" techwriting jobs was because my first job at the company was to write the online help system - in C :-). I'm sure they knew I wasn't a genius programmer, but the code I wrote demonstrated that I at least had a fundamental understanding of what their job was. I also made sure that I always kept a positive outlook and an interest in learning more about programming, as well as about the product. I think this helped them establish a frame of reference in their minds for communicating with me. Some concrete suggestions: 1) I highly recommend Kelly & Pohl's _C by Dissection_, as a good introduction to C and a slight introduction to C++. I surveyed a large number of C books in 1992 and _C by Dissection_ was the one that made the most sense to me. It taught by discussing a concept, discussing an example of using that concept, providing a code listing demonstrating the example, then dissecting the code listing, statement by statement, to examine how it works. I don't know about books that've been published since then, but _C by Dissection_ will always be a fond favorite. _C by Dissection_ ends each chapter with a brief discussion of C++ features related to the chapter topic, and has an appendix summarizing C++ features at the end of the book. Note that this does *not* deal with Object-Oriented Analysis/Design/Programming issues; there are many books on this, I'd suggest you start by reading some of the many FAQs on the Internet related to this. 2) For your purposes, it's probably a good idea to use the environment your programmers are using. Also, see if you can interest one of the programmers in mentoring you through the process; if you can enlist one, then you might consider going to management and getting some official support (at least to the extent of approval to use company systems for your work; possibly getting them to pay for books, or even classes). 3) Caveat the above, I'd suggest you get one of the visual C/C++ IDEs (Integrated Development Environments). This will allow you to learn and play with fun, spiffy GUI visual programs, which is a bit more fun than plain old text-interface programs. 4) I'd also suggest you get _Code Complete_, by Steve McConnel, for an introduction to some of the theoretical issues of software development. In fact, _Code Complete_ is on my general recommended reading list for any programmer or writer who works with programmers or software development. 5) Programming, per se, breaks down into several broad topic areas. Here's a list, but note that it's not in order of learning nor in order of importance; many of these are typically taught at the same time, some are not taught formally but are expected to be absorbed while the others are being taught. A real programmer is more than the sum of the programming languages he or she knows. logic structure math language syntax algorithms data structures programming methodologies project management Taking a course or reading a book on logic and symbolic logic will help you prepare for learning to program. I did this and it helped quite a bit. Unfortunately, I didn't take any of the programming-related math courses, which still hampers me on occasion, even though I tend to stick to "lightweight" programming projects. Language syntax is far more than knowing a few or even several programming languages; a good programmer is familiar with the underlying logic of language design and can quickly pick up new languages, having internalized the structures and broad syntatic issues and being able to fit a new language into those. This is part of why good programmers don't tend to like "messy" languages like VisualBasic. They weren't designed in the real sense and hence don't click as well with those internalized structures. Is there an easy way to get this knowledge, a way other than learning many different languages? Maybe. As one poster here pointed out, you could start with an easier language, designed as a learning language, and then jump from there to C. Or you might be able to find a good book that looks at the design issues; I can't think of one offhand, if anybody else can, I'd like to hear about it. [ One of the better experiences I had learning a new language was a C-like language (ColdMUD, if anybody's interest) where the language spec was laid out in terms of "this is the statement syntax; these are the flow control structures; these are the logic structures; these are the data structures; etc". You may find it beneficial to find and skim a book that examines C from this light, before you plunge into actual programming.] Aside from being able to express commands in a logical fashion, being able to translate those commands into the programming language syntax, and being able to arrange the code in structural fashion, you also need to understand data structures and algorithms. Most of the C books you look at are *not* going to address this latter topic well, and you'll continually run into your shortcomings if you don't address this. Donald Knuth has written several very weighty tomes that are the bibles of serious programmers; however, they're extremely dry and mathematical. There are various books on algorithms and data structures; the two topics are usually intensely inseparable. I haven't any specific recommendations, though experienced programmers have recommended the one by Aho, Hopcroft and Ullman. In general, these books are often written giving examples in the author's favorite language, or in some sort of artificial pseudo-language invented for the book. I recommend getting one that gives the examples in C. One that happens to be on the shelf near me is _Data Structures Using C_ by Tenenbaum, Langsam and Augenstein. No idea how good it is, though the guys who worked out of this office before me are said to be excellent programmers. Having looked at a book and chosen it, before you buy, check around on the net, look at the reviews on Amazon, search dejanews, check the C newsgroup FAQ, and see what opinions are about the accuracy of the book. Often I've heard horror stories about broken examples in the books, which can lead to really frustrating times for the student who doens't realize they're broken. [Later note: I highly recommend Bruce Eckel's book, _Thinking In C++_. I'm not sure how good it would be for a neophyte programmer, but I've been much impressed with his later _Thinking In Java_ (also VERY highly recommended).] My writing background has worked hand-in-hand with learning about programming methodologies - which has fed back into thinking more carefully about writing methodologies. A lot of the materal in JoAnn Hackos' _Managing Your Documentation Process_ came out of the SEI (Software Engineering Institute)'s research on software development processes. _Code Complete_ has a lot about both software methodologies and software project management. Some (or most) of the different methodologies may have a lot of popular support on the web, so check around, you may find web sites devoted to promulgating the methodology, FAQs, etc. Some of the FAQs can make the easiest reading (this might be worthy of the subthread in itself; FAQs are an interesting case of evolutionary documentation, or documentation by statistic; whatever questions keep popping up get added to the FAQ. Maybe this is why they're so useful :-). [Later note: I read an interesting theory about why FAQs are so useful. Because the questions are repeatedly asked and answered, often the answer that makes it into the FAQ has had a chance to get down to the fundamental, often-hidden misunderstanding or miscommunication that caused the question to be asked. This sounds like a sound theory. This phenomenon, in addition to the sheer statistical mass of questions leading to your most likely question having a specific answer, is probably a good part of why real FAQs are so useful.] You may also find reading the CACM (Communications of the ACM (Association for Computing Machinery), a Computer Science academic journal) useful, as well as the IEEE Software journal. You can feel free to e-mail me with questions if you get stuck, but C is not my main language these days (Java and Perl are) and in any event, I may not be able to respond immediately to questions. If anybody wants to take a crack at learning Perl, I have a list of books to get and read... :-). Steven J. Owens