If nothing else (and I think there is plenty of else), I can look back on all those years of writing code and pick out the main themes and principles, the things that seemed to matter most. That’s what this CS101 series is about: things I think matter most when it comes to designing software.
Lately I’ve been looking into fours, doing things in fours. With that in mind, here’s Four Primary Principles for Programmer:
- Learn to learn.
- Learn to look stuff up.
- Learn to communicate.
- Learn your craft.
That’s right; learning your craft is number four! I think the first three are good principles in general. All three are useful skills in life, but I’ve found them to apply particularly to software design. I’m not saying software is unique in this; many professions need constant access to stored knowledge. No one knows all the details, so everyone needs documentation at some point!
Knowing your craft is certainly important—it made it into the top four! But the first two are constant job requirements, and the third is an invaluable skill. All three apply regardless of your craft. Let me explain them in more detail.
Learn to learn. This is a required skill. Programmers constantly learn new things. There are new tools, new languages, new processes, new standards, new client contexts and new technology. This is an evolving field; there’s always something new. I’ve learned as much in this past year as in every one of the 30+ past years I’ve been doing this.
In fact, I advocate teaching yourself one new computer language a year. I don’t make the recommendation to exercise your learning skills, although it does do that. I think learning new programming languages is important to your understanding of what they are and how they work.
It’s like a musician learning many instruments. If it’s about the music, then the tools—the instruments, the programming languages—don’t matter. Which is not to say that becoming a virtuoso on an instrument isn’t a valid choice. But the job pool is limited, so you need to be a true virtuoso.
Each year, just pick a new language and learn it (the interweb makes that very easy). You have plenty to choose from: Python, Ruby, Scheme, Haskell, Smalltalk, Lisp, Erlang, Prolog, APL, Forth, Eiffel, Perl, Ada,… The list continues, and those are just a few of the slightly to somewhat off-the-mainstream languages! You might be amazed at how many programming languages there actually are.
Learn to look stuff up. Another required (and acquired) skill. No one can know it all, so the key is knowing where to look stuff up. As I said, we all need the documentation sometimes. That was Scotty’s secret, you know. He had access to Wikipedia!
Seriously, Wikipedia is wonderful for technical research. The quality of Wiki entries is high on technical material (probably because of the many technical people involved in Wiki and in the interweb). And technical material doesn’t have the political freight as does some social material. Genuine error is rare, let alone deliberate disinformation.
The interweb in general was always rich in technical resource. Its origins were technical, so for a long time its content was also heavily technical. But recent searches turn up results with a lot of (a) people already asking your question and (b) people guessing at the answer for group (a). It has become harder to sift out the actual answer.
But it’s usually still there. The interweb remains a great, if noisy, technical resource!
Learn to communicate. This covers tools, such as Word and Excel (or whatever), but also has to do with improving your writing, and possibly speaking, skills. You may need to do documentation for others, or give a presentation, but you’ll find that skill with documentation and analysis tools is also a benefit to you.
This occurs in two ways. First, you can use these tools to explore a problem or at least put it down on paper. Sometimes a diagram or a flowchart or some kind of drawing is very helpful in breaking down and understanding a problem. Second, documenting your work using modern tools for the job is almost pleasant; the result definitely is!
You will want to be familiar with a good authoring tool (such as Word), a good data analysis tool (such as Excel), a good drawing tool (programmers make many diagrams), and maybe a presentation tool (PowerPoint; sorry about all the MS Office references, but they are very good tools) and a database tool (guess what: MS Access).
The world is increasingly electronic, and it is more and more common to communicate by electronic means. You’ll want to be facile (which includes being literate and clear) with email as well as with whatever other tools make sense in your business. Increasingly, communication means the interweb, so you’ll want to be interweb aware if not savvy.
Interesting how the interweb manages to be a part of all three first general principles. Think it’s invaded and permeated our life much?
Learn your craft. Well, duh. Naturally you want to be good at what you do. That includes the background knowledge, such as knowing the programming language, as well as specific knowledge, such as the data scheme of your database. The stronger your background knowledge, the more you can see of a system, the more of that system you understand. The more you can see, the better you are at debugging or making changes.
Background knowledge also tends to transfer from position to position better than specific knowledge. XML, for instance, is used in so many areas of the computer world now that knowing it is a big benefit. Knowing how computers work and communicate on a general level can be extremely helpful in giving you utility in many areas. It gives you a strong foundation on which to build.
Knowing a given language, such as Java, is fairly useful, but can narrow down the field some. And consider that a C programmer, or a C++ programmer, might well have felt like a Java Programmer does today. This, by the way, is why you want to learn new languages! It looks like Java is here to stay, it looks like there are plenty of Java jobs, but eventually the next new thing does come along. Background knowledge (and the ability to learn!) helps with the next new thing.
There’s a lot more to it, of course. Programmers need attention to detail, for example. When it comes to software, you do have to sweat the small stuff. Each bit matters!
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.
Time to start talking more about programming. It’s one of my defining aspects. I’ll try to make it as interesting as possible for the non-programmers. For the programmers, I’m sorry, but that means sometimes I’ll have to get a little basic or skirt a few corners. Feel free to use the Comments section!
Physically software is just a long string of numbers. In fact it’s really just a string of things and not things. Holes in paper; or not holes in paper. Magnetic domains magnetized; or not. Tiny electronic switches turned on; or not. You can represent software as a string of black and white jelly beans. It’s all the exact same thing. What matters is the pattern of thing and not thing.
Now the packages of eight bits, the bytes, are clumped into small groups, usually, of four (4 x 8 = 32). These are called words. In some cases the words are of two bytes (2 x 8 = 16) or eight bytes (8 x 8 = 64). The phrases “32-bit” and “64-bit” refer to this is the level of abstraction. The software is a string of words now rather than just a string of bits. The words are meaningful in the (abstract) language of the program.
Other professions deal more with abstraction. Architects and Mechanical Engineers, for example, deal with drawings and models, which are abstractions of buildings or machines. They start from a pure abstraction, the idea and design, and work to build a concrete thing. [In passing, computer models and 3D printers have made the abstractions much more concrete. We've come a long way since faded blue prints.]
Mathematicians and theoretical physicists are entirely in the realm of abstraction! In some cases, 11-dimensional objects for example, a concrete object is not possible. Or took place long ago; the Big Bang took place a very long time ago! In other cases, the forces, energies or times involved are far beyond our technology. They could be concrete in theory, but we’re not likely to pull it off any time soon.
I don’t like the term Software Engineer. Real engineers have licenses and certifications and prescribed educations. No such exists (currently) for software makers. It is still a new craft in our society (it goes back only to the 1950s or so), and we haven’t caught up to how complex and demanding it really is. Anyone can use the term Software Engineer, so it doesn’t have the meaning it could.
People who work with software are sometimes called knowledge workers, but I think that’s also poor terminology. All workers use their own knowledge as well as the business’s knowledge. Some professions require more base knowledge than others, but it is still a continuum. I just think it’s a vague way to specify a profession.
If you stood in a flat, empty field and looked across at your goal, it would be easy to answer the question. You have some idea how long it takes to walk a distance across a flat, open ground. The time it takes is just a function of distance to cover.
After you’ve conquered a few forest paths you begin to get an eye for the lay of the land. You begin to get a feel for the kinds of obstacles you’re most likely to encounter. That makes you better at using rules of experienced thumbs to calculate better travel estimates.
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.
