Worked the first six years of my career using no version history tracking or backups at all on one of our main systems. Nobody knew we didn’t have backups and I didn’t know how to use git and figured it wasn’t so important since I was maintaining it alone anyway.
I dunno about OP, but I am, and I have definitely prioritized tickets based on how interesting they sound.
User setup for a new hire that is already here and waiting? Meh. Weird network problem with no apparent solution which will likely require days of investigation? Sounds good.
Doesn’t that construction only work in categories that also contain their own morphisms as objects since a profunctor maps (Cᵒᵖ × C) → Set and not the same like (Cᵒᵖ × C) → C? Since the category of Haskell types special, containing its own morphisms, so the profunctor could be like (haskᵒᵖ × hask) -> hask? or I just don’t understand it.
Hom functors exist for locally small categories, which is just to say that the hom classes are sets. The distinction can be ignored often because local smallness is a trivial consequence of how the category is defined, but it’s not generally true
I have to say, I’m getting more and more frustrated by the bad code I have to write due to bad business circumstances.
I want clean, readable code with proper documentation and at least a bit of internal consistency and not the shoehorned mess of hacks, todos and weird corner cases.
Don’t just put “TODO”. If they’re in the final pull request, they need to mention a ticket that’s intended to fix that TODO. If you/your team decides it’s not important, then remove it and close out the ticket. Either way, you’re required to do something with it.
programmer_humor
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.