Computer Programming, High School

To argue that computer programming should be a required high school course is absurd. But I’ve learned that many high schools still don’t offer any kind of computer programming/computer science classes. This is surprising to me, because even my high school, a mostly rural school with children of blue collar families and farmers, offered Computer Programming I and II (and before the days of Visual Studio).

I haven’t been able to find much data on the subject, but this Washington Post article states that few than 1 in 10 high schools across the state offer computer science courses:

Across the Washington region’s school systems, fewer than one in 10 high school students took computer science this academic year, according to district data.

I imagine the statistics are similar in other states. Also, one must wonder what is considered “computer science.” A high school near my house teachers Microsoft Powerpoint, Word and Publisher classes. This I find as surprising as the fact that most schools don’t offer computer science classes at all. Computer science, as far as code design, data structures, methodologies, algorithms, is hardly something of rapid change. These fundamentals are the basics that should be learned before any student delves into the specifics of a language. The Microsoft Office Suite, on the other hand, is little more than a set of common, user-friendly tools, guaranteed to be a version or two out of date in the span of four years! Why waste time teaching such things?

I have read that finding qualified teachers to take on computer sciences courses is a challenge. This makes sense, as any skilled engineer would probably rather be earning three times the income of a high school teacher.

Maybe this is an area where the local engineering community could step up. Why not let a good engineer cut away for an hour a day to do some community service by teaching a class? It would be a great way to help high schools–a win-win. The high schools would get a qualified teacher for a specialized class, and the business community would nurture future engineers. This idea seems so obvious that I can’t imagine it isn’t already being tried somewhere!

On Publishing and Writing and Documenting

record_paper2Reading

I was telling my daughter the other evening that it is important to know how to spell, and just as important to know how to write (and write well). She’s going into 5th grade, so such a lecture may be a bit premature. No worries. This lecture will be a repetitive one.

As I recall, the conversation came up when I made note of how impressed I was that she was reading a book just for fun on summer break. Reading–reading real books by real authors with real editors–is the best way to learn the craft. And for whatever reason, it seems that fiction is the best place to learn to write. (This is an opinion, but I have no problem asserting it as undeniable truth.) The technical stuff–most of it–is dry and full of poor writing. I’ve stumbled across countless examples of verbiage in techie books and articles that would make any English professor curse.

I love fiction. Shouldn’t we all? I read much more fiction than non. It would be easy to argue that the skills used to convey well-written fiction have little, if any crossover into a technical career. Don’t say it! (If you already said it, take it back!)

On the contrary, I’ve found that reading quality fiction is applicable my professional career, and its application comes in a form of learning that requires little deliberate uptake. So long as a story holds my attention, reading is easy and fun, and the learning and improving grammar is a secondary, seemingly osmotic benefit. While lost in a great story, we build upon vocabulary and command of language. We see styles and methods that we like. These we recall. We see styles that seem awkward or boring. These we recall as well (and avoid).

I cannot name a single professional career in which the ability to write is not of importance. I’d be interested in hearing of another opinion on this matter. It may sound absurd, as though I am declaring that simple arithmetic is important. But if this is such an obvious assertion, why does it seem that so many communications are written with bold indifference toward basic English?

Lest I get too far ahead of myself, I should come clean with something. The other day I sent my boss a very short email, typed on my iPhone, as I hurried to get things situated at home. The email, I thought, was short and to the point:

Micky-- 
Running a little late this morning. In by 9:30.
-Matt

(Micky is not my boss’s actual name, for the record.) The text above is what I meant to write. It is not what was sent. When I arrived to work, “a little late,” as I had told my boss, he had already had a good laugh at my email. Here’s what I actually wrote:

Micky-- 
Rubbing a little late this morning. In by 9:30.
-Matt

Rubbing. There it was… In my boss’s inbox forever. Foiled by auto-correct again!

Auto-correct is great for very short things, but only when used with caution. In this case it wasn’t a big deal (or was it?). Aside from the hilarity, my boss knew what I meant, and he guessed that auto-correct created the error. As silly as this example may be, it does leave a certain aftertaste, does it not? I’m a technical person, paid for focus and attention to detail. I write software… Software that needs to work the right way every time. While the example above is chuckle-worthy, it is also cringe-worthy. I know better!

Publishing

Publishing articles here and there has been fun. There’s something extremely satisfying about seeing your name in print. (See how I used two adjectives in that last sentence? Don’t do that in a technical document. Ever.) There is a certain thrill in having your words read by an audience. But with this comes a great amount of work and time commitment, which I haven’t consistently had the bandwidth for. To be sure, writing an article for a trade publication must be a labor of love, as the payout for such things is right around $0.00.

It isn’t all that difficult to get an article published, and it may be something worth seeking, if not regularly, at least once. The key is simply to have a specific goal for the article and a certain amount of knowledge of the subject (along with a willingness to put in some research where necessary). When it comes to publishing in a trade publication or website, it is also important to spend time self editing. Most of these outlets don’t edit much (or very well). It is embarrassing to see a typo make its way through to the end product. Even worse, reading a sentence or entire paragraph that you wish you had revised can be infuriating.

Infuriating may be a strong word… Or not. Personally, when reading anything, be it a book, article, or blog post, I lose focus and interest when I become annoyed by an author’s lack of writing skill. And while I am fairly confident that even this post will have a sentence or two that should be reworked, I stand by this assertion!

Keep the grammar simple. If you aren’t sure whether a particular sentence structure works, don’t use it. Lofty language is for poets, not for those of us attempting to convey a point. If a may set aside humility for a moment, the most consistently positive feedback I’ve received over the years has been with regard to my ability to write. What’s the secret here? Nothing, really, at least not that I can pinpoint. (See what I did there? I used a fragment. I love fragments. They are concise. And clever.)

A few things when it comes to software development and writing:

  • The developer who actually takes the time to document, from commenting code to precise checkin comments to keeping the wiki clean, already has a leg up.
  • Don’t write to impress. Chances are you will fail. Write to communicate.
  • Keep it simple, grammatically clean, and to the point… “Pithy,” as Bill O’Reilly likes to say. As I mentioned before, if you believe something doesn’t make sense, rewrite it in a way that you would like to read it.
  • There is little need to editorialize when documenting software. It may be necessary for certain things, but only in small doses.
  • Documentation is often treated as something that is done once and forgotten. This is a problem.
  • We all like to insert humor into our work lives. This isn’t a bad thing. But if there is any chance your words will be read by a customer or outsider of any kind, don’t do it. The words you use may find their way to people considering your company as a partner, client, or provider. Given the fact that the things engineers write may escape the scrutiny of corporate leadership, we should inject professionalism early on.
  • Have you ever sent a document out to the team for feedback and peer review? When you don’t get any responses (and you probably won’t), don’t assume that this means your document is perfect. It isn’t.
  • The Oxford Comma is the subject of some amount of debate among literary nerds. I think its use in technical documentation is appropriate.
  • Semicolons suck. Too strong? Okay, fine. Semicolons are way overused! This doesn’t have much to do with technical documentation, per se. I just couldn’t help but editorialize a bit.

I am hitting the Publish button now. I have not re-read or edited this post. Shame on me!

Some Random Links

Swift – Not really new news by now, but I’m looking forward to having some time to tinker with it.

Chordify – Give it an mp3 or URL, see chords, play along. Really cool.

Oracle vs. Google vs. Java – This is still going on?

Why Choose Jenkins (over Hudson)

Browser Usage Statisics — Chrome is clearly in the lead. So why do we all continue to bend over backward to support Internet Explorer quirks? Probably because so many corporations insist on it.

HTML6

Moore’s Law Plateauing? — While I’m skeptical, do people really pay that much attention to processor speed any more? Increasing persistent storage speed along with the leaps forward from SSD seems to be our greatest performance gain these days… If the cost ever comes down.

Patent Troll Targeting Podcasts — Why isn’t this getting more attention?

What’s The Value of College?

CNN: Surging College Tuition

CNN: Surging college costs price out middle class

Not long ago I found myself working alongside a brilliant college dropout–A young junior programmer who was just plain gifted when it came to software development. I was very surprised that he hadn’t completed a degree of any kind. It made me wonder why I had, without much consideration, put such high value on a four-year degree.

A recent InfoWorld article, 15 hot programming trends — and 15 going cold, touches on the issue of rising tuition costs and the questionable value that they bring.

I attended Ball State University — a place hardly known for being an engineering college. It was a nearby school with a Computer Science program that did not cost as much as IU or Purdue. For someone like me, it was attainable. While I enjoyed my time at Ball State, and I learned much, very little of my Computer Science education turned out to be directly applicable to my career. Sure, I learned formal concepts, design practices and perhaps a little about requirements gathering and QA (very little). Some of what I thought I knew had to be unlearned, as I came to realize that things operate differently in the “real world.”

Ultimately, as someone with an inherent interest in writing software, I suspect that everything I really needed to know could have been learned in a year of dedicated study. The rest comes from workplace experience.

The problem, of course, is that if I hadn’t gone the college route, spending 4+ years working on a Bachelor’s degree, I would never have been able to land my first job interview. And it was that first job where I really learned how all this stuff that I knew really came together in a real business environment on a project of significant size.

Through the years, I’ve met great, good and awful software engineers with varying backgrounds and educations. Many of the best software developers attended college, but graduated with a degree in something unrelated (History, Art, New Testament Studies, English, to name a few). These people gravitated to Software Engineering and Development through various means, some of them going on to pursue certifications and other training.

My experience hardly reflects any kind of comprehensive analysis, but I don’t hesitate to say that most of the software engineers with undergraduate degrees in non-CS fields are among those that I consider excellent.

There was a time, not all that long ago, when droves of students gravitated to Computer Science because they heard that it was a great career to pursue. While I happen to agree that it is a great career, I don’t think it is a career for just anyone. It requires a certain type of interest and motivation. Perhaps it is because some folks enter Computer Science undergraduate programs for the wrong reasons, but I have observed all ranges of skill level from those with CS backgrounds. I’ve found myself shocked (more than a few times) by the poor quality of code created by developers with formal CS educations. I once was asked to help debug some code written by a colleague that had compilation problems. It didn’t take long to find the problme: A 2,000+ lines-of-code function that caused the compiler to choke.

Doctors, Teachers, Lawyers, Accountants–These are all people who require specific degrees and certifications. I know that I don’t want to have my eyes checked by a self-trained Optometrist. In software fields it is different. After a software engineer has some experience, it seems that his or her degree becomes afterthought. Unless the subject of college comes up during a lunch conversation, rarely do I actually know the formal education or degree of a colleague. What I do know is that person’s quality and volume of work. Don’t get me wrong–there are things that may be taught in a Computer Science department that are absolutely necessary. Knowledge of algorithms and design patterns is important. It should be noted, however, that knowledge and application are different beasts.

I wonder–If college costs keep rising at such a staggering rate, at what point does the return on investment lose its worth? With companies hard pressed to find good software engineers, and with a greater percentage of the population unable to afford a 4 year degree at even a semi-respected university, when will the traditional model change? There are so many options–from certifications to local technical schools that are available at a fraction of the cost. At some point it seems that a college degree becomes more of a social status symbol than a true reflection of one’s talent or ability.

We’ll have to begin to ask ourselves: Which candidate is right for the job? Is it the one fresh out of college with a CS degree and a 3.8 GPA who lacks experience working with others on a project of scale, or is it the non-college-route self-taught programmer who has proven talent that can be seen by way of open-source contributions?

Occasionally I have seen job postings for software engineers which claim to require a Master’s Degree in Computer Science. I have to wonder: What does the hiring manager believe he or she might get from the engineer with a Master’s Degree that differs from the engineer with a lowly Bachelor’s Degree? In my experience, most Master’s Programs a little more than the same programs that undergraduates complete… The only difference is that the students in the program have already completed a four-year degree (and that degree could be anything).

This isn’t to demean formal education. If I had it to do over, I wouldn’t change my time at Ball State University. No way! I was fortunate, however. When I went to Ball State, college was merely ridiculously expensive. Today it is insanely expensive. In 10 years, it will be unattainably expensive. When that happens, where will the software engineers come from?

High Output = High Output of Defects Too (So go easy on ‘em!)


ImageWe all know that software defects are pretty much inevitable. (Right?)

A bad developer may produce a fraction as many defects of a great developer. I’m guessing Linux Torvalds has written more bugs that I could write in my entire career… And yet, to say that this means I am a better software developer would be absurd.

Inherent in this fact is an easy truth to understand but a difficult truth to respond to: The developer with lower output of overall contribution likely has a lower volume of defects tied to his or her name (or commits), while the superstar developer may be put in that less-than-fun situation of accepting responsibility for a defect a little more frequently than anyone would like.

The obvious reason for this is the simple fact that with great output of success comes a greater output of defects (even though, percentage-wise, the great developer may create significantly fewer). A less obvious reason for this is that the great developer–the super-talented one whose volume of output is consistently astonishing–is much more isolated from peer-review of other teammates. Those who don’t understand or work at a pace behind that of the great developer are less apt to offer insightful peer review. Also, the most talented developer on the team may be the most demanded upon (and when we believe in Software Ninjas, we’re setting ourselves up for problems).

There may be good reason to go easy on the guy or gal who must humbly own up to that defect that made its way into production. If fingers must be pointed, its the entire time that should be reviewing the work of their peers.

SSH User Annoyance & Solution

I’m in an environment where whenever I ssh to a machine I have a different username than that of my main machine. For example, the username on my desktop of “Some.Desktop.User,” whereas all the Linux environments I ssh to use the username “Some.Linux.User.” I’ve typed “ssh <host>” countless times, only to be annoyed when I realize that the password I am being prompted for is for “Some.Linux.User,” which does not exist on the host. Of course I should have typed “ssh <host> -l Some.Linux.User.”

To make life a little easier, do this:

In ~/.ssh create a file named config. In that file add the following:

Host *
User Some.Linux.User

Likewise, if you have a number of different accounts on different servers, you can do something like this:

Host servername.domain
User Some.Linux.User.1

Not exactly a super secret tip, but a useful time saver.