last day (23 days later) » 

11:20
11
Q: Could producing a grave bug that made headlines make you unemployable?

Danubian SailorDoes producing such a grave bug like Log4Shell make you effectively unemployable? The characters of the drama have committed under their real names, and taking into account how prominent the bug is, it's easy to assume that every potential employer googling for candidate's name will learn that th...

It's worth noting that we're talking about volunteer work here and not something someone did at their job.
@BSMP yes, but the fact that you aren't paid for something doesn't make you not responsible. Giving an extreme example, the 9/11 hijackers were technically speaking, volunteers.
I wasn't saying anything about responsibility. But just as you included a note about the severity of the issue for non-IT people, I think it's worth explaining that the problem isn't related to someone's paid work, because that might affect the answer. It's also worth noting that this is an open source thing and that's how/why knowing folks real names is a thing. In most circumstances, the name of the individual people responsible for an error wouldn't be public.
"Does producing such a grave bug like Log4Shell make you effectively unemployable?" - No.
Also, I don't think we should call it a bug. It is a feature that is incredibly dangerous, and works exactly how designed.
It's probably pretty unlikely that anyone hiring you would even know you wrote that specific code. They would probably just notice that you contributed to an open source project and think that's a good thing. They probably won't go looking at all you individual commits over the last 20 years.
I remember someone saying to me like this "Fire you because you make a mistake that costs x amount of money? that means we just trained you, costing that amount of money, and to just let you go after that equals wasting that amount of money for nothing"
Your assumption that senior devs never make simple errors is also not correct. Everyone makes errors, it's how you deal with those errors that matters more.
ojs
ojs
It could be argued that designing a feature like that, ignoring all criticism and then not documenting it because it would draw more criticism and make everyone abandon the library is worse than producing the bug by accident.
@ojs Out of interest, I am aware that it was designed and implemented as desired, but is the feature undocumented, and was it criticised when suggested? Do you have links for that?
ojs
ojs
11:20
@GregoryCurrie I don't have any links, but I have used Log4J in the past, read the documentation and didn't notice this misfeature. Fortunately we switched to Logback. As for criticism, several places where I have worked had this rite of passage that the product has a terrible design, which every new employee notices and calls out. They are then told that it is intentional, originally invented by company founder or someone who's now an important manager and absolutely can't be changed. I doubt Log4j is different.
My first boss 15 years ago or so told me "only those who work make mistakes", puts things in perspective.
Contributing to big software projects (be they open source or not) pretty much CAN make you unemployable, but the methods are different. Bugs happen and everyone knows that. What's more, the Log4J vulnerability is a design bug and not a coding bug, so the individual developers pushing it in the repository are not necessarily the ones to blame.
 
5 hours later…
16:38
@encryptoferia I think this is the sunken cost fallacy. The training cost and the cost of the mistake are already gone. A history of costly mistakes implies a risk of future mistakes, and that risk may not be worth taking. That said, it takes a lot for that to happen and people shouldn't be fired unless it's a significant error.
 
2 hours later…
18:55
@BSMP Re revision 3, just FWIW: as a non-IT person, the new last paragraph is all IT jargon to me, as terms like "critical security vulnerability", "logging library", or "open source and commercial projects" make my eyes glaze over. The comparison about drunk driving and summer tyres is much more understandable to me, although obviously I can't comment on the accuracy of the comparison.
19:32
Unfortunately, the comparison is more about the OP's opinion on the behavior of the developers and not the seriousness of the issue.

I did find an article saying that they've seen people try to use this to deploy ransonware. Would that make the problem clearer?
19:49
@Randal'Thor I would have liked to list specific software that's affected but it seems that part of the issue is that so many things use it (and it isn't immediately obvious whether something is vulnerable) they don't even know the scale of it yet.
@Randal'Thor If I understand the problem correctly, it allows malicious parties to run their own code on your server. So a better metaphor might be leaving a spare key to your house where anyone can see and get to it.
@BSMP I don't know what ransonware (ransomware?) is either. Maybe an analogy is the way to go, but that's going to be inherently more subjective than a direct description of effects.
@BSMP So basically the tech version of this other recent HNQ? :-)
@Randal'Thor Ransomware: nbcnews.com/news/…
@Randal'Thor Yes, though I should let someone who thoroughly understands the bug explain it at this point. Maybe one of the folks who posted an answer.

  last day (23 days later) »