Y'all Listen to This

Just a few quick tips for anyone who is trying to write a "Southern" character, about that most Southern of words, y'all. The first tip is that's how you spell it. Remember that an apostrophe, outside of being used in a possessive, indicates missing, unpronounced letters. Y'all is short for you all; the "ou" is what's missing. Some people, and I have to admit some of these people are Southerners themselves, write ya'll, probably from the influence of words like we'll.

The other tip is that y'all is a second person plural only; it's not some sort of blanket Southern replacement for you. It can only be used to refer to two or more people. I think some observers get confused because they see person A talking to person B, no one else in the conversation, and hear y'all. But in those cases, more than one person is being referred to, even if not present. Examples:

"Why don't y'all come over and watch the game with us?"

In this case, person A is inviting person B's entire family over.

"I hear y'all need to find a decent quarterback."

In this case, person A is referring to person B's chosen football team.

"Do y'all need anyone right now?"

Person A is asking if Person B's firm is hiring.

And so on. What you have to avoid is something like this:

"Y'all look good in that shirt."

"Y'all shouldn't have said that."

"I'm going to punch y'all in the mouth."

In these cases, Person B knows that Person A is some sort of impostor, and will alert the authorities as soon as possible.


Share this

Learning How to Program: A Guide. Part VIII

The Strengths and Weaknesses of Individual Colleges

(Be sure to check out part 1, part 2, part 3, part 4, part 5, part 6, and part 7 of this series if you haven't already).

In the last article I discussed the three general purposes of higher education: academics, training, and gatekeeping. Here's what these purposes mean to computing specifically.

Academics, in computing, means advancing the study of computer science, the creation of algorithms that do new things, or old things better, the limits of computation, the development of artificial intelligence, more secure transmission and storage of data, and myriad other things. A college that is strong in academics prepares the student to help the field progress--onwards to graduate school, research, teaching, and so on.

Training, in computing, is mostly about training for software development. Programming is a big part of this, but also the broader software development process, using ideas from general project management, and understanding databases, networks, and other things with which software interacts.

There's some overlap in these two areas, but they are quite different overall. Think of academics as comprehensive study of computing in order to help create a better future, and training as the development of skills to make the best software we can right now. Of course, to understand anything about computer science you have to know how to program, and to be a good programmer you have to know a little bit about most areas in computing. But you can become very knowledgeable about computer science without having the practical programming knowledge to do much useful development, and you can be a very useful programmer in many areas without deep understanding of computing as a science.

Finally, there's gatekeeping. That is, a degree is a stated requirement for some jobs. Beyond that, the perceived quality of the degree (that is, what college awarded the degree) may affect future employer's decisions as regards hiring and promotion. This is part of gatekeeping as well.

In order to receive a lasting benefit from attending college, it's important that you match your goals to the purposes of the school and program. Your first thought here might be just to go to a school that's really strong in all three purposes. That would be a great idea, except there aren't really any schools that are strong in all purposes.

Why not? One issue is time. Once you subtract all the courses given to core academics and start dividing the number of courses that are left among the various subjects in computing, there's no way to cover everything. Just to cover the academic function in its totality is impossible--take a look again at the list of possible elective subjects in the ACM recommendations linked in part 7. The more training you include, the more academics you leave out, and vice-versa.

Let's look at some samples to show the kinds of trade-offs that are involved. I want to stress that these are not pseudonyms for actual schools--I'm not here to point anyone to, or away from, a specific college. These just show common situations.

BIG STATE U is a land-grant institution with a total enrollment of 25,000 students, offering BS and MS degrees in computer science and computer engineering. The graduate programs are strong, with most graduate students, and many undergraduate students, working alongside professors in grant-derived projects. The undergraduate program's primary goal, then, is preparing students for graduate study.

This school gets high marks for academics. However, it may be lacking in training with all the focus on preparation for the graduate program. Another problem is that, like many schools with extensive graduate programs, many of the early undergraduate courses aren't taught by professors at all, but by graduate students. This isn't to say that graduate students can't be good teachers, but more often they are inexperienced and ill-prepared to help the neediest students. I was a teaching assistant as a graduate student, and though I consider myself an excellent teacher now, I assure you, I was not an excellent teacher then. Another problem is that even in the courses taught by professors, the professors haven't necessarily been recruited and retained on the basis of their teaching ability, but rather on the basis of their research abilities, and, not to put too fine a point on it, their ability to lure in grant money. Again, from a pure academic point of view, this is not always a problem. If you are primarily interested in research, the benefit of doing high-quality hands-on research may outweigh any deficiencies in the classroom. But if you are more interested in the training purpose, you may be in trouble.

This university probably gets a good grade in gatekeeping, regardless of the destination, academics or industry. In particular, successful undergraduate students can easily progress to the graduate program.

Finally, the school has a "medium" cost of attendence. There are lower-cost alternatives, but it is far from the most expensive.

OAK-LINED COLLEGE is a highly-regarded smaller school with an emphasis on the liberal arts, which nonetheless has programs in computing. There are fewer degree choices in computing, but the school tries to compensate with a decent selection of electives and some interesting interdisciplinary degrees. The core educational requirements are large enough that fewer credits remain for the courses in the major. The college has few graduate programs, and none in computing. This means there are considerably fewer opportunities for undergraduate students to engage in real research; it also means that professors are more likely to be hired and retained on the basis of their teaching ability, and almost every course should be taught by an actual professor.

This school does well in academics, but not as well as Big State U. With fewer courses, and without the graduate program or ongoing serious research to interact with, the student will only progress so far through that list of ACM recommended subjects. On the plus side, having even the earliest courses taught by career academics means that what the student does learn, he or she will likely learn well.

The program will perform decently in training, but given the liberal-arts focus of the overall college, it's unlikely that many of the courses focus on nuts-and-bolts practicalities.

Gatekeeping is excellent, both in academics or industry.

This is the most expensive of the three sample schools.

ONLINE TECH is a distance education school whose existence is shown only by an elaborate web site. They offer a surprisingly wide variety of degrees in computing, including standbys like computer science, but also in narrow categories, like web design or database development. The graduate offerings are sparser, and it's implied that few of the undergraduate students migrate to the graduate program. Rather, the graduate program is aimed at the student who earned an undergraduate degree long ago, and now needs to go back for a master's degree while still working full time.

This school probably has high marks in training. It's not so much worried about preparing students for the future of computing, but rather, for getting them gainful employment as soon as possible. The instructors are more likely to be from the industry, rather than career academics. The marks are lower for academics, though. The students who pass through have less patience for material that doesn't directly apply to daily work, and most of the students aren't intending to add graduate degrees.

The school does okay in gatekeeping for industry, where many prospective employers will just look at the names of the courses, and not care too much about where they were taken. The school gets poor marks in gatekeeping for academics, though. Traditional brick-and-mortar schools, even those that offer some courses online, are reluctant to accept credits from Online Tech for transfer, and traditional graduate programs are less likely to be impressed.

This is the least expensive of the three sample schools.

Again, these are not three actual schools, just typical examples. And there are plenty of schools that don't fit these patterns at all. There are all types of schools at all types of price ranges, many with surprising strengths and weaknesses. My point here is to demonstrate the kinds of trade-offs a student of programming will face when choosing a school. More on that in the next article ...


Share this

Learning How to Program: A Guide. Part VII

The Purposes of Higher Education

(Be sure to check out part 1, part 2, part 3, part 4, part 5, and part 6 of this series if you haven't already).

Lots of people who want to learn about programming, or anything else, for that matter, enroll at a college. As I stated previously, I don't think that's the best idea right at the beginning for programmer -- not when you are trying to determine whether or not programming is for you. But what about when you've passed the first couple of stages, and have confidence that you can be a good programmer? Should you go to college then? And if so, how do you pick out a good college to attend?

These are tricky questions, and it's going to take more than one article to answer them. In this article I'm going to lay out my Grand Unified Theory of Higher Education, and afterwards I'll explain how this relates to programming education and your decision to go to college.

Higher education, by which I mean any educational experience intended for people who have graduated high school, has historically served three purposes: academics, training, and gatekeeping.

  • Academics encompasses what was traditionally viewed as a "college education," the propagation of culture from one generation to the next, the liberal arts, the sciences and literature, the hallmark skills of the educated person, such as critical reading and clear writing.
  • Training is preparation to enter a particular profession, learning the mental or physical skills expected by industry.
  • Gatekeeping occurs when there is a hard requirement for a particular credential in a particular career. For example, a teaching certificate is required to teach in most K-12 classrooms.

The legal profession is a good example of how these purposes interact. If you desire to become a lawyer, the first step (after graduating high school) is to earn a bachelor's degree. You can effectively choose any bachelor's degree and major you want for this stage of your pre-professional journey; hence, your undergraduate degree can be focused entirely on academics. Once you complete your bachelor's degree, you will enroll in a law school, where you will receive training in the specific skills required to practice law. After you earn your law degree, before you can practice law you must pass your state's bar examination, which serves the gatekeeping function.

I believe the major underlying source of so much trouble in higher education is that we've muddled these purposes together. We've put all of the purposes under one roof, so to speak, and declared college education mandatory no what the career field. This results in colleges that try to do it all--academics, training, and gatekeeping--which means they don't serve any purpose as well as they should, and students who attend for one purpose are often in trouble when they encounter requirements from another purpose.

More on that later. For now, let's ask: how does all of this relate to our main topic, learning how to program?

When programming courses first arrived on campuses, they were part of what was then a new degree major called computer science. You may be surprised to learn that computer science is really about the science. That is, it serves the academic purpose, rather than the training purpose. Design guidelines for computer science curricula are handed down from the Association of Computing Machinery (ACM) and the Computer Society division of the IEEE. You can see their work at www.acm.org/education/curricula-recommendations. If you skim the contents of the computer science guidelines, you'll see how they've divided up the field, and what they consider "core" parts of any program and what could be left as an elective.

There you see the conflict between academics and training. Consider the knowledge area they currently call AL/BasicComputability (this style of naming looking like somebody was over-thinking the problem, but nevermind). Among the topics is "the halting problem," which states that a Turing machine (a theoretical simple computing device) cannot be designed to tell if another Turing machine will ever halt (as opposed to running indefinitely) when given a particular input. This statement has far-reaching implications in the area of theoretical computer science, understanding what computation can and cannot do. You wouldn't want to enter a graduate program in computer science without knowing what the halting problem was all about. However, in the practical world of programming, its use is close to zero. You can be a great programmer and go your whole life without hearing about the halting problem and be no worse because of it.

In contrast, look at one of the new topic areas, PF/SecureProgramming. One of the topics is avoiding array overflows. This is always a good idea, but it is emphasized here because array overflows can be manipulated by hackers to produce program actions unanticipated by the original programmer. That's good, practical advice, solid training for the developing programmer. But it's too narrow and too practical to fit in with the academic, "science" part of computer science.

Unfortunately, these attempts to serve all purposes in one place means no one is getting exactly what they want from college. Once you accept this, though, you can decide if college is right for you, and if so, which college is right for you, based on the degree to which you favor one purpose over the others. That's what I'll discuss next.


Share this

Learning How to Program: A Guide. Part VI

Problem Solving

(Be sure to check out part 1, part 2, part 3, part 4, and part 5 of this series if you haven't already).

The next step in learning to be a programmer is learning to solve problems with programs. This step is absolutely critical, and is really the foundation of what a good programmer does, but it's sadly under-taught. Before you tackle this step, though, make sure you are finished with the first step, which is learning the basic syntax of whatever language you have chosen.

In the previous step, you are really learning how to read a program. To test your abilities in this area, examine programs that use just those parts of the language that you learned about, and make sure you can follow them without reading any accompanying descriptions. In other words, try to execute the programs manually, using pencil and scratch paper if necessary. It's okay if you sometimes have to check your reference on a particular point of syntax or semantics -- maybe you haven't memorized everything yet, but the point is that you should be able to read through a program and comprehend it without too much difficulty. Once you have reached this stage, when you can declare with confidence that you know how to read basic programs in your chosen language, you are ready to learn how to actually write them.

But wait, I hear some of you saying, wasn't I writing programs in the previous step? That's what you told me to do, and that's what I did! In the previous stage, though, you're really just modifying existing programs, expanding or altering them slightly. The goal is to be able to write programs from scratch. I like to compare this to cooking. I am not a good cook, but that's not to say that I haven't sometimes put tasty food on the table. I can do this because I can follow a recipe -- if it's not too tricky -- and I can make small modifications to the recipe if the grocery store was missing a particular ingredient, or I need to make food less spicy for my daughter, or something like that. In contrast to my meager abilities, I had an uncle who was a great cook. Uncle Jim was the sort of guy who could just poke around in your refrigerator and pantry and whip something up that would meet your tastes.

Ultimately, that's what you need to be able to do as a programmer. Someone tells you what the program should do -- the specifications or requirements -- and then it's up to you to figure out how to write a program to do that. That's problem solving.

I just wrote a whole book on the subject. It uses C++ for the example code, so if you know basic C++, or are willing to learn (if you are already learning a similar language like Java, it won't be hard at all), that's where I would recommend you head next. The book's not expensive, but if you want to go ahead and get started, let me give you some ideas.

Do you remember previously how I talked about learning a language step-by-step, so that with each program you write during this learning phase, you are only wrestling with one new idea? One of the best techniques for solving a complicated problem is to divide or reduce the problem in some way so that you are only dealing with one issue at a time. If you aren't sure how to write a program that meets all the given specifications, just change the specifications. This is only temporary, of course, and eventually you'll have to solve the problem as written, in the meantime you can make progress, build a foundation for solving the entire problem, and possibly discover more about the problem and its ultimate solution.

The most important thing about this phase, the problem-solving phase of your development as a programmer, is that it cannot be skipped. Students can gain a lot of confidence with program modification, messing-around, experimentation, whatever you want to call it, and while it's an important first step, no amount of that can make you a programmer. I see a lot of fledgling programmers who are in such a hurry to get to the "good stuff," more advanced programming with impressive output, that they press forward without realizing that they've passed over trying to master the crucial skill that determines whether or not they're really going to enjoy programming. They learn a lot about programming without ever really doing any. Don't be this person!


Share this

Learning How to Program: A Guide. Part V

Let's Do It, Already.

(Be sure to check out part 1, part 2, part 3, and part 4 of this series if you haven't already).

You've definitely decided to give programming a try, and you've picked out your introductory language. So now what?

You need to install whatever development tools you're going to use. You can get started with just a text editor and a command-line compiler, and you might even know someone who tells you that "real" programmers don't need all that fancy syntax highlighting and debugging and what else. Don't listen to that person. A nice editor with syntax highlighting (text is different colors depending on its meaning within the programming language) and completion (sort of like the suggestions in a Google search box, it lets you choose from options based on what you've already typed) is very helpful even in the early stages of programming to keep the syntax straight. And a debugger is useful for much more than simply finding and removing bugs in code. It's a great tool for understanding what's going on in the code line-by-line. If there is a section of code that you copied into your editor but don't fully understand how it works, there's nothing better than stepping through the code with the debugger, checking the values of the variables as they change. Get to know your debugger early and use it often.

The first program you want to write, though, is going to be the "hello world" program or something equivalent. You just want to make sure that you know how to use the compiler (or interpreter) to actually build and execute a program.

From there, follow along in whatever book or online guide you have. By "follow along" I mean never simply read -- always do. Write programs every step of the way to confirm your understanding of what you have read. Always take it one simple step at a time. By that I mean never introduce more than one "new" thing at a time in your programs. Also, experiment is much as possible at each step before moving on to the next.

Let me give you an example. Suppose you started with a "hello world" program. In C++ the line of code that did all the work would look something like this:

cout << "Hello World!\n";

In Java:

System.out.println("Hello World!");


print "Hello World!"

Regardless, once that first program works, try playing around with it to do other things. Give yourself specific goals and see if you can achieve them. Can you display "Hello" and "World" on separate lines, for example? What about displaying unusual characters? What if, for example, you wanted a double quotation mark to be displayed?

Then see what comes next in your resource and incorporate that into your tiny program. For example, what often comes next is an explanation of numerical expressions. So try modifying your program to compute and display the number of seconds in one year.

Let's say the next topic after that is variables. Try storing the number of years in a variable called years and then computing (and displaying) the number of seconds in that many years. Think of some other simple computation tasks like that and write simple programs to perform them.

If the next topic is user input, modify your previous programs to accept user input. Read years from the user instead of making it a fixed value, and so on.

One of the suggestions I make repeatedly in my book is that when you're stuck on a problem, you should break it down so that you are only working on one issue at a time. But you can use this concept in the other direction as well. By learning each part of the programming language separately, it's much easier than trying to put lots of new ideas together in one go.

Furthermore, by asking yourself questions, "how can I do X?", and then trying to answer them, you'll learn about the features of the language in a systematic way. You'll make mistakes, but they will be easier to correct because you'll know where to look for them, and you'll learn from them.

Remember, the goal at this stage is to determine whether programming is right for you, and that means whether or not you are enjoying it. When you sit down at your computer to push forward in your learning, how are you feeling? Excited? Curious? If it already feels like punching a clock, that's a bad sign. You should get a nice jolt of satisfaction when one of your programs work. It shouldn't just feel like relief.


Share this


Subscribe to Front page feed