This is a different type of post. I know there have been a number of posts by others talking about millennials in the workforce (Wikipedia by Google: "
Millennials (also known as the Millennial Generation or Generation Y) are the demographic cohort following Generation X. There are no precise dates when the generation starts and ends. Researchers and commentators use birth years ranging from the early 1980s to the early 2000s.) My college teaching career, to the current day, stopped in the middle of an early 1990s recession. Most of the people I've worked with in my post-academic careers have been more experienced Baby Boomers or Generation Xers.
Now I've probably mentioned my first real professional job (after earning two math degrees and a short stint teaching at a Navy facility) was in an end user support area for the property actuaries in a well-known insurance company. Basically, end user support was IT resources dedicated to the area vs part of some big IT department. Actuarial applications were often written in an IBM-developed rapid programming language called APL; APL is a concise, powerful, mathematically-notated interpretive language that reads from right to left, and the company had problems trying to retrain COBOL programmers to do APL. The company decided, given my MA in math, to hire me as the trainee in a 4-person area.
The first employee, Joe, was a middle-aged programmer who had started out on the property actuary track. At the time I think you had to go through 10 exams to get certified as a fellow. I don't know why he washed out of the exam track but he eventually transitioned into computing support. I think he had some military-related hearing disabilities, not unlike my Dad. For whatever reason (his lack of managerial experience, past history, communication issues, etc.), the actuaries decided not to make him supervisor of the team and decided to hire experienced Blue Cross personnel to the outstanding supervisor and staff programmer positions. The supervisor candidate backed out at the last minute.
The company told Joe to take on training me, but the first day Joe said to me, "Nothing against you, Ron, but training others is not in my job description." So basically I had to train myself. About 3 months later, the actuaries decided to hire an IT department middle-aged guy who had been instrumental in installing APL (but couldn't read a line of code and didn't have a college degree) as the supervisor. From day 1, Jesse made it clear he wanted me gone: he was intimidated by this 23-year-old kid with an MA in math. He told me directly, "The only way you can advance in this company is through my position, and I'm not going anywhere." When I eventually left the company a year later, he replaced me with someone from the general office support staff, without a college degree. He had no incentive to assign me to a high-profile project and worked a number of gimmicks to force me to resign. One example is he arbitrarily took a project assigned to me and decided to give it to a summer intern and basically put my nose into it by assigning the kid's crap back to me when he went back to school.
But I learned enough APL to attract an offer from the largest APL timesharing company in Houston. (The timesharing industry gradually folded under the onslaught of cheap PC computing by the time I earned my doctorate. In general, timesharing was a bridge solution to buying another expensive mainframe. We basically offered an enhanced version of APL and metered access to rapid prototyping applications to managers working around backlogged corporate IT. One anecdote I remember from that first employer was a colleague looking for an input-processing utility; I quickly fashioned some code off the top of my head. The colleague measured the cost at about 80 cents; the branch manager tried his hand multiple times and never got closer than about $1.15. On another occasion, an Exxon client wanted me to devise an application for tracking timesharing. I had very little to go on beyond his initial comments; he was absolutely thrilled and told me that my utility was spreading like mushrooms around Exxon--at least 15 more implementations.)
Now the reason for mentioning the above is not to brag about past accomplishments or to argue they're unique or significant, but to point out one basic thing: one often has to deal with uncertainty in professional environments, and your ability to be productive under poorly defined circumstances is something prized by employers. I used to tell my students, "Employers aren't looking for someone to simply retype someone else's code." [Some professors used to hand out pseudocode assignments.] I used to do my fair share of maintenance programming, written and patched by different people with alternative coding styles, uncommented code, little or no documentation. I've gone into gigs with literally less than 2 days of transition with a departing DBA, still others where I replaced a terminated DBA with zero transition. I've worked for managers who literally could not do my job.
I haven't really discussed Oracle DBA work in the blog, and I'll try to avoid to be unduly technical in my discussion. I went onto an Oracle EBS (ERP) project a few months back [I have significant experience with EBS as well as general DBA experience]. One unexpected development was my hiring manager was in the process of transitioning out of the company, was no longer a manager and spent much of remaining time at home in Idaho. (The project is on the East Coast.) He had made a couple of trainee type hires, one a young woman with little professional experience hired a few weeks before me, the other more of a middle-aged Windows administrator. Other colleagues included more of a senior general Oracle DBA from Michigan a couple of weeks before me and a CPA female who had migrated into an EBS DBA role a few years back. The Windows administrator quit (in the middle of a staff meeting) shortly after my Idaho colleague left the project. The Michigan DBA, who was in the midst of moving his family to the East Coast, got an offer from a former employer to stay in Michigan. Another functional team member just accepted a federal civil service position. So we were down to 3 project staffers and were warned that project funding could dry up by September or even next month.
For the most part, the CPA and I have been doing the real work. It's not really clear what the trainee was doing from a project perspective; it seemed she was studying from some Linux (operating system) manuals and some Oracle course training using a PC database. The CPA tried to mentor her shortly after her hire but quickly turned sour of what she thought was gross incompetence; in particular, the young woman didn't even know how to create a shortcut on her desktop.
I've been more patient with her requests, but there have been some circumstances that had me shaking my head. One is what I call the scp (secure copy) incident. In a typical cloning environment (say, for a test or development database) you might copy software and database backup files to the target server. So I was demonstrating the process from one of our backup servers to her personal virtual machine (think of a computer in a computer; she was running a Linux virtual machine on a Windows PC). She even took notes on what I was doing. In any event, 2 days later she asked for help from the Michigan DBA (Bob) . I hear them talking about scp, and Bob is going to Google at his cubicle to look up the syntax of the scp command. I flatly don't understand this at all; why was Bob doing this? Couldn't she look up the syntax on Google herself? It's bad enough she didn't seem to remember what I taught, with notes, 2 days earlier.
A second puzzling example was maybe a week or two back. She was having difficulty bringing up the database "Agilex" on her PC. So I go to a location where there should be an initAgilex.ora file. I found nothing but an initorcl.ora file. I source orcl and connect to the database--and find the database "orcl" is already up. She says there's only one database on the box. So why had she tried to start up a nonexistent database?
A third example is her conceptual misunderstanding involving wildcards. For example, suppose that I want a file from /u01/app/abcdefghi. If app was the only directory under /u01 and only one subdirectory started with abc, I could cd /u01/*/abc*. She never quite got the concept of wildcards down; she started to put asterisks everywhere; for example, suppose the app directory also included directory cghid. She would try *ghi*, which would fail, but *ghi would get there. I often had her do filtered greps (string searches) and she would often just attach * at the end of the search string. (You can use *, but it's a repetition character; the wildcard character is '.' Simply putting an asterisk at the end of the string filter could pull in results without the last string character.) I would ask her, "Why are you putting an asterisk in that expression?" I suppose she could have viewed the question in a defensive manner, but I was performing my role as a teacher or mentor.
More recently, she had been tasked with creating a repository database. I had to tell her how to structure her task--here's where your find documentation, here is the process of installing the 12c software, downloading a template for the repository and running dbca. Oracle often zips database software under the same directory across different zip files; if they aren't combined, Oracle Installer won't work. She asked for my help in merging zipfiles: something I had previously demonstrated to her on multiple occasions. (Actually it's very simple: you simply unzip one file in a working directory and you unzip the other.)
Last Friday she once again came to me for help in resolving prerequisite issues for database software installation. Briefly, there are operating system requirements, including (on Linux boxes) kernel requirements, package version prerequisites, some user oracle setups. Now I have personally walked her through these (on an earlier version of software) 2-3 times. She had stopped at the Oracle installer's prerequisite check screen; among other things, none of the kernel parameters had been adjusted. She defended it, saying she couldn't find where Oracle documented the parameters. (It took me less than 5 minutes to find it.) I quickly guided her down to a remaining 2 patches with some dependency problems. (Her trial license had expired; I suggested an alternative solution, but she refused. I think she wanted someone else to get a trial license so she could use.) There was a first button to refresh her prerequisite check (although we already knew two packages had failed). She was pushing back and wanting to use a different button option.
It's not clear why she got upset; maybe she was impatient at how I was walking her through the interface; maybe she was on the defense because I wanted her to explain her actions with the interface; I was totally professional and patient; I never made disparaging remarks at any time, I did not scream at her.. At some point around refreshing the prerequisite check, she accused me of being a "hothead"--and walked of her own cubicle on me. HINT to millennials: this is extraordinarily disrespectful, unprofessional behavior; I have seen people discharged at a fraction of the provocation. I have never addressed a boss or senior colleague in a judgmental fashion, never mind the hand that is feeding you. It wasn't the first time she pulled this walkout stunt. I recall on a prior occasion, she told me "Dude! You need to chill!" "You're grumpy..."
On Tuesday she sent me an email to the effect "I hope you're mature enough to get past what happened on Friday." She went to say that her Oracle software installation blew up. I wrote back and asked whether she had fixed her packages or had she decided to ignore the warnings and proceed with the install. She basically confirmed the latter. She sent a final email some time later, saying that she had a new job and she was leaving sooner than later. I could take over her server for all she cared. And she said something to the effect I had some good points, but there was a side to me she didn't care for. Classy to the end.
I would not have hired her; I will never serve as her reference. It doesn't have anything to do with her unprofessional behavior. I simply could never trust her in a DBA role. She is too impulsive, impatient and reckless; I've seen incompetent DBA's set back projects for weeks or cause hours of downtime in a business day.
All that time I invested in her professional development was for nothing. I have mentored dozens of developers or DBAs over the years, not to mention former college students. I doubt I'll ever invest that much time with a junior team member in the future. I know she'll never find anyone who is willing to mentor and help her like I did.
Another minor point: cellphones. I know a lot of people, not just young people, are obsessed with their phones. I get only a fraction of calls of other people, but if it goes off in a private meeting, say, with a manager, I'll send the call to voicemail and turn off the phone. It seemed like this young woman's phone at times was going off every 3 minutes--her mother, her boyfriend, whatever. If someone is taking the time out of his schedule to help you, interruptions can be very rude. Now the lady did sometimes not take a call, but it seemed over a number of sessions every time I thought we were making progress, the phone would go off, and it would take 5 minutes to get back on track. I never really lectured her over her phone (perhaps she was aware of my annoyance, but that should be obvious and a matter of common sense and consideration).
It's difficult to generalize from this one case study. But some advice for millennials:
- show some initiative and a hard work ethic
- be respectful of your senior colleague's time constraints
- show some genuine appreciation and gratitude
- be tactful in how you address and communicate to your colleagues
The young lady in this post is headed for a failed career; she had extraordinary access to her hiring manager (Idaho) and me, and it was not lost on her managers she constantly seemed to be seeking my help, six months into the job; I suspect they were in the early stages of her termination. I asked the CPA how long she thought the new job would last. "Two weeks." That long, huh?
