But don’t add so many tools that your toolbelt trips you up. Programming hed: The best tools for you dek: but don’t add so many tools that your toolbelt trips you up. dek: when picking a language, it sometimes pays to buck the mainstream. dek: the programmer who isn’t careful can easily be overwhelmed. By Nelson King
Learn a programming language, become a programmer, right? It’s not quite that simple. For one thing, what programming language should you learn? For another, there’s a lot more to programming than writing code. In the previous two parts of this series on becoming a professional programmer, I’ve covered the environment and mindset of a programmer. Now it’s time to get down to some nitty-gritty.
A professional programmer needs to master the tools of the trade. I suppose the term “tools of the trade” may not sound very exotic. Sorry, but there’s not much about programming that’s exotic. It’s complex, demanding; even mysterious at times. But it’s still a profession that requires knowledge of specific tools coupled with practice and experience. What are the tools of the trade? Loosely, I’d call it a programmer’s toolkit. The toolkit (which is mostly in your head) contains mainly two types of things: languages and framework knowledge.
The first part is obvious: Even the most blasé of programmers needs to master one or more programming languages. The second part is more nebulous, but just as important: The programming framework consists of knowledge about software components and how to make things fit together. It includes things like software development environments; design and profiling tools; operating system utilities; and a whole lot more. I’ll get into specifics shortly.
How long does it take to acquire a toolkit? Oh, about a career, to be flip about it. That’s just a way of saying that programmers add to, modify, and forget things from their toolkits throughout their careers. Is this toolkit important, or am I just making up a catchall term? Both. What’s in your toolkit is very important if you want to make a go of professional programming-it may determine not only your employment but also your various rewards (monetary and spiritual).
Of course, there is no standardized way of describing what a programmer needs to know or to specify what should be in a programmer’s toolkit. Programmers should build their own toolkits; what I’ll try to do is point out some guidelines.
There’s gotta be a better way
Eventually every programmer discovers that much of programming is difficult–time-consuming, frustrating, prone to failure, and even tedious. This discovery leads some programmers to believe that there must be better ways to do what they do. Anything that makes programming easier, faster, better (and maybe cheaper) is generally good. The impulse to improve the practice of programming along with the changing environment of technology motivates most of the changes we see in programming every decade, every few years, and even every year.
If I had to pin down in a few words what good programmers strive to attain, it would be conservation of energy. Some writers simply say programmers are lazy. I prefer to say they want to work smart. In reality, there is an enormous amount of programming to be done and programmers get paid for finishing work. Hence the desire to get as much good work done as quickly as possible.
What should differentiate professional programmers from amateurs is how efficiently they can accomplish software projects. They know the language(s) needed; they have a background in the methods (such as object-oriented programming); they know the development environment; and they know how the software in the project is constructed. They know shortcuts and pitfalls. In short, professional programmers bring to a project a toolkit of programming specifics and their accumulated experience.
“I can program in six languages”
Almost every project leader and IT manager has interviewed an programming applicant whose résumé lists several programming languages, such as C, C++, COBOL, Fortran, Visual Basic, and Java. You ask the applicant about the list and they puff themselves up and say, “Sure, I can program in six languages.”
Most of the time, somebody who says this has just revealed that (a) they don’t know much about programming and (b) they don’t know that programming is more than knowing a language.
Effective professional programming requires not only mastery of a language, but also the mastery of the methodology and techniques involved in using it. It almost always means mastery of a software development environment. Learning all this and putting it to good use is not trivial work. None but the most gifted programmers (and sometimes not even they) can manage more than one or two languages this way–at least at the same time.
Of course, almost any programmer can learn a new language, and sequentially you may learn several. There are similarities that help the learning process, but to cover all the practical ground as well as the language is a tall order that usually takes months, if not years. Most programmers can’t master any language quickly, even if they’ve learned several over the years. Maybe the honest thing to say is “I’ve learned several languages. Currently, I’m best at .”
Here’s a pop quiz question: What’s the most-used programming language in the world? If you said Java, Basic, C, or C++, you’re wrong. It’s HTML. Sometime during the past couple of years HTML took over the No. 1 spot from Basic. Of course, there is a quibble–is HTML really a programming language? Technically, no. It’s a markup language–something used to identify sections of a Web page. Functionally, however, the differences between what HTML can do and what a traditional programming language does are not very great. On the other hand, HTML is a deficient programming language and needs lots of supplements to make it work for more complicated applications.
Consequently, it’s worth some time to figure out what language (or languages) you’ll choose to master. As I said, this isn’t an easy choice. For one thing, there’s a certain amount of trendiness that goes with languages, and what is trendy today may make you unemployed in a few years-just ask people who became experts in Forth or Lisp. There’s also a tendency for typecasting: Once a Java programmer, always a Java programmer. Finally, the language you choose should also be closely associated with the type of professional programming you want to pursue.
As I mentioned in Part I of this series, if you want to work for big corporations, create commercial software, be on your own–or whatever–the choice of programming languages can help you move in that direction. A good example is C++, which has long been the premiere development language for commercial software (the shrink-wrap variety). Other languages (especially Java) are used in commercial software houses, but a mastery of C++ is more likely to get you a job.
There are other associations–HTML for Web page development, Java for Web applications, C or assembler for low-level and embedded software (hardware drivers, appliance controllers, etc.), and Visual Basic or Delphi for corporate applications. To this list you can add some very new languages such as XML (Web) and C# (corporate). There’s plenty of overlap and many exceptions to the use of languages, but the associations I’ve just listed can be considered mainstream.
Of course, when picking languages, you can buck the mainstream. There are many languages used for specialized applications-for example, Perl and tcl (Web CGI scripts), or Visual FoxPro and PowerBuilder (corporate database applications). Entire careers have been fashioned around specialized languages, but you need to be aware of how their limited use may affect your marketability in the long term.
All the world’s an object
One aspect of programming–and the programmer’s toolkit–that should cut across language and framework boundaries is object-oriented programming (OOP). For the last four or five years, OOP has been the dominant way of programming. And this should not change in the foreseeable future. When it became mainstream during the early ’90s, it was a major step forward in solving some key problems-notably the ability to reuse code.
I mentioned that efficiency is important for programmers, and OOP does that by creating objects. For a trivial example, say you have a “bell” object. Using any number of OOP languages (Java, C++, C#, Visual Basic) you can program the bell object to make a bell sound when called by another object (or program). You can give it specific properties, like different bell tones and duration of sound. Then, whenever you write a program that needs a bell sound, you can use this same bell object. Write once, use many times.
The OOP model has taken the programming world by storm. It also caused large numbers of programmers to retool (and it wasn’t easy). I don’t think I’d get much argument that somewhere along the line all professional programmers should be familiar with–if not expert in–OOP and at least one OOP language. The object-oriented programming model itself explains how objects are constructed and used together to make programs, and for the most part this applies to all OOP languages; it’s currently the most important element of the programming framework.
There’s another term–application frameworkthat’s an important buzzword at the moment. It’s related to the concept of a programming framework. An application framework specifies the components that make up an application: forms (screens), menus, reports, database environments, and so forth. Very often an application framework is associated with a particular language and a commercial development environment–for example, the application framework of Java within IBM Visual Age for Java.
One of the hottest trends in programming is the use of components, specialized objects that can be cobbled together to make applications. For the most part, this is an OOP approach, although components are quite similar to what programmers used to keep in their libraries. The term library is still used (Java, C++) to mean a collection of routines, functions, or objects that are intimately familiar to the programmer, and which can be used to create larger and more complex applications. Components, singly or in libraries, can be purchased; a programmer or a company often may create some of their own.
If you’re into application programming–and the majority of programmers are–then an application framework is relevant. It helps by defining the elements of an application and showing you (in a given environment) how these elements are combined. A programming framework is a similar idea, but with a broader context; it is composed of things that help a programmer in general, such as knowledge of database management systems (Oracle, IBM DB2, Microsoft SQL Server), network protocols (HTTP, TCP/IP), distributed computing specifications (CORBA, DCOM), operating system functionality, and specialized programming tools such as modelers, profilers, and debuggers.
As you can see, the idea of a programmer’s toolkit is broad in scope. It ranges from programming languages to knowledge of specific platforms (software and even hardware). It includes things that are peripheral to coding, but important for efficient creation of software. This brings me back to our original motivation–making programming easier. When you add skills, knowledge, and specific software tools to your toolkit, the object is to make you a better programmer and to make programming easier.
It would be relatively simple if all a professional programmer needed to do was learn a mainstream language (say Java), an appropriate programming framework (the OOP model), and a development environment (like WebGain Studio or Borland JBuilder). But even this much covers a vast amount of material and some very sophisticated skills. The complexity of programming threatens to overwhelm the programmer; there’s a struggle between improving your knowledge (the programmer’s toolkit) and becoming befuddled by it.
All the while the industry moves on–new platforms, new paradigms, new worlds. You also move on–new employers or clients, new programming languages, new items for the toolkit. You might as well hang a sign over your head: “Programmer under construction. Will learn for pay.”