Subj : Re: Software Job Market Myths To : comp.programming,comp.software-eng From : rem642b Date : Sun Aug 21 2005 03:47 pm > From: Ben Pfaff > Among the hallmarks of a professional programmer are flexibility and > the ability to learn *quickly*. A professional programmer should be > able to bring himself up to speed on a new language, a new library, a > new protocol or specification, or an important new concept within a > matter of days or weeks. If that were believed by employers, they would have hired me at Java or C++ or VB programming way back in 1991 when I had never used any of those languages, because I could have learned them just as fast back then if given financial incentive as I actually did more recently without any incentive except FFW (Focus For Work) wanting me to and promising eventual help finding a job if I'd take those classes. But what you and I believe about people with lots of good programming experience isn't believed by hiring managers who expect new employees to "hit the ground running" instead of need time to learn the primary language of the job after already hired. Yes, it's reasonable that extras, but not the core language or system, should be learnable after already hired. The earlier posted seemed to be unaware of the basic jargon that would indicate any familiarity with the core knowledge of the hypothetical job being tested by that made-up aptitude test. > If it were me doing the hiring, I would be looking for people who can > learn and adapt quickly, not people who already know the popular > buzzword-of-the-week. So you would hire, for your computer programming team, some high-school student who had never written a single line of software but who was very bright and capable of learning it after hire? > I consult at a company one day a week. Some time ago, my boss > asked me to implement a particular feature. I figured out how to > do it. It would require me to modify our machine's APM and ACPI > implementations in the BIOS, plus add some "backdoor" features to > the chipset, as well as interface to operating system power > management features. I didn't know how to do any of this. So I > took a couple of days and read most of the ACPI and APM > specifications, pored over Linux source code and Windows API > documentation, looked at many machines' ACPI ASL code, read > chipset docs from all over. And then I wrote a bunch of ACPI ASL > code and x86 assembly for APM and modified the chipset > appropriately, tested the whole thing to the best of my ability > and wrote up a bunch of notes for QA, and put the changeset out > for review. Professional programmers should be able to do all of > that. No, not at all. What you describe is what a combined hardware/software engineer does. All that hacking with chipsets is beyond the scope of a regular (non-hardware) software engineer or an application programmer. It wouldn't be appropriate to expect a software engineer or application programmer to muck with chipsets any more than it would be appropriate to expect a pediatrician to perform brain surjury. I was going to ask you to make up a more representative example of what an application programmer should be expected to do, but since that's not your specialty, you're more into hardware and low-level drivers/interfaces, asking you for that example wouldn't be appropriate. Should I then recite some actual example where I performed a comparable task in my field? I already told about how I was presented with the general idea of making a CAI (Computer-Assisted Instruction, i.e. automated-coursework) program for calculus derivations, similar to the one that already existed for symbolic logic derivations, and how I promptly wrote up a proposed UI-transaction specification and then wrote an actual working prototype per that spec. http://groups.google.com/group/comp.lang.lisp/msg/81e64d42249b709f Message-ID: Would that suffice? That was at the beginning of the 5-year project that ended in 1991, so of course I can't remember whether it took me one week or two weeks to finish the working prototype. But you want an example where I had to look up something on the Web to satisfy the needs of my employer? Well back when I was last employed on a regular basis, in 1991, there was no such thing as the Web, and my boss totally disallowed using newsgroups because he believed they had no value except to divert time away from legitimate work, so I never had a chance to do that. If you don't require it to be for paying work, then there are many times in recent years when I was working on my own project and I needed to learn some particular InterNet protocol or whatever to make one more step forward in the project. I wrote my own software to perform as SMTP client, HTML parser, parser for multiple formats of WHOIS records (ARIN in two formats, APNIC, RIPE, LACNIC, and one of those changed to a totally different format about a year after I had my program working so then I had to write a whole new parser for that one to replace the old parser), parser for about a hundred different formats of Received lines in RFC822 headers, extra-safe interfaces for both stack-based toolbox traps and parameter-block OS traps for Macintosh system 6.x, assembly language code that respected both the FORTRAN-IV calling conventions used by IBM 370 and successor systems running VM/CMS and storage and register conventions of PSL (Portable Standard Lisp) running on that VM/CMS system, and a whole bunch of machine/assembly languages needed to do fast code at a time when the machine code compiled from high-level code was much too slow to be practical and the CPUs themselves were sufficiently slow that the difference between compiled code and handcrafted assembly language made the difference between a program too slow to use at all and a program that was fast enough to be practical. > A professional programmer should already know all of the basics: > algorithms, data structures, a few programming languages, many > concepts. Modulo the language you use treating a human being as if he/she were just a single-function device, I agree. I've been programming with flexible (Lisp) data structures for more than fifteen years total full-time equivalent, and long ago I had acquired enough years of that that I very well understood how to design data structures to aid development&implementation of algorithms, and could easily learn new languages with their particular kinds of data structures and control-structure syntax (the control structures themselves are pretty much all the same, various subsets of what Lisp offers, except in assembly/machine language where co-routine linkage (*) and the like are possible too). * (For example, fun1 does while true do read(coFun2), and fun2 does while true do write(coFun1), and each function is coded to be the toplevel function as if on top of the other, and co-routine linkage makes it actually work that way! I actually wrote assembly-language programs like that, avoiding the need to convert one or the other of the two functions to be a state machine with start and next methods called from the other which could remain as a single function.) > Applying all that to a new situation should be routine given the > amount of background that he (she) has. Pretty much routine I agree. Whereas programming with stuff you already know proceeds without any pause, programming with something new requires stopping actual work to go look up tutorials and/or references on the net and study them and think how they might be applied to the task at hand, and do some experiments with features that aren't 100% clear from the documentation, and then after the general idea and the details of the specific useful features are understood, the actual work can finally resume. One thing that is even more almost routine is using a new API function from a well-documented API such as Java, where you just go look up the particular class of interest, browse the methods to see which ones you actually need to use, and then immediately start writing code using those. (This assumes of course you've ever written Java code before and know how to understand the API docs. If you've never written a line in Java before, this is more like the first case of pouring over tutorials/manuals and doing experiments before you can start to write practical code.) > But I wouldn't expect that same programmer to have the comparable > background needed for a job in biology. Here is where I really must correct your poor wording whereby you treat a human being like a single-function device: A card reader cannot do anything except read cardsd. A keyboard cannot do anything except convert finger pressure patterns into patterns of textual data going into a computer. A pROM burner can't do anything except burn patterns of data into a pROM. You talk like a programmer is a device which can't do anything except write computer programs, not washing dishes, not cooking, not taking care of children, not operating a DNA sequencing machine, not driving a car, not filling out his/her own income tax forms, not putting a new roll or stack of paper in the printer, not performing simple bicycle repairs, not checking the oil level in a car, can't translate biological research papers from French to English even with the aid of BabelFish/SysTran to perform most of the vocabulary lookups, and can't invent novel uses for reverse-flow heat exchangers. The fact is, if the only thing you know about a person is that he/she is expert at writing computer software, there's no way you can conclude whether he/she can or can not do any of the particular tasks I listed above. Some people are so narrow minded that in fact they can't do any of those tasks, and rely on maids to prepare and serve their meals and take their dishes to the dishwater and operate the dishwasher and put the dishes back in the shelves. But most people you call "programmers" know how to do a lot more various tasks than just what you believe they can do. I, for example, understand enough about biology and genetics that I might possibly qualify for an entry-level trainee position in a DNA-sequencing lab. But I wouldn't gloat and boast in my belief about how I can learn stuff after I'm hired. I'd concentrate on what I do actually already know or understand, such as SNPs (Single Nucleotide Polymorphisms), the four DNA and RNA bases (although if the exact spelling of them is important I'd need to look them up), the genetic code (triples of bases map to single amino acids, and if I needed the exact mapping or the chemical structure of any particular amino acid I'd have to consult a reference table), etc. If I were asked specifics about such on a pre-employment test, I'd have to openly admit I didn't know the particular answer from memory, but give some indication I knew the general idea, instead of totally beg the question with remarks about ability to learn after hired. For example, if I were asked to name the 20 amino acids, I'd list Glycine, Adenine (not sure of that one), Tryptophan, Cysteine (sp?), Alanine, Lysine (sp?), Serine, and if asked to list several known proteins I'd list Hemogloben, DNA replicase, to show that even though I haven't memorized them all, I at least wasn't confused as to the difference between an amino acid and a protein. And if I was asked something I didn't know at all, I'd just skip that question instead of trying to snow the grader with remarks that's sufficient that I know how to look it up on Google. In fact, given the opportunity to use Google as reference while composing responses to articles, the earlier poster should have actually demonstrate his ability to use Google, like I'll do now (below), but first, citing the earlier poster "I have heard of most of those terms, but I couldn't answer any of those questions. I _could_ find out in fairly short order." and then repeating one of the terms he claims not to answer even one of the questions about: "Describe XML". If he can't say even one word about XML except that he could look it up if he wanted to, then I would never hire him. Lack of even the slightest understanding of XML precludes the kind of work where XML was one of the requirements. OK, in another post I already answered the questions where I already know something, including XML, so here goes with Google search for the terms I didn't know at all. No wait, I'm not even going to use Google, I'll just look in the index of a VB.NET book (Deitel, ISBN 0-13-029363-6) that my former VB instructor loaned me when I mentionned that I needed to learn .NET but there wasn't any .NET course available at DeAnza (except VB 1 which I already took in non-.NET mode and wouldn't be allowed to re-take in .NET mode): XSL = Extensible Stylesheet Language XSLT = XSL Transformations, which is a portion of XSD The two are discussed together: XSLT transforms an almost pure XML document (description of data, no info about formatting it for display in the bulk, only one stylsheet declaration near the start which tells the location of the XSL document which is used to specify the specific formatting rules) into an XHTML document for display. XSD not in the book, I guess I'll have to go to Google after all: Linkname: XML Schema Tutorial URL: http://www.w3schools.com/schema/default.asp XML Schema is an XML based alternative to DTD. It provides more detailed type-checking than is possible in the raw data types checked by a DTD. Linkname: XML Schema Part 2: Datatypes URL: http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/ xsd is a namespace used for some tags within an XML-schema file, for example Now if I had live access to any system that could take in a regular XML file and an XML Schema, and validate the former per the latter, then I might be able to play with it and get a true understanding of how this all worked in detail. If I were hired for an XML job, presumably such facilities would be available at the job site. Until then, I think I know about the right amount about the idea, more than the other poster seemed to know. (I already knew about XML stylesheets and XML validation via both DTD and Schema, I just hadn't memorized the specific abbreviations XSL/XSLT and XSD. But regarding XML, however, there's really no excuse for anyone in computers nowadays not to know what that abbreviation stands for! Saying you'll look up XML in Google, to find out what that abbreviation stands for, after being hired for an XML or .NET job, is unacceptable, IMO. As to the question about two ways to start a VB program: In the VB class I took two years ago, the only time I ever had access to VB, we learned only one way to start a VB program. But it was so long ago I can't even remember exactly that one way. If I had VB with one of my programs (or somebody else's program) sitting on-screen in front of me, I could surely look on the screen and find the correct button to push to switch from design mode to run mode, and it'd do the right thing. I'd be curious what the *other* way to start a VB program is, not counting anything involving .NET of course since that's not VB per se as the aptitude question clearly implied. I think there's some way to convert a VB application into an executable, whereby clicking on the desktop icon actually invokes run mode directly instead of invoking the IDE, but we never did that in the class. But at least I know how to use two of the three modes. (IIRC, debug mode never was of any practical use to me.) .