Committing time to answer questions is the crucial first step

This is Part 3 in my Series on Supporting/Managing Engineers

Configuring bridging, building bridges

Unlike software, systems, network, and voice engineering, regulated engineering disciplines require licensing. According to the National Society of Professional Engineers, a college engineering graduate candidate can "begin to accumulate qualifying engineering experience". What happens during these four years of post-graduate experience? "The experience must be supervised. That is, it must take place under the ultimate responsibility of one or more qualified engineers." Further, the experience is expected to be "high quality, requiring the candidate to develop technical skill and initiative in the application of engineering principles."

These are the engineers building the bridges you drive over, the flammable electrical parts you install in your walls, and the explosive power plants you live near. Society expects high standards because of the risks to health and safety.

So to advance in their field, those engineers seek out supervision. And because of the licensing, senior engineers must participate in the mentoring process. They have a valuable structure of mentoring.

But what about the "engineers" who run email servers, build voice networks, and write software? Generally, these information technology (IT) and computing disciplines are unregulated. Anybody can do IT as badly as they like, and we have no mentoring structures in place.

ASCII question, but got no ANSI

Computing has grown without formal, legally-mandated mentoring requirements because computers serve as self-checking devices: if the new programmer tries to do something crazy or foolish, it won't compile or it won't work.  Unlike faulty bridge designs, computing systems are relatively easy to test. If you try to build a network but don't know what you're doing, that network won't function.

But in IT/computing fields, mentoring is still needed:

1. IT Engineers often have questions that cannot quickly be googled or tested by experimentation
2. IT Engineers need to learn from the mistakes & experience of others
3. IT Engineers need review from other brains to help check their own ideas

It can be hard for a junior engineer to get a solid answer to a question. The best engineers are always busy, and they'd rather spend their time with computers, not people. For example, the Myers-Briggs personality type INTJ is  used to link introverted personality types to Computer Programmers and Engineers. For these introverts, answering your question is draining. "If you're a true introvert, networking is excruciating," writes Susan Adams in Forbes 2014.

So if you're learning something new,  how do you get your questions answered if you're among people who'd rather avoid people?

A Mentor commits to answer questions

With so many demands on a skilled professional's life, the key scarcity is the willingness to provide answers when questioned. So if you're going to be a mentor engineer,  be sure you're available to hear questions, and provide good answers.

That is, mentoring in IT Engineering is first about the mentor's commitment. The mentor has to be willing to take questions from junior engineers, and commit to answer them.

As a professional programmer, Jud McCranie answered hundreds of this author's written questions about programming through 1989-1993. He's a great example of a mentor, investing in answering questions of a curious mentee.

I had some great mentors as I was learning. Jud McCranie is a professional programmer I met through through a university-operated  Bulletin Board System in the early 1990s. He answered a thousand questions from me on programming, and even decrypted my amateurish encryption algorithms. He was a mentor because he took my questions and didn't ignore them. He challenged my thinking, often asking me questions I couldn't answer myself.  I'm always thankful for his patient consideration of numerous questions from a teenager. (McCranie is cited in one of Knuth's new volumes, the Art of Computer Programming.)

Another superb question-answering mentor was the late Jon Hamlin, an ex-CIA intern and graduate of Valdosta State University and University of Georgia. Jon was far more interested in system administration, networking and UNIX, and in his role as computer science lab manager at Valdosta State University, Jon had access to extensive SunOS/Solaris resources and the time to think about my questions. He setup a Linux computer and gave me access, and helped me clean up a few messes.

Both of these men put in hours of their lives to answer questions I wrote through email, and they're part of my motivation to answer questions for others.

Why it's so hard to get somebody to really answer a question

I just claimed that there's a scarcity of willingness to answer questions, so the first role of a mentor is to commit to be available to answer questions. Why is that?

1. There are lots of ignorant people willing to give bad answers. But you don't want them to be your mentor.

2. Competent Computing/IT Engineers are very busy. Getting a senior engineer to commit the time to mentor is a big deal. Photo: Tim Regan.

   It takes real time and expertise to answer questions. As Erica Friedman writes, sometimes you're expecting a simple answer about a complex system."Some answers attempt extremely top-level analysis, but few people will have time or expertise to answer a truly complex simple question."

3. Competent engineers usually prefer to stay busy engineering, not doing chit-chat. According to  John Hales of Global Knowledge, communication and explanation are not key character attributes for successful IT Professionals.
4. IT Engineers are often expected to make progress quickly, so they can't wait long for answers. As one contributor said on StackExchange, there's no time pressure to answer questions in online forums, and so it's easier to get questions answered there.

Because engineers who prefer results over talking, and the demands on competent engineers, it's hard to get a timely answer from a competent engineer.

The curious case of the unasked question

“I would rather have questions that can't be answered than answers that can't be questioned.”  ~ Richard Feynman

Once a mentor is available to answer questions in a timely way, the mentee must be willing and able to ask questions. Often they are not.

Michael Adams of Quizbean identifies several common reasons junior staff don't ask questions. For engineers, some key reasons they don't ask questions are:

1. Nervousness. "They don't want to be embarrassed in front of their boss or co-workers," Adams writes. This can be caused by simple anxiety, or excessive pride if they don't want to admit there's something they don't know. Antidote: So the mentor must make it easy and unthreatening to ask questions by readily enjoying the curious discovery of new facts. Computing fields move famously fast, so there are always new things to learn.
2. Avoiding annoyance. They don't want to ask questions because they perceive it to be inconvenient. Antidote: Therefore the mentor must actively invite the questions.
3. Bewilderment. The mentee doesn't know where to start because everything feels so unfamiliar. Antidote: The mentor should set milestones of capability to encourage steady improvements in comprehension; e.g., crawl, then walk, then run. E.g., Login to the server first. Then locate the logs. Then read the logs. Then understand the logs.
4. Previous trauma. The world is full of jerks, and many people have been criticized by those jerks for asking good questions. The mentee may need to recover from unhealthy work environment where legitimate questions were met with caustic attitudes.
5. Lack of curiosity. One of the most dangerous problems is a lack of curiosity in the subject matter. Mauricio Porfiri, a robotics researcher at New York University, says that "Being creative and being curious is more important than being the smartest or the best at equations if you want to be a great engineer." Albert Einstein said that "The important thing is not to stop questioning. Curiosity has its own reason for existing." The lack of curiosity leads to a dangerous complacency, causing the mentee not to care enough to bother to formulate questions or challenge their own assumptions, but to muddle through with the current level of ignorance. Computing is great because it encourages curiosity. Have a question? Try it out. A chemist or physicist or mechanical engineer needs equipment for a lab, but the Computer Scientist needs only a computer and the means to program it. Ayodeji Awosika writes about the dangers of suppressed curiosity in "The Theory of Nothing: Why Lack of Curiosity Leads to Mediocrity."

Beyond Q&A: The Weekly Mentoring Meeting

To support growth of a mentee, mentors can schedule regular time with the mentee. Just like the commitment to answer questions, the mentor must make make these meetings a commitment. Commonly, this happens as a weekly meeting to ask questions and plan progress.

Jim Anderson's approach to mentoring includes a weekly meeting. The advisee's next steps were documented on his office whiteboard for clarity and easy reference.

Jim Anderson, a Computer Scientist at UNC-Chapel Hill, followed a simple model of tracking progress for his advisees: he wrote the next steps for each of his mentees on the whiteboard in his office. Then they could easily see what was expected. And in each weekly meeting, he could easily recall their responsibilities.

Plan the route out of ignorance. Even in non-supervisory mentoring, it's helpful for the mentor to plan and track progress so the mentor ensures that the incomprehensible is coming into focus for the mentee. Without this guidance, the mentee may be trapped in a complicated area without a path forward, and without the ability to ask questions to get out of it.

Review recent accomplishments. The weekly meeting is also a good time to review samples of the mentee's work. The mentor can praise progress and identify the most important improvements the mentee can work on next. But even when identifying the next growth area, the mentee should recognize the mentor's achievements.

For example, for Computing/IT professionals, reviewing work can mean:

• Discussing interesting troubleshooting problems and the approach to troubleshooting.
• Reviewing system configurations to see how a mentee's task was accomplished.
• Reviewing source code.

Establishing Healthy Mentorship

To begin healthy IT/Computing mentoring,

• Get experienced engineers genuinely willing to answer questions: call them Mentors.
• Get other engineers with curiosity, who are willing to ask questions.

Photo: Merrimack College Mentoring Program.