Wednesday, October 31, 2007

Resumes: functional or reverse chronological? The advice is generally to go back to reverse chronology

Mary Lorenz has a resume advice page today on CNN “Five easy ways to improve your resume,” and CNN introduces it with “is your resume awesome?” The link is here.

There is some disagreement among career consultants among the functional resume. Outplacement companies like Right Management, back in 2002, suggested a resume that lists “accomplishments” and decreases the importance of chronology, especially for job seekers over 50.

Recruiters, however, tell me otherwise. They really like to see a resume in reverse chronological order. True, as in the article, they like to see quantifiable results, active verbs, and brevity (eliminate redundant words and use sentence fragments within reason).

There are a couple of reasons for this. First, resumes need to be scanable for keywords. Second, employers are concerned about accounting for gaps in employment and eliminating the possibility of fraud. This is especially true for “headhunting” companies that place consultants with clients.

Recruiters disagree as to whether resumes should list activities basically unrelated to the job sought. That’s especially the case in a changing economy where people have down time, take “interim jobs” (that don’t always work out well), or earn incidental income (that doesn’t mean “off the books”) from volunteer-associated activities or even blogging. They don’t want to distract their clients (there is the “too much detail” problem in business and sales), but they want to eliminate possible red flags. This is a tough call, as the Internet complicates the way people are perceived when others find them online, as on social networking sites and blogs (which happens much more than many job seekers realize).

Update: Nov. 11, 2007

Mary Ellen Slayter, career writer for The Washington Post, has a column today (page k01) "Accomplishments, Not Duties, Jump Off the Page", here.

Wednesday, October 24, 2007

How things changed

As I look back over my "career" since 1970 with some historical perspective, I see, indeed, how things changed, and how perspective on a career evolved.

I started out in defense, moved over to vendors and then to commercial financial applications. By the mid 1970s I saw that mainframe applications program was a whole "culture" of values -- perfectionism, and a higher than usual stable income but relatively few perks. The deal then was to "get IBM" and then it became, get IMS and CICS. By the late 1980s the minis were coming in, and then PC's, but it took until the 1990s for people to catch on to the concept of end-user driven computing. First they would do it with DOS and Windows 3.1 applications, and by later in the 90s (as java exploded into the market like a nova) the Internet.

It was no longer possible to make a good living as a "generalist" like it once had. You could "switch" to client-server from mainframe after Y2K but not specialize enough in anything to get another job. You needed to actually develop and implement something to really understand the technology; starting out in support would not be good enough. Then, if you took your retirement, you would find yourself at home, gathering together your skills, finding that vendors would almost give away something like Visual Studio and various SQL's, to see if you could build your own paradigm on your own and make yourself famous.

How quickly times changed.

Monday, October 22, 2007

Again, more reports on shortages in technical sales people

About a year ago, Bob Weinstein had a syndicated column called “Can Techies Sell” and I wrote an entry about it Oct 2 2006. Today, in The Washington Times, Recruitment Times, p. D3, there is a column “Severe Shortage of Technical Salespeople.” Once again, Weinstein poohs the notion that sales people can sell anything, at least in technology.

The great “myth” is that techies are introverted and don’t like to manipulate people as people. In fact, you have to “sell” even to be successful bringing in revenue or just a public reputation with your own content. But, from a psychological point of view, one can understand the resistance to sales culture for its own sake – cold calling, developing and trading leads, schmoozing, manipulating, putting on misleading appearances.

Some people, in fact, get a source of psychological identity in their skills in manipulating others. They may well justify this in terms of their own families, a psychological mechanism that more introverted people could find phony.

A much better fit, as Weinstein says, is the concept of sales engineer – a job oriented around customer service and solving business problems, in support of a marketer who may take more of the responsibility for generating leads through “social” contacts. As Weinstein writes, sometimes such a job does lead to a better understanding of how a business works, and what it takes to support the bottom line.

Even so, many sales jobs that companies offer seek sales experience rather than technical experience, even if the sales experience (including meeting quotas) is in a different area.

A main issue for me is how “public” the job is. If the responsibility is to sell something that I had a hand in developing because I believe in it, there is no problem, even if it means setting aside everything else I do publicly – something I have already discussed on these forums. But I would never want the reputation of a peddler.

Monday, October 01, 2007

Object oriented COBOL and a political science application

In developing the Political Argument and Facts project (look in my main blog, for example here), I thought it would be useful to describe how it could be implemented in COBOL, with object oriented concepts. Of course, a project like this might be more likely to get done in a language like java, C# or C++, with considerable sophistication in architecture for web interface. But it’s helpful to think about how this might be done with older, essentially procedural languages that may be more familiar to many IT professionals.

Remember the basic components of such a system. There are objects, which comprise data and methods to operate on the data. In a system, in practice an object exists as a reference to a location in memory. A template for an object, with data layouts but no data, and corresponding methods (procedural code) is called a class. An object is created by instantiating a class (sometimes with a “constructor.”)

Murach, in his COBOL text, gives an example of a book inventory application. An analyst does some functional decomposition to identify the classes and objects. In Murach’s example, the objects can be “book inventory” (an item), file manager, book manager, and user interface.

In this “political science” application, the “objects” (again, corresponding to template classes) would be arguments, incidents, facts, media references, authors, and resumes. “Facts” could well be “subclasses” of “incidents” as they would be simpler. (An example of a “fact” would be the text or a specific state or federal statute.) From a resume, one could determine if a given author or contributor was a “professional” or “amateur.” Media would comprise books, periodicals, websites, movies, and television series and programs. Whereas in Murach’s example a “book item” is the specific object for a class “book” (that is, “my book” is really “my copy of the book” – definitely relevant to copyright law!) in this application, a book is really the piece of intellectual property. A better decomposition is with periodicals. The meaningful object will usually be a specific “periodical article” that usually has specific dates, page numbers, author, publisher, etc. The information roughly corresponds to footnote or bibliography information in a high school or college term paper.

Microfocus COBOL provides one template for object-oriented code in this language. Mainframe compilers may have templates that are a bit different. The overall scheme starts with a driver program. In the Environment Division there is an Object Section and a Class-Control that enumerates the classes. The Data Division, in the Working-Storage section, will contain (binary – computational) object references words to all of the objects in the application. It also contains working storage areas with the data items that apply to each separate object (for each separate class). The Procedure Division will start with an INVOKE of an object to create it with a “New” option. It then will invoke the various classes, and the applicable methods in each class.

Each class itself becomes a compilable COBOL program. As with the main program, in the Environment Division there is an Object Section with Class-Control that enumerates the classes. There follows an “Object” declaration with a “working-storage section” for that class, followed by a Procedure Division with the Methods for the class. What looks odd is that each Method itself has a Data Division and Linkage Section with the data values for the particular object that the method must work with, and a separate Procedure Division with the statements for the method. The program source ends with an End Object and End Class statement, even within the context of the Environment Division, and this will seem odd to programmers used to procedural use of COBOL.

It’s important to remember that this environment seems to suggest computing environments that may have been popular more than a decade ago, when software vendors wrote DOS applications that did not even require Windows (or something comparable) and where companies wanted to deploy “end user” controlled applications on their work stations, well before XML and web integration became more standard.

So how would this play out with my proposed political application? It’s useful to think about what a typical application might be. One idea would be to trace all the arguments related to a particular topic, say, “mandatory paid maternity leave.” I’ll leave aside for right now the political and social controversy and just say that there seem to be compelling arguments on “both” sides. The application would first invoke the class to look up the argument (maybe by a free form key – certainly an SQL lookup with the appropriate error processing). It would then invoke another class to track all the “incidents” related to each side of the argument. For each incident, it would have to invoke still another method (with some linkage parameters for positioning) to display the bibliographic objects, such as book or periodical or web references. (Such a program might provide hyperlinks with embedded image files, in a manner similar to the way banks and insurance companies or even payroll companies may display information to secured visiting customers.) Finally, for each bibliographic entry, it might provide the resume “object” of the contributor, so the visitor could assess the professional credibility of the source of the information. The visitor would experience as set of professional looking web pages, linked forward and backward conveniently (perhaps with indexes displayed in a frame) and in a ten minute visit could assess what is really going on with a controversial issue like this. With such an application with all the factual information so well organized and publicly available, politicians would have a harder time with one-sided behavior.

Then consider how update applications would be designed. The argument class program would have a “create argument” method, which would accept the argument text and various items of supplementary information. In my own prototype, I have an item called “srcecode” which identifies a body of incidents or facts that would justify the argument. The method could establish (with an SQL Select) whether the “source code” has been used. If not, it could cause an incident panel to come up to force the visitor to enter justifying incidents or facts. The incident record(s) will require unique “incident codes” and bibliographic information which will in turn invoke bibliographic source class’s methods (I call them “media” in my own hard drive). There would also be “contributor” objects and classes that would process resume data for people who contribute to the database, in order to help establish the credibility of what finally appears to visitors.

Typical classes:

Fact (subclass of incident)
Media item (could have different classes for books, periodicals, movies, websites, with subclasses and common methods – polymorphism)
Contributor (with resume)