Dr. Dobb's Journal May 2000
Dear DDJ,
I read Jonathan Erickson's editorial "Worker Shortage a Tall Tale?" (February 2000) and agree with many of his observations. I would like to add that it is difficult to find "good" programmers. Of course, many companies, General American included, hire contractors and consultants to perform software development. This is always a fun road. I have found through the years that we are witnessing a substantial decline in programmer productivity. Object modeling and code reuse have promised to increase this, but for the most part, younger programmers do not spend enough time with architecture and overall design, and older programmers are reluctant to adopt this approach. Many do not even have the skill set necessary to do so. Therefore, it has been my experience that we can easily find programmers, but as a whole they are not very good.
I define "good" as the ability to come into an organization and demonstrate increases in productivity and quality. Good programmers should be more like engineers than craftsmen. Many programmers do not even have their own "toolkits." When programmers come into an organization and spend six months to a year on one particular part of an application using one set of technologies, why would it make sense to move that person out of their specialized domain? In project management, we view people as resources to component development. This makes them highly specialized. Why would I have a transmission guy fix my car stereo? Why not have a dedicated interface design team, a data access team, and one just for implementing business rules into MTS? Productivity and quality should increase. Right?
I think we are in the initial stages of the removal of the general practitioner -- (the generic programmer) to one that is highly specialized. Of course, as technology changes, their jobs will become obsolete, which will force them to change. This is right. What you spend your career doing is an intellectual choice that you have the power to make. If you make the wrong investment with respect to intellectual capital in the long run then society can provide training not compensation for that mistake.
I think it is correct that we are in an overall state of excess demand for certain skill sets. My problem is that the labor supply for these skill sets is inadequate and I think this is going to be a trend for this decade.
Jeff Cromwell
jcromwell@primary.net
Dear DDJ,
Jonathan Erickson's finding (February 2000 "Editorial") that people are looking for narrowly defined skill sets hits the nail right on the head. But the problem goes much further. It may be true that many of the "narrow-minded" may know how to program in C++, VB, or Java very well, but not have a clue about what is "good programming." It's probably also true that those "older folks" know very well what good programming is but cannot efficiently translate that skill into good VB code. I know a few of the young guys who love to spend their days seeing what they can make Java do, but don't invest the time in reviewing their programs for reliable, maintainable efficient design. But I also know a few of those that know what good programming is but don't spend the time learning to use the new tools. A common thread is that neither spends any time to speak of outside of "work" improving their skills in the areas of weakness.
I'm an independent consultant. I write custom database applications for a variety of platforms. I use (currently) Visual Basic pointing at a variety of SQL databases ...some on NT, some on larger machines, some on Linux. I spend at least as much time keeping current on VB, SQL 7, Informix, NT, Linux, and so on, as I do actually designing and writing code. I don't attend seminars, schools, or buy-a-certification training programs. I read new information. Try examples to see what can be used and what is fluff. None of this provides me with a formal credential. But then, I place little value in all the certifications available. That began years ago when I did network consulting work for a number of "Novell CNEs" that couldn't set up a print server. There's little difference today...many people with all the proper certifications know where to point-and-click to attempt to configure a network or a SQL database, but they haven't a clue what to do (other than call Microsoft) when that doesn't work. My own son worked with me for six years and was lured away for a pile of money by a networking company full of "certified" people. Being young, he was initially impressed by all the other techs there that spent a great deal of time telling them all about the training they had and knowledge they possessed. Then he realized that once they pointed-and-clicked, they were done. They had no idea what they were truly doing. His latest incident was helping another tech with a Linux box that provided DNS for their (and their client's) networks. The NT tech typed in the command (from a scrap of note paper left from a prior employee) that was supposed to alter the configuration. When it didn't, he said "Well, I guess we have to reboot it." My son said "This is not NT" and proceeded to put in the correct configuration command for him. When they get in a new piece of hardware, he grabs one, takes it home and by the end of the next weekend, understands it. His peers poke fun at him. The younger ones are perfectly happy with their "Cisco Certification" and quickly inform him that they already know everything about it (even though it's a Livingston Postmaster!). The older one's don't even speak to him...they think he's speaking Greek most of the time anyway.
Where does all this ranting get us? This business is like any other. If you take pride in your work, have a particular affinity for the work, and you like the work you do, you'll put in the extra effort on your own to improve. If you are simply interested in money and a good job, then you are more concerned with having nice entries on your résumé. Don't get me wrong. I love all those guys in the second category. They get the nice corporate/government jobs then contract people like me to get the job done.
Jim North
jim@nov8.net
Dear DDJ,
I was tickled to see Larry Sollman's suggestions in "Letters" (DDJ, March 2000) on the daunting task of buying a technical book. I have additional hints to offer:
J. Stephen Riley Silber
jsrs@moselle.com
Dear DDJ,
I was gazing at Jonathan Erickson's "Editorial" (December 1999) and the accompanying photo of the "Kryptos" sculpture, and a couple of possibilities for deciphering it popped up in my mind.
Just some random ideas from a devious mind, please pass them on to someone who has better deciphering skills than I if you so desire, perhaps even Mr. Stein if you think the ideas have merit.
Graham M. Sherrington
sherro@loom.net.au
Dear DDJ,
In the February 2000 "Letters" section, Bart Samwel posed an interesting question to Jiri Soukup, author of "Data Structures as Objects" (DDJ, October 1999), about putting objects into bags and sets. Is it enough to consider the properties just of the containers? Don't the objects being put into them have characteristics affecting the issue?
Of the examples Bart uses, a copy of any one issue of DDJ is an instance of an object, which is identical to all other instances of its type. It is a concrete isolable object in its own right -- though of course it has a dependence on the structures which give birth to it. A 1 is not like that. Outside of pure math, it is not a concrete isolable object; it is more a property of an object; it cannot occur except as a sort of external attribute of something able to occur in variable quantity or quantities. A single copy of DDJ never has a 1 anywhere in its structure -- any 1 applicable to it is something its surroundings applies to it. Also, a 1 has a nature, which is less definitive than that of a copy of DDJ. The weight its surroundings lends to it depends on where in a group of figures it occurs; the 1 in 0.001--is it as identical to the 1 in 100 as one copy of DDJ is to another?
Ones and copies of magazines each combine with others of their sort in their own way -- yielding different sorts of product (perhaps more than one) as they do so. A set consisting of the figures 0 to 9 is different in nature from the set constituting a monthly production run of DDJ. And the difference originates at least partly in the sorts of thing they contain: In the former, each member is demonstrably different from all the others yet shares certain properties with them; in the latter, all are identical -- while each is still isolable. The real issue, is it not a system of attributes allowing reliable and consistent design, implementation and testing of collections -- custom-made as well as standard? Two-thousand-one -- is it a bag, a set, a collection, or what?
John Negus
john.negus2@libertysurf.fr
DDJ