10 Sunday Nov 2019
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
Posted in Stories
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
Posted in CS101
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.
10 Monday Mar 2014
Posted in Opinion
Tags
computer programmer, computer programmers, computer programming, computer science, it depends, software design, The Universal Answer, Universal Answer
At some point it strikes you. For some it happens early in Computer Science class after hearing a professor say it for the umpteenth time. For others it happens when hearing it come from their own mouths for the umpteenth time. The Universal Answer to any (and all) computer (science) question(s).
“It depends.”
07 Friday Mar 2014
Posted in Fun
04 Tuesday Mar 2014
Posted in CS101
One of the things that programmers do a bazillion times during their career is come up with a name for something. Every variable, every sub-routine, every class, every method, every instance, even the program itself and all its supporting files: they all need names. In some cases the naming is obvious and easy, but in others it’s complicated. You can end up creating a big ball of mud if go about it casually.
So one thing you want to start doing is being intentional about naming things.
