He sits across the desk from you and you feel like you're talking to your father. According to his CV, he started out on IBM mainframes. He speaks fluent COBOL. You've never actually seen COBOL. He took a C++ class recently at the local university, but he's never used it on the job. His CV is obviously honest. He has more actual experience than the rest of your development team combined, but you're pretty sure he has no idea what HTML stands for. Do you hire him? You don't hire a CV
"He" could, of course, easily be a "she," but it's less likely that a middle-aged programmer will be female than male, simply because far fewer women were entering the profession in the late 70s and early 80s than today. It's irrelevant, as are many other details on that CV. You've done enough hires to know the CV isn't the deciding factor. But you don't often find yourself with an applicant who could have voted for Jimmy Carter. You find yourself wondering what, exactly, you should be looking for. You can make several assumptions safely. First, this individual is probably coming from a company that collapsed, or was gobbled up, after years of stability. Twenty-year veterans who still write code or do design for a living tend to remain in hands-on positions, rather than migrating into management or training, only in environments where they (and their skills) become entrenched. Second, this individual is almost certainly very competent. Failure has real consequences in hands-on development, and few people last 20 years at it if they aren't highly skilled. Finally, this individual loves what he does. Facing the end of a long run with a single employer, this individual wants to join your development team -- facing younger, fresher competitors. This person probably has the experience to pursue management but chooses to be here. Conclusion: This applicant loves development. Skills within skills
When evaluating an employee from the "Second Wave" era -- the age of hierarchical management and waterfall methodologies --it's important to have a sense of history. "IT" was "Data Processing," and it differed in more than just form. The entire mindset was different. Code was seldom reused; testing was done at the end, and only at the end, of a development project. There were no "software tools" in the contemporary sense. Programmers tended to work alone. They had to understand "job control language," or mainframe hardware instructions, intimately. Designers (analysts, in those days) tended to interact only minimally with programmers, and users were lucky to have 15 minutes of input at the very beginning of a project. Yet systems were built and put into production, somehow. And to work effectively in an environment like this, programmers had to have certain qualities that you can pretty much count on finding in the veteran COBOL programmer. Meticulous code review
The COBOL veteran had to fight for processor time against dozens of other programmers and hundreds of users. It was nothing like the do-it-at-your-PC, compile-time-0.8-seconds process we have today. Compiling a program often meant waiting in line, and a single mistake could cost hours. The successful programmer knew that it was important to get a clean compile on the first or second pass. So your applicant is diligent in writing the cleanest code possible. It is altogether necessary today? In our lazy, resource-fat age, no. Is it more professional? Absolutely. Effective, well-planned testing
If compile time was rare back in COBOL days, hardware time was even rarer. In an era when testing a new system meant gathering up a handful of test tapes or drive packs and booking time on the drives for a test (often during holes in the production time schedule), it was foolishness not to have a system test planned to the smallest detail. Imagine applying such careful attention to detail to today's more complex systems. Solid documentation
This applicant grew up without today's ubiquitous software development suites. Self-documenting tools and techniques didn't exist. COBOL itself is, of course, self-documenting, but this person documented system design and development with notebooks and hand-drawn flowcharts. You can count on a serious attitude toward capturing detail that will be useful to others. Loyalty
When an employee stays with their craft for as long as this person has -- especially in these job-hopping days in IT -- it's because they find value in something other than a paycheck. They wish to invest in the environment that receives them. It's in their makeup to give you their best, and to go the extra mile for you. The value of mentoring In the days when employees stayed with a company for many years, mentoring was the rule, not the exception. A young IT professional was mentored early on and invariably became a mentor in later years. Your applicant has probably been through both phases. Now, consider your under-30 brood, and consider how good your team could become if its members could soak up some of the qualities this COBOL programmer brings to the party. My personal COBOL guy
My own COBOL guy was named Judy. She had been in the business a little over a decade when I was a neophyte programmer in the Reagan years, working with her at a life insurance company. Female programmers were rare, and female programmers with experience and authority even rarer. I, too, was a COBOL jockey, writing hybrid Command-Level CICS code (don't ask; you don't want to know). Judy gave up lunch breaks to review my code. I learned to get it right the first time, and I learned that a true professional doesn't think twice about working through lunch, or staying after hours, if that's what it takes. She taught me to have my test plan perfected before I booked the first minute of drive time. Working with her made me work harder; I wanted her to respect me the way I respected her. She taught me patience and perseverance. Most importantly, she taught me to do what she had done: to invest myself in my younger colleagues, when I myself had some experience under my belt. Make the call
If you look closely at the man or woman sitting before you, you'll see a glint of dignity staring back at you. You're not looking at a future C++ whiz -- it'll never happen. And there may not be any brilliant Web design lurking there. But what this applicant offers your team, no university or cyberpunk mojo can provide. Your team is lean and mean because the industry is lean and mean, and that's what the market demands. But as important as it is to know how to hunt, it's just as important to know how to plant and harvest. A good manager knows the difference and how to leverage it. Hire the COBOL guy. Created by developers, for developers, Builder.com brings software developers fresh, real-world perspective on topics from programming to architecture to management. Builder.com will improve the way developers work with the information, tools, and services to help them conquer the challenges they face everyday in real-world development.
ZDNet UK's Developer News Section delivers the latest headlines together with the best UK jobs, right to your browser.
Have your say on all developer topics. From j2ee, to C++, from Visual Basic to Javascript plus much more. Share your experience with others on the Developers Forum.
Let the editors know what you think in the Mailroom.
For all job and work-related news, or to search for a job and get information on training, go to ZDNet Jobs. If you have something to say about work and employment issues say it here at the Jobs Forum. Let the editors know what you think in the Mailroom.
