Hiring The Inquisitive Mind

by Jon Davis 25. September 2008 18:40

You walk into a new contract to perform customizations to the company's proprietary web app. It's a mid-sized web app with a few hundred .aspx files and thousands of .cs files, with a detailed data layer. You're tasked to perform customizations to one of the more complex pieces of the web app, which uses third party controls and lots of code built around UI events.

The boss knows the answer to all questions, but he's only there about a quarter of the time, and when he is there he's only there for a few minutes and then he's gone for at least an hour again.

You want to be on your best behavior, but part of that is proving that you can be very productive. The person who originally implemented the code you're customizing has left the company. There is one fellow developer sitting on the other side of the cubicle. Since the boss is usually gone, you are tempted to ask questions to the other developer, but you know you're only given a few minutes / hours / days' grace to interrupt his/her workflow.

Question: How many minutes, hours or days is it appropriate to ask very trivial questions to the other developer in the boss's absence, such as "What's this object do, it's not obvious and I'm not seeing it referenced anywhere except here where it's updated", "Does the application have XX functionality that I can reference?", or "Do you know what I should do about YY behavior?"

 I asked this question in a "room" filled with fellow developers, and received very contrasting responses:

Answer 1: "Why don't you look at what the 'object' does yourself? 'Do you know what I should do about YY behavior' in my world becomes 'Where are the g**d*** SPECS?'"

Answer 2: "You're asking a really standard question for contract developers. It's really normal for a programmer that is being pushed too hard for fast development by the boss to write crappy code with little documentation and then quit from the pressure hehe. Then they hire someone else to fix the code. The question is, has the boss become more relaxed to allow the developer to do their job, or is the boss still just the boss. No doubt, to form good code, a programmer must never be rushed. But the boss is a boss first. Their duty is to productivity and revenue. There are good and bad bosses. Some bosses also know the employees that they're dealing with, but some are just delegators, not managers. You have to remember, bosses start as employees somewhere and are promoted over time. Some justly, some not so justly. They may or may not have the qualifications to be the boss. If it's possible, just map out the main functions of the program and concentrate on the areas that the boss is asking be reworked first. Try to take a little time each day to add comment summaries to each function if they arent already there. Start small. Over time you'll learn how the puzzle fits together and can address systemic problems then. More than likely the boss is watching you more to see how quickly you can analyze code and be self-sufficient. I'd limit the questions to only what is absolutely necessary with the other workers, hehe. The answer depends on the team and personalities, but [in the scenario you described,] you're too new to make that assessment. For now the answer is 0. Make a friend first."

Answer 3: "We have a mentor program here. New guys get a more seasoned person of their discipline to ask questions and get them up to speed. They also realize it takes anywhere from 3-9 months before the new person is self-sufficient."

When I was a teenager in 1994, I witnessed something that has followed me throughout the rest of my career. My father was going through a difficult period in his life, and he realized it had affected his job, so much so that he knew it was ending. In a discussion with his boss, he asked, "Did you expect me to hit the ground running?!" To which the boss replied, "Yes. I expected you to hit the ground running." This startled my dad, but he realized that his boss was right. And as he shared this experience with the rest of us, I could feel his pain. Even as I write this, I shed a tear or two for him, in memory of his anguish, because tough lessons like that are more devastatingly difficult to learn than anything else. Indeed, we as a family were all the way on the other side of the planet, in Nairobi, Kenya, on behalf of this job. And we had to turn back, and head back to the United States, because of a hard lesson learned.

I've had quite a few jobs in my career. I have sometimes (usually?) managed to show up trying to hit the ground running. And I generally succeed. I showe up being as productive as everyone else on the preexisting team within two or three days. I haven't been able to do that, though, without asking a lot of questions. But in no time flat I would turn around and have a lot of answers, too, that had been lost to the others on the team--I tried hard to make the most of my combination of industry experience and a fresh pair of eyes. Within weeks, I'd pooh pooh years-held workarounds to bugs and come up with better, faster, and more reliable solutions and share them with the team.

 

The more you know, the more you realize how little you know. (And if you don't know that then you're missing out.)

On the practical end, the above line ("The more you know..") shows itself proven when the questions being asked further the progression and involvement of development and deployment. Name any technical lead who is successful without being a great communicator, partly by the spoken word and partly by asking questions and listening to answers in order to forumulate the appropriate solution for the situation.

But I'll admit that on the flip side, asking a lot of questions up front in a new environment and situation makes a person appear unskilled. Personally, I think the opposite is the truth, but most employee folks don't realize it. An inquisitive mind is one who is smart enough to form the question--smart not only in choosing to do so and how to do so, but in knowing what questions to ask in the first place. Such is one who is also often careful not to sit around spinning wheels, which is a waste of not only that person's time but, more dangerously, the company dollar.

The mindset of the person who hates to be asked questions is usually driven by the frustration of being suddenly distracted from their work and having to face someone else's problem rather than their own. Seriously, though, how selfish. I knew a guy made me stand there and wait 5 minutes while he coded and occasionally held up a #1 finger ("one moment" gesture) just so I could get my 15 seconds out of him for an instant-answer question. How much time is lost to the question by the losing track of a chain of thoughts? I tend to think it's about double the time of the question. That said, though, if the question takes two minutes to answer and four minutes to refocus, that's six minutes lost, rather than another 5 minutes on top of it to wait, or thirty minutes lost to wheel-spinning by the asking party.

In my perspective, the most productive teams are the ones where all members are able to openly share the minds of the others, collaborate, and work together, for at least either a few short spurts during the day or for one or two dedicated hours during the day. This as opposed to coding in total heads-down isolation, with the same amount of time as otherwise spent collaborating, spent instead chatting about life and toys.

An IT / networking guy once told me, in the context of this, "What I tell the guys working for me is, 'Do what you can to try to figure out what you can for at least thirty to sixty minutes. If you still can't find an answer during that time, go to a co-worker, and if you still can't figure it out, only then should you come to me.'"

This attitude seems to be shared by many people in the technology industry; however, in the software engineering field, I am thoroughly persuaded that it is flat out wrong.

Do the math!

A) You spend two hours spinning your wheels. You finally reach what you think to be a eureka moment discovering the answer to your problem, but you soon discover that you were wrong. You spend another hour, and another after that, on false-guess workarounds to your problem. In the end, another hour is spent debugging your guesswork workarounds, but it all eventually gets functional, on your own.
Time/pay units wasted: 5 hours. And by the way, you're looking pretty sucky at this point.

B) You spend an hour spinning your wheels. You give up and talk to a permanent employee, who then gives up after fifteen minutes and so you go talk to the manager, who has the solution explained within five minutes. The co-worker loses another 20 minutes trying to get his/her mind back on track to what he/she was working on.
Time/pay units wasted: 2 hours (60 + 15x2 + 5x2 + 20 minutes).

C) You spend five minutes spinning your wheels. You give up and talk to your manager, who has the answer explained within five minutes.
Time/pay units wasted: 15 minutes (5 + 5x2).

Assuming that these scenarios are typical, only one conclusion can be made. From the perspective of the company's and tasks' best interests, there is no better person to have on your team than the one who asks a lot of questions up front. The more skilled individual will ask the more relevant question, not the lesser question. Questions that would solve the problem quickly--such as ideas and proposals in question form--rather than questions that introduce more questions.

Time spent spinning wheels is even more expensive if you're on a contract through a company like Robert Half Technology. Any company hiring through such a staffing firm is going to be paying out anywhere from 10% to 150% on top of what you're making. So when I'm working with an agency and I'm "out on the field", so to speak, as a contractor on a short-term "job" trying to accomplish some special tasks, I am absolutely frightened of spinning my wheels.

Indeed, while some managers would consider the highly inquisitive employee to be "high maintenance", supposedly "high maintenance" employees are proven to be shown to actually be the most valuable subjects of their management.

Incidentally, I don't just ask questions to fix my problems. Sometimes I ask questions to understand, so that I can be self-sufficient beyond the problem. I often ask questions to listen to the answerer's adjectives, word choice, side comments, and back stories. This is very valuable information that can really help in the understanding of the bigger picture and the way things are.

Not only do I feel free to produce questions, though, I also love to answer questions. Questions make me feel needed. They make me feel knowledgeable. They make me feel respected. No matter how extensive, complex, or brainlessly simple they are, and no matter how busy I am, I love it when people pick my brain.

The love of answering questions comes so naturally for me that I forget that other people hate it when I myself ask questions. But after so many jobs where I've been hounded for asking so many questions up front, I've reached some very important conclusions, of which I am beginning to feel strongly about.

1. I need to ask few or no technical questions from peers I don't know very well, because those whose time I am taking feel nothing like I feel when I enjoy being asked questions. Co-workers tend to hate questions like they hate bugs and spam. The manager, on the other hand, should be fully able to either answer the questions or to assign someone to answer questions. The manager's job is indeed to meet your needs. Both of you work for the same company. You don't work for the manager any more than the manager works for you. If the manager doesn't see it that way, and if the manager's refusal to give you his/her time or time with a co-worker is killing your productivity, then it's a crappy job and, if you have the option, you should look for work elsewhere. But if he/she is willing, no matter how intimidating, impose on your manager with questions, not your co-workers.
 

2. Companies and team leaders need to learn to train teams to embrace questions and teach people to enjoy answering peer questions rather than hate them. I don't know what it is that makes me so happy to be asked questions of, but I do believe it's a learnable trait. I'm also quite positive that it's something that can benefit a team and a company at large; I've only seen good come out of it, and the only negative I've seen has been flaring up of feelings and agitation. That, I believe, is correctable.

People need to be trained to be intellectually honest. This is a cultural mindset that says that:

  • It doesn't matter what you do or don't know, your knowledge about proprietary systems is a proprietary company asset that belongs to the company, not to you or to any one individual.
  • Answering questions earns you respect.
  • Admitting you don't know something wins you the opportunity to discover from the questioner's findings.
  • Being a go-to person is a role of leadership that brings you higher up the ladder (unless you refuse to answer, in which case respect goes through the floor).

3. Despite all that I've said, it's okay to put an end to too many questions. If someone is bothering you, it's fine to say, "Hey buddy, I think you're ready to be on your own now, if you have any further questions please save them for the manager." Completely okay. What's not okay is instead putting on a pouty face, making strange noises of irritation, lying through your teeth about how you don't know, and telling the boss that you're unable to get your work done because you're getting pestered. Until you've communicated a request for questions to stop (politely, ideally), that behavior is selfish.

I once had a guy sitting next to me who ignored me for one or two hours straight on a question that absolutely needed about sixty seconds of his time because he and I were the only engineers in the office and my hands were tied, before he spun around and shouted, "I don't f#$%'n know!!" This behavior is uncalled for. If I was a manager and witnessed that I'd fire such a person on the spot, with absolutely no care for what cost. That's beyond rude, it's reflective of a long-growing seed of unaddressed resentment and untrustworthiness, such being the kind of negative growth patterns that can tear a team apart and make it never function normally again until the problem is expunged. But that's just my view on that; I'm the one who got yelled at.

Intellectual Honesty

by Jon Davis 6. July 2008 16:47

In 1998, when I was working at a fulfillment company called K/P Corporation as a web developer, the several offices scattered throughout California routinely held meetings, exchanged e-mails sent both from the bottom up and from the top down, brought in trainers, and even distributed inspirational books company-wide for our enjoyment.

One time after a typical round of corporate meetings and e-mail announcements, the president of the company tried to list a number of key behavioral patterns and attitudes he wanted the company to have. Usually this stuff goes in one ear and out the other--yeah yeah, "work hard", "be respectful", "don't poop in your pants", who hasn't heard this stuff before--one of these things stood out to me, because it was something I wasn't used to hearing.

It was "intellectual honesty -- don't be afraid to share what you know".

I've noticed that not all American cultures behind the doors of corporations have standardized on a philosophy of intellectual honesty over the last decade. I suppose human nature hasn't changed for the better at all since the history of mankind. Time isn't our friend in this regard. Traditional respect has degraded over time. The elderly respectables have been laid to dust, and the brats of yesterday have assumed their roles.

I've been expanding on the term "intellectual honesty" over the years, identifying more and more elements that I think describe what it should really mean:

  • Be unafraid to share what you know.
  • Don't hoard knowledge.
  • Accept criticism about your understanding.
  • Be teachable.
  • Be willing to teach.
  • Be willing to be wrong.
  • Acknowledge correction.
  • Sharing it is as important as doing it.

A lot of this, but not all of it, relates closely with the idea, "seek humility in yourself with everyone below you".

This is an extremely difficult philosphy to follow because it requires you to minimize self and maximize teamwork.

The opposite of intellectual honesty smells a lot like body odor, looks like a giant, dark wolf ("I am a servant of The Nothing!"), and a corporate environment that doesn't encourage intellectual honesty might be described more like:

  • The veteran of proprietary knowledge cannot be fired because he alone understands.
  • Disagreements are intolerable. 
    • The veteran of proprietary knowledge who alone understands the legacy codebase automatically wins all arguments about the newer codebase without consideration of the disagreement.
    • Don't even consider the plausibility of, or answer to resolve, the arguments of the individual who questions the strategies of leadership's new directions.
    • Shun the individual who dares to question authority, even when he does it in a one-on-one private meeting.
    • Don't resolve the occasional serious disagreement by evaluating the premise. Just isolate the disagreer and call him "disrespectful" and "high maintenance".
  • Speak about critical team, technology, or business decisions in hushed tones (".. msh, msh, ...... took my stapler ... shm, msh.."), in a dark corner, of another room, with the doors closed, with no one invited except the leader and the leader's leader.
  • Shun the newer individual who likes to innovate.
  • Send negative "stop wasting time on this" e-mails to any individual who shares new discoveries.
  • No underling grunt could possibly know more about any individual thing than management!

An individual is often intellectually dishonest as a selfish defensive strategy. Often this ugly beast bears its teeth and attacks when people are faced with personalities opposite of their own. People who can't handle someone putting an ounce of emotion into their words often find it very difficult to be intellectually honest. Other people will impose their opinions but will hold their ears and run away when hearing someone share something that differs with their own philosophies, even if what they're hearing is perfectly sensible. This situation is called cognative dissonance, and mastery of pushing past cognative dissonance is one of several important skills used to carry out intellectual honesty, second only after plain and simple humility.

Fear is a huge cause of a lack of mastery over cognative dissonace,

  • fear of humiliation,
  • fear of losing rank,
  • fear of losing respect,
  • fear of losing control, and
  • fear of unplanned changes to scope

Some of these fears are reasonable, but they should all be fought and avoided.

  • A humble person cannot be humiliated for being wrong, because he already accepted that he is not omniscient God.
  • A wise person will recognize that the loss of rank, if temporary, is either unlikely or else probably appropriate.
  • An experienced person already knows that he loses tons of respect if he doesn't practice intellectual honesty.
  • A responsible person recognizes that part of responsibility to "keep things under control" is making sure that everyone who can benefit from knowledge or from correction can benefit (has access to such benefits).
  • An adept and agile person will have prepared, both mentally and logistically, to adjust to changes of scope.

Do I think I'm intellectually honest? That's a bit like asking if I think I'm humble; you can't answer that either way without lying. But it is certainly a philosophy worth striving for. Not to mention the hopes and expectations that an employmentt environment might strive for it, too.

But kudos to the Open Source Software movement and community. While many proponents of traditional Linux and other "dark knowledge to be known only by the sorcerer" are not regarded as such, the notion of "share, and join us as we all strive to improve" seems to be the core philosophy of excellent open source software.

Currently rated 4.0 by 1 people

  • Currently 4/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , ,


 

Powered by BlogEngine.NET 1.4.5.0
Theme by Mads Kristensen

About the author

Jon Davis (aka "stimpy77") has been a programmer, developer, and consultant for web and Windows software solutions professionally since 1997, with experience ranging from OS and hardware support to DHTML programming to IIS/ASP web apps to Java network programming to Visual Basic applications to C# desktop apps.
 
Software in all forms is also his sole hobby, whether playing PC games or tinkering with programming them. "I was playing Defender on the Commodore 64," he reminisces, "when I decided at the age of 12 or so that I want to be a computer programmer when I grow up."

Jon was previously employed as a senior .NET developer at a very well-known Internet services company whom you're more likely than not to have directly done business with. However, this blog and all of jondavis.net have no affiliation with, and are not representative of, his former employer in any way.

Contact Me 


Tag cloud

Calendar

<<  September 2018  >>
MoTuWeThFrSaSu
272829303112
3456789
10111213141516
17181920212223
24252627282930
1234567

View posts in large calendar