23 Thursday Jun 2022
There are many general skills a programmer should have to be effective and valuable. Some are very general — for instance, the ability to learn and to think abstractly — but some are more specific — various tools and tricks of skilled programming.
Among those tools are several non-programming languages all programmers should know. Those include HTML, XML, SQL, and an old one whose name doesn’t end with “L” — Regular Expressions (aka REs, aka RegEx or RegExp).
19 Tuesday Oct 2021
Tags
code clarity, computer code, computer programmers, readable code, space character, tab character, text file
There are many issues that divide programmers: operating systems and editors being two huge ones. I’ve worked on too many platforms to care much about the first one, but I’m a lifelong gvim user.
One of the lesser dividing issues involves the crucial source coding choice: Tabs or Spaces? The issue is both less and more important these days. Less because editors are very capable; more because Python is popular.
05 Friday Feb 2021
Posted in CS101
I’ve been going through my old Computer Language magazines, and man have things changed since 1984. It’s a fascinating trip through the early days of personal computing.
I was reading an article about using dates in an application and was struck by the prescience of one bit.
10 Sunday Nov 2019
Posted in Stories
Programmers, like carpenters, are builders — we make things. The work can be for pay, but carpenters, for example, can build their own bookshelves and doghouses. Programmers also make software for themselves, sometimes to amuse, sometimes to provide a useful function.
A few of the apps I created for myself over the years turned out to be major workhorses for me — tools I used frequently. One of the earliest was PF.EXE, my Process File utility.
02 Wednesday Aug 2017
Sometimes ya gotta laugh. I just spent nearly an hour chasing one of those bugs that “can’t be happening” because “the code looks absolutely correct (as far as I can tell).” Of course, the bug, once you find it, was always hiding in plain view.
This time the fix involved adding just two characters, incidentally improving the program semantics, and very much reminded me of the old joke about the huge cargo ship that breaks down at sea…
05 Monday Oct 2015
Posted in CS101
Tags
computer code, computer programmers, computer programming, programming language, real programmers, software development
There is a common tendency, as we crank out code, to think that we’ll come back later and write some really good comments — comments that future reviewers will view with admiration for their clarity, completeness, and humor. But if we’re honest we have to admit: Later never comes. We never go back and write those great comments. Often we don’t write any comments at all other than some placeholder we might dash off at the time.
Which is why Rule #4: Comment As You Go!
23 Monday Jun 2014
Tags
computer programmers, computer programming, project estimation, project management, software design, software development
Last week I took my car in for scheduled service, and when I asked how long it might take, the guy said it was specified as one-and-a-half hours of labor. He could do that because there are thousands upon thousands of data points where a competent mechanic has performed that exact service, so there is a very clear idea how long it takes.
But ask a researcher how long it will take to find what they’re looking for, and the answer is usually, “I have no idea. I’ll know after I find it.” The path a researcher follows is usually new and unexplored, so it’s impossible to predict how long the path actually is.
Creating new software is much more like research than auto service, because it involves traveling unknown ground. Despite this, software development managers often act as if new development is predictable.
It often isn’t!
10 Tuesday Jun 2014
Think of writing code as you think of writing a formal letter.
When you write a formal letter, you have two goals: you have a message to communicate, and you must follow the protocol of a formal letter. Your message comes through when your writing is clear and good. Following the protocol is a matter of knowing and following some syntax rules.
A message + formal syntax. The result is a document with a context.
13 Tuesday May 2014
Posted in CS101
Tags
compiling code, computer programmer, computer programmers, computer programming, errors, Java, software development, warnings
There have been times when, working on other people’s code, one of the first things that pops up is that their code generates thousands of warnings. I’m not exaggerating the number; there have been at least two times I can recall where someone’s code set generated that many warnings. And both times, the code set wasn’t all that large (only tens of thousands of lines).
Which leads us to Rule #3: Don’t ignore warnings!
14 Monday Apr 2014
Posted in Opinion
The heartbleed bug has been in the news lately. Rightfully so; it’s a pretty big deal, at least in theory. How much damage is practically possible and how much damage may have occurred is unknown so far. But the potential security hole is enormous!
Two things really stand out about this bug: Firstly, attackers get (potentially) vast amounts of internal computer data while leaving no record. Secondly, the bug is a simple error caused by, metaphorically speaking, not looking both ways when crossing a one-way street.
The Hard-Core Coder 