16 Monday Jun 2014
Tags
computer programmer, computer programming, computer science, software, software design, software development
Computer Programming is hard! It’s at least as hard as what commercial architects do, and I will argue that it’s as intellectually difficult as what doctors and lawyers do.
Many people think it’s easy, because they know some nine-year-old who “programs,” but there’s a difference between fooling around with the computer and building good software applications.
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!
05 Wednesday Mar 2014
Here’s a simple tip! I can’t begin to count how many potential code bugs this has eliminated. It takes some getting used to but once you make it automatic it’s a real help in keeping code and your thinking correct.
The tip is this: when you write relational expressions, always use less-than, never use greater-than. (Less-than-or-equal is okay, too.)
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.
03 Monday Mar 2014
Posted in CS101
When you write code, always remember Rule #2: Source code is for humans. This rule ties to Rule #1 about clarity. You’re writing for humans, so write clearly! The compiler can understand any syntactically correct ball of mud you make, but humans need all the help you can give them. Write for your human readers, not the compiler.
27 Thursday Feb 2014
Posted in CS101
Tags
computer programmers, computer programming, four principles, learn to learn, software development
Over the years I’ve come to believe in four basic principles computer programmers should adhere to. They reflect four paths of continuing education programmers walk throughout their career. The bottom line, really, is that you’re going to be doing these things a lot; it will serve you well to learn to do them well and with intention.
26 Wednesday Feb 2014
Posted in CS101
Clarity is the #1 priority when writing code. Clarity trumps everything else; it’s even more important than the code being correct! One of the biggest wins a serious programmer can offer is writing clear, readable code.
