- Joined
- Feb 9, 2013
Unfortunately, this is sorta his wheelhouse for the time being.Is there a supervisor or anyone to rein in the pajeet incarnate? This is not even specifically python fuckery, it's not language-specific to know to not raise "errors" that are not errors. A 404 isn't even an error class in commonly used python http packages, it's an attribute value on a successful response. Errors are things like Internet Lumberjack activity, or AIDS in the pool. (I'd make something to catch the "expected" 404, too, to better tell them apart from when whatever it is that you're scraping fucks with their urls.)
We started off this project with a django project that he was responsible for and the django project used celery to launch jobs that I wrote and I was responsible for.
Now gradually my jobs are being folded into his project and I'm having to work with all the nonsense that he wrote already.
At some point I'll propose some big architectural PRs to clean up his existing code, but I'm just really not in the mood for it this afternoon, I guess.
Like our storage module is really sloppy and there's a lot of automagical assumptions in it. I'm sure it's convenient if you're both the author of the module and its sole client but that's changing now.
Yeah, I have a similar attitude. I've written a lot of code that is superficially sloppy and looks like it's completely devoid of checks, but I've already done all the checks up front in the main entrypoint.My "junior" coworker sometimes errs on the opposite end of the scale and adds retard insurance against crashes where it's not needed. For example, I would not be adding a runtime check for or forcing a datetime to be timezone-aware. The one thing I do check for is whether a reusable function that's meant to run in a database transaction (but will "successfully" run and corrupt data outside of one) does in fact run in a database transaction.
It's like that joke:
“The patient says, "Doctor, it hurts when I do this."
The doctor says, "Then don't do that!”
I make it productive by insisting (even if just to myself) that there's some really obvious visual identifier that indicates something's special about the function. Extra underscores in the name or some special keyword in the name, things like that.
Since I've been doing more python at work for the past few months, I prefer to import the module and use it as the prefix, and I avoid doing
from foobar import blah_blah_blah
, unless blah_blah_blah
has very clear name, and it's still understandable thousands of lines away from the top of the file.