Wait... WHAT??
Who the hell copy pastes code into their program without first examining and understanding what each step is actually doing, how and why the pieces fit together as they do, and how it works as a whole to solve the problem?
Wait... WHAT??
Who the hell copy pastes code into their program without first examining and understanding what each step is actually doing, how and why the pieces fit together as they do, and how it works as a whole to solve the problem?
Almost everybody at some point or another?
https://marketplace.visualstudio.com/items?itemName=matsz.pa...
He got shit done and that was what mattered to his bosses... of course it was all a steaming pile of unmaintainable garbage but that didn't matter to anyone.
If he couldn't find it on Stackoverflow he would ask another developer who would tell him how to do it... then Mr Senior Developer would ask that other developer if he could just "send him the code".
Last I heard he's still at that company and still making bank doing nothing but copying and pasting other people's work.
The developers of Docker for Windows and the Razor Synapse driver management tool. Among others.
The people who write the software that runs the airplane you’re on.
Has anyone about 40 lines of code with an average line width of 80 characters? I have this rather spare region that doesn't look nice on the mini map.
But seriously, I think the reasons are mundane and developers often have an ample list of problems to solve, so easy solutions for some of those are used as much as possible. Ensuring only one process runs at a time is probably just a feature that invites negligence.
It shouldn't happen, but I am not surprised.
Usually have to dig in all the responses to get a balanced overview, then apply those concept(s) to your problem at hand....
It's been raised with management, and nothing has been done about it.
Quite a lot of people do that. It's pretty much the reputation of Stackoverflow. And of course everybody knows it's bad, but it saves time and it works and there's deadlines so they move on and ship it to production.
How to find this particular bug is not that hard, though: you're looking for a way to ensure that your program can run only once, so you use that mutex. But you want to be sure that mutex is unique to your program and not shared with others that use the same method, so you create another program that uses the same method and test if they conflict. If they do, then your mutex is not unique to your program.
Unfortunately, if they don't, you only know that there exists one program which does collide with your app's mutex. Nothing more, nothing less.
> But you want to be sure that mutex is unique to your program
This one's actually impossible to test. Or to be pedantic, we know it can't be done - another app can be using your app's guid for its mutex, but in realistic cases, it's just really hard to test for. There could be even a real use case for collision - independent agents walking the process tree and relying on locks based on guids to not step on each other.
The trick of it is, it's only "bad" if you care about code quality and/or maintainability, fuzzy attributes which are seldom measured or optimized for. It's the only logical conclusion to "move fast and break things."
p.s. - the good news is, most of us are working on software that doesn't really matter terribly much, so the fact that it's bad also doesn't matter very much
Millions upon millions of people learning via googling
But yeah hopefully not in production & ideally sandboxed