This week’s “Ask a ScienceBlogger” is an interesting one, but *very* tricky to answer.
The question was proposed by fellow SBer [Dave Munger:][munger] **”What’s a time in your
career when you were criticized extremely harshly by someone you respect? Did it help you or
set your career back?”**
[munger]: http://scienceblogs.com/cognitivedaily/
I have to tread carefully while answering this one. It’s a good question, but it involves people who *could* be reading the blog.
Overall, I’ve been remarkably lucky in my career. For the most part, I’ve had excellent
mentors who’ve been kind and helpful, and I’ve done my best to listen to them, and not
screw things up badly enough for them to really tear into me. But no one in a research career can escape complete unscathed. So I’ve got my own war stories of the ways that I’ve been shredded. And the effect/outcome has varied enormously.
### Grad School: Finding the Right Research Community
The obvious place to start is grad school. Back then, I was doing work in parallel computing.
The particular area that I was focused on was what’s now a very hot topic called [“grid
computing”][grid]. At the time, thought, it was very much *not* an area of interest. Back
then, the big interest was in massively parallel supercomputers, and how to compile
numerically intensive array-based code so that it could take advantage of the superfast
hardware. But I didn’t care. I wanted to do what I wanted to do. And the result was that
it was almost impossible for me to publish my work.
I got some positively *brutal* reviews. What was depressing about that wasn’t just the negativity of the reviews, but the sheer *pointlessness* of them. They weren’t really criticizing the quality of the work – they were judging it as something that it wasn’t: everything parallel was viewed through the lens of array-based supercomputing, and my work
was not intended as that, and it was terrible for it. It got to the point where the last
paper I submitted in grad school repeated the phrase “While this does not perform well on
numerical array based code, that is not it’s intended problem domain” in no less than **six** different places in a ten-page paper. And still came back with a rejection where the reviews basically said “Yeah, but it doesn’t work on numerical array based code”.
What did I learn from that? As a researcher, you’re a member of a community. You need to
consider the community when you’re doing the work. That doesn’t mean doing things that you
think are irrelevant, but it does mean that *framing* your work so that it fits in with some
community is an absolutely essential step. I could have done nearly the same work, but
presented it in terms of distributed computing rather than parallel computing, and fit nicely
into the distributed programming community. It would have amounted to taking the research
agenda I was interested in, and reordering it a little, but that wouldn’t have been a big
deal. But because I believed in it as parallel computing, I insisted on publishing it in the
parallel programming community, and got burned as a result. I don’t mean to say that the
right way to be a researcher is to pile on to whatever is hot and trendy today; but rather that you need to understand research communities, and learn how to frame your work so that it will be seen by the people who will appreciate it. When I was in grad school, the kind of work
I was doing simply *was not* of any interest to the parallel programming community; trying to
force them to look at it was a waste of my time. But there were communities that would
have been very interested in it, had I taken the time to learn about them and present it to
them in the correct way.
### Work: Standing Up for Myself
I’ve got two other stories about being harshly criticized that I think are interesting; both led to the same conclusion, but in very different ways.
At one point not too long after grad school, I worked for a manager who was very manipulative.
He constantly tore me down, criticized everything I did, shredded every idea I proposed, and
generally tried to make me believe I was an idiot, so that I would quietly and meekly do
whatever he wanted me to do. It was a horrible experience; I already had a tendency to be
insecure, and being told day in and day out that *every* idea I had was ridiculous, every line
of code I wrote was terrible, every word that came out of my mouth was stupid just reinforced
that.
I eventually got out of that situation through nothing more than pure luck, and under the
tutelage of my new manager, learned that I wasn’t an idiot, that I could have good ideas
sometimes, and that I had to be able to stand up for myself. What I learned from the new
manager was that there is no excuse for that kind of abuse – not for the manager dishing it
out, and not for the managee taking it. There will always be asshole managers – but an abusive
manager/employee relationship like that can only exist because *both people* allow it to.
In my case, even if I truly *were* as stupid and awful as that manager kept telling me I was,
that’s no way to treat an employee. A *good* manager with a poorly performing employee should
either work with them to improve their work, or fire them. And a good employee should know
that as well, so that if their manager is treating them as a poorly performing employee, but
not doing anything to help them improve, they need to stand up to the criticism, and do what’s
necessary to fix things *for themselves* – either by confronting the manager, by taking the
matter to an higher level manager or ombudsman, or by quitting and finding a different job.
The last little story of criticism is the happiest one. It involves the same good manager who
I worked for in the second half of the previous story. After I’d worked for him for several
years, and my third project for him was finishing up, I wanted to get into something called
software configuration management. He was absolutely opposed to my doing that; he said that
there was simply *no way* that I should waste my time running down that rat-hole. And that
made me reconsider. But I’d learned from my earlier experiences. I spent some time looking at
the problem, looking at research communities, and looking at communities inside of the
company, and I was *still* convinced that getting into SCM was the right thing to do. So I
put together all of the information I’d gather into a research plan, and convinced him to let me spend at least *some* of my time working on it. He ended up getting
promoted to another job, and transferred me to yet another manager, who ended up being the
best manager I ever heard; the work that he’d initially discouraged, but grudgingly let me try
turned into the best work I’ve ever done, and 10 years later, I’m still working in SCM, and loving it.
But as happy as I am with where I wound up, I’m very grateful for that criticism that he
gave me. He was right that getting into that area was *not* going to be an easy task.
His criticism made me take the time to really methodically think it through: to think about the communities that I needed to work with, to think about the best way to frame the work, and to carefully plan out the right way to approach and prioritize the work. There’s no way that
I would have been as successful in my new area if he *hadn’t* forced me to do that.
I’ll be starting on a new project towards the middle of next year (but still in SCM), and
I’m going to attack my ideas and plans in exactly the way that I had to do to convince
that manager to let me work on that old project. It was the right way to approach
a new piece of work. I didn’t know that before, but his *constructive* criticism,
while harsh, was absolutely appropriate, and taught me something that I really needed to know.
[grid]: http://en.wikipedia.org/wiki/Grid_computing
First, I hope your dad is doing better. Second:
This brings to mind a quote attributed to W. Edwards Deming (though I can’t find a written attribution at the moment, and I’m paraphrasing). After giving one of his lectures on management, an audience member complained that Deming hadn’t addressed the issue of how to handle all the deadwood in his company. To which Deming replied, “Did you hire them that way or did you kill them yourself?”
By the way, any posts you might make on SCM would be appreciated by at least one member of your reading audience.
Johnny:
Thanks for the good wishes. My father is doing better. It’s going to be a long recovery, as he learns how to maneuver minus one leg, but it sure beats the alternative!
I like the Deming quote. That basic idea has had a huge impact on my own idea of what management is about. Before I got into industry, I thought that the job of a manager in a research lab was primarily bureaucratic: budgets, planning, etc. But since then, I’ve learned a whole lot: manager’s do get stuck doing a lot of bureaucratic nonsense, but that’s not the important part of their job. The important thing is all about people: understanding what people are good at, how to make sure that they focus on something that they’re good at and which is also good for the company; how to recognize someones weaknesses, and help them improve them enough that those weaknesses don’t hold them back. A manager who just criticizes his/her people for not being good enough is a bad manager. Dead-wood employees are either people who should never have been hired, or who’ve been *taught* to be dead-wood by bad managers.
Oops, and I forgot to say. Part of my agreement with my employer that allows me to write this blog is that I have to keep work and blog very separate. So there’s no way I can write here about SCM, or anything related to it.
What I can do, finally, is give an indirect pointer to what I work on. If you do a google search on “jazz” and “eclipse”, you can find some articles about public demos of the system I work on. It’s not the way I would have chosen it to be in all aspects, but it’s closer to my idea of what a system should be than anything else I’ve ever seen. I’m very proud to be a part of it. And that’s all I can say here :-). Next year, when I transition back to full time research, I’ll probably try to set up a work blog, and then
maybe I can say more.
What I learned from the new manager was that there is no excuse for that kind of abuse – not for the manager dishing it out, and not for the managee taking it. There will always be asshole managers – but an abusive manager/employee relationship like that can only exist because both people allow it to.
Small comment on this: I don’t think this is a fair criticism on the employee if he/she is relatively new to the adult world and hasn’t yet learnt a good perspective on such matters and how to stand up for him/herself. Some of us are not born (or brought up) with feistiness and natural assertiveness, and when an abusive situation is all you’ve known, it does take a while to see a perspective from outside the situation, realise that this shouldn’t be happening, and figure out something constructive to do about it.
SharonC:
A mistake made because of lack of experience is still a mistake :-).
I don’t mean that as an excuse for not having sympathy for
someone in that kind of a work situation, or as a way of tearing down someone in a bad situation even more. What I was trying to say is just the kind of thing that my better managers have taught me: that there *is* something you can, and in fact *should* do in an abusive work situation.
The reason that I was in that situation was because I’m definitely *not* a naturally assertive person, and I didn’t have the experience to realize what *I* was doing wrong. I definitely knew that the manager was mistreating me, but I didn’t understand that (a) there was anything that I *could* do about it, and (b) that in that situation, I *should* do something about it.
But what I learned from it is not just that the abusive manager was an asshole, but that *I* played a role in allowing him to abuse me. And maybe someone with an asshole boss will read this, and realize that they *don’t* have to take it.
And SETI@Home is doing absurdly huge numerical computation in a distributed way.
One idea i had in the early days of SETI@Home was that a room full of 486/33’s (which would otherwise be discarded) could perform useful work en masse. A simple benchmark proved this absurd. It took 27 486/33’s to equal one Pii/350, a machine which was already obsolete by a factor of five.
But, a 486/33 can do things it could always do. Like run without a CPU fan, send and recieve faxes, etc.
Stephen:
My idea at the time wasn’t to try to combine old machine. I was a sysadmin at the time, and we installed this beautiful new network of top of the line sparkstations. What bugged me was that here we had 8 of these machines in the grad office, and *most* of the time, 7 of them were being used for either emacs or netnews, which used less that 5% of their CPU. But then someone would go and do something complicated, like one of the AI students running a huge machine learning experiment, or one of the compiler students trying to do a large interprocedural register allocation experiment, and they’d peg the CPU of their machine for an hour. Those kinds of things aren’t numerical, but they *are* highly parallelizable. So why should they have to sit and wait for an hour for their test to run, when there are 7 nearly idle machines sitting and doing pretty much nothing? I wanted to do small scale parallelism for non-numerical apps to take advantage of all of that wasted CPU. And what I created for my dissertation was a combination of language and compiler that could get you speedups of something on the order of 3x by using idle CPU on a bunch of workstations. 3x speedup by distributing among 8 processors was garbage by the standards of the numerical computing community; it certainly wasn’t worth the trouble for computation fluid flow, or anything like that. But for the person waiting an hour per run, getting it down to 20 minutes *was* a big deal, and (at the time) no one else had proposed any way of doing it that wasn’t prohibitively difficult for the programmer. The key to my system was that it required very little programmer effort to write their code in a parallel fashion, and then provided a hefty speedup.
I once was about to take an academic position that would have been really awful, but I was too young and too starry-eyed to realize it. My advisor and another professor at that time staged something like an “intervention” and essentially ordered me not to take it. Indeed something MUCH better came along. It was a little shocking at the time, but I’ll always be grateful for that.
Why do I have roughly 2,400 publications (including prestigious edited on-line sites such as OEIS and MathWorld, but not blogs), presentations, and broadcasts to my credit? In part BECAUSE of the 5,000+ rejected submissions along the way.
Getting work rejected is a worst harmless, as it is not really about you or your work, but the dynamics of the market and the mood of the editor. You have to condition yourself to resubmit within 24 hours.
Getting a rejection with an acual reason, even if only a phrase scribbled on a rejection slip, let alone an actual email or letter, is tremendously valuable.
The mode of the set of responses is the null set. Typically, submit a poem, or story, or screenplay, or song somewhere (let alone a technical paper) and the response is almost always useless silence.
Was it Emily Dickenson who said that submitting a poem and waiting for a response is like dropping a flower into the Grand Canyon and waiting for an echo?
Poems are not the same as math papers — but not as different as you might think. Poetry and equations are maximally compressed, compared to vernacular prose.
Deming’s comment on dead wood is interesting, but dodges the question. There are some we hired by accident; to some extent, it’s our fault, but the only way to avoid hiring losers is to avoid hiring entirely. Some people seem great until you have them in the office day after day and discover that they’re not pulling their weight. It’s just that no test has 100% specificity (no false positives), and those that come close have lousy sensitivity (lots of false negatives, meaning you miss hiring good people).
You can try to do better, but perfection is unattainable. So you’ve hired a loser. What now?
The other category, “killed them yourself”, is also making a false assumption. As time goes on, the world changes, and some people don’t change with it. I may have a guy who’s a complete whiz at making paper catalogues, but is making a complete mess of our web site, and I can’t seem to train otherwise. He’s not dead wood because something I did killed him, but because my needs have changed and he’s unable to change with them.
Again, perhaps I could improve my training efforts, but I can’t achieve perfection. I have a person doing a job that no longer needs doing; that’s dead wood.
Finally, even if the problem is entirely my fault, and my primary problem is the practices that produce dead wood, that doesn’t mean that the problem doesn’t still need solving. I screwed up. I will try not to screw up again. But I still have to deal with the situation that my screw-up created.