Predatory journals stung by Star Wars Hoax

[snowblizz]

Now, I'm gonna defend Trekkin a bit here.

In context, this is the second time Pendell posts about someone hoxing science journals, when that's not exactly the case. In both cases the "science" and "journal" part of it are on decidedly shaky grounds.


I don't entirely agree with Trekkin, and would have expressed myself less.. umm.. forcefully? But, I understand the frustration. Because this is the way predatory "journals" erode the idea in science publishing and hence the fabric of science. And it's huge problem even without the unknowing or willful discrediting of science in general that's going on today. In part by the debunkers, but more so by those who jump on the bandwagon of it, like lazy journalists and those looking for clicks.

[georgie_leech]

Now, I'm gonna defend Trekkin a bit here.

In context, this is the second time Pendell posts about someone hoxing science journals, when that's not exactly the case. In both cases the "science" and "journal" part of it are on decidedly shaky grounds.


I don't entirely agree with Trekkin, and would have expressed myself less.. umm.. forcefully? But, I understand the frustration. Because this is the way predatory "journals" erode the idea in science publishing and hence the fabric of science. And it's huge problem even without the unknowing or willful discrediting of science in general that's going on today. In part by the debunkers, but more so by those who jump on the bandwagon of it, like lazy journalists and those looking for clicks.

Now that I can agree with. Best case scenario, these sorts of things help weaken any influence predatory journals have, and said lack of influence helps raise trust in the scientific community. Alas, there will probably be people who take this sort of thing as an opportunity to go "Bah, look at what "science" believes! Crystal Energy doesn't seem so stupid now does it?"

[pendell]

Well, I have to acknowledge that I have touched a sore point, and I will bear it in mind in future.

On the topic of people skills, everyone knows about the kurfuffle at Google in which that engineer got fired , right? That whole topic is almost entirely against forum rules, so I won't delve into it. Nonetheless, one of the rebuttals, by Yonatan Zunger , who recently left Google, has some close bearing on the issue of people skills in engineering -- and, by extension, in science as well.

What I am is an engineer, and I was rather surprised that anyone has managed to make it this far without understanding some very basic points about what the job is. The manifesto talks about making “software engineering more people-oriented with pair programming and more collaboration” but that this is fundamentally limited by “how people-oriented certain roles and Google can be;” and even more surprisingly, it has an entire section titled “de-emphasize empathy,” as one of the proposed solutions.

People who haven’t done engineering, or people who have done just the basics, sometimes think that what engineering looks like is sitting at your computer and hyper-optimizing an inner loop, or cleaning up a class API. We’ve all done this kind of thing, and for many of us (including me) it’s tremendous fun. And when you’re at the novice stages of engineering, this is the large bulk of your work: something straightforward and bounded which can be done right or wrong, and where you can hone your basic skills.

But it’s not a coincidence that job titles at Google switch from numbers to words at a certain point. That’s precisely the point at which you have, in a way, completed your first apprenticeship: you can operate independently without close supervision. And this is the point where you start doing real engineering.
Engineering is not the art of building devices; it’s the art of fixing problems. Devices are a means, not an end. Fixing problems means first of all understanding them — and since the whole purpose of the things we do is to fix problems in the outside world, problems involving people, that means that understanding people, and the ways in which they will interact with your system, is fundamental to every step of building a system . (This is so key that we have a bunch of entire job ladders — PM’s and UX’ers and so on — who have done nothing but specialize in those problems. But the presence of specialists doesn’t mean engineers are off the hook; far from it. Engineering leaders absolutely need to understand product deeply; it’s a core job requirement.)

And once you’ve understood the system, and worked out what has to be built, do you retreat to a cave and start writing code? If you’re a hobbyist, yes. If you’re a professional, especially one working on systems that can use terms like “planet-scale” and “carrier-class” without the slightest exaggeration, then you’ll quickly find that the large bulk of your job is about coordinating and cooperating with other groups. It’s about making sure you’re all building one system, instead of twenty different ones; about making sure that dependencies and risks are managed, about designing the right modularity boundaries that make it easy to continue to innovate in the future, about preemptively managing the sorts of dangers that teams like SRE, Security, Privacy, and Abuse are the experts in catching before they turn your project into rubble.

Essentially, engineering is all about cooperation, collaboration, and empathy for both your colleagues and your customers. If someone told you that engineering was a field where you could get away with not dealing with people or feelings, then I’m very sorry to tell you that you have been lied to. Solitary work is something that only happens at the most junior levels, and even then it’s only possible because someone senior to you — most likely your manager — has been putting in long hours to build up the social structures in your group that let you focus on code.

...

Anyone can learn how to write code; hell, by the time someone reaches L7 or so, it’s expected that they have an essentially complete mastery of technique. The truly hard parts about this job are knowing which code to write, building the clear plan of what has to be done in order to achieve which goal, and building the consensus required to make that happen.

All of which is why the conclusions of this manifesto are precisely backwards. It’s true that [employee subset] are socialized to be better at paying attention to people’s emotional needs and so on — this is something that makes them better engineers, not worse ones. It’s a skillset that I did not start out with, and have had to learn through years upon years of grueling work. (And I should add that I’m very much an introvert; if you had asked me twenty years ago if I were suited to dealing with complex interpersonal issues day-to-day, I would have looked at you like you were mad.) But I learned it because it’s the heart of the job, and because it turns out that this is where the most extraordinary challenges and worthwhile results happen.

Bolding mine and some moderate editing to remove the more controversial parts which might trip the forum filters. But he's right; once you get past the lowest levels of engineering -- definitely true for me at CACI and Honeywell -- you simply don't have the option of not dealing with people. You can't simply dismiss the non-engineering PHB types because they are the ones who pay your bills and buy your product. Once you're working on a project that is bigger than one person, social skills, consensus-building, become paramount. If you're one of the few who can be put in a cave and left alone to work for days on end, it's because someone else, probably your manager, is doing all the social stuff for you. That's not exactly the fast track on the promotion path.

And if people skills are critical for the job, then outreach and so forth, silly as it is, is important practice for dealing with people.

That's how it is in software engineering. Is it really different in the hard sciences?

ETA: Actually, I've learned from this. Because the mistake the original manifesto author made is the one I made by re-posting these articles on journals being caught out by deliberate fraud. Although I meant it innocently, the implication was that a number of scientists -- including readers of this group -- are no good at their jobs. And that enraged them.

If we were working at the same organization, I'd be responsible for the lost human-hours and emotional energy lost as a result, and be partly responsible for the damage control. The important thing is to remain focused on the mission, and if you're expressing or even implying that a subset of your fellow employees are no damn good at their jobs, well, you're hurting the organizations mission. Probably more than you can ever make up for by your ordinary work in the course of your duties.

It is a lesson in people I shall not forget.


Respectfully,

Brian P.

[Rockphed]

Bolding mine and some moderate editing to remove the more controversial parts which might trip the forum filters. But he's right; once you get past the lowest levels of engineering -- definitely true for me at CACI and Honeywell -- you simply don't have the option of not dealing with people. You can't simply dismiss the non-engineering PHB types because they are the ones who pay your bills and buy your product. Once you're working on a project that is bigger than one person, social skills, consensus-building, become paramount. If you're one of the few who can be put in a cave and left alone to work for days on end, it's because someone else, probably your manager, is doing all the social stuff for you. That's not exactly the fast track on the promotion path.

And if people skills are critical for the job, then outreach and so forth, silly as it is, is important practice for dealing with people.

That's how it is in software engineering. Is it really different in the hard sciences?

Respectfully,

Brian P.

Every job I have had in engineering required someone to figure out how to deal with people. At my most recent job, it was mostly the project manager who did the dealing with the customer, but the engineering lead had to interact with people from all over the company (the project manager, the rest of the engineers, the other types of engineers, the tool builders, etc.) and being diplomatic about that made things run much smoother. If you were pleasant and nice, people agreed to try it your way and offered helpful suggestions. If you were aggressive and demanding, people told you that it was your problem and that you had to fix it (even when it really wasn't and they could have fixed it with minimal effort).

As far as I can tell, working in the hard sciences is even worse. Not only is there still a large component of interpersonal interaction required to get the nominal work (SCIENCE!!!) done, but for results to be promulgated properly someone has to be personable and convince other scientists to get on board. Yes, in science quite a bit of that convincing is done by presenting data that refutes opposing views, but some is also required to get competing projects to instead support each other. Case in point: there are 3 groups of astronomers looking for gravity waves by looking at pulsars. Up until the LIGO detection of gravity waves a year ago they were all competing and not sharing data or methods (there was a Nobel prize on offer for someone detecting gravity waves after all). Since the LIGO detection, they have engaged in much more data and method sharing.

Another case in point: the scientists I am working with recently had a meeting about a very large, very pending project. At the meeting was a representative for a competing project that is experiencing budget troubles. Said representative is normally very diplomatic in his attempts to get people to stop backing the new project and just write him a check for his project. At the meeting, he made several barbed and snide comments about the people at the meeting. The general consensus among people at the meeting was that he was grumpy because his budget had been slashed, again, so the science justification for his project was getting very thin.

[Misereor]

If we were working at the same organization, I'd be responsible for the lost human-hours and emotional energy lost as a result, and be partly responsible for the damage control. The important thing is to remain focused on the mission, and if you're expressing or even implying that a subset of your fellow employees are no damn good at their jobs, well, you're hurting the organizations mission. Probably more than you can ever make up for by your ordinary work in the course of your duties.

Very much worth keeping in mind.

*Like*

[Telok]

Thoughts on Reproducibility

That was posted yesterday, it's a very relevant comment on the effect of the trash journals and fraudulent publications among the people who actually do the science.

Essentially it comes down to there being three 'tiers' of publisher, the junk, the staid and unexciting basic and normal journals, and the big names. People actually doing something with information from these journals ignore the junk, because it's not useful to them. The primary impact the trash journals have is to boost publication numbers in automated searches.

Also, you may want to check out his "Things I Won't Work With" section. There's some pretty funny stuff in there.