This is probably just the grumpy old git that I am revealing itself, but while I really like Python and similar languages, I get quote annoyed when that is all that is taught CS students. (And don't get me started on Java :-) ).

Those languages are great for getting stuff done (in appropriate application areas), but they leave huge gaps in understanding about how computers actually work - the programming model they present is significantly divorced from real machine architectures and my experience with students who've been taught primarily languages like these is that they have to "unlearn" a lot of stuff before they can become truly good programmers.

/JB

Something like Python is bare minimum for basics, still I think it's better than Java as there is less un-needed clutter.

C is fun.............. and C++ is even more fun..........................

It does help that you have to consider things at quite basic level, and for even more basic stuff things like MIPS are also good. Even C doesn't give you the clear understanding how control logic and other things really work.

Still, literary skills needed to support coding aren't too close to those needed in prose. I think there should be some investment in the field.

I've worked with many programmers whose second language is English. The spelling/grammar of their internal emails is often atrocious. Despite this, the quality and clearness of their code far exceeds their ability to craft prose.

A well written program may not even need documentation. If the procedure names and variable names are descriptive and the code is logical and concise it immediately conveys the purpose of the program and the transformation encoded in the function or procedure.

On the other hand, I have worked with programmers who have a firm grasp of conventional spelling and grammar but couldn't program "Hello World" if their life depended on it.

Some programmers have an innate ability to breakdown the problem into very clear steps, program those steps in very clear, uncluttered code. And you can understand everything that is happening in the code without comments. It's a talent that is not [spoken or written] language dependent.

Ah, so now I have a new excuse for my crappy code: I struggled with English in high school!

Seriously though, I can't write creatively, and for that matter can't write scientific papers all that well, but I'd like to think my code has gotten to a decent point (or at least had, I don't get to do anywhere near as much coding as I used to). But for me, there's no question that it came from a lot of practice. Quite frankly, I just didn't know enough when I was starting to realize how important it can be to worry about writing clean code that's decently commented. Eventually I learned that if you do it right the first time, it tends to mean a lot less fixing the code later .

Writing good documentation is hard. It's not just a case of explaining the how or why of a given piece of code, it's knowing how much or little detail is just right to get the point across and doing so in a way that's understandable to a wide range of technical abilities. I think it's quite possible for some programmers to excel at coding and yet not be the best person for writing documentation.

Quote:

Those languages are great for getting stuff done (in appropriate application areas), but they leave huge gaps in understanding about how computers actually work

At the risk of going off on a tangent, I think this is an important point. Having a clear understanding of how a computer is going to end up handling your code can help you appreciate and anticipate a large number of issues. It can also give you an intuition for when something doesn't quite feel right. You may not be able to put your finger on what it is, but it's often enough to make you start googling a subject.

One of the few good changes proposed in UK education is the scrapping of current IT courses and a move to a more industry supported syllabus with a greater focus on programming (most IT courses currently include zero programming and are totally word/excel/business process oriented). It's shocking that we expect students to start a course at college and university levels with little or no actual coding experience. Imagine taking A-level or degree maths/english without having previously been taught to add up or read/write.

Computers are so important in our lives now that there needs to be an attempt to teach the basics of how they work at a hardware level and a limited amount of programming to solidify those concepts.

Going back to the original article, I think it's just a case of, some programmers are just simply poor programmers. Perhaps they're lazy or take little professional pride in their work? Perhaps it's any number of other reasons. However, good programmers who do take pride in their work will often take pride in their other pursuits and be good at those too. Sometimes that may happen to mean they're good with language or maths, but equally they could be atrocious spellers and have poor grammar, but excel in other areas.

Going back to the original article, I think it's just a case of, some programmers are just simply poor programmers. Perhaps they're lazy or take little professional pride in their work? Perhaps it's any number of other reasons.

In my experience the main cause isn't laziness or lack of pride, it's more that most people in some hard to define way just don't have the right mind set. There's something about the way a good programmer's mind works that is necessary, and most people (including those who have studied programming at degree level and even, sadly, a significant number who have done it professionally) just don't have that way of thinking.

The original premise is false. I've worked with many programmers whose second language is English. The spelling/grammar of their internal emails is often atrocious. Despite this, the quality and clearness of their code far exceeds their ability to craft prose.

That argument is a red herring for the simple reason you don't know how adept those individuals are at expressing ideas in their first language. In fact, your ESL-schooled programmers might write cracking native prose, since they can at least communicate intelligibly in more than one language.

Meisler's idea is partly that one should be able to formulate and express thoughts in words coherently in order to write not only code but attendant programming and documentation -- not because English is a special language (though it can be especially confusing), but because of the connection between programming, communication and logical thought, as well as the need for all three in application programming interface documentation (which is perhaps why people with "atrocious" English have managed to confect readable descriptions in ways that don't belie their questionable competence with their second (or possibly twelfth, for aught we know) language.

There are all kinds of legitimate ways to attack Mr. Meisler's point (such as the one you use at the end of your post), but eliminating the larger group based on an unattributed subset which Mr. Meisler would surely except isn't one of them.

One aspect that makes English an especially good language to know is that it can't be written on a perfect grid as can French, Spanish and Italian (for starters). As Graves and Hodge point out in The Reader over Your Shoulder, the ability to write well in English has directly to do with being able to think and argue logically in terms of meaning, associations and usage -- which is why the authors of that amusingly rude book get to have so much fun creating "fair copies" of essays by other writers (Shaw, T.S. Eliot, etc.!).

Do address the original question from the other point of view, I think most good programmers would make very poor creative writers. They would present facts clearly in short declarative statements, there would be no art to their writing at all. Good code is clear and easy to understand. Good writing uses a huge variety of tricks and methods to give more than the just facts contained in a sentence, but also to add colour and depth, to create a particular feeling in the mind of the reader.

I don't think the point was for programmers to have to be creative writers specifically, but you might be wrong about the idea that laconic thought leads to bad prose.

I have an Australian programmer friend who's one of the pithiest writers and drinking companions I know, and it has everything to do with the way he codes and solves problems. All his best jokes involve pointing out some obvious fallacy in everyone else's thinking that leads to an irreverent paradox.

He's also extremely literate. I first knew him as a sound engineer and remember that he was the only person I knew with that job who used to lay books by Foucault, Virilio and Lyotard on the console. Virtually every other engineer I worked with back then read Tom Clancy or possibly Clive Barker.

I agree - proper commenting, naming of variables, structures, subroutines, and documentation is key to making software useable/reusable.

Exactly and well stated. Like you & others in this thread I'm a tri-decade+ developer as well as network engineer. I've served my time as an IT Director as well.

COding & documentation conventions are still, in this "modern" era, very neglected, almost taken for granted. On one side you end up with the "business major" sorts who do not understand why it takes 3-5x longer to design, document and debug (never done but it is part of it all) an app as it does to do the actual coding.

Explaining to a client/boss that the initial pseudo-code/outline is where the time needs to be spent. If this is done apps not only meet deadlines easily they also tend to be far easier to debug, usually with less time need for debugging.

Coders have always wanted to just code. To flight coders, even developers, already see at minimum the entire module they've been given to code or even the entire project in their head. You know we actually see the code...heck when in college for both my math and CS degrees I would often dream solutions to equations or code whole modules in a night or two of sleep.

But becoming a developer is about not only team work but the ability to organize & compartmentalize all the needed tasked to bring an app to completion. I agree that those with poor communication skills are not good "developers" but can be fine as coders. I consider a developer as one who can conceptualize, design then code an app. Coders are the freaks who live simply to write code. I've known and used some amazing coders who could bang out error free code at an amazing rate but had zero ability to communicate with others let alone what their code was supposed to do and what it needed. I've also found coders who could write code that somehow worked but was so inelegant and downright schizoid as to be pointless. I prefer the former...as the latter rarely bath and tend to prefer working in mom's basement.

Quote:

Originally Posted by HarryT

That's really where the difference lies between professional programmers and amateur hobbyists. Hobbyists may be (and often are) good coders, but coding only forms a small part of what professional programmers actually do.

Not sure I am comfy with your definition here.

The ability to design, document, code and implement a programmatic solution in a cogent fashion does not make one a professional anymore than the ability to properly repair a toilet makes one a professional plumber. A professional is one who undertakes a task and makes it work then rolls with the changes, unforeseen dead ends or other unexpected events during the development and implementation phases of an app's life cycle.

But I do get what you are trying to say here...a pro does these things as business-as-usual manner rather than some sort of forced-march held at gun-point. A pro also is one who can act in either a lead or subordinate role. Basically pro's act like "they've been there before".

I don't believe in the idea of a "professional" or "amateur" in regard to classifying a developer. To me the difference is simply if one does it to earn a living. Rather I differentiate into "developer/designers" vs. "pure coders" vs. plain old hacks who don't have the discipline to accept deadlines, design changes and coding conventions. The latter are the ones who give the good developers a bad name.

I have held a similar discussion with a math prof because I was a double major in math/CS. He was a mathematician at Lawrence-Livermore who retired from to teach. In class one day we got into the importance of math skills in relation to programming. He felt it was not necessary to even get through the first 3-semesters of calculus. I disagreed with an explanation...my argument was and still is both areas need the same fundamental skill. That skill is problem solving using an algebra of some sort to develop results in the defined solution space. Meaning simply that one needs to be a problem solver who can keep organized. I further feel while one does not need to be an expert mathematician but needs to be able to function. I consider commonly understood algebraic systems to simply be a type of programming language used to take data, grind and crunch on it then spit out a solution defined by that very algebraic system.

I suppose written communication tools form just another algebra with it's corresponding solution space. So the same argument would seem to apply. Meaning perhaps I do agree that one does need to be able to communicate to truly be a developer. Perhaps it is even a broader brush here. If you cannot communicate well it's a lot tougher to succeed. It is just there are different forms of communication in which we each excel. Still we all need to at minimum be familiar with one area and solid to expert in the other areas. BTW, I like the obvious tie-in to being a well rounded reader as a necessary tool in our communications toolkit.

I've done this long enough to know I am NOT an adept technical writer but I considered a rather good developer and mathematician. Plus my spelling is horrid and I am mildly numerically-dyslexic so adding, subtracting, multiplying and dividing can be an adventure for me as well as it was a nightmare for my profs in the college days.

In my experience the main cause isn't laziness or lack of pride, it's more that most people in some hard to define way just don't have the right mind set. There's something about the way a good programmer's mind works that is necessary, and most people (including those who have studied programming at degree level and even, sadly, a significant number who have done it professionally) just don't have that way of thinking.

/JB

I can relate to that. An aptitude for problem solving goes a long way.

I think by lazyness/pride I was thinking along the lines of, coders who do their day job but will often be found reading around the subject, experimenting in their own time, working on side projects. Looking for ways to improve their craft and deliver better code.

Whilst I have met programmers who do just turn up to the job, do their stuff and go home never to touch a line of code until the next day of work, it's rare to find a really good coder who hasn't at least at one point early in their career, spent time on side projects.

Whilst I have met programmers who do just turn up to the job, do their stuff and go home never to touch a line of code until the next day of work, it's rare to find a really good coder who hasn't at least at one point early in their career, spent time on side projects.

30 years ago I'd spend all day programming at work, come home, and spend all evening programming at home. These days, programming is the way I pay the bills. When I leave the office, the last thing I want to do is to do more of it at home. Time tends to make you a little cynical about such things.

30 years ago I'd spend all day programming at work, come home, and spend all evening programming at home. These days, programming is the way I pay the bills. When I leave the office, the last thing I want to do is to do more of it at home. Time tends to make you a little cynical about such things.

Ditto. Although closer to 20 years than 30 in my case. I've been coding for more than 30 years, but I started when I was 9....didn't hold a day job at the time...

Actually, I am just now getting back in to the hobbyist aspects, but it probably won't go beyond the occasional tweak of an open source project. On my off hours, I'd rather watch a movie, or go skiing, or sleep.